[過去ﾛｸﾞ] 次世代言語12 Go Rust Swift Kotlin TypeScript (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
101: 2018/07/09(月)11:15 ID:m7D4XdEw(1) AAS
rubyにはなんであんなクズみたいなのばかり集まっちゃったんだろうな。ruby自信に詰みはないというのに
102: 2018/07/09(月)11:25 ID:rKnQV5/G(1) AAS
当時のRailsの流行は頭の悪い人達のコンプレックスに支えられていたからだよ
英語わからない難しい要件わからない複雑なコーディングできない、でも俺はペチパーとは違う、という層に夢を見せた
103(2): 2018/07/09(月)11:44 ID:KFrfmR/A(1/4) AAS
依存型がある言語はML族もしくはF#の軽量構文みたいなのが多いのはなんでなの？
C系のシンタックスだと何か不都合でもあるの？
104(1): 2018/07/09(月)11:48 ID:a+N+/6A7(1/2) AAS
わざわざC系のシンタックスにする意味ある？
105(1): 2018/07/09(月)11:52 ID:b/biyW6c(1/4) AAS
>>103
後の引数のpredicateが前の引数を参照するためにはカリー化されてると都合がいい
106(3): 2018/07/09(月)12:46 ID:KFrfmR/A(2/4) AAS
>>104
C系の方が慣れてる人が多いでしょ？それだけである程度意味があると思うけど
>>105
正直何言ってるかよくわからないんだけど、依存型とカリー化って別に関係ないんじゃないの？
だって、依存型のあるATS2では関数宣言↓だけは何故かC(Golangっぽい？)シンタックスだよ
fn test(x: double, y: double): double
だから、ATS2はML族なのにカリー化しづらいよ
107: 2018/07/09(月)13:29 ID:wsFssMnI(2/2) AAS
>>106
型について研究してる畑の人ではML系の方が多数派だからね
それは論理学数学から醸成されたのがML系だからってのもあるし、型についても扱いやすいシンタックスが既にあるML系とわざわざ型を扱うシンタックスを設計しなければいけないC系ベースどっちをまず採用するかってなったんじゃない？
知らんけど
108(2): 2018/07/09(月)13:40 ID:XHrPXSC2(1/2) AAS
>>103
> 依存型がある言語はML族もしくはF#の軽量構文みたいなのが多いのはなんでなの？
> C系のシンタックスだと何か不都合でもあるの？
依存型や本来の多相型(polymorphism)［†］などは型理論の体系つまり高階の型付λ計算に関する論理体系に基づくので
プログラミング言語の型システムとして組み込む場合には同じくλ計算に基づくと関数プログラミング言語の枠組みとは親和性が良いが
Cなどのように変数の値を書き換える代入文や代入演算を有する命令的プログラミング言語とは馴染まない。［‡］
だからそれらの型システムを導入した言語は既存の関数プログラミング言語の構文を流用するケースが多いのだろう。
なおStandard ML/CAML/OCaml/F#などeager evaluationを評価ルールとするいわゆるML系の関数プログラミング言語の一群は
ref型のように代入可能な変数を許すが、本格的な型理論に基づく型システムを組み込む場合はref型の類は除いたsublanguageに対して
行うのが普通。
［†］：本来の多相型とはGirardが竹内の基本予想に関する学位論文で最初に発見（あるいは発明）し
Reynoldsが独立に再発見した型の全称化・抽象化やMilnerが発見したlet-polymorphismなどを指す。
オブジェクト指向での継承に伴って使われるようになった“polymorphism”は
定義が不明確で勝手な拡大解釈が多いので「本来の」という修飾句の対象範囲からは除く。
［‡］：代入操作（代入文と代入演算の総称）を含む命令的プログラミング言語
（Ｃなどの手続き的プログラミング言語やオブジェクト指向プログラミング言語を纏めてこう呼ぶ）に
例えば多相型が馴染まない理由は代入操作可能な変数の型として多相型を許すことは
その変数について動的な型付けを許すことに他ならなくなる。
例で少し説明するが既知なら許してくれ。最も基本的な多相型 ∀t.t （どんな型でもＯＫ）と宣言された変数 x を考える、つまり
∀t.t x;
この変数はどんな型の変数としても使えるので、これにint型の値 1 は代入できる、
x = 1;
この後で式の中でこの変数の値を参照すると int型の値 1 が許される文脈以外ではエラーになる。
即ち、型理論における本来の多相型つまり静的な型付けでの多相型の概念は代入可能な変数では失われるということだ。
109(1): 2018/07/09(月)15:02 ID:wwylxN3+(1/5) AAS
Cは関数()をカリー化しなかったが配列[]をカリー化した
2次元配列を1次元のように扱い、逆にスカラー (0次元) を1次元のように扱う
Cには共用体もあるからML系に似ている部分は多かった
110: 2018/07/09(月)16:22 ID:wwylxN3+(2/5) AAS
オリジナルのC/C++はもう実質的に依存型と同じものを既に使いこなしてるな
依存型がまだないという自称C系ってのは本当はJava系と名乗るべきだな
111: 2018/07/09(月)16:59 ID:a+N+/6A7(2/2) AAS
>>106
こいつCのシンタックスじゃないって理由でPython嫌ってそうｗ
112: 2018/07/09(月)17:03 ID:b/biyW6c(2/4) AAS
>>106
カリー化されてると全部1引数の fun a -> aを使う(かもしれない)型 の形で済むだろ
ATS2がどうしてるかは知らん
113: 2018/07/09(月)18:16 ID:KFrfmR/A(3/4) AAS
別にC以外のシンタックスを嫌ってる訳じゃないよ(てか、なんでそういう風に受けとる…？)
普及を考えれば新規ユーザーのハードルを下げるためにも少しくらい相性が悪かろうが
C系のシンタックスを採用した方が良いんじゃない？って思っただけ
どれだけ理論が優れていようが結局のところ広く普及した言語の大半
(C/C++, Java, C#, JavaScript, PHP...etc.)はC系のシンタックス
勿論C系以外で普及した言語もある(Python, Ruby...etc.)けど…数はそれほど多くない
Cのシンタックスを採用することに致命的な不都合があれば話は別だけど
そうでなければ1つくらい依存型ありの言語でC系の言語があったって良いんじゃない？
優れた理論が使われてる言語がそんなしようもない理由で普及しなかったら勿体ないじゃん
普及させるためにはそういう些細な部分は妥協したらどうだ？と思ったわけ
114(1): 2018/07/09(月)18:21 ID:xuxQDn++(1) AAS
ALGOL舐めてるわけ?
115: 2018/07/09(月)18:22 ID:IyYxWzMk(1) AAS
COBOL舐めてるわけ？
Fortran舐めてるわけ？
116(1): 2018/07/09(月)18:40 ID:EEzdGAQJ(1) AAS
>>109
> Cは関数()をカリー化しなかったが配列[]をカリー化した
配列をカリー化の意味が分からんのだが
117(1): 2018/07/09(月)18:41 ID:b/biyW6c(3/4) AAS
まともな推論を入れようとしたら>>108みたいな理由で式ベースになるんだから
C系に似せようとしたところで不格好で無駄に記述量も多いキメラができるだけだろ
ところでBASIC舐めてるわけ？
118: 2018/07/09(月)20:41 ID:wwylxN3+(3/5) AAS
>>116
C系は分かりにくいという証拠だ
119: 2018/07/09(月)20:54 ID:XHrPXSC2(2/2) AAS
>>114
> ALGOL舐めてるわけ?
AlgolとくにAlgol 60は実用性はともかく言語設計の観点からは非常に優れた言語だったが、命令的言語であるがゆえに型理論には馴染まない部分がある
今回の君のような内容ゼロの一言レスしてる暇があったら、ReynoldsやTennentの教科書・論文ぐらいは読んで勉強したらどうよ
120(1): 2018/07/09(月)21:22 ID:KFrfmR/A(4/4) AAS
>>117
そうか？式指向でC系のシンタックスっていったら真っ先にRustが頭に浮かんだが
別に不格好とも無駄に記述量が多いとも感じないが…
そもそもC系の時点で何指向だろうが関数型と比べると記述量は少し多くなるものだし…
C系を式指向にしたところでそんなに変になるところは無いと思うんだが
別に全部C系にしろって言ってる訳じゃないんだ
依存型ありの言語にも1, 2個くらいC系があっても良いのにっ思ってるだけで…
121: 2018/07/09(月)21:40 ID:wwylxN3+(4/5) AAS
現実は正しい
格付けの方が間違ってるんじゃねえか
リーマンショックみたいに
122: 2018/07/09(月)21:46 ID:U1rzq4XN(1) AAS
あってもいいということはなくてもおかしくないという事だよ
言語設計者が依存型を普及させたいにしてもC系シンタックスを蛇蝎の如く嫌っている可能性だってある訳だ
そうでない君が依存型+C系シンタックスが普及に必要だと思うならそれは正しく良い意味で言い出しっぺの法則だね
123: 2018/07/09(月)21:56 ID:b/biyW6c(4/4) AAS
>>120
rustは根っこのところは手続き型だからな
もっと式ベースを徹底していったらC系文法なんてどんどん余計なものになってくよ
124(1): 2018/07/09(月)22:16 ID:wwylxN3+(5/5) AAS
式指向にしてブロックが値を返す
ブロックの中でreturnなどと書いたらブロックだけではなくメソッド全体が終了する
これSmalltalkとRubyでやったやつだ
125: 2018/07/10(火)02:09 ID:PeZ34IEg(1) AAS
>>124
＞ブロックの中でreturnなどと書いたらブロックだけではなくメソッド全体が終了する
他のほぼ全ての言語もそうじゃね？
126: 2018/07/10(火)06:52 ID:TRoApVCG(1) AAS
やっとラムダが当たり前になったところだぞ
型理論の成果がプロダクト利用に広まるには時間がかかるんだよ
127(1): 2018/07/10(火)08:08 ID:Iy+fy/d3(1/2) AAS
なんでJavaだけバージョンアップしなきゃだのセキュリティアップデートがどうの、大騒ぎしてんの？
JavaScriptなんて毎日のように新しいsyntaxぶち込まれてるし、
Kotlinがここまでアプデに振り回されてるのはあまり聞いたことない気がする
他でここまでセキュホがギャースカ言われてるのって、ポンコツペチプァとWordPressくらいじゃね？
Javaってそんな糞脆いの？
128: 2018/07/10(火)08:21 ID:eM8UKooB(1) AAS
>>108
詳しい人から見てF*ってどうなん？良さそう？
129: 2018/07/10(火)08:36 ID:zIs1qZZm(1/2) AAS
Fuck
130: 2018/07/10(火)09:24 ID:xdf1qrhG(1/2) AAS
BrainF*ck
略してF*
上下前次1-新書関写板覧索設栞歴
あと 872 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.010s