[過去ﾛｸﾞ]
次世代言語12 Go Rust Swift Kotlin TypeScript (1002ﾚｽ)
次世代言語12 Go Rust Swift Kotlin TypeScript http://mevius.5ch.net/test/read.cgi/tech/1530664695/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
611: デフォルトの名無しさん [sage] 2018/08/06(月) 21:10:23.18 ID:6BhDg/Vc 1. 関数プログラミング自体が実は大したことない 2. 副作用禁止の強制が邪魔 3. 使ってるプログラマーのレベルが低い(偏屈しか使わない・ユーザー層が薄い) 4. まだ成熟していないだけ どうだろう。4だと思いたいが… http://mevius.5ch.net/test/read.cgi/tech/1530664695/611
612: デフォルトの名無しさん [sage] 2018/08/06(月) 21:20:23.85 ID:2AWODdBK ・Web系→モデルやロジックが単純なので関数型のメリットなし ・ゲーム系→常に時間変化を扱うので関数型のメリットなし ・業務系→PGの単価が上がって割に合わないので関数型のメリットなし http://mevius.5ch.net/test/read.cgi/tech/1530664695/612
613: デフォルトの名無しさん [] 2018/08/06(月) 21:28:53.61 ID:13KQrLiC 関数型の定義が未だに分からない 2だけならどの言語でも原則として受け入れられているんじゃないの http://mevius.5ch.net/test/read.cgi/tech/1530664695/613
614: デフォルトの名無しさん [sage] 2018/08/06(月) 21:45:44.03 ID:2AWODdBK 関数型はテストするまでもなく結果の明らかな極めて宣言性の高いコーディングができるというのが実用上最大の強みなわけだけど、 関数型マニアの関心は主に無限リストやら再帰やらモナドやら、自らその宣言性を捨てるテクニックにばかり向いていて、 結局関数型の何が嬉しいのかよくわからん状態になってしまってるのが現状 http://mevius.5ch.net/test/read.cgi/tech/1530664695/614
615: デフォルトの名無しさん [] 2018/08/06(月) 21:58:21.43 ID:13KQrLiC 具体的にはどんなコードになるの？ そんな単純なコードの断片だけを組み合わせるだけで実用に耐えうる可読性や性能を発揮できるもんなの？ http://mevius.5ch.net/test/read.cgi/tech/1530664695/615
616: デフォルトの名無しさん [sage] 2018/08/06(月) 21:59:00.02 ID:iAZi0X5l 関数単位、メソッド単位でなるべく純粋にしておくのは重要 短い関数内部の実装まで純粋にしようとするのは宗教 http://mevius.5ch.net/test/read.cgi/tech/1530664695/616
617: デフォルトの名無しさん [sage] 2018/08/06(月) 22:15:10.24 ID:GZIQzwJh 平気で数百メガあるようなデータに対して副作用のないメソッドチェーンで加工するのって普通にやることなの？ http://mevius.5ch.net/test/read.cgi/tech/1530664695/617
618: デフォルトの名無しさん [sage] 2018/08/06(月) 22:27:24.52 ID:YK5LkNr+ >>617 そういうのはステップ毎に一時ファイルに書き出すのが普通でしょ COBOL時代からの伝統的なスタイルであり、今でもHadoopなどに受け継がれている 副作用がなくむしろ関数型的だ http://mevius.5ch.net/test/read.cgi/tech/1530664695/618
619: デフォルトの名無しさん [sage] 2018/08/06(月) 23:04:02.54 ID:GZIQzwJh じゃあ数メガぐらいのデータなら？ http://mevius.5ch.net/test/read.cgi/tech/1530664695/619
620: デフォルトの名無しさん [sage] 2018/08/06(月) 23:11:20.61 ID:4RMVWTln 遅延評価だったりストリーム使えるんなら大体気にしなくていいんじゃないかね http://mevius.5ch.net/test/read.cgi/tech/1530664695/620
621: デフォルトの名無しさん [sage] 2018/08/06(月) 23:47:33.03 ID:+WS/BAR+ 関数型言語の本質は関数そのものを柔軟に扱うことだと思うんだけどな 例えばジェネリック関数のある言語ではジェネリック関数をジェネリックなまま引数や戻り値として扱えないと関数型言語っぽくない気がする http://mevius.5ch.net/test/read.cgi/tech/1530664695/621
622: デフォルトの名無しさん [sage] 2018/08/06(月) 23:57:07.45 ID:6BhDg/Vc >>613 副作用はよろしくない、というのは確かに広く受け入れられている。 でもHaskellなどが要求する基準は、もっとずっと高い。 ちょっと前にstackツールのコードを見たことがある。今どうなってるかは知らんが当時は、 ある純粋な関数の中でデバッグ用ログをより詳細に出力するってフラグを、ソースコードに即値でベタ書きしていた。 これは他の言語では例えば環境変数を読み込む関数をその場で実行すれば良いだけなのだが、 Haskellでそれをやろうとすると、関数のシグニチャを非純粋なものに置き換えて、使用する全箇所も合わせて換えるか、 あるいはフラグを引き渡す配管を新設するか、などの工事が必要になる。 http://mevius.5ch.net/test/read.cgi/tech/1530664695/622
623: デフォルトの名無しさん [sage] 2018/08/07(火) 00:00:17.86 ID:Cr+icss0 >>620 それは勘違い 遅延ストリームでステップ毎にコピーしてるんなら、コピーするオブジェクト数はバッチでステップ毎に全件コピーするのと変わらん というかメモリアクセスが細切れになる分だけ遅くなる 遅延ストリームはレイテンシの低減には有効だけどスループットも下がるよ http://mevius.5ch.net/test/read.cgi/tech/1530664695/623
624: 622 [sage] 2018/08/07(火) 00:12:00.15 ID:iXXZIPQ5 ...という工事が必要になる。だから仕方ないと言えなくもない。 このような事態は純粋な言語では良くあるのだが、このことだけで、すわHaskellあかんやん、は早計だと思う。 Implicit ParametersやGivenのようなアイデアも出てきてるし、これは解決する余地のある課題なのかもしれない。 あるいはこのような事態を引き起こす設計に問題があるのかも。 http://mevius.5ch.net/test/read.cgi/tech/1530664695/624
625: デフォルトの名無しさん [sage] 2018/08/07(火) 00:18:57.06 ID:UMEYDAwp 次世代言語たって、シングルスレッドのJSをこねくり回してドヤってる人と Native言語でハードウェアの性能を最大限引きだそうとしてる人とで 必要とするもの違うからいっしょに議論してもかみ合わない http://mevius.5ch.net/test/read.cgi/tech/1530664695/625
626: デフォルトの名無しさん [sage] 2018/08/07(火) 00:20:39.37 ID:wPKvZYDw そもそもハスケルの仕様通りの評価順序で実装してたらまともな実行速度でないっしょ。 そういうごまかしを含んでる時点でしょーもねーわ。 http://mevius.5ch.net/test/read.cgi/tech/1530664695/626
627: デフォルトの名無しさん [sage] 2018/08/07(火) 00:30:11.90 ID:Cr+icss0 副作用はよろしくない、といってるくせに再帰やら遅延ストリームやらモナドやら状態依存のコードを好んで書きたがるのが関数型マニア そもそも状態に依存するコードなんか極力書くな、避けられるならモナドなんか使うな、という正論を言えない空気があり、 競って予測困難で難解なコードを書いて「俺すげえ」のマウント合戦を繰り広げている こんな状態で流行るわけがない http://mevius.5ch.net/test/read.cgi/tech/1530664695/627
628: デフォルトの名無しさん [sage] 2018/08/07(火) 01:14:56.51 ID:rAZv+q4y 状態依存は避けられないのに状態を禁止してしまったからやたらと状態関連が発達してしまっているけど、状態なしで書ける部分と状態が必要な部分を分けて書くという理念は守られているはず…… http://mevius.5ch.net/test/read.cgi/tech/1530664695/628
629: デフォルトの名無しさん [sage] 2018/08/07(火) 01:27:00.12 ID:lcDZ2HG8 Haskellの定義を知ってる人ならいるけど関数型の定義は誰も知らないんだよ だから「Haskellは関数型である」とか 「Haskellマニアと関数型マニアは同一人物である」とかいう根拠がそもそも存在しない http://mevius.5ch.net/test/read.cgi/tech/1530664695/629
630: デフォルトの名無しさん [sage] 2018/08/07(火) 01:37:43.21 ID:wdyVMIbP つまりおまいらはまたオブジェクティバラブルなコード時代に戻るというの？ http://mevius.5ch.net/test/read.cgi/tech/1530664695/630
631: デフォルトの名無しさん [sage] 2018/08/07(火) 01:38:48.13 ID:kyOAfGFT 日本語でおｋ http://mevius.5ch.net/test/read.cgi/tech/1530664695/631
632: デフォルトの名無しさん [sage] 2018/08/07(火) 01:39:33.68 ID:UMEYDAwp 関数型言語の定義ってラムダ計算を計算モデルにしてる言語でいいだろ http://mevius.5ch.net/test/read.cgi/tech/1530664695/632
633: デフォルトの名無しさん [sage] 2018/08/07(火) 02:09:48.40 ID:lcDZ2HG8 そのラムダ計算には型があるのかないのか 副作用があるのかないのか なにも定義されていない http://mevius.5ch.net/test/read.cgi/tech/1530664695/633
634: デフォルトの名無しさん [sage] 2018/08/07(火) 03:28:30.29 ID:hhcOlifT 型なしラムダ計算だったとしてもlispだし型付ラムダ計算だったとしてもML/Haskell/etc…だし広義には問題なくない？ 副作用の有無=純粋性は程度で片付けなきゃやってられない(どの汎用言語にもプログラムならどこかしら副作用が存在する)し 定期的に定義に固執しすぎなレス見掛けるけど自分でその問い掛けを考えたか？って感じなのが多い http://mevius.5ch.net/test/read.cgi/tech/1530664695/634
635: デフォルトの名無しさん [sage] 2018/08/07(火) 03:47:47.09 ID:1Z28ZkuF 計算機科学の研究課題としては興味深いが プロダクション用途ではないだろう だから何が悪いというわけではないが http://mevius.5ch.net/test/read.cgi/tech/1530664695/635
636: デフォルトの名無しさん [sage] 2018/08/07(火) 06:13:33.64 ID:o88xwRN/ >>614 がいいこと言った。 見通しが良いコードにするための宣言型言語のはずが むしろ見通しを悪くしている。 http://mevius.5ch.net/test/read.cgi/tech/1530664695/636
637: デフォルトの名無しさん [sage] 2018/08/07(火) 07:56:24.18 ID:c0zbvnlv Scalaという見通しの悪い言語が関数型として世に知られてしまったのも不幸だったよね 意識高い系のオモチャに選ばれたのがScalaではなくF#だったら状況はだいぶ違っていたのではないか http://mevius.5ch.net/test/read.cgi/tech/1530664695/637
638: デフォルトの名無しさん [sage] 2018/08/07(火) 07:59:10.87 ID:6yZcjsMn 状態に依存する部分と純粋な部分を切り分けること自体は純粋関数型言語じゃなくてもできること そもそもHaskell使える開発者が集まってるならHaskellじゃなくてもみんな極力そのように書くし、 強制されないと副作用ごちゃまぜコードを書くような土方はHaskellは使えない 純粋性を強制するメリットが禁止して柔軟性を失うデメリットに釣り合ってない http://mevius.5ch.net/test/read.cgi/tech/1530664695/638
639: デフォルトの名無しさん [sage] 2018/08/07(火) 08:35:30.11 ID:iXXZIPQ5 純粋性を強制するメリット、を考えてみた。 例えばエディタの設定ファイルをHaskell自身で書くことができる。 設定ファイルがSafeHaskellであることを要請して、かつ設定操作に限定された型のみを許すようにする。 これで設定ファイルに、勝手にビットコインを採掘するスクリプトを忍ばせるような悪さができなくなるし、 Haskellそのものの柔軟性を活かして好きなだけ設定を短く表現できる。 安全さと強力さが両立された。 http://mevius.5ch.net/test/read.cgi/tech/1530664695/639
640: デフォルトの名無しさん [sage] 2018/08/07(火) 08:38:42.25 ID:FVK8LmPZ Haskellは状態に依存するコードを書こうとすると途端に 可読性の低い冗長なコードになるのがダメなところだと思う 純粋な部分の構文に比べて手抜きすぎなんだよ http://mevius.5ch.net/test/read.cgi/tech/1530664695/640
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 362 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.015s