【アンチ】関数型言語は使えない【玩具】２

**デフォルトの名無しさん** · 2012/02/28(火) 20:45:47.95

前スレ
http://toro.2ch.net/test/read.cgi/tech/1320743217/

**デフォルトの名無しさん** · 2016/05/12(木) 21:17:01.69

馬鹿はOOPやってれば良いだろ・・・と言いたいところだけど、次世代の言語は
Haskell一択になるからね。
馬鹿でも使えないといけない。
使えるようにならなければ廃業するしかない。

**デフォルトの名無しさん** · 2016/05/12(木) 22:52:47.25

純粋な関数型言語でも破壊的操作できるしな
Strefとか

**デフォルトの名無しさん** · 2016/05/12(木) 23:10:15.34

>>614
それは純粋…なのか？

**デフォルトの名無しさん** · 2016/05/13(金) 00:06:04.14

STRefやSTArrayを使ってもIOと同じく純粋なんじゃない？
unafePerformIoは流石に純粋な関数じゃないけど

**デフォルトの名無しさん** · 2016/09/02(金) 11:30:53.61

純粋てそんなに大事か？

**デフォルトの名無しさん** · 2016/09/07(水) 03:49:40.44

関数型に習熟する程、コードが難読暗号化していくんだよね
結局、人間の脳の思考は手続き型なので、相容れない

**デフォルトの名無しさん** · 2016/09/07(水) 08:57:13.44

文系バカは黙ってろよ

**デフォルトの名無しさん** · 2016/09/07(水) 11:54:58.12

バカでもつかえる言語がいい

**デフォルトの名無しさん** · 2016/09/07(水) 13:38:27.31

状態のある関数を避けようとしても結局最後には必要になるんだよな

**デフォルトの名無しさん** · 2016/09/07(水) 14:11:30.18

関数型は状態を扱う箇所を局所化しやすいだけでそりゃ状態はどっかで扱うよ

**デフォルトの名無しさん** · 2016/09/07(水) 16:43:13.31

純粋関数支持者は理想の世界だけで生きててなかなかそこから抜け出さないんだよな
現実のどろどろした世界は一切触れようとせず、最後の最後でどうしても必要に
なると初めて触れるんだよ

**デフォルトの名無しさん** · 2016/09/08(木) 00:39:46.00

4年前のスレか
まだ生きてるのか

**デフォルトの名無しさん** · 2016/09/08(木) 00:40:58.48

>>581や>>583はtanakhか？

**デフォルトの名無しさん** · 2016/09/08(木) 01:09:27.51

>>623
それでアプリ動くならいいんじゃねーの

**デフォルトの名無しさん** · 2016/09/09(金) 21:09:27.70

逃げてるからいざさわると不自然になる

**デフォルトの名無しさん** · 2016/09/10(土) 18:41:34.87

モナドが汚い部分を全部吸ってくれる
空気清浄機のフィルター的な存在

**デフォルトの名無しさん** · 2016/09/10(土) 20:15:01.99

クソが詰まってる感じ？

**デフォルトの名無しさん** · 2016/09/19(月) 10:59:05.14

聳え立つ糞
mtl

**デフォルトの名無しさん** · 2016/11/15(火) 20:14:40.42

たまにコンビニでモナド買って食べたくなるよな。

**デフォルトの名無しさん** · 2016/11/17(木) 02:07:42.46

競技プログラミングの問題だとHaskellでエレガントに書ける場合が多い…気がする
現実の入出力の多いシステムの開発でどこまで役に立つかは知らん

**デフォルトの名無しさん** · 2016/11/17(木) 02:48:09.51

いや、競技プログラミングだと書きにくい。
最初の一問目だと条件緩いから良いんだけど、三問目くらいからかなりキツくなる
Haskellは油断するとオーダー滅茶苦茶嵩むので簡単にTLEするし、非道いときには想定解で実装してもギリギリ時間切れ喰らうこともある。
最悪なのはHaskellで最適化するのはかなりのウルトラCを要求され、超絶技巧コーディングを試験時間内に気づくのは困難を極める点。
競技プログラミングの条件はC言語で解くことを前提に作問されていて時間やメモリ使用制限が厳しい
Haskellでの参加者は大体前半までの正解者はいるが、後半の問題は提出者は僅かにいても正解者はほぼいない惨状
有名Haskellerでも競技プログラミングはC++で参加してるのが普通

**デフォルトの名無しさん** · 2016/11/17(木) 03:09:31.83

>>633
はぇ〜そうなのか
Haskellだと記述は楽なのだがそういう問題があったか
関数型言語は計算機の低レベルのアーキテクチャと大きくかけ離れてるから
同じコンパイラ型言語だと実行速度の最適化は手続き型言語に比べて限界があるのかもしれんな

**デフォルトの名無しさん** · 2016/11/17(木) 07:58:20.07

OCamlならいいんじゃね

**デフォルトの名無しさん** · 2016/11/18(金) 19:51:19.73

前スレの>>1の意見を見ると、商業主義に魂を売ってるのが分かる。
プログラミングの過程における新たな発見みたいな価値を全て
否定しているんだな。
玩具でもよくできた玩具ならそれだけで価値はある。
金になるかならないか考えるならプログラミングする必要はないし、
人を雇えばいい。他人にコードを書かせて一番儲かるプログラミング
方法を強制すればいいし、ほかには金を投資する事と営業する事だけを
考えればいい。
コンピュータ使って自分自身で何か作る必要ないじゃないか。

**デフォルトの名無しさん** · 2016/11/18(金) 20:13:59.76

>>633
>Haskellは油断するとオーダー滅茶苦茶嵩むので簡単にTLEするし、

これはない
定数部分が遅くなってもオーダーが間違ってるのはHaskellのせいじゃない

> 非道いときには想定解で実装してもギリギリ時間切れ喰らうこともある。

これはよくある

**デフォルトの名無しさん** · 2016/11/19(土) 14:19:16.69

Haskellはうっかり！！！プログラマのせい！！！で計算量を読み違えがちなので競技プログラミングには扱いにくい

参考
http://d.hatena.ne.jp/nishiohirokazu/touch/20100622/1277208908

**デフォルトの名無しさん** · 2016/11/19(土) 14:36:49.50

余再帰のコードは必然的に遅延評価絡みなので空間（ときどき時間）のオーダーを読み間違う
遅延評価ならではのコードを書かない限り気にする必要はない
あとは自己責任

**デフォルトの名無しさん** · 2016/11/19(土) 14:37:58.17

つうかそもそも競プロコード書いてるときに余再帰コード書くやつは根本的に色々間違ってるだろ

**デフォルトの名無しさん** · 2017/01/10(火) 22:20:35.26

そもそもHaskellは速いコード書く様な言語じゃないと思う。
reverse関数とかは配列と破壊的代入がある方が関数型の半分で済む。

ただ、手続き型より数学に近い言語だからコンピュータの仕組みが理解出来ない人にもプログラミング教えやすいとは思う。
(実際、変数に値を代入する(コピー)って感覚がわからない人はいた)

あと、参照透明だから、入力に依存しない関数はコンパイル時実行とか導入すれば速くなりそう。
去年知ったけど、いつの間にか普通の再帰が自動で末尾再帰最適化(ループへ変換)されてたから、Haskellもまだ最適化の余地は沢山あると思う。
(元々参照透明の強みは積極的な最適化だと言われてる)

今のHaskellみたいに並列処理に特別な関数や型を使うんじゃ無くて、普通に書いたらまんま並列処理できる様にもなって欲しい。
(参照透明の利点。ただ、効率的な並列がやりにくいとも)

それに、現行コンピュータのアーキテクチャから切り離されてるから、量子コンピュータとかにも使えそうとか、家にPCが無くても紙と鉛筆でプログラミング勉強しやすいってのはある。

**デフォルトの名無しさん** · 2017/01/11(水) 00:22:39.53

え、Haskellの実行速度、十分早いんじゃないの

**デフォルトの名無しさん** · 2017/01/11(水) 00:56:53.12

十分速いの定義が曖昧です

Java程度の速度は出ることが十分速いというのなら十分速いのでしょう
しかしC++/Cにはどうしても及びません

それから、この文脈のはやいは早いでなく速いがより適切です。

**デフォルトの名無しさん** · 2017/01/11(水) 01:30:51.23

とりあえず2chで誤字脱字の指摘はせんでえーよ。
変換間違えてもめんどいからそのまま書き込むし

**デフォルトの名無しさん** · 2017/01/11(水) 04:54:14.36

充分速いけど、手続き型よりコンピュータの特性活かしたコードにならないから。。。
単純に速さ求めるなら手続き型に敵わない。
保守性の高さとか、並列処理の書きやすさとかが関数型の利点。
万能だとは思わない方がいい。
(単純に関数型ならではの最適化を実装出来てないだけかもだけど)

いあ、ある程度の速度低下を許容出来るほど書いてて気持ちいいが。

**デフォルトの名無しさん** · 2017/01/11(水) 08:14:15.91

んー配列上のいくつかを入れ替えるってんならそりゃCの方が速いよね
がもうちょっと高度なロジックとかで遅延評価なども生きた時にともすればCを上回る時ガーって無いのかと。
いやじゃあその遅延評価もCで実装すればとかになっちゃうので結局人間のある程度の最適化＋コンパイラの最適化でこの規模のこういう奴だとHaskellの方が速かったって事例があるかって話になると思うのだけど。
まあそれよりも生産性の高さとかが土俵ってのは認識してる

**デフォルトの名無しさん** · 2017/01/11(水) 11:20:16.02

取り敢えずC#には勝ちたい

**デフォルトの名無しさん** · 2017/01/13(金) 06:50:42.54

>>646
安全性、生産性、速度が欲しいなら、素直にML使えよ

**デフォルトの名無しさん** · 2017/01/13(金) 08:10:23.06

F#でおけー

**デフォルトの名無しさん** · 2017/04/04(火) 12:35:32.05

ここまでC#圧勝

**デフォルトの名無しさん** · 2017/05/22(月) 00:29:15.41

x = x + 1
やっぱりこの式不自然なんだよ
確かに最初は漏れも違和感はあったさ

慣れちゃったけどｗ

**デフォルトの名無しさん** · 2017/05/22(月) 04:32:34.68

n
Σ f(i)
i=1
も不自然か？

**デフォルトの名無しさん** · 2017/05/22(月) 11:59:31.98

Σ f(i)
i ∈ {1,2,..,n}

でないと不自然だと思う派

**デフォルトの名無しさん** · 2017/07/02(日) 08:19:37.90

>>637
だうと。
適切なところで正格にして計算を掃き出してやらんと、途中の計算がデップリと太るぞ。

**デフォルトの名無しさん** · 2017/11/16(木) 18:01:27.10

x := x+ 1

**デフォルトの名無しさん** · 2017/12/01(金) 01:42:33.48

>>651
代数的に見たら左辺右辺は同時に起きてるから不自然だけど
変数一つ一つの手続きとして見たら同時ではないから不自然でもない

**デフォルトの名無しさん** · 2017/12/01(金) 10:32:26.35

そもそもxと書いてあっても左辺と右辺で意味違うから

**デフォルトの名無しさん** · 2017/12/30(土) 11:49:18.87

x.setValue(x.getValue()+1)

**デフォルトの名無しさん** · 2018/02/16(金) 06:28:20.88

☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

**デフォルトの名無しさん** · 2018/02/16(金) 17:09:26.03

恥を知れ

**デフォルトの名無しさん** · 2018/05/23(水) 20:55:10.20

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

MRENS

**デフォルトの名無しさん** · 2018/07/05(木) 00:58:45.63

Y2X

**デフォルトの名無しさん** · 2018/08/23(木) 15:45:34.06

>>660
聡を知れ