[過去ﾛｸﾞ] 次世代言語12 Go Rust Swift Kotlin TypeScript (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
611: 2018/08/06(月)21:10 ID:6BhDg/Vc(1/2) AAS
1. 関数プログラミング自体が実は大したことない
2. 副作用禁止の強制が邪魔
3. 使ってるプログラマーのレベルが低い(偏屈しか使わない・ユーザー層が薄い)
4. まだ成熟していないだけ
どうだろう。4だと思いたいが…
612: 2018/08/06(月)21:20 ID:2AWODdBK(1/2) AAS
・Web系→モデルやロジックが単純なので関数型のメリットなし
・ゲーム系→常に時間変化を扱うので関数型のメリットなし
・業務系→PGの単価が上がって割に合わないので関数型のメリットなし
613(1): 2018/08/06(月)21:28 ID:13KQrLiC(1/2) AAS
関数型の定義が未だに分からない
2だけならどの言語でも原則として受け入れられているんじゃないの
614(1): 2018/08/06(月)21:45 ID:2AWODdBK(2/2) AAS
関数型はテストするまでもなく結果の明らかな極めて宣言性の高いコーディングができるというのが実用上最大の強みなわけだけど、
関数型マニアの関心は主に無限リストやら再帰やらモナドやら、自らその宣言性を捨てるテクニックにばかり向いていて、
結局関数型の何が嬉しいのかよくわからん状態になってしまってるのが現状
615: 2018/08/06(月)21:58 ID:13KQrLiC(2/2) AAS
具体的にはどんなコードになるの？
そんな単純なコードの断片だけを組み合わせるだけで実用に耐えうる可読性や性能を発揮できるもんなの？
616: 2018/08/06(月)21:59 ID:iAZi0X5l(1) AAS
関数単位、メソッド単位でなるべく純粋にしておくのは重要
短い関数内部の実装まで純粋にしようとするのは宗教
617(1): 2018/08/06(月)22:15 ID:GZIQzwJh(1/2) AAS
平気で数百メガあるようなデータに対して副作用のないメソッドチェーンで加工するのって普通にやることなの？
618: 2018/08/06(月)22:27 ID:YK5LkNr+(1) AAS
>>617
そういうのはステップ毎に一時ファイルに書き出すのが普通でしょ
COBOL時代からの伝統的なスタイルであり、今でもHadoopなどに受け継がれている
副作用がなくむしろ関数型的だ
619: 2018/08/06(月)23:04 ID:GZIQzwJh(2/2) AAS
じゃあ数メガぐらいのデータなら？
620(1): 2018/08/06(月)23:11 ID:4RMVWTln(1) AAS
遅延評価だったりストリーム使えるんなら大体気にしなくていいんじゃないかね
621: 2018/08/06(月)23:47 ID:+WS/BAR+(1) AAS
関数型言語の本質は関数そのものを柔軟に扱うことだと思うんだけどな
例えばジェネリック関数のある言語ではジェネリック関数をジェネリックなまま引数や戻り値として扱えないと関数型言語っぽくない気がする
622(1): 2018/08/06(月)23:57 ID:6BhDg/Vc(2/2) AAS
>>613
副作用はよろしくない、というのは確かに広く受け入れられている。
でもHaskellなどが要求する基準は、もっとずっと高い。
ちょっと前にstackツールのコードを見たことがある。今どうなってるかは知らんが当時は、
ある純粋な関数の中でデバッグ用ログをより詳細に出力するってフラグを、ソースコードに即値でベタ書きしていた。
これは他の言語では例えば環境変数を読み込む関数をその場で実行すれば良いだけなのだが、
Haskellでそれをやろうとすると、関数のシグニチャを非純粋なものに置き換えて、使用する全箇所も合わせて換えるか、
あるいはフラグを引き渡す配管を新設するか、などの工事が必要になる。
623: 2018/08/07(火)00:00 ID:Cr+icss0(1/2) AAS
>>620
それは勘違い
遅延ストリームでステップ毎にコピーしてるんなら、コピーするオブジェクト数はバッチでステップ毎に全件コピーするのと変わらん
というかメモリアクセスが細切れになる分だけ遅くなる
遅延ストリームはレイテンシの低減には有効だけどスループットも下がるよ
624: 622 2018/08/07(火)00:12 ID:iXXZIPQ5(1/4) AAS
...という工事が必要になる。だから仕方ないと言えなくもない。
このような事態は純粋な言語では良くあるのだが、このことだけで、すわHaskellあかんやん、は早計だと思う。
Implicit ParametersやGivenのようなアイデアも出てきてるし、これは解決する余地のある課題なのかもしれない。
あるいはこのような事態を引き起こす設計に問題があるのかも。
625: 2018/08/07(火)00:18 ID:UMEYDAwp(1/3) AAS
次世代言語たって、シングルスレッドのJSをこねくり回してドヤってる人と
Native言語でハードウェアの性能を最大限引きだそうとしてる人とで
必要とするもの違うからいっしょに議論してもかみ合わない
626: 2018/08/07(火)00:20 ID:wPKvZYDw(1) AAS
そもそもハスケルの仕様通りの評価順序で実装してたらまともな実行速度でないっしょ。
そういうごまかしを含んでる時点でしょーもねーわ。
627: 2018/08/07(火)00:30 ID:Cr+icss0(2/2) AAS
副作用はよろしくない、といってるくせに再帰やら遅延ストリームやらモナドやら状態依存のコードを好んで書きたがるのが関数型マニア
そもそも状態に依存するコードなんか極力書くな、避けられるならモナドなんか使うな、という正論を言えない空気があり、
競って予測困難で難解なコードを書いて「俺すげえ」のマウント合戦を繰り広げている
こんな状態で流行るわけがない
628: 2018/08/07(火)01:14 ID:rAZv+q4y(1/4) AAS
状態依存は避けられないのに状態を禁止してしまったからやたらと状態関連が発達してしまっているけど、状態なしで書ける部分と状態が必要な部分を分けて書くという理念は守られているはず……
629: 2018/08/07(火)01:27 ID:lcDZ2HG8(1/2) AAS
Haskellの定義を知ってる人ならいるけど関数型の定義は誰も知らないんだよ
だから「Haskellは関数型である」とか
「Haskellマニアと関数型マニアは同一人物である」とかいう根拠がそもそも存在しない
630: 2018/08/07(火)01:37 ID:wdyVMIbP(1) AAS
つまりおまいらはまたオブジェクティバラブルなコード時代に戻るというの？
631: 2018/08/07(火)01:38 ID:kyOAfGFT(1) AAS
日本語でおｋ
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は状態に依存するコードを書こうとすると途端に
可読性の低い冗長なコードになるのがダメなところだと思う
純粋な部分の構文に比べて手抜きすぎなんだよ
上下前次1-新書関写板覧索設栞歴
あと 362 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.022s