関数型言語は何故普及しないのかを考える
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/10/11(月) 19:07:49このテーマの存在をどうかお忘れなきよう願います。
前スレ
関数型言語は何故普及しないのかを考える
http://hibari.2ch.net/test/read.cgi/tech/1277215506/l50
0685デフォルトの名無しさん
2010/12/23(木) 16:46:21http://hibari.2ch.net/test/read.cgi/tech/1289292155/477
関数型言語でどうやるかはしらない。
0686デフォルトの名無しさん
2010/12/23(木) 17:18:242進数はn進数の一種だからbit演算子より整数の割り算と余りの方が良いのでは？
http://haskell.org/ghc/docs/7.0-latest/html/libraries/haskell2010-1.0.0.0/Prelude.html
>div :: a -> a -> a
> integer division truncated toward negative infinity
>mod :: a -> a -> a
> integer modulus, satisfying
> (x `div` y)*y + (x `mod` y) == x
>divMod :: a -> a -> (a, a)
> simultaneous div and mod
0687デフォルトの名無しさん
2010/12/23(木) 19:20:00超ありがとう。満足♪
f :: Int -> IO ()
f n = if n==0 then return () else f (Data.Bits.shiftR n 1) >> (printf "%d" (n .&. 1))
g n k = if n==0 then return () else g (div n k) k >> (printf "%d" (mod n k))
reverseを使ってみた版
当初IO [a]をliftMでreverseみたいなのが頭の中にあったものの
printとかじゃIO[a]は作れなかったので
結局リストに入れただけ
思ったより複雑になってしまったし
あまり利点が感じられなかった
h:: Int -> Int -> [IO ()]
h n k = if n==0 then [] else (printf "%d" (mod n k)) : (h (div n k) k)
i n k = List.reverse $ ((putStrLn ""):(h n k))
j k n = List.foldl (\a b -> a >> b) (return ()) (i n k)
tester k = mapM_ (j k) [1..10]
--2進数と3進数で10まで出力
main = tester 2 >> tester 3
0688339
2010/12/23(木) 19:36:49規制で書けなかった
おまえは一行で言語の仕様を全て把握できるんだな？
定義しようが同じ関数には違いないんだろ？
a <== b <== c <== d
<==は関数であり文の外で定義されているものとする
<==はxクラスを受け取ってyクラスを渡す
ab間bc間cd間が同じ関数だと知ることができる
関数は関係そのものである
従って同じ関係であると"知ることができる"
e<==(f<==(g<==(h)))
g<==メソッドはmクラスを受け取りnクラスを渡す
f<==メソッドはnクラスを受け取りmクラスを受け取っていない
同じ関係となるためには渡すクラスもmクラスにする必要がある
ところがそれを一箇所で定義できないため確信できない
定義が誤って一致したとしても文中でそれを知る術が無い
コピペを変更し忘れた場面を想像して欲しい
したがって同じ関係かどうか"知ることができない"
OOPLも演算子オーバーライドを使えば書くことはできる
だがそれはOOPLに不要な機能とされている
現にJAVAはC++との差別化を図りそれを削っている
C++もCの思想を優先したに過ぎない
「プログラマーのできることを制限しない」という思想だ
すなわち高級言語とは真逆の思想だ
0689339
2010/12/23(木) 19:38:22a(b)
aとbが関数でありxクラスを受け取ってxクラスを返すものとする
するとaとbを入れ替えて書くこともできる
入力に関わらず同じ値を返す関数を想像してくれ
全体の関係は変わるがaとbの定義は変わらない
述語と目的語が場面によって換わるので自然言語的とは言えない
e.f
OOPLで入れ換えるにはf.eを別に定義することになる
同じ名前であってもオブジェクトとメソッドという定義が変わる
したがって入れ換えることができず自然言語的と言える
人は理由も無く面倒なことはしたがらない
ましてそれが良くないと判っていればなおさら
つまり面倒であることが抑止力になるということ
関数型は自然言語的でないしそれっぽく書くのも面倒
上の例で判るように一文に関数を詰め込んだ方が書き易いから
思想が反映された書き方の違いこそ言語の違い
高級言語は何をできるかより何をできないかに存在意義がある
関数型はOOPLより少しできてしまうから低級なだけ
低級な言語を理由無く使おうとしないのが人間の心理
普及させたければ使う理由を作ってやれば良い
0690339
2010/12/23(木) 19:40:57じゃあ自分と何かとの関係を考えてみてくれ
├──関係─→┤＿＿何か＿＿│
関数型であればこうなる
├──関数─→┨＿＿何か＿＿┃
何かが関数であればこうなる
├──関数─→┨＿＿関数＿＿┃
関数は直接扱える
扱えないと既に関係を扱っていることと矛盾するため
関数を直接扱えるということは関数を知ることができる
関数は関係そのものだから関係も"知ることができる"
どこからどの関数なのか境界が曖昧になるところに注目
それこそが参照透過性や遅延評価の有無になる
OOPLであればこうなる
┃＿＿＿オブジェクト＿＿＿＿┃
├─メソッド→┨＿＿何か＿＿┃
何かがオブジェクトであればこうなる
┃＿＿＿＿＿＿＿オブジェクト＿＿＿＿＿＿＿┃
├─メソッド→┨＿＿＿オブジェクト＿＿＿＿┃
├─メソッド→┼─メソッド→┨＿＿何か＿＿┃
オブジェクト以外の何かは直接扱えない
直接何かを扱うことがオブジェクトの定義に反するため
従ってメソッドは直接扱えず知ることができない
メソッドは関係そのものだから関係も"知ることができない"
関数型はミクロの関係を扱おうとする
OOPLはマクロの関係を扱おうとする
相反する概念なのだから良いとこ取りはできない
関数型言語を知らなくても本質は語れる
関数とオブジェクト指向を理解してればな
これでも解らないならもう知らん
0691デフォルトの名無しさん
2010/12/23(木) 20:33:55そうだな、俺が悪かった、もう許せ
0692デフォルトの名無しさん
2010/12/23(木) 21:25:59>>622は論理回路、金融デリバティブと書いてるが他にもある？
0693デフォルトの名無しさん
2010/12/23(木) 21:31:32科学技術計算ではFORTRANに勝てず
低水準の仕事ではCやアセンブラに勝てず
事務計算ではCOBOLに勝てず
WebではJavaやLLに勝てないから
きんゆうでりばてぃぶとかになるのか？
0694デフォルトの名無しさん
2010/12/23(木) 21:39:230695デフォルトの名無しさん
2010/12/23(木) 22:00:50おもちゃとして遊びに使われるに決まってる
おれは Haskell で遊んでるぞ
0696デフォルトの名無しさん
2010/12/23(木) 22:09:140697デフォルトの名無しさん
2010/12/23(木) 22:15:050698デフォルトの名無しさん
2010/12/23(木) 22:25:29parseん：じいさん、manyはさっき(コンパイラが)食ったばかりですよ
0699デフォルトの名無しさん
2010/12/23(木) 22:44:52状況とか価値の判断がおかしくなるんだよ
幼児よりもキチガイに近い
もともと頭の悪かったやつにプログラミングなんてやらせても意味ない
0700デフォルトの名無しさん
2010/12/23(木) 22:49:11さすがにCOBOLには勝ってるのでは…
それと、低水準の処理でアセンブラに「勝てる」言語など、永遠に登場しないだろう。
コンピュータ・アーキテクチャが変わりでもしない限り。
0701デフォルトの名無しさん
2010/12/23(木) 23:21:24いやマジでつっこまれてもｗ
COBOLって任意桁数のBCD演算やらISAMやらを組み込みで持ってて
メインフレームの固定長データセットに非常に相性が良いようだし
COBOLが使われてる分野では未だに圧倒的なシェアを誇る言語だと
思っていたけど、何しろ全然詳しくないので…
事務処理の世界はもう関数型の独壇場だったのか？
0702デフォルトの名無しさん
2010/12/23(木) 23:30:170703デフォルトの名無しさん
2010/12/23(木) 23:33:430704デフォルトの名無しさん
2010/12/23(木) 23:36:57例えば給与明細の紙を出力するためにデータベースからデータを取ってきて
それを整形表示して印刷とかそんなの？
0705デフォルトの名無しさん
2010/12/23(木) 23:38:50相当範囲は広い。
0706デフォルトの名無しさん
2010/12/23(木) 23:44:160707デフォルトの名無しさん
2010/12/23(木) 23:46:38勝てないのに普及させるのは相当難しくないか？
0708デフォルトの名無しさん
2010/12/23(木) 23:48:49うん俺もそんなんをイメージしていた
汎用機にもツリー型とかリレーショナルなデータベースはあるはずだけど
固定長のISAMファイルって要するに簡易的なデータベースだから
ただのISAMでやってるケースも多いのではと思われ
バッチだけでなくオンライン的な処理が必要な場合は
資源管理のためにトランザクションモニタとかジョブキューとか使うんだろう
Javaは特別にその種の仕事に特化した言語じゃないから、
J2EEあたりのブクブクに太ってた頃のJavaでリプレースしようとして
泣いた会社は結構あるのでは
全然詳しく無いし、ただの想像だけど
0709デフォルトの名無しさん
2010/12/23(木) 23:50:110710デフォルトの名無しさん
2010/12/23(木) 23:51:080711デフォルトの名無しさん
2010/12/23(木) 23:53:350712デフォルトの名無しさん
2010/12/23(木) 23:57:45C++, Java, C#, Flash/ActionScript, Luaといったあたり？
0713デフォルトの名無しさん
2010/12/24(金) 00:06:06アダルトに特化するしかない
0714デフォルトの名無しさん
2010/12/24(金) 00:06:32メーカによりけりだろ？
メーカー固有のゲーム製作言語とかあったりするし…
0715デフォルトの名無しさん
2010/12/24(金) 00:09:36つまり「大人のおもちゃ」か！
0716デフォルトの名無しさん
2010/12/24(金) 00:22:33Real World Haskell を成人図書コーナーに置けば
中高生が隠れて読み耽るだろう
0717デフォルトの名無しさん
2010/12/24(金) 05:45:44http://www.indeed.com/jobtrends?q=Perl,PHP,Python,Ruby,COBOL,Fortran,Lisp,SML,Haskell
COBOLの求人はLLに抜かれましたが、関数型言語の数十倍あります。
http://www.indeed.com/jobtrends?q=Lisp,SML,Haskell,Scala,Clojure
古参をごぼう抜きしたScalaは普及が続くかも知れません。
0718デフォルトの名無しさん
2010/12/24(金) 07:46:13プログラムしてて楽しければ、役に立たなくてもいいじゃん
（応用じゃない）純粋な数学と同じだよ
0719デフォルトの名無しさん
2010/12/24(金) 07:48:44なんで考えるかというとそういう趣旨のスレだから
0720デフォルトの名無しさん
2010/12/24(金) 07:49:13Webアプリを簡単に組めないプログラム言語を
探す方が難しい。
0721デフォルトの名無しさん
2010/12/24(金) 07:52:41数学的思考が出来ないドカタは理解出来なくて当然！
こういう上から目線が多いから、いつまでたっても普及しない。
0722デフォルトの名無しさん
2010/12/24(金) 07:53:07あると、将来その分野に進出するケースも
想定して忌避することはある。関数型言語の
場合ここら辺はあるのかな。
0723デフォルトの名無しさん
2010/12/24(金) 07:54:35それは、はっきりいって、あると思う。
0724デフォルトの名無しさん
2010/12/24(金) 09:33:09まあ、プログラム言語としての利用じゃないわけだけどね。
0725デフォルトの名無しさん
2010/12/24(金) 10:14:050726デフォルトの名無しさん
2010/12/24(金) 10:33:39数値計算とか数式処理って専用のソフト使わないの？
matlabとかmathematicaとか
0727デフォルトの名無しさん
2010/12/24(金) 10:58:42そもそも関数型を本当に普及させたいのかと疑問に思う
自分はポルシェを乗り回せるぜ、というひとは、ポルシェがカローラになるより
ポルシェのままのほうがうれしいのでは？
0728デフォルトの名無しさん
2010/12/24(金) 12:36:18それもあるし、関数型が普及する必要があるとみんな思ってるのかも疑問
普及する必要あるのか？
無ければ普及しないぞ
0729デフォルトの名無しさん
2010/12/24(金) 13:23:24Haskellは、IOモナドが分かりにくいのが一番の理由じゃないかな。
副作用を分かりやすく形式化したもののはずなのに、これが分かりにくくて普及しないって、にんともかんとも。
0730デフォルトの名無しさん
2010/12/24(金) 15:37:43部分評価とか非正格評価は分散サーバとかに使える。
純粋ナンタラで美しいｨｨ！とか
モナドはストリームより表現力が上ｪｪｪ！
とかはどうでもいい。
0731デフォルトの名無しさん
2010/12/24(金) 15:56:03普及した方が、給料は上がる。
0732デフォルトの名無しさん
2010/12/24(金) 16:29:50一般に、普及すると仕事は増えるけど給料は下がるのでは
需要「だけ」が増えれば給料も上がるかもしれないが
そういう都合のいい普及の仕方ってあるのだろうか
0733デフォルトの名無しさん
2010/12/24(金) 16:49:37普及の程度にもよるけど。10年後に世の中の主流が
Haskellになると周知されたら、今、ソフトウェアハウス
で月給40万のHaskellプログラマの月給は転職前提で
100万を超える。そういう意味で。それを夢見て。
0734デフォルトの名無しさん
2010/12/24(金) 17:01:220735デフォルトの名無しさん
2010/12/24(金) 17:43:361番でなくては。
0736デフォルトの名無しさん
2010/12/24(金) 19:11:45その給料を出す方から見た関数型の必要性は？
0737デフォルトの名無しさん
2010/12/24(金) 21:20:09最近の数値計算はMatlabとC、C++が主流っぽい
0738デフォルトの名無しさん
2010/12/24(金) 21:22:460739デフォルトの名無しさん
2010/12/24(金) 21:29:580740デフォルトの名無しさん
2010/12/25(土) 00:21:59やはり、Webかクラウドに最適だと言えなきゃね。
0741デフォルトの名無しさん
2010/12/25(土) 00:53:530742デフォルトの名無しさん
2010/12/25(土) 01:04:590743デフォルトの名無しさん
2010/12/25(土) 01:15:03マルチコアCPU時代のプログラム言語は関数型言語でウッドボールって
説はどうなったの？
最近、あんまり聞かないから、フカシだったの?
0744デフォルトの名無しさん
2010/12/25(土) 01:57:05「ねぁ、はやく。はやく、あなたを感じたいの！」
「ふふ… ここかい？ ここが君のメールボックスなのかい？」
「そうそうよ。はやく、あなたの… あなたのメッセージを私にいれて」
「いいね？ 一緒に動くんだよ」
「いいから、はやくあなたのメッセージをいれてったら！」
>>743
「あら？ 早漏？」
0745デフォルトの名無しさん
2010/12/25(土) 02:34:54ItaniumのEPIC向けの最適化にも関数型言語が適してるなんて話もあったなｗ
0746デフォルトの名無しさん
2010/12/25(土) 02:52:54って、以下の考え方でおｋ？
(L1 L2 L3 ... Ln)
で、L(k+1)はLkの結果とは関係がない
Lｋは互いに無関係だから別々のスレッドで処理できる
さらにLkは
(M1 M2 ... Mn)
で、M(k+1)は以下略
どんどんスレッド増えていくからうまくいってないのかな
0747デフォルトの名無しさん
2010/12/25(土) 03:00:50条件が厳しすぎると思う。状態の概念は導入しないと。
0748デフォルトの名無しさん
2010/12/25(土) 05:50:090749デフォルトの名無しさん
2010/12/25(土) 09:12:080750デフォルトの名無しさん
2010/12/25(土) 11:18:390751デフォルトの名無しさん
2010/12/25(土) 13:20:41関数型って難解なのか？
何年もかけて習得した手続き型でのテクが使えないから
最初は手も足も出ないが
0752デフォルトの名無しさん
2010/12/25(土) 13:40:500753デフォルトの名無しさん
2010/12/25(土) 13:56:00結城浩とかえぴすてーめーとかやねうらおｗとか
0754デフォルトの名無しさん
2010/12/25(土) 13:56:51俺選 ザ・手続き型コード
while(*p++=*c++){}
0755デフォルトの名無しさん
2010/12/25(土) 13:56:56ただ鉄痔木型のノウハウがあまり通用しなかったりするのもたしか
0756デフォルトの名無しさん
2010/12/25(土) 13:59:12例えばJavaを書いてる人がRubyを習得するのは「比較的」楽だろう。
その習得を容易にさせた何かの総称。
Rubyを触った時は方言が聞き取りにくいが日本のどっかって感じだが
Hakellを触るのは外国に来た気分だった。
0757デフォルトの名無しさん
2010/12/25(土) 14:03:160758デフォルトの名無しさん
2010/12/25(土) 14:15:54ワードカウントといったら辞書にワードを挿入、カウントをインクリメント
するんだろ、とかまず発想するし
深さ優先探索といったらスタックの出し入れだの枝のマーキングだのを考える
そもそも「深さ優先」とかいう時点で計算の順序を思いっきり想定している
0759デフォルトの名無しさん
2010/12/25(土) 14:22:42ループと外部イテレータ。
ループが外部に晒され、副作用も晒される。
外部イテレータがあれば内部イテレータも簡単に書けるが、逆は難しい。
つまり、副作用ありの言語で副作用を隠蔽するのは簡単だが、逆は難しい。
0760デフォルトの名無しさん
2010/12/25(土) 14:51:30それとおすすめの関数型言語の本があったら教えて欲しい
来年はとりあえずその言語の習得から始めようかと思ってるんで
0761デフォルトの名無しさん
2010/12/25(土) 15:04:320762デフォルトの名無しさん
2010/12/25(土) 16:07:37もう「関数型の」利点なんて大して無いんじゃね
俺にとって使い易い言語がたまたま関数型だっただけだと思ってる
「プログラミングHaskell」おすすめ
0763デフォルトの名無しさん
2010/12/25(土) 16:13:27それを読んだら、「関数プログラミング」もおすすめ
0764デフォルトの名無しさん
2010/12/25(土) 17:30:300765デフォルトの名無しさん
2010/12/25(土) 17:36:03スタックを浪費するだけのアホ再帰は有害。
半端に関数型かじった生半可な奴がよく書く糞コードの典型例。
0766デフォルトの名無しさん
2010/12/25(土) 17:38:530767デフォルトの名無しさん
2010/12/25(土) 17:41:41再帰が見えない連中の典型的なコメント。
ここで、「見える」とは棋士が「読む」のでは
なく、一瞥で決める。そういう意味。
0768デフォルトの名無しさん
2010/12/25(土) 17:45:06世知辛い世の中だな。
0769デフォルトの名無しさん
2010/12/25(土) 18:06:51わかりやすいという奴がいたらお目にかかりたいものだよなw
0770デフォルトの名無しさん
2010/12/25(土) 18:22:19自分の知っている事を事前条件にしようとしてるって意味で
プログラム言語だというくくりで学習しようとするから成長曲線が鈍るんだよね
パラダイムシフトって単語使うのはいやだけど考え方が違う物なのだから、
一度自分は何も知らないって地点に立ってくれるだけで楽に学習可能なハズなんだけど
そういう事をするには既存言語で得た地位が高いプライドになって邪魔してる感じ
0771デフォルトの名無しさん
2010/12/25(土) 18:32:25「早すぎる最適化は諸悪の根源である」という格言を知らない人なのかも
知れないけど、たんに再帰を苦手な人が「パフォーマンスが悪いから書くな」と
言っているだけのことが多いんだろうな
0772デフォルトの名無しさん
2010/12/25(土) 18:36:05なんつーか手続き型でいきなり書くとしっくりこないw
0773デフォルトの名無しさん
2010/12/25(土) 18:37:21> 一度自分は何も知らないって地点に立ってくれるだけで
簡単にいうけど、そう簡単なことではないのでは
多くの人にとってプログラミング言語は単に目的を達成するための手段で、
慣れた言語なら簡単に達成できることのために一度全てを捨てるほどの
多大な努力を必要とするなら、よほどの動機付けやメリットが必要になる
0774デフォルトの名無しさん
2010/12/25(土) 18:37:50一番の利点はプログラミングに対する学習コストが下がることだと思う
駆け出しの頃、iとかjとか色々な変数の意味の解析からしなきゃならなくて
クイックソートのコードってなんて難しいんだって思ったものだけど
あれがHaskellであったなら、すっきり理解できただろうと思う。
短い上、リスト内包表記と再帰理解すればいいだけだし
0775デフォルトの名無しさん
2010/12/25(土) 18:40:48それぐらいの話なら関数型言語である必要は無い気がする
要は高級言語であればいいんだよね、Pythonみたいな
リスト内包も再帰も使えるよ
0776デフォルトの名無しさん
2010/12/25(土) 18:42:05クイックソートは末尾再帰じゃないから、手続き型でもループは使わないよ
その思い出話は捏造くさい
0777デフォルトの名無しさん
2010/12/25(土) 18:42:33高階関数の使用に原因がある、という意見はあまり聞かないが。
人間の問題の解く際の理解力、構成力の個人差を考えると、凡庸
な頭脳の持ち主にとって、障壁になりそうなのは、ここら辺り。
頭がオーバーヒートして、思考停止に陥る危険があるのかも知れ
ない。 この問題が原因だとすれば深刻。
0778デフォルトの名無しさん
2010/12/25(土) 18:44:56higher order functionを難しい人は確かにいるだろうけど、
そういう人はCでqsort()やsignal()、コールバックを使うにも困るはずなので、
別にぜんぜん関数型に限った話じゃない
そうした人はたんにプログラマに全く向いていない人であるというだけのこと
0779デフォルトの名無しさん
2010/12/25(土) 18:51:52多くのプログラマが現に使えないし、多分、プログラマと
して向いていない。それにもかかわらず、プログラマとして
何十万人(多分もっとずっと多い)も存在している。
0780デフォルトの名無しさん
2010/12/25(土) 18:52:39なんというかPythonはわりと関数型言語に近いと思うんだよね
何故関数型言語が普及しないのかってスレだけどさ
普通の言語にどんどん関数型の機能が取り入れられてるから
関数型の考え方はどんどん普及してるってのが個人的な思い
少し言えば、理解コストについては、
型がある言語のほうが低いと思う
引数の型を調べるコストが減るからね
>>776
手続き型でも再帰の理解が必要ってのは省いたよ
0781デフォルトの名無しさん
2010/12/25(土) 18:59:54うん、現に今のメジャーな手続き型言語の多くが何らかの形で
ファーストクラスの関数的なものを扱えて、LISPのリスト処理能力をある程度
パクってる
手続き型をベースとしているけど、関数型の便利なところをどんどんパクっている
C#、JavaScript、Ruby、Pythonのような言語で特に困っていない人たちに
アピールできるようなメリットがなければ、なかなか普及は難しいんじゃないの
0782デフォルトの名無しさん
2010/12/25(土) 19:01:26だから、コード量が多いと、些細な事でもこれはどういう意味だろうって考えて
アルゴリズムの重要な部分とは違う所で止まってしまう
関数型は手続き型に比べてそういうのが少ない
Win32APIとかでコードを書こうとしてた頃にやっと
「全部理解しようとすると結局挫折する」ってことを学んだけど
最初はそういうのわからなかったから結構勉強は時間かかった
あと、クイックソートは非再帰版も良く見るよ。スタック使うやつ
まぁスタック使えばどんな再帰もループに展開出来るわけだが
0783デフォルトの名無しさん
2010/12/25(土) 19:06:04無限ループしてない限りは、オーバーフローしないよね。
0784デフォルトの名無しさん
2010/12/25(土) 19:09:33個人的には代数的データ型が欲しい
オブジェクト指向でinstanceofで派生クラスチェックとか、
全く型システムの恩恵を受けてる気がしない
■ このスレッドは過去ログ倉庫に格納されています