新言語を開発したい

**デフォルトの名無しさん** · 2010/05/30(日) 21:52:01

http://pc12.2ch.net/test/read.cgi/tech/1274015781/l50 の継続スレのかたわれです。
低水準言語にこだわる人は「低水準言語を開発したい」のほうへどうぞ。

**デフォルトの名無しさん** · 2012/11/04(日) 17:24:12.16

>>305
それはオーバーロード

**デフォルトの名無しさん** · 2012/11/04(日) 22:55:33.65

>>310
お前の使って言語は型推論もしてくれないようなクソ言語なわけだ

**デフォルトの名無しさん** · 2012/11/04(日) 23:20:07.69

型だけ違ってアルゴリズムが同じコードを
コピペしまくった方がメンテしやすいとは
>>310は面白い奴だなぁ

**デフォルトの名無しさん** · 2012/11/04(日) 23:35:28.72

>>314
そこで void * ですよ

**デフォルトの名無しさん** · 2012/11/04(日) 23:40:56.78

型安全なコードより
キャストを使ったコードの方がメンテしやすいとは
>>310は面白い奴だなぁ

**デフォルトの名無しさん** · 2012/11/05(月) 00:50:23.41

そこで始原クラス
class Object
ですよ

**デフォルトの名無しさん** · 2012/11/05(月) 01:14:51.74

Objectも元の型に戻すのにキャストいるだろw

**デフォルトの名無しさん** · 2012/11/05(月) 02:54:14.83

幸せなやつばかりでいいな。

多相型を使っても使わなくても、ポリモーフィズムは実現できるし
メンテしやすいように書くこともできる。

しかし、よりメンテしづらいものを書けてしまうのが多相型。

共通する動作を1か所にまとめ、異なる動作をする部分は別々に記述する。
これが、バグを作り込まないための言語としてあるべき姿。

異なる部分が、共通する部分の中に取り込まれる形では
（プログラムの正しさではない）仕様の正しさを人間が検証するのに不向き。

お気楽プログラムしか書かないなら気にしないんだろうけど。
いや、そういうのしか書かないなら本当に気にしなくていいことだよ。

**デフォルトの名無しさん** · 2012/11/05(月) 05:10:38.83

内容がない文章だな。
俺が反論を書いてやろう。

多相型を使っても使わなくても、ポリモーフィズムは実現できるし
メンテしやすいように書くこともできる。

しかし、よりメンテしづらいものを書けてしまうのが多相型を使わない方式

共通する動作を1か所にまとめ、異なる動作をする部分は別々に記述する。
これが、バグを作り込まないための言語としてあるべき姿。

異なる部分が、共通する部分の中に取り込まれる形では
（プログラムの正しさではない）仕様の正しさを人間が検証するのに不向き。

お気楽プログラムしか書かないなら気にしないんだろうけど。
いや、そういうのしか書かないなら本当に気にしなくていいことだよ。

**デフォルトの名無しさん** · 2012/11/05(月) 05:11:49.36

なぜこのような反論が成り立ってしまうかというと
>>319に”理由”が書いてないからだ。

理由がなくて主張だけするのであれば、
ほらこのように言葉を入れるだけで成り立ってしまう。

**デフォルトの名無しさん** · 2012/11/05(月) 05:18:15.45

>>319は次レスするときは、
多相型を使った場合と、使わなかった場合の
実装例を出すべきだな。

それ以外に反論する方法はなかろう。

**デフォルトの名無しさん** · 2012/11/05(月) 16:45:44.46

荒らしと思われると困るのでレス無用だが、現金より強力な最強プログラミング言語を拳固以外で何かあれば手に入れたい。

**デフォルトの名無しさん** · 2012/11/06(火) 03:14:21.92

反論になってないものに反論することは出来ないし
俺も困らないからどうでもいいや。
少なくとも俺の作ってるのには含まれない機能だしね。

**デフォルトの名無しさん** · 2012/11/06(火) 07:19:46.53

int用リスト、double用リスト、string用リスト、その他ユーザ定義型用リストを作って
それぞれにsort関数書く方がメンテしやすいんですよね？www

**デフォルトの名無しさん** · 2012/11/06(火) 08:23:12.14

多相型ってパターンマッチングとかで使うものじゃなかった？
今話されているような使い方されることもあるの？

C++0xにconceptが入らなかったことが悔やまれる

**326** · 2012/11/06(火) 08:50:05.39

326のことは忘れてください

**デフォルトの名無しさん** · 2012/11/06(火) 13:19:39.00

＞312
多層型を実現するのにオーバーロードを使ってるんだろ。
ソート関数いくつも書くより比較演算子をオーバーロードした方が楽だって事。

**デフォルトの名無しさん** · 2012/11/06(火) 19:44:16.39

Parametric polymorphism
Inclusion polymorphism
Ad-hoc polymorphism

全部違うものなのに、区別しないで議論しても仕方ない

**デフォルトの名無しさん** · 2012/11/06(火) 19:57:09.25

何を言っているのかわかりづらいので、
Adhoc polymorphism
Parametric polymorphism
Subtype polymorphism
という用語を使って話してもらえますか？

オーバーロードというのは、型ごとに別の定義を持つ(組み込みのものを含む)
adhoc polymorphismのことを言っているということでいいですか?

**デフォルトの名無しさん** · 2012/11/06(火) 19:57:50.51

>>329
めっさかぶった！w
inclusion = subtypeね。

**デフォルトの名無しさん** · 2012/11/06(火) 22:01:55.60

>>328
とりあえずソート関数の型を書いてみようか

**デフォルトの名無しさん** · 2012/11/06(火) 23:35:26.36

sort[T <: Comparable] : Seq[T] => Seq[T]

**デフォルトの名無しさん** · 2012/11/07(水) 00:01:27.20

sort :: Ord a => [a] -> [a]

**デフォルトの名無しさん** · 2012/11/07(水) 00:03:29.58

haskellはList限定なのね

**デフォルトの名無しさん** · 2012/11/07(水) 00:10:16.25

コンテナの中身は多相型で、sort関数自体は
List, Seq, ByteString などでオーバーロード的に定義されてる

**デフォルトの名無しさん** · 2012/11/07(水) 00:17:28.72

あ、ごめん
オーバーロード的に、は嘘だった

**デフォルトの名無しさん** · 2012/11/07(水) 00:59:02.84

>>335
配列対象だとモナらないといけないので型もSTな感じに変わってくる。

**デフォルトの名無しさん** · 2012/11/08(木) 08:11:00.12

オブジェクト指向と関数型、静的型とRubyのような簡潔さ
JVMならどこでも動くポータブルさとJavaの豊富なコード資産

思いつく限りの良い性質を取り入れたScalaが
残念な言語になったのは何故だろう？
良い性質を取り入れるだけでは新言語は良くならないという事か

**デフォルトの名無しさん** · 2012/11/08(木) 10:01:45.79

scalaは型システムが一般人向きじゃない。

**デフォルトの名無しさん** · 2012/11/08(木) 18:11:07.19

>オブジェクト指向と関数型、静的型とRubyのような簡潔さ
>JVMならどこでも動くポータブルさとJavaの豊富なコード資産

この2行だけだと、「思いつく限り」という程いい点が多いように思えない。

**デフォルトの名無しさん** · 2012/11/08(木) 18:36:01.32

Ｊａｖａっていう名の知れたものの資産ぐらいだね。
それもそんなにあるかどうか・・・

**デフォルトの名無しさん** · 2012/11/09(金) 01:33:02.45

やっぱりRubyのような機能を
取り入れたのが失敗のもとなんじゃないですか？ｗ

**デフォルトの名無しさん** · 2012/11/09(金) 10:40:19.66

Javaがコード資産ないという評価だと、ほとんど全ての言語はアウトだな。

**デフォルトの名無しさん** · 2012/11/09(金) 11:55:35.81

ほかとの比較でね。
優位である点が見当たらない。

**デフォルトの名無しさん** · 2012/11/09(金) 15:35:05.92

トップクラスの豊富さなのに、
それをそのまま使えるんだから優位以外の何物でもないと思うが。

**デフォルトの名無しさん** · 2012/11/09(金) 21:12:18.20

Scala大人気でした…
http://jp.techcrunch.com/archives/20120912javascript-tops-latest-programming-language-popularity-ranking-from-redmonk/

**デフォルトの名無しさん** · 2012/11/09(金) 22:10:11.12

Haskellの隣の順位という時点で
大人気とは言いがたい

**デフォルトの名無しさん** · 2012/11/09(金) 22:42:35.38

Javaは優位な点だらけでしょｗ

静的型付け言語というのが一番のメリットで、
その中でここまでうまくやれてるのって
他にないでしょ。

**デフォルトの名無しさん** · 2012/11/09(金) 22:58:45.41

Javaは冗長すぎてウンコ

**デフォルトの名無しさん** · 2012/11/10(土) 07:52:09.13

java は参照渡しができなくてウンコ

**デフォルトの名無しさん** · 2012/11/10(土) 08:08:17.60

そんな細かい指摘しか無いの？

○○をするにはどうすればいいんだろう？と思った時
他の言語なら最近出てきたものが、
Javaの世界には既にあったって驚くことばかりなんだけど。

**デフォルトの名無しさん** · 2012/11/10(土) 08:16:29.74

Ｊava は参照渡しができなくてウンコ

**デフォルトの名無しさん** · 2012/11/10(土) 08:30:16.44

参照渡しの代わりになる技術はあるが、
その逆はない。

例えば、eclipseのリファクタリング機能。
あれと同等の数と信頼性を持ったものはない。

これはecliseが凄いだけというやつがいるが、
Javaだからこそ、ここまで作ることが可能だった。

**デフォルトの名無しさん** · 2012/11/10(土) 08:39:31.82

>>354
＞参照渡しの代わりになる技術はある
ない
そしてJavaは参照渡し（call by reference)はない、あくまでも値渡し(call bye value)のみしかもたない
結論：Javaはウンコ

**デフォルトの名無しさん** · 2012/11/10(土) 08:55:26.14

>>355
参照渡しができなくても
参照渡しをすることで作りたかったアプリは
別に参照渡しを使わなくても作れるということ。

目的は参照渡しではない。
真の目的はアプリを作ることだ。

**デフォルトの名無しさん** · 2012/11/10(土) 09:00:15.79

>>356
Eclipseのリファクタリング機能がなくても
Eclipseで作りたかったアプリは
別にEclipseを使わなくても作れるということ。

目的はEclipseによるリファクタリングではない。
真の目的はアプリを作ることだ。

**デフォルトの名無しさん** · 2012/11/10(土) 09:06:31.88

> 他の言語なら最近出てきたものが、
> Javaの世界には既にあったって驚くことばかりなんだけど。

他の言語なら昔からあったクロージャが
Javaにはまだ無いって驚くわ。

**デフォルトの名無しさん** · 2012/11/10(土) 09:11:18.33

Javaの基本データ型に参照が必要だと感じたことはないけど、
プログラミングスタイルがそういうやり方に慣れちゃってるんだろうね。
必要なら、mutableなオブジェクト型を作って渡してやればいいだけだろうけど。

**デフォルトの名無しさん** · 2012/11/10(土) 09:15:23.92

こんな感じ

class Reference<T> {
T val;
void set(T v) { val=v; }
T get() { return val; }
}

class Example {
public static void main(String[] args) {
Reference<Integer> ref = new Reference<>();
f(ref);
System.out.println(ref.get());
}

static void f(Reference<Integer> ref) {
ref.set(777);
}
}

**デフォルトの名無しさん** · 2012/11/10(土) 09:23:23.55

>>357
はいその通りですね。
もう一つの目的、早く作るってことができるのは
Javaだけです。
参照わたしはなくても、早く作れますのでｗ

**デフォルトの名無しさん** · 2012/11/10(土) 09:24:55.92

>>358
クロージャなくても作れるからねぇ。

戦術と戦略の違いかな。
戦略上重要なものがJavaの世界にはあふれている。

**デフォルトの名無しさん** · 2012/11/10(土) 09:41:44.28

Javaでクロージャのようなことしたかったら、こんなかんじ。
interface Closure {
　void call();
}

class Example {
　public static void main(String[] args) {
　　final Reference<Integer> ref = new Reference<>();
　　f(new Closure() {
　　　　public void call() {
　　　　　ref.set(777);
　　　　}
　　　});
　　System.out.println(ref.get());
　}

　static void f(Closure c) {
　　c.call();
　}
}

**デフォルトの名無しさん** · 2012/11/10(土) 09:45:04.96

>>363
そういうクロージャもどきが
いろんなライブラリで定義されてて
互換性がないところが生産性悪い

一方のライブラリで作ったクロージャを
別のライブラリに直接渡せないとか馬鹿かと

**デフォルトの名無しさん** · 2012/11/10(土) 09:46:04.93

>>363
クロージャの説明に、mainとかclassいらなくね？

お前の説明は無関係ない部分が多いんだよ。

**デフォルトの名無しさん** · 2012/11/10(土) 09:48:22.78

>>364
直接渡せないなら
変換すればいいじゃない？

ほんの数行で書けるでしょ？

**デフォルトの名無しさん** · 2012/11/10(土) 09:51:19.44

そうやって可読性を落とすからJavaはゴミなんだよ

**デフォルトの名無しさん** · 2012/11/10(土) 09:53:29.72

>>364
どんなライブラリ使ってるの？
普通のJavaの流儀だとクロージャを使うことはないと思うけど、
自分の知ってる機能が言語に無いと不便に感じるかもしれないね。

**デフォルトの名無しさん** · 2012/11/10(土) 10:05:28.89

Apache Commons
totallylazy

**デフォルトの名無しさん** · 2012/11/10(土) 10:09:45.17

現状のJavaが優れているからといって、新言語をJavaに似せても
その言語が良い物になるかっていうと違うだろ
Javaの強みは圧倒的なコード資産とノウハウなワケで
それは新言語にそっくりコピーは出来ないんだから

**デフォルトの名無しさん** · 2012/11/10(土) 10:30:11.67

http://e-words.jp/w/E58F82E785A7E6B8A1E38197.html

クラスへの参照を渡すのは参照渡しじゃないのか。

**デフォルトの名無しさん** · 2012/11/10(土) 10:34:06.86

>>371
参照渡しじゃない。
それは「参照の値渡し」

**デフォルトの名無しさん** · 2012/11/10(土) 10:53:13.97

言ってる意味はわかるけど渡された参照値経由で操作するなら
アクセスコスト的にもロジックの理解度的にも問題なくね？

**デフォルトの名無しさん** · 2012/11/10(土) 11:11:47.24

似ていると理解するのは間違っていないと思うが、同じだと考えるのは危険でしょ
渡されてきた仮引数に代入しても
値渡しだからオリジナルは書き換わらない

**デフォルトの名無しさん** · 2012/11/10(土) 11:26:24.59

同じだと書いてる人いるか？

**デフォルトの名無しさん** · 2012/11/10(土) 11:30:03.24

違うものであっても結果的に同じことが出来るなら問題ない。
もっとも、それがとても大変な手間がかかるというのなら話は別だが。

大変な手間＝タイピング時間のことではないよ。

**デフォルトの名無しさん** · 2012/11/10(土) 11:53:02.69

「ほげ言語」のパラドックス
http://practical-scheme.net/trans/beating-the-averages-j.html

**デフォルトの名無しさん** · 2012/11/10(土) 13:32:57.76

>>377
前半をチラッと見ただけで書くけど、

俺は学習用の言語と
アプリを作る実用用（使い続ける、メンテナンスが必要なもの）の言語は
別の特性を持っているものだと考えている。

**デフォルトの名無しさん** · 2012/11/10(土) 13:43:18.60

今、学習用の言語ってある？昔はPascalだったそうだけど。

**デフォルトの名無しさん** · 2012/11/10(土) 13:44:39.22

LispとかPrologじゃないの。

**デフォルトの名無しさん** · 2012/11/10(土) 15:42:49.70

今はほとんどJavaでしょ。
学習用も業務用もJava。

LispやPrologは毛色の違うのを学ぶ程度。
LispやPrologでカリキュラム組んでる大学ありますかね?
(探せば１つ２つ出てくるかもしれないが)

**デフォルトの名無しさん** · 2012/11/10(土) 15:44:20.29

PythonやCを使ってる大学もあるよね。
この２つもどちらもカバーする言語。

**デフォルトの名無しさん** · 2012/11/10(土) 17:24:41.42

>>381
20年前の時点で ML があった。勝手に無断出席しておけばよかった。

**デフォルトの名無しさん** · 2012/11/11(日) 17:04:18.70

特定の言語でプログラミングを学習するということ自体、おかしい。
テンプレートとかは、その言語特有の記号や文字の並べ方を学習しないといけないけど。
アセンブラ言語の構文糖が全部揃ってる言語じゃないと、最適化やアルゴリズムは学べない。

**デフォルトの名無しさん** · 2012/11/11(日) 17:16:01.00

Knuth先生かよw

**デフォルトの名無しさん** · 2012/11/11(日) 19:11:40.48

>>384
例えば普段Javaを使っている人が関数型言語を学ぶと、J
avaの技術力も上がる。文法もなにかも違うのにだ。

つまり、言語を学ぶと「文法」と「考え方」の2つを学ぶことになる。
文法は他の言語に応用はあまりできないが考え方は応用できる。

で実際のアプリ開発の話をすればどんな凄い言語であっても
0の状態からウェブフレームワークやデータベースアクセスライブラリや
HTMLパーサーを書けるわけじゃない。簡易的なものはできても
実用レベルに到達するにはすごく時間がかかる。

そういう点で実際にアプリを作るのであれば言語周辺技術が
発展している必要がある。量が多くて質も良くて互換性が高いものが良い。

最新の技術を取りれていくような言語は、変化が大きくそれ故に
互換性がなくなりがちになる。そうするといままで動いていたものが
動かなくなる。だからアプリ作成には向かない

学習用の言語とアプリ作成用の言語は、言語が目指す目的が違っている
だから学習用とアプリ作成用の言語は違うものになる。

**デフォルトの名無しさん** · 2012/11/11(日) 22:25:04.19

Java製のデータベースサーバーってどんなのがあるの？

**デフォルトの名無しさん** · 2012/11/11(日) 23:27:30.88

いきなり何の話だ？

**デフォルトの名無しさん** · 2012/11/11(日) 23:47:35.64

そもそもJavaは「サーバを作るための」言語ではない。

**デフォルトの名無しさん** · 2012/11/12(月) 00:03:21.61

最近はJavaはウェブサービスを作るのによく使われてるね

**デフォルトの名無しさん** · 2012/11/12(月) 01:54:04.39

「サーバソフトウェア」を作る言語ではない。

**デフォルトの名無しさん** · 2012/11/12(月) 02:20:38.81

だからなんなんだよｗ
アセンブラだってサーバー作る言語じゃねーだろ。

**デフォルトの名無しさん** · 2012/11/12(月) 02:42:28.52

馬鹿には無理

**デフォルトの名無しさん** · 2012/11/12(月) 05:51:54.94

簡易的なものはできても
実用レベルに到達するにはすごく時間がかかる。
だからJavaはデータベースサーバー作成には向かない。

**デフォルトの名無しさん** · 2012/11/12(月) 09:55:14.04

> 実用レベルに到達するにはすごく時間がかかる
言語関係なくね

**デフォルトの名無しさん** · 2012/11/12(月) 10:52:39.18

学習用の言語とアプリ作成用の言語は、言語が目指す目的が違っている
だから学習用とアプリ作成用の言語は違うものになる。

**デフォルトの名無しさん** · 2012/11/12(月) 10:53:49.45

Javaで書いたDBあるよ。当たり前だけど。

**デフォルトの名無しさん** · 2012/11/12(月) 17:10:48.70

全ての機能が備わってる←低スペックCPU向け or 学習向け

いくつかの機能が無い←高スペックCPU向け or 大規模アプリ制作向け

**デフォルトの名無しさん** · 2012/11/12(月) 21:20:30.27

>>386
学習用、の言語をいくつか教えてください。なんだか行き詰った感じを打開したいです
はじめての言語は pascal, c/c++/java をちょとだけかじりました、z80/6809/i8086 ならなんとか、他はしりません

**デフォルトの名無しさん** · 2012/11/12(月) 21:32:07.86

>>399
つ LEGOマインドストーム、プログラミン

**デフォルトの名無しさん** · 2012/11/12(月) 21:33:48.71

学習用ってか、教育用だろうね

**デフォルトの名無しさん** · 2012/12/09(日) 23:33:16.35

言語を開発するには、たとえば awk ぐらいの言語を開発するには
どんな本を読めばいいの？

**デフォルトの名無しさん** · 2012/12/10(月) 00:12:07.81

コンパイラコンパイラ

**デフォルトの名無しさん** · 2012/12/10(月) 00:14:43.08

ぐぐってみればわかるよ

**デフォルトの名無しさん** · 2012/12/15(土) 13:08:39.41

>>402
素人が本を読んでも理解できない。
大学で専門知識を身につける過程で
教材として読むのが本なのだから。
まずは良い先生のいる大学に入ることが先決。

**デフォルトの名無しさん** · 2012/12/15(土) 14:09:45.40

>>402
> たとえば awk ぐらいの言語
awk のソース読めばいいんじゃね
現実問題 awk(awkでも何でもないawk) なんて知れてる行数だよね

% pwd
/usr/src/contrib/one-true-awk
% wc *.[chy]
233 1052 6431 awk.h
486 2452 13914 awkgram.y
976 3868 23267 b.c
582 2238 13104 lex.c
706 2838 17340 lib.c
218 884 5961 main.c
168 820 5138 maketab.c
276 861 5185 parse.c
195 984 6859 proto.h
1960 7223 44856 run.c
457 2000 12574 tran.c
6257 25220 154629 total

**デフォルトの名無しさん** · 2012/12/16(日) 05:41:22.57

何の知識もない人が、いきなりlexerやparserのソースコードを読んでもむずかしいと思う。
最近なら素人向けにそういうのを解説した本や雑誌がありそうだけど。

**デフォルトの名無しさん** · 2012/12/16(日) 06:13:43.37

最近だと『言語実装パターン』辺りが

**デフォルトの名無しさん** · 2012/12/18(火) 10:19:05.86

いやー難しいもんだね。
言語理論自体が一つの学問になっているくらいの難解さなうえに
言語を作るためには何かしらの言語を操れるスキルが必要。
独学でやったら人生を浪費してしまうよ。
素直に大学の専門学部に行くべし。

**デフォルトの名無しさん** · 2012/12/18(火) 10:39:12.78

http://www.amazon.co.jp/dp/4797337958/

**デフォルトの名無しさん** · 2012/12/18(火) 11:13:06.47

大学行っても勉強するのは自分だよ。

**デフォルトの名無しさん** · 2012/12/19(水) 19:45:23.97

>>410
「ふつう」の人にオススメできない本でした。
環境を486・linux・javaに限定しているのでWindowsで動くバイナリを期待した人は落胆するでしょう。
「x86系CPUを選んだ理由は、現在この地上において最も普及しており、、、」と書いているわりには
Windowsを完全にスルーするのはどうかと思います。まあパーサやアセンブラの関係なんでしょうけど、、、。
各章でコンパイラ・リンカ・ＣＰＵ・実行の仕組みなど多くを扱っている為かページ数だけ増大し、内容が薄いものになっています。
構文解析には既成のパーサを用いている為、その実装や理論・アルゴリズムは他の書籍に丸投げしているので残念ながらこの本1冊でコンパイラを理解するのは無理でしょう。
また486に関しても同様です。
コンパイラ本にはドラゴンブックや中田育男先生の本、486には「はじめて読む486」など名著が存在するのでしょうがないですが、、、。
逆にいうとそれらの名著をすでにお持ちの方は「この」本は必要ないように思われます。
著者はあくまで「現実的な」コンパイラを目指していますが、その「現実的な」コンパイラを実装したところでそれをどうように活用するの？という疑問が沸いてきました。
速い実行速度が必要ならばＣ言語で事足りるし、柔軟な言語が必要であればperl・rubyやjavaで十分だと思います。
コンパイラの理論を勉強するのであればこの本の存在意義は皆無です。

「俺は天才だからコンピュータ言語に新たなパラダイムを吹き込む！」といった人は読むべき本です。
最後に良心と思ったのは価格です。これが倍以上の値段だったら発狂しているところでした。