[過去ﾛｸﾞ] 次世代言語12 Go Rust Swift Kotlin TypeScript (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
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#って、何処で使われてるの？
671: 2018/08/08(水)07:11 ID:NcOXcLna(1) AAS
既存の手続き型言語で培われてきたアルゴリズムは
ミュータブルなデータ構造に対して最大限の効果を発揮するものなんだから
イミュータブルなデータ構造が基本の言語で同じことをやろうとするのが誤り
672: 2018/08/08(水)07:27 ID:wNvOXIQi(1) AAS
イミュータブルなデータ構造の方が速い、ってケースはあり得るのかしらん
673: 2018/08/08(水)08:23 ID:IxvHxUWv(1) AAS
ミュータブルがイミュータブルを包含するなら無い。
674: 2018/08/08(水)08:26 ID:XKTLbEez(2/2) AAS
速いってケースは思いつかないけど(ヒープを遠慮なく使う時点でたぶんアウト)
SSAとかは興味深い
675: 2018/08/08(水)08:42 ID:Lg30iyda(1/2) AAS
なんか俺がいなくても結局誰かをガイジ呼ばわりして叩くスタンスには変わりないんだな
上下前次1-新書関写板覧索設栞歴
あと 327 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.018s