[過去ログ] 次世代言語12 Go Rust Swift Kotlin TypeScript (1002レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
632: 2018/08/07(火)01:39 ID:UMEYDAwp(2/3) AAS
関数型言語の定義ってラムダ計算を計算モデルにしてる言語でいいだろ
633(1): 2018/08/07(火)02:09 ID:lcDZ2HG8(2/2) AAS
そのラムダ計算には型があるのかないのか
副作用があるのかないのか
なにも定義されていない
634: 2018/08/07(火)03:28 ID:hhcOlifT(1) AAS
型なしラムダ計算だったとしてもlispだし型付ラムダ計算だったとしてもML/Haskell/etc…だし広義には問題なくない?
副作用の有無=純粋性は程度で片付けなきゃやってられない(どの汎用言語にもプログラムならどこかしら副作用が存在する)し
定期的に定義に固執しすぎなレス見掛けるけど自分でその問い掛けを考えたか?って感じなのが多い
635: 2018/08/07(火)03:47 ID:1Z28ZkuF(1) AAS
計算機科学の研究課題としては興味深いが
プロダクション用途ではないだろう
だから何が悪いというわけではないが
636: 2018/08/07(火)06:13 ID:o88xwRN/(1) AAS
>>614 がいいこと言った。
見通しが良いコードにするための宣言型言語のはずが
むしろ見通しを悪くしている。
637: 2018/08/07(火)07:56 ID:c0zbvnlv(1) AAS
Scalaという見通しの悪い言語が関数型として世に知られてしまったのも不幸だったよね
意識高い系のオモチャに選ばれたのがScalaではなくF#だったら状況はだいぶ違っていたのではないか
638: 2018/08/07(火)07:59 ID:6yZcjsMn(1) AAS
状態に依存する部分と純粋な部分を切り分けること自体は純粋関数型言語じゃなくてもできること
そもそもHaskell使える開発者が集まってるならHaskellじゃなくてもみんな極力そのように書くし、
強制されないと副作用ごちゃまぜコードを書くような土方はHaskellは使えない
純粋性を強制するメリットが禁止して柔軟性を失うデメリットに釣り合ってない
639: 2018/08/07(火)08:35 ID:iXXZIPQ5(2/4) AAS
純粋性を強制するメリット、を考えてみた。
例えばエディタの設定ファイルをHaskell自身で書くことができる。
設定ファイルがSafeHaskellであることを要請して、かつ設定操作に限定された型のみを許すようにする。
これで設定ファイルに、勝手にビットコインを採掘するスクリプトを忍ばせるような悪さができなくなるし、
Haskellそのものの柔軟性を活かして好きなだけ設定を短く表現できる。
安全さと強力さが両立された。
640: 2018/08/07(火)08:38 ID:FVK8LmPZ(1/2) AAS
Haskellは状態に依存するコードを書こうとすると途端に
可読性の低い冗長なコードになるのがダメなところだと思う
純粋な部分の構文に比べて手抜きすぎなんだよ
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」とか呼んで発表してるのは幾らでもあるがゴミばかり
状態などというものを考えず単純に構文的な置き換えだけで扱えるλ計算の長所を破壊し放棄する拡張をしても何もメリットはない
単にほとんど誰にも論文のカウント数を1増やすだけ
まあ御当人の学位取得や助教職のアプリケーションには有効なのかも知れないが
655: 2018/08/07(火)16:27 ID:1g1T9ybM(2/2) AAS
>>654訂正
誤> 単にほとんど誰にも論文のカウント数を1増やすだけ
正> 単にほとんど誰にも読まれない論文のカウント数を1増やすだけ
656: 2018/08/07(火)16:59 ID:7ewfkb5/(4/4) AAS
モナドクラスは副作用を入れたinstanceと入れないinstanceの見た目を同じにする
副作用を禁止しても見た目が美しくなったりしない
Haskellには副作用を禁止するモチベーションがない
657: 2018/08/07(火)17:10 ID:ghIQqx1y(1) AAS
副作用あったら遅延評価できないじゃんwwwww
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
個人的には正直そうした方が良いと思う
上下前次1-新書関写板覧索設栞歴
あと 341 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ
ぬこの手 ぬこTOP 0.010s