前スレ
http://toro.2ch.net/test/read.cgi/tech/1320743217/
【アンチ】関数型言語は使えない【玩具】 ２
■ このスレッドは過去ログ倉庫に格納されています
2012/02/28(火) 20:45:47.95
2デフォルトの名無しさん
2012/02/28(火) 21:08:37.062012/02/28(火) 21:38:51.34
今時の技術についていけなくなったら辞めてくださいね
2012/02/28(火) 22:28:08.33
前スレで関数型言語は玩具にすぎないと結論出たからスレは不要
2012/02/28(火) 23:03:54.55
>>1乙
前スレ>>992-993
なら、Haskellもコンパイラの進歩でpythonに並ぶ余地はあるって事か
元々、length関数や、++演算子（リストの連結演算子）が初心者にも簡単に作れるってのが気に入ってるだけだから、体感できない速度差は気にならんけど・・・
Haskellに惹かれるのは、defとか、forとか、（モナド使わない限りはifも）そう言うキーワードをなるべく見ないで済むってのが、一番大きい気がする
（というか、forとifが一番見たくない）
あと、基本的に右辺と左辺が=（等しい）なのも気に入ってる
コンパイラのmain=...と言うのも、あながち間違ってない
速度こそpythonに劣るだろうけど、自作のmap関数や、++演算子などの":"で区切られて、状態を次の再帰に引き摺らないものは、単純再帰でも、ループとして扱われる
（だからこそ、末尾再帰は、次の再帰に状態を引き摺らないのでループになる）
結局、アセンブラに実現できることは、関数型言語でも、命令型言語でも、最終的な最適化の形は同じになるだろうけど、それは時間が解決する話
関数型言語の最終的な最適化の形は
http://ideone.com/SaMJe と http://ideone.com/kzkty が同じ速度になる事
これは、参照透明性が確保されて無いと、最適化できない事の一つ
（まだ実現されてないけし、逆に言えば、参照透明性が確保された関数に限れば、命令型言語でも理論的には最適化可能なはず）
前スレ>>992-993
なら、Haskellもコンパイラの進歩でpythonに並ぶ余地はあるって事か
元々、length関数や、++演算子（リストの連結演算子）が初心者にも簡単に作れるってのが気に入ってるだけだから、体感できない速度差は気にならんけど・・・
Haskellに惹かれるのは、defとか、forとか、（モナド使わない限りはifも）そう言うキーワードをなるべく見ないで済むってのが、一番大きい気がする
（というか、forとifが一番見たくない）
あと、基本的に右辺と左辺が=（等しい）なのも気に入ってる
コンパイラのmain=...と言うのも、あながち間違ってない
速度こそpythonに劣るだろうけど、自作のmap関数や、++演算子などの":"で区切られて、状態を次の再帰に引き摺らないものは、単純再帰でも、ループとして扱われる
（だからこそ、末尾再帰は、次の再帰に状態を引き摺らないのでループになる）
結局、アセンブラに実現できることは、関数型言語でも、命令型言語でも、最終的な最適化の形は同じになるだろうけど、それは時間が解決する話
関数型言語の最終的な最適化の形は
http://ideone.com/SaMJe と http://ideone.com/kzkty が同じ速度になる事
これは、参照透明性が確保されて無いと、最適化できない事の一つ
（まだ実現されてないけし、逆に言えば、参照透明性が確保された関数に限れば、命令型言語でも理論的には最適化可能なはず）
■ このスレッドは過去ログ倉庫に格納されています
