[過去ﾛｸﾞ] 次世代言語12 Go Rust Swift Kotlin TypeScript (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
641: 2018/08/07(火)08:54 ID:UMEYDAwp(3/3) AAS
手抜きではないだろ、むしろ逆
worldを隠しつつ宣言的に書くという変態技のために
モナド用の構文糖衣が多数あるせいで関数型の簡潔さが失われている
642(2): 2018/08/07(火)09:11 ID:FVK8LmPZ(2/2) AAS
シンタックスシュガーを幾ら用意しても簡潔に書けるようにする工夫がないから
どう書いても冗長って話なんだけど？分かってないなぁ
643: 2018/08/07(火)10:46 ID:rAZv+q4y(2/4) AAS
それは手抜きと表現すべきではない。わかってないなあ
644(1): 2018/08/07(火)10:58 ID:hbLPpe/0(1/2) AAS
>>642
じゃあ例えばどういう工夫なの？
お前のHaskellの理解力が試されてるから慎重に答えてね
無理なら別に逃げてもいいよ
645: 2018/08/07(火)11:45 ID:7ewfkb5/(1/4) AAS
工夫するたびに言語の差は大きくなって言葉が通じなくなる
逆に言語を一つにしたければチューリングマシンだとかラムダ計算だとか
人が手を加えないまるで手抜きのような方向に行けばいい
646(1): 2018/08/07(火)11:56 ID:MwJ3Tuus(1) AAS
>>644
そうだなぁ。何でもいいんだけど、たとえば in-place quicksort をHaskellで可読性高く書けるかって話ですよ
いままでCにも劣る可読性のコードしか見たことないわ
だから、お前が可読性高い in-place quicksort を書いて見せたらこっちの意見は取り下げてもいいけどね
無理なら別に逃げてもいいよw
647: 2018/08/07(火)11:56 ID:UdLWsfQc(1) AAS
関数型は実行モデルに由来する制約が少なくて言語設計の自由度が高い分、アイランドモンキー族にとって馴染みにくいものになってると思うんだよな
「結論から言え」なカルチャーが色濃く出すぎてる
648(1): 2018/08/07(火)12:42 ID:hbLPpe/0(2/2) AAS
>>646
お前の可読性の基準なんかこっちはしらんがな
お前が言う工夫が例えば何かって聞いてんだよ
まさかノーアイデアで批判だけしてんの？
649: 2018/08/07(火)13:44 ID:iXXZIPQ5(3/4) AAS
可読性が低く冗長なのが問題だ。簡潔に書ける工夫があればよい。
例えばどういう工夫が？
例えば in-place quicksort が問題だ。簡潔に書ける工夫はないだろ？
----
まあ問題意識は判った。確かに可読性と速度の両立は課題だと思う。
650: 2018/08/07(火)13:56 ID:7ewfkb5/(2/4) AAS
CとHaskellの両立ができないやつは二刀流を自粛している
これは自粛であって禁止ではない
651: 2018/08/07(火)14:11 ID:iXXZIPQ5(4/4) AAS
あれっひょっとして >>642 は
「もっと状態方面を簡潔に書けるよう工夫しろよ」って非難してるのか。
だとしたら誤読だったすまん。
652: 2018/08/07(火)14:14 ID:87aOzLJL(1) AAS
インプレースに書かなくてもインプレースにしてくれるのが stream fusion
653: 2018/08/07(火)14:20 ID:7ewfkb5/(3/4) AAS
副作用を書かなくても書ける（副作用禁止とは言っていない）
654(1): 2018/08/07(火)16:25 ID:1g1T9ybM(1/2) AAS
>>633
> そのラムダ計算には型があるのかないのか
> 副作用があるのかないのか
副作用を入れたものは本来はλ計算ではないよ
そういう変てこなバリエーションをデッチ上げて「何ちゃらλ-calculus」とか呼んで発表してるのは幾らでもあるがゴミばかり
状態などというものを考えず単純に構文的な置き換えだけで扱えるλ計算の長所を破壊し放棄する拡張をしても何もメリットはない
単にほとんど誰にも論文のカウント数を１増やすだけ
まあ御当人の学位取得や助教職のアプリケーションには有効なのかも知れないが
655: 2018/08/07(火)16:27 ID:1g1T9ybM(2/2) AAS
>>654訂正
誤> 単にほとんど誰にも論文のカウント数を１増やすだけ
正> 単にほとんど誰にも読まれない論文のカウント数を１増やすだけ
656: 2018/08/07(火)16:59 ID:7ewfkb5/(4/4) AAS
モナドクラスは副作用を入れたinstanceと入れないinstanceの見た目を同じにする
副作用を禁止しても見た目が美しくなったりしない
Haskellには副作用を禁止するモチベーションがない
657: 2018/08/07(火)17:10 ID:ghIQqx1y(1) AAS
副作用あったら遅延評価できないじゃんｗｗｗｗｗ
658: 2018/08/07(火)17:44 ID:STmUhm8q(1) AAS
>>648
ここはHaskellスレじゃないんですよ？
ゴミ言語にはゴミである理由さえ説明すれば十分ですよ
659(1): 2018/08/07(火)21:56 ID:rAZv+q4y(3/4) AAS
Inplaceが必要な時はHaskellを使うべきではない
Inplaceが不要な時に力を発揮する言語だし、Inplaceなんて避けておけというメッセージのこもった言語だ
660(1): 2018/08/07(火)22:38 ID:ThdtCxHP(1) AAS
>>659
それって言い方を変えると
HaskellもPythonみたいにクリティカルな部分はCで書いてそれ呼び出せ
って解釈できる気がするんだが、そう解釈しておk？飛躍しすぎ？
661: 2018/08/07(火)23:17 ID:rAZv+q4y(4/4) AAS
>>660
個人的には正直そうした方が良いと思う
662(1): 2018/08/07(火)23:57 ID:z8E9h/cA(1) AAS
たかがin-placeが必要なだけでCの助けが必要って？
そんなウンコは次世代言語に相応しくないな
663: 2018/08/08(水)00:39 ID:MPyzl9Mf(1/2) AAS
結局C++で全部書けばいいじゃんってなる
664: 2018/08/08(水)00:41 ID:wOobAAAA(1) AAS
>>662
なるべくin-placeは避けろという言語に対してin-placeがかけないなら云々とかもう思想が合ってないとしか言いようがないな
665: 2018/08/08(水)00:46 ID:LvbSOyDD(1/2) AAS
Haskellは富豪プログラム専用。in-placeがどうしても必要になるような貧乏人の道具ではない
666: 2018/08/08(水)01:04 ID:vRZZuWNv(1/4) AAS
副作とノー副作を合一合体して書けるScalaサイキョってことか？
667: 2018/08/08(水)01:05 ID:vRZZuWNv(2/4) AAS
ちなInplaceって何ンゴ？
668: 2018/08/08(水)01:17 ID:XKTLbEez(1/2) AAS
関数型言語に学ぶ価値はあるけど使う価値はないっ昔から言われてるじゃん
Monad勉強してへーうまくできてんなー(実行効率悪そうだけど)
って思っときゃいいの
そして最近の言語はOptionalとかいいとこだけうまく取り込んでるわけだ
669(1): 2018/08/08(水)01:33 ID:x4iNladl(1/2) AAS
シンプルさと実用性を兼ね備えたF#が最強でいいよ
670(1): 2018/08/08(水)06:39 ID:qzF7QRmg(1) AAS
>>669
F#って、何処で使われてるの？
上下前次1-新書関写板覧索設栞歴
あと 332 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.009s