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

1 ：2012/02/28 〜 最終レス ：2012/10/21

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

2 ：

オブジェクト指向言語で関数型風味(？)に書いたらこんな感じ？
http://ideone.com/CXMrq
要素数と実行時間が何の関係無くなるけど
そもそも何を比較してたんだっけ

3 ：

今時の技術についていけなくなったら辞めてくださいね

4 ：

前スレで関数型言語は玩具にすぎないと結論出たからスレは不要

5 ：

>>1乙
前スレ>>992-993
なら、Haskellもコンパイラの進歩でpythonに並ぶ余地はあるって事か
元々、length関数や、++演算子（リストの連結演算子）が初心者にも簡単に作れるってのが気に入ってるだけだから、体感できない速度差は気にならんけど・・・
Haskellに惹かれるのは、defとか、forとか、（モナド使わない限りはifも）そう言うキーワードをなるべく見ないで済むってのが、一番大きい気がする
（というか、forとifが一番見たくない）
あと、基本的に右辺と左辺が=（等しい）なのも気に入ってる
コンパイラのmain=...と言うのも、あながち間違ってない
速度こそpythonに劣るだろうけど、自作のmap関数や、++演算子などの":"で区切られて、状態を次の再帰に引き摺らないものは、単純再帰でも、ループとして扱われる
（だからこそ、末尾再帰は、次の再帰に状態を引き摺らないのでループになる）
結局、アセンブラに実現できることは、関数型言語でも、命令型言語でも、最終的な最適化の形は同じになるだろうけど、それは時間が解決する話
関数型言語の最終的な最適化の形は
http://ideone.com/SaMJe と　http://ideone.com/kzkty が同じ速度になる事
これは、参照透明性が確保されて無いと、最適化できない事の一つ
（まだ実現されてないけし、逆に言えば、参照透明性が確保された関数に限れば、命令型言語でも理論的には最適化可能なはず）

6 ：

>>5 最後の行について
Fortran95には、純粋関数/手続きというのがあって、これは副作用を持たない
ということなのたが、ベクトル演算ができるようになる。
が、write文が使えなくなるとか、グローバル変数が使えないとかいろいろ
制約があって非常に使いにくい。

7 ：

●過去スレ
関数型言語は何故普及しないのかを考える
http://hibari.2ch.net/test/read.cgi/tech/1277215506/
関数型言語は何故普及しないのかを考える
http://hibari.2ch.net/test/read.cgi/tech/1286791669/
【アンチ】関数型言語は使えない【玩具】
http://toro.2ch.net/test/read.cgi/tech/1320743217/
●関連スレ
関数型言語Part5
http://toro.2ch.net/test/read.cgi/tech/1252470706/

8 ：

速度比較は、よくネタになるけど、最も抽象度の低い言語でも出来る例での比較→言語自体の優劣の流れは無意味だろ。
VBとアセンブラを比べるようなもんだけど、単純作業での比較にこだわる人が多いのはなんでだろう？

9 ：

なぜ関数型言語は普及しないか - プログラミング日記
http://d.hatena.ne.jp/morchin/20110614/p1
「なぜ関数型言語は普及しないか」に対する言及
http://togetter.com/li/149656
関数型言語が普及しない理由 - mizon dev
http://d.hatena.ne.jp/mizon9/20111112/1321046483
関数型言語が普及しない理由その2 - mizon dev
http://d.hatena.ne.jp/mizon9/20111112/1321128525
関数型言語が普及しない理由 - 偏見プログラマの語り！
http://d.hatena.ne.jp/kura-replace/20111114/1321236695
関数型言語が普及しない理由 - より良い環境を求めて
http://d.hatena.ne.jp/n314/20111114/1321290502

10 ：

>>8 パッと見て、いろいろ言えるからではないだろうか。
そこそこ重たい数値計算をやりだすと、関数型言語が謳う理想通りにいかない
場面はいろいろあるのだが、2chのように限られた字数でしかも関係者外にも
わかるように問題点を説明するのはなかなかうまくいかない。

11 ：

個人的にはHaskell、lispはアプリ言語が欲しい時によく使うし、C、Javaはインフラで使ってる。
各言語には目的によって向き不向きがあるから、用途を論じるとか、用途拡大方法を考えるならまだ判る。
同じような単純作業の比較で何を得たいのか判らないんだよね。

12 ：

>>8
抽象度が低くてもチューリング完全なら最終的にできることは一緒
どれだけ簡潔に書けるかという意味でいうなら、reverseという簡単な例ですら
CとHaskellには大きな差がちゃんと在った
つーか前スレの配列版HaskellはCの次に速かったぞ
コード量もC並みだが

13 ：

>>12
>reverseという簡単な例ですら
そういう単純な例で実行時間が違うのはわかるけどさ、それを言語全体の優劣判定に短絡するのが無意味だと思うんだが。
コンピュータの利用範囲が広がるに連れて、アセンブラだけでは実現に手間がかかるから色んな言語が開発された訳だから。
例えば金融商品企画のようなアプリを、リソースを大量に使えばCでも開発は理屈上は可能だが、
それはもはやHaskellのインタープリターをCで再発明するくらいの問題になる。
だから疑問は、リソースには色々あるのに、なぜ単純な例で時間だけに拘るのか？という事。
単純例しか経験がなくて、時間以外のリソースは微々たるものだと考えてる者なら必然だけどね。

14 ：

誰かHaskellが遅いから言語として劣ってるって書いてたっけ？
事実としては「Haskellは遅い」それだけ
言語の優劣は各自で判断すべき

15 ：

はっきり数字出ましたし。

16 ：

関数型のリファレンス言語と見られる言語が遅かったら
そりゃ価値を見出せないよ

17 ：

速さならOCamlがC並ってのは良く聞く
自分はdefとかrecとか関数定義にプログラミング言語特有のキーワード使う機会が少ないのが気に入ってhaskell使ってるけど

18 ：

>>13
>単純例しか経験がなくて、時間以外のリソースは微々たるものだと考えてる者なら必然だけどね。
このスレは、既存のHaskellコンパイラより早いHaskellインタープリターを自作出来る猛者が集う場所ですよ？

19 ：

遅い遅いって一生言ってろ、でいいんじゃね？
シートベルトって窮屈じゃん、って言ってるバカと同じなんだから。

20 ：

>>14
>事実としては「Haskellは遅い」それだけ
そのとおり。
Haskellでできる事は全部、C、Pythonならもっと早く出来る。
時間は重要なリソースだという事は学生にはわからんだろうな。

21 ：

>>20
えっ。Haskellの遅延評価のようなことがC、Pythonなら
もっと速くできるなんていっていいのですか。
少なくとも「早く」はできませんよね。

22 ：

>>21
そういうときは、コードを書いて「これを書いてみろ」って言うくらいじゃないとね
ていうか、遅延評価は手段のひとつであって、それ自体が目的であることは滅多に無い

23 ：

時間という点では開発時間も重要だね
でも長いコードと、それと同性能で短いコードで
前者の方が早く作れたりするのは良くあることだから
コード量と開発時間の相関も割りと微妙なんだよね
学習コストだとか、命令型と関数型の両方を扱える人のうち
関数型の方が早く開発出来る人の割合とかも気になるところ

24 ：

haskellが遅いってのは、
c/c++より遅い、あるいは静的言語の中では平均的に遅い、という意味なんだが、
時々文脈を（意図的に？）混同して、スクリプト言語よりも遅いとか言い出す輩が後を絶たない。
前スレで可変長配列と片方向連結リストを混同して勝利宣言してる馬鹿を見た時はまたかと思ったよ。

25 ：

>>17
夢を壊して申し訳ないが...
OCaml
http://ideone.com/MqIzH  （リスト）
http://ideone.com/LH93F  （配列）

26 ：

藁人形製作乙です。。。

27 ：

>>24
Haskellは可変長配列に代表されるような速いデータ構造を
扱おうと思ったら途端に面倒になるのが問題なんだろ
悔しかったらPythonより速いコードをPython並みに簡潔に書いてみろ

28 ：

Haskell並みに安全で機械語にコンパイルされたコードをPythonから生成してから言え

29 ：

>>28
Haskellが安全？www
xs = head []

30 ：

実行速度の比較をしているときに安全とか抽象力とかいうから
虫ケラ、じゃなかった、ハスケラはコミュ障だっていわれんの！

31 ：

>>28
Pythonより速いコードをPython並みに簡潔に書けないという
ギブアップ宣言か
もう「Haskell = 遅い」が定着しそうな勢いだな

32 ：

pythonは永続データと破壊操作を巧みに両立させて速度稼いでいるからな。
どっかでhaskellの人が永続=透明性と書かない人は理解してない人と断定してたけど、
どうしてhaskellの有名人はみんなアレなんだ？

33 ：

おまえの脳内の勢いがすごい勢いで加速中ということはよくわかった

34 ：

vectorパッケージが見つからない、と思ったらGHC6.8とはね・・・
古すぎるだろ・・・・
ふふふ残念ながらMPが足りないようだ・・・

・・・とするのは悔しいので前スレのSTUArray版(お借りします)とVector版を手持ちの環境で走らせて計測してみましたよ
STUArray版（コードは省略）
結果（+RTS -sオプションから抜粋）
9 MB total memory in use (0 MB lost due to fragmentation)
Total time 0.12s ( 0.10s elapsed)
次はVector版
コード
module Main where
import qualified Data.Vector.Unboxed as V
main :: IO ()
main = print $ V.head $ V.reverse $ V.iterateN 1000000 (+1) (1 :: Int)
結果
5 MB total memory in use (0 MB lost due to fragmentation)
Total time 0.05s ( 0.04s elapsed)
まあこんなところですね

35 ：

隔離スレとして、ちゃんと機能してるようで何より。

36 ：

「なんで時間だけに拘るの？」
「遅いのは事実だ！！」
凄いコミュ力だなw

37 ：

>>23
>コード量と開発時間の相関も割りと微妙なんだよね
その言語に慣れている者が書くという前提で、一日に書けるコード量は言語による大差は無いというのをどっかで見た。

38 ：

コード書いてる時間より
ビルド, 実行, ソースとにらめっこ, ウロウロしながら思考
してる時間の方が長い希ガス

39 ：

コード量が同じなら抽象度の高い言語の方が多くの事が出来るだろうな。

40 ：

>>39
一般に低水準の言語の方がワード単位の入力時間が短くなる。
極端な場合、倍位にはなる。だから、よほど難しい問題でないかぎり、
>>37がいうように一日に書けるコード量は同じに、近い。
しかし、それだけ体力もいるから、プログラマの定年が若くなる。
高水準な言語だと60歳でも十分。この差は大きい。

41 ：

高水準な言語とはもしかしてCOBOLのことを言っているのだろうか。

42 ：

リスト操作の速度を比較しようって決まって、
ベンチマークも決まって実装計測して結果が揃ったところで
どうして時間だけとか言い出すのは完全にコミュ障だろw

43 ：

数行の「リスト操作」って、何を比較したことにもならんぞw

44 ：

>>43 くやしいのうw

45 ：

gccがhaskellになったら考える
なったらなったでメンテする人がいなくなりそうだけど

46 ：

>>43
まあ元々、アッカーマンとか無視してる時点で、無意味だから。

47 ：

haskellが一行で配列を高速にreverseしたのがそんなに悔しいんですか？

48 ：

reverse関数「を」どれくらい簡潔に実装できるかって話してたのに
（しかも言い出したのはHaskeller）
ライブラリのreverse関数呼び出してドヤ顔して馬鹿じゃないの？

49 ：

>>31を「1行」とかいう人は
目か頭のいずれかもしくは両方とも悪い。

50 ：

>>49
???
ああ、自分の頭が悪いって告白ですか
そういうのはパパやママに言ってください
我々の所為じゃないので

51 ：

>>46
アッカーマンを無視するってどういうこと？

52 ：

>>48
ん、ああそういう流れだっけ？
じゃこれで
module Main where
import Prelude hiding (length, head)
import Data.Vector.Unboxed
rev :: Vector Int -> Vector Int
rev v = generate (length v) $ \ i -> v ! (length v - 1 - i)
main :: IO ()
main = print $ head $ rev $ iterateN 1000000 (+1) (1 :: Int)
9 MB total memory in use (0 MB lost due to fragmentation)
Total time 0.06s ( 0.05s elapsed)
今度はgenerate自作しろって言い出すんでしょうかね（笑）

53 ：

っていうか『プリミティブなアルゴリズムが簡潔に書ける！』とか言って
車輪の再発明繰り返して喜んでるだけのhaskellerに問題があるよねえ
（どういう意味にせよ）少しは実用的な話をしようぜ？

54 ：

>>50
ああ、43のtypoだと解らない程度の頭なんだね。
カワイソス

55 ：

>>52
おそ！

56 ：

2chで”流れ”を感じ始めたら、少なくとも二重の意味でヤバイな。

57 ：

>>51
関数型が得意なベンチマークでなきゃヤダヤダ

ってこと。

58 ：

Rは関数型に入りますか？

59 ：

C言語プリプロセッサは関数型に入りますか？

60 ：

バナナの皮は関数型言語に入りますか？
λ
形が似てるんですが

61 ：

お前、先生が許可したら人もRのか
関数型言語をRつもりか！

62 ：

haskellの遅延評価は、元々先行評価よりも遅い傾向にあるんだけどな・・・
（一部のみ、先行評価より速い）
そもそも、reverseが単方向リストに不利なわけだが・・・
とりあえず、main/print（ＩＯモナド使った関数）以外の関数を自作してみた
http://ideone.com/15yhM
自分がHaskellに惚れたのは、IO関連以外は言葉遊びみたいな感じで自作出来るのが楽しいから
(rangeはもうちょっと作りこめたかも・・・）
速さよりも、その構造を調べるのが楽しい
data Natural = Zero | Succ (Natural) deraiving (Eq,Ord,Show,Read)
自然数の定義と、リストの定義が似ているのが分かる。
自然数は、その長さそのものが数字としての意味を持ち、リストは長さにも長さと言う意味はあるが、自然数との決定的な違いは、要素自体も値を持っているか？だけだと言うのが分かる

遅延評価生かしたプログラムなら、ファイル処理とかだろうけど、ideoneでファイルの読み込ませ方知らん（と言うか、在るのか？）
ので、一応、こんなのも作ってみた（1から1000000までの足し算の合計のリストを作って、先頭の１０要素を表示）
http://ideone.com/insk7
簡約の様子を見てみると関数同士が絡み合って、一番外側の関数の終了条件のみで、他の関数の終了条件を満たして無くても、関数が終わるのが自然と理解できる
もちろん、最初から無駄の無い処理を書かれると負ける。foldllやmapみたいな、状態を次の再帰に引き摺らない様に書けば、スタック消費が抑えられるって言うだけで、Haskell自体の最適化は弱い

63 ：

不覚にも>>60-61の流れに

64 ：

なんで、list reverseだけでここまで引っ張ってるんだ!?
>>11を受けて関数型言語/命令型言語の適材適所の話題になると期待したのだが。

65 ：

>>64
まあここは隔離スレだし、目的が互いに異なる言語同士を単純作業で比較したがる人が集まる場所でもある。
鳥と魚を比較するのに、共通項目だからといって体重や肺活量で比較するようなもんで、最重要と言えるほどの意味は無いと思うが。
比較するなら、計算モデルからのアプローチ（CTMCPなど）も有るので、該当スレが宜しいかと。

66 ：

本スレで煽り質問しかできないバカは回線切って吊れ

67 ：

>>62
>haskellの遅延評価は、元々先行評価よりも遅い傾向にあるんだけどな・・・
>（一部のみ、先行評価より速い）
評価する際の処理時間が先行評価より速い遅延評価って尊えば何だっけ？
遅延評価を使ったプログラムの総時間と混同してないか？

68 ：

>>67
X 尊えば
O 例えば

69 ：

>>67
>評価する際の処理時間が先行評価より速い遅延評価って尊えば何だっけ？
遅延評価とか先行評価とかいうのは評価『戦略』であって、『評価するかどうか』を決めるだけだ。
実際に『評価する際』には評価戦略の段階は通り過ぎてるからその問は無意味だろう。
そして遅延評価は評価するまでに猶予を置く意味合いしか無いから、
無駄な計算をしないという仮定のもとでは、遅延評価戦略が先行評価戦略よりも速くなることは有り得ない。
>>62のいう『一部』というのはたらい回し関数みたいなもののことを言ってるんだろうが、
あれはグラフ簡約がたまたまメモ化の役割を果たし無駄が省けているためであって遅延評価だからではない。
そもそも速度で評価戦略を語ることがナンセンスだよ。
あれは（たらい回しみたいな）一部の計算を無駄なく書くのを簡単にするためのものだ。
無駄なく書くのが難しくなってる計算の方が多くね、ってのが遅延評価に対して意味のある批判だろうよ。

70 ：

>>69
>そもそも速度で評価戦略を語ることがナンセンスだよ。
別にそんな話はしてなくて、「先行評価より早いものがある」について具体例が知りたいだけ。
だから、総時間と混同してないか？って書いたんだがなあ。
どっかでの、Haskell=遅いって話のことなら俺は無関係。

71 ：

だからさ、評価戦略によって『評価するかどうか』が決まってからは遅延評価も先行評価も同じ道を辿るんだから、
評価戦略に対して「aはbより早い」とかいうのは論理的に間違ってるってこと。

72 ：

>そもそも速度で評価戦略を語ることがナンセンスだよ。
これはhaskellerの負け惜しみとかそう言うんじゃなくてさ、
速度と評価戦略が別次元の問題だってことを言いたいだけ。
haskellのたらい回しとcのたらい回しは記述が似てても、
『そもそもやってることが違う』んだから。

73 ：

遅延評価は計算量を減らす目的もあるけどそれが全てじゃないよね
それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし
割と手軽に計算量を減らせる(処理系にお任せ出来る)ってくらいだろう
無限リストとかを評価しちゃうと氏ぬのは言語に関係無いから
その辺はCでも配列でなく関数とかで仮想化するし

74 ：

＞それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし
いや、まったく同じ計算をするなら同じ処理時間になるよ。
ならないとしてもそれは遅延評価のせいではない。

75 ：

＞遅延評価戦略が先行評価戦略よりも速くなることは有り得ない。
よくみると俺もこんな発言をしていた。
俺も論理的に間違っているということだな（ｷﾘｯ

76 ：

>>64
ネタの投下も無しに贅沢な
それに、>>62はプリミティブな関数が自作出来るのが楽しいって言ってるだろ
python版出すなり、新しいネタ出すなりすれば良い

77 ：

＞それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし
というか『適うわけない』と思った根拠はなんなのだ？
論理的に同じ計算をするならあとはなんというか、言語の基礎体力だけの問題になるはずだが。
あれか、haskellではIntがボックス化されているからとかなんかそういうのか。

78 ：

>>74
＞まったく同じ計算をするなら同じ処理時間になる
同じロジック書いても
遅延評価を実装するために発生するオーバーヘッドとかの影響で
まったく同じ計算(機械語レベルで)にはならないんじゃないの？

79 ：

>>77
＞言語の基礎体力だけの問題
そうだよ、そういう話
例え同じロジックでもインタプリタ方式の方が遅いとかそういうの
Cは安全性を犠牲にしてでも速度優先するってコンセプトがあるわけだし

80 ：

>>-79までの中に、62が居るとのお告げがあった。

81 ：

>>78
遅延させることに意味がある場合、それはオーバーヘッドとは言わないんでは？
計算結果を明示的にキャッシュするのだってもちろんスペース喰うわけで。
そういうことじゃなくてGHCの実装の深いところに基づくオーバーヘッドだというなら、
俺にもよく分からないが、お前にはそれが有意な差であると合理的に説明できるのか？

82 ：

>>80
そのレスバグだろ
開始インデックスの指定漏れてんぞ

83 ：

>>81
意味有る無しに関わらずオーバーヘッドと言うよ
機械語レベルでの違いによるものなら大小に関わらず有意だよ

84 ：

>>83
呼ぶのか。なるほど。
それは明示的に計算結果をキャッシュするコストと比べてどうなの？

85 ：

このコストっては手間的な意味じゃなくてね

86 ：

あと機械語レベルで差が出るというソースは？
簡易なものなら是非見てみたい。

87 ：

無いと思うならそれでいいよ
haskellはcと同じ速度ってことでさ

88 ：

まあ説明できないことは最初から分かってたさ

89 ：

オーバーヘッドがあったとしても遅延評価には利点があるという話だったんだけど
ここまで速度に拘るとは思わなかったからね

90 ：

あるかどうかもよく分からないオーバーヘッドの話を持ち出したのはそちらではなくって？
まあね。実際俺もあるとおもうよ。オーバーヘッド。
話として持ち出すからには根拠を持っていてほしいなと思っただけさ。

91 ：

ちなみに俺がオーバーヘッドがあると思ったのは
単にゼロオーバーヘッドでの実装は無理だろうと思ったのと
「c言語 haskell 速度比較」とかでググッた結果を見たというだけ
流石に個々の速度比較の詳細までは知らない
逆にオーバーヘッドが無いってのを示してくれたらもちろん前言撤回するよ

92 ：

こんなスレにいる駄民がそんなことを示せるわけ無いじゃないか！俺のことだよ！
ていうかよくよく読み返すと>>78は疑問文だねえ。
俺が謝ったほうがいいのかも知れない。
だがわたしは(ry

93 ：

遅延評価って、一見全部読み込んでから一部だけ出力するって処理で、必要な分しか読み込まないってので、>>62の上のmyreverseはリストを反転する必要があるから、全部読み込んでるけど、下のaddlistをmytake 10 してる方は、最初の10要素分しか読み込まない
先行評価だと、全部読み込んでから始まるか、最初の10要素だけ読み込む様に書き分ける
ファイル処理とかで、書き分ける必要が無い事になる
とは言え、最近の言語なら、オブジェクトにその辺の処理を押し込んでそうだが

94 ：

オーバーヘッドつーか、評価機構の構造自体が違うのに、
全体の処理時間が同じなわけがないだろjk

95 ：

正格評価でもありとあらゆるところにdelayとforceを忍ばせれば
遅延評価になると思うんだけど
計算量が減るところだけ遅延評価にした方がやっぱりいいと思うんだよね

96 ：

>>93
そのかわり、ファイル読み込んで同じファイルに書き出すときとか
「あー、この辺で正格評価するべ」的なこと考えんといかんけどな

97 ：

配列のreverseくらいならC++でも一行だな
std::copy(in.rbegin(), in.rend(), std::back_inserter(out));

98 ：

最近の関数型って実装まで気にするような段階なんだな
はてなあたりの選民気取りが「haskellはCより速い(ｷﾘｯ」とか言い始めたら俺もそろそろ関数型始めようかな

99 ：

速度稼ぐ必要があるコードだと結局はモナド頼りなんだろ？
関数型言語って名前捨てて”モナド型言語”とでも呼べばいいんじゃね？

100 ：

おめえらhaskell以外の話もしろよ

101 ：

遅延評価のコストについては、コンパイラの本とかに載ってることあるよ

102 ：

>>98 大学の研究のレベルから、一般はてな民が話題にするまで10年ぐらいだから、
おまえは常に10年遅れだけど、好きにすればいいと思うよwwww

103 ：

xmonadの影響で今になってX11プログラミングを始めた漏れが
8時（10分以上遅れ）をお知らせしますね

104 ：

10年遅れどころかMLなら40年遅れHaskell直系のMirandaからでも30年遅れだろ

105 ：

作ればあるもん

106 ：

>>104
登場時期が基準とかおもちゃじゃあるまいし

107 ：

ギークやらアルファブロガーやら呼ばれる人が話題する時点ではまだ玩具
それを使用する企業やそれなりの規模のオープンソースプロジェクトが
出始めるくらいから実用品だな

108 ：

Javaと心中するのは自由ですから、他人を巻き込もうと必死にならないでねw

109 ：

定番の必死認定

110 ：

このスレでの関数型言語って純粋関数型言語(Haskell,Mirandaとか)だけ？
非純粋関数型言語(Lisp,R,OCamlとか)も含むの？
Haskellはよく知らないけどCommon Lispは実用かなって思って

111 ：

アンチの脳内の都合で、その場により変わりますw

112 ：

>>111
あなたの認識ではどっちですか？

113 ：

関数型言語に定義なんてないし的当だよ
一般的な定義は
・関数を実行時に生成できる
・関数を引数として渡せる
・関数を関数の戻り値として返せる
だと思うけど、最近は勝手に
・変数に一度しか代入できない
とかルールを付け加えたり好きかっていう人が増えたから

114 ：

昔は、関数型言語と比べて手続き型言語は原始的で貧弱に思えたけど、
最近は手続き型言語もクロージャを取り込んで関数的にも書けるから、
そうなると実用上は手続き型言語で十分だと感じるけどな。
基本は手続き的に処理を書きつつ、コレクションの操作だけ map や filter,
reduce を使って関数的に書く。他人にも読みやすいコードを書こうとすれば
最終的にはそのくらいのところに落ち着くと思うけど。
>>108 みたいな「仮想ドカタ」を煽るのは現実が見えていないと思うなあ。
今時、職業プログラマだって C, Java だけじゃなくて JavaScript も Ruby も使うよ。
JavaScript で言えば、JQuery なんて発想がかなり関数的だと思うけど。
XML を対象に XPath でパターンマッチかけて filter やら map やら。
ほとんどそういう処理。

115 ：

>>113
上の３つだとJavaScriptやC++(functor)、C#(delegate)あたりも含まれるな
初代スレの1はむしろ参照透過性、変数に一度しか代入できないことの方を嫌ってるように見える

116 ：

>>113
そうなんだよね。僕もそのくらいが「関数型言語」だと思うんだけど、
逆に、そのくらいはもう、手続き型言語にも取り込まれてるんだよね。
だから、そんなのはもう関数型言語「ならでは」の長所になってない。
逆に、末尾再帰除去とかカリー化とかになってくると、まだ差がある。
とはいえ >>114 くらいのスタイルだと、
別に末尾再帰除去やカリー化がなくても、そこまで困らないけどね。

117 ：

javascriptはschemeをC言語っぽい文法に直したものだろ
昔から関数型言語と言われているよ

118 ：

Haskellなどで言う「関数」は、集合・写像ベースの概念だから、変数の書き換えに依存しないやり方のほうが関数を率直に表現出来るってだけの話だ。
Cにも同じ字面の「関数」があるが、関数型言語の関数と区別したい時は、サブルーチンと呼んだ方が実態に近い。

119 ：

良い所とか取り込んで明確な境界が無くなくなってる面があるんですね
研究目的の言語の成果が実用目的の言語に適用されたと考えたら
必ずしも実用である必要は無いのかもしれませんね

120 ：

>>117
それは違うかな。
「言われている」ではなく、
関数型言語を知っている人たちが JavaScript は関数型言語っぽいと
「言っている」が正しい表現じゃないかな。
少なくとも、
Ecma-262 の 4 Overview には
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
ECMAScript is an object-oriented programming language for performing computations and manipulating computational objects within a host environment.
と書いてあるんだから、何言語かと一つに決めるなら、
明らかにオブジェクト指向言語でしょ。

121 ：

>>119
「何ができるか」って意味なら差はどんどん無くなってる
だが、他人のコードを読むときには「何ができないか」ってのも重要で、
そこが手続き型言語と関数型言語では違う
わざわざコードを読んで副作用が無いか目でチェックしなくても
言語仕様で保証されてるなら読むのが楽になる
OOPのアクセス修飾子なんかと同じだな

122 ：

>>120
http://www.ecmascript.org/es4/spec/overview.pdf
ここの４ページにはこうある
ECMAScript 4th Edition (ES4) is a multi-paradigm programming language that is evolved from the
3rd Edition2 (ES3), which in turn is based on JavaScript3, a programming language for the web developed at
Netscape Communications Corporation starting in 1995.
ES3 is a simple, highly dynamic, object-based language that takes its major ideas from the languages Self
and Scheme.

123 ：

http://ja.wikipedia.org/wiki/ECMAScript
ECMAScript 4 は過去2回仕様作成が挑戦されたが、仕様がまとまらず、失敗に終わっている。

124 ：

何でも関数型言語にしたがる香具師がいるな…

125 ：

関数型言語の判断基準について、整理してみた。大きく３つのグループに分類できる。
・関数型言語(誰も文句無し)
・関数型プログラミングが可能な言語
・それ以外の手続き型言語
　FP
　　---- 壁0. 変数の壁 ----
　Haskell
　　---- 壁1. 純粋性(副作用)の壁 ----
　SML/OCaml
　　---- 壁2. 型推論の壁 ----
　Scheme
　　---- 壁3. 末尾再帰最適化の壁 ----
　========<< 越えられない壁 >>========
　Smalltalk/Ruby
　　---- 壁4. 条件判定式/局所宣言式の壁 ----
　Perl/Python/JavaScript
　　---- 壁5. クロージャ/ラムダ式の壁 ----
　========<< 越えられない壁 >>========
　C/C++/Java...etc
なお、このカキコは「関数型言語Part5」スレの過去カキコ(283-335)を編集したもの
議論の参考になればと思う

126 ：

末尾再帰最適化とか、マジ関係無いだろ
実装上の話だろ

127 ：

GCC(C/C++) → 末尾再帰最適化あり
あとC++のboost::lambda(ラムダ式)とはどうなんだろうか
言語自体に直接ラムダ式があるわけじゃないけど
boost::lambdaとスマートポインタでクロージャも作れるらしい
壁4はよく分からない

128 ：

>>126
関数型言語にとってリストが最も基本的な複合データ型であることは、
誰もが認めることだろう
でも末尾再帰最適化が実装されていない言語の多くでは、
可変長配列(RubyであればArrayクラス)でリストを代用している
もしも、これを真面目に「ドット対の連なり」としてリストを定義して
その操作を再帰関数で定義した場合、ちょっとしたデータ量であっても
簡単にスタックオーバーフローが発生してしまう
だから、関数型言語で書かれたコードを末尾再帰最適化が実装されていない言語へ
移植しようとした場合、再帰ではなくfor/while文のような手続き型構文を使わざるをえない
これは(末尾再帰最適化という)実装がプログラミングスタイルに大きな影響を与えるという
典型的な一例であると思う

129 ：

>>128
>関数型言語にとってリストが最も基本的な複合データ型であることは、
>誰もが認めることだろう
認めねーよ。
それも実装上の話だろ。

130 ：

>>128
でも、機械を上手く動かすためのコンパイラの技術だろ
関数型言語の定義に含めることには違和感がある

131 ：

リストは副作用を嫌う関数的プログラミングがLISPから借りてきた実装上の「逃げ」。
末尾再帰最適化でループの代用にしたのと根っこは同じ。

132 ：

ま、実用を目指したコンピュータ言語なんてものは
全てが実装上の話になってしまうんだけどな。

133 ：

末尾再帰なんてC言語の教科書で知ったから
関数型言語と結びつけるイメージが全く沸かない

134 ：

128は本質をついている。
リストは再帰的データ構造を持つので、
再帰を反復の記述にとる関数型とは相性がいい。

135 ：

関数型言語にとって副作用が無いことは
本質的なことなの？
そうだと言える根拠とかあるの？
MLやHaskellが設計された頃の流行りだった
だけじゃないの？
”副作用は悪”っていう思想は、古いアルゴリズムの
教科書にはよく載ってる

136 ：

>>134
反復もリストも、圏論の抽象力の前では、単なる実装上の都合だよ

137 ：

>>125
壁３は本質的じゃないね。それよりも
--- 壁3'. 宣言性(記述順序に左右されない)の壁
を入れたほうが関数プログラミングの本質に近づくと思うのだが。

138 ：

>>137
宣言という言葉をあまり狭義に使うのはどうかな。
IBMの簡易言語RPG(現在バージョンはIVかな)は
Decision Tableを使って制御を行っているので、
昔は宣言型言語に分類されていた。同じ宣言でも
こうまで異なると問題だ。

139 ：

定義のことを宣言って言ってるだけじゃね？
英語でどうなんだか知らんけど。

140 ：

CTMCPすら知らずに妄想する隔離スレか。

141 ：

抽象度が高いことを示すコードが出てないんだが
pythonに作れなくて、Haskellに作れるものって何がある？
とりあえずHaskellでif関数自作できるとかはよく見かけるが

142 ：

if関数ったって組み込みの（型クラスを含む）条件分岐機構を使わずには書けんだろ。

143 ：

>>140知らなかったので、検索して目次を眺めてみたが、スレタイのような議論をするなら読むべきかと思った。

144 ：

>>142 ARMなら条件分岐なしのコードにコンパイルできるんでね？

145 ：

>>142
へ？
パターンマッチとガードでごく普通の関数として書けるけど
型クラスなんて大仰なもん使わんよ
と言うか、ifが普通に書けるのが遅延評価と関数もファーストクラスの値っていう特徴の賜物じゃないか
if flg t f | flg == True = t
　　　　　　| flg == False = f
関数型言語は必ず値を返すって性質上、if elseしか許されないが
先行評価のだと、両方とも関数を受け取った時点で評価前に実行されちゃうから正しく動かない
（評価前に両方実行されて、評価後にどちらかが実行される）

146 ：

つーか、関数型言語の利点と言えば、バグが無いことを保障できるって事じゃね？
数学の証明で公式が永遠に正しいことを保障するのと同じで、関数にバグが無いこと保証できれば、その関数の使い方を間違わなければ、その関数が原因のバグは無いと保証できる

147 ：

分岐を関数で表現するのは難しくない。
T（x,y）=x
F（x,y）=y
IF（c,x,y）=c（x,y）
最後のは糖衣構文で、cはTかFが入る。
問題はこれを先行評価すると、
xの評価、yの評価、どっちかの選択と
進行してしまい、無駄な評価またはやっては
ならない評価をしてしまうことになる。
遅延評価では必要になるまで引数は評価されず、
c（x,y）にはxかyの一方しか含まれないので、
上記の問題は起こらない。

148 ：

すでにコメントされていたか。

149 ：

元ネタ書いたの誰か知らんが >>125 は酷すぎる。
上下に並べている壁が、それぞれ軸が違う。
壁２は型システムの問題だろ。
壁４も意味不明。
末尾再帰最適化の有無を越えられない壁とか書いてるのもアホ丸出し。
末尾再帰になるような処理は手続き型なら最初からループで書く方が自然。
だから要らないだけ。

150 ：

型推論とオブジェクトの相性の悪さが問題だな
誤解を恐れずざっくり切るなら、
オブジェクト指向が適している分野に関数型言語は不適。

151 ：

せんせー、OCamlさんが泣いてます

152 ：

>>145
パターンマッチがすでに条件分岐機構なんだが…
条件分岐機構使って条件分岐書き換えてドヤ顔されてもな。

153 ：

>>147
Smalltalkの宣伝乙w

154 ：

一般論を書いたつもりだがどの部分がsmalltalk?

155 ：

一般論を書いたつもりだがどの部分がsmalltalk?

156 ：

T（x,y）=xがTrueクラスの定義
F（x,y）=yがTrueクラスの定義
IF（c,x,y）=c（x,y）がメソッドの動的束縛に相当した実装になっている。
具体的には、if式はifTrue:ifFalse:というメソッドで実装されている。
これがTrueクラスでは、第1引数のクロージャを評価するよう定義されていて、
Falseクラスでは、第2引数のクロージャを評価するよう定義されている。
クライアントコードでは例えば
x = y ifTrue: [do something] ifFalse: [ do something else]
というメッセージ式を評価する時に、
x=yがtrueならTrueクラスのifTrue:ifFalse:が束縛されて
第1引数の[do something]が評価される。([ ]で囲まれたものはクロージャ)
x=yがfalseならFalseクラスのifTrue:ifFalse:が束縛されて
第2引数の[do something else]が評価される。

157 ：

>>154
Smalltalkで勉強したからそう言っただけだろ
プログラム言語が開発される以前に、ラムダ理論で
既に知られていたなんて知らなんだろ

158 ：

>>157
いや、知ってたよ。
つーか、俺自身がSmalltalkより先に型なしラムダ計算やってたし。
現代の実用言語では>>147の定義の実装がSmalltalkに色濃く残っている
というだけの話にそこまで突っかかるかね？
関数型の人(特にLISP系とHaskell系)ってそうやって上から目線で小馬鹿にするから
逆に相手から冷笑されるんだよ。

159 ：

悪いけどJava屋の俺からするとSmalltalkの人も同じだよ。
＞上から目線で小馬鹿にする

160 ：

どっちも原理主義者で純血主義者ですもんね

161 ：

ハスケラやSmallTalkはわかるがLISPerは純血主義の対極だろｗ

162 ：

LispもHaskellも習得のコストさえ無視できれば
言語自体には使う価値があるけど
Smalltalkには何も無い

163 ：

よほどSmallTalkに叩かれた暗い過去があるんだねｗ
もしかしてIDEスレじゃね？ぷぷぷ あのスレのジャバ厨は悲惨だったｗｗ

164 ：

そんなにスモールトーク叩きたければ別スレ立てれば？
スレ違いウザｗ よほど悔しかったんだねｗｗ

165 ：

Smalltalkを頭ごなしに馬鹿にする奴でSmalltalkをまともに使ったことある奴を見たことがない。

166 ：

Pharoがゴミ過ぎて笑える
玩具で喜んでて滑稽

167 ：

負け犬>>166の遠吠え

168 ：

「俺は世間の奴らとは違う」という自尊心を満たすために
マイナーなものを選択するという変な層がいるから性質が悪い。
そういう人にとっては「世間はJava」でなければ困るわけだ。
「RubyでもJavaScriptでも普通に関数的にも書ける」と言われると
「中には手続き型言語で関数的に書いている人もいるだろうが、
それは(俺と同じ)一部の先進的な層で、世間一般はJavaだろ」
という主張をしてくる。自分が特殊でありさえすれば何でもいいというね。

169 ：

自己紹介乙としか言いようがないw

170 ：

関数型言語由来の機能で便利なところってのはクロージャとラムダ。
それはもう手続き型言語で普通に使える。
関数型言語の便利な機能は、
既にメインストリームである手続き型言語に取り込まれ、
今では世間一般のプログラマも当たり前に関数的な書き方をするようになっている。
めでたしめでたし。
現実的には、もうこれで終了してる話だろ。

171 ：

パターンマッチは便利なので手続き型言語にも取り込んでほしい
で、パターンマッチは再帰と相性良いので、
ついでに末尾再帰最適化も取り込んでほしい
汎用的な関数から具体的な関数を定義するのに
カリー化は便利なので是非とりこんで欲しい

172 ：

>>171
末尾再帰最適化はC/C++でやってるし
上でも出てるけど関数型とは無関係

173 ：

＞汎用的な関数から具体的な関数を定義するのに
＞カリー化は便利なので是非とりこんで欲しい
こういう奴にカリー化という包丁を渡すと
オレオレ高階関数ライブラリを作り始めて
メンテナンス不可能なコードを量産されるのがオチ。

174 ：

逆にダックタイピングは便利なので関数型言語にも取り込んでほしい

175 ：

あ、型推論できないから取り込めませんね。失礼

176 ：

>>175
構造的部分型で良ければOCamlで出来るけどな > ダックタイピング
もちろん型推論もできる

177 ：

>>174はダックタイピングの誤用だな

178 ：

>>172
パターンマッチ無いのに末尾再帰最適化だけ出来ても
正直そんなに嬉しくない

179 ：

パターンマッチと再帰は無関係だし
視野が狭すぎ

180 ：

代数的データ型使わないのにパターンマッチがあっても何も嬉しくない

181 ：

代数データ型と再帰構造は直交する概念だろｗ
どこまで視野が狭いんだかｗ

182 ：

>代数データ型と再帰構造は直交する概念だろｗ
>どこまで視野が狭いんだかｗ
何それ？
代数データ型を使って
再帰構造を表現することはできないって事？

183 ：

便利な機能が全部ある言語を選んだらHaskellになった

184 ：

いらない機能を全部つめこんだらSmalltalkになった

185 ：

>>181
パターンマッチと再帰は直交する
代数的データ構造と再帰は直交する
パターンマッチと代数的データ構造は直交しない

186 ：

>>156
ありがとうございます。
Smalltalkって、C++やJavaの先祖くらいにしか思っていなかったけれども、
結構おもしろいですね。FPとOOPはレイヤーを積み重ねると互いに相手を
模倣できるという話を聞いたことがあるが、Smalltalkを学習すると
その意味がわかるのではないかという気がした。

187 ：

あちこちのスレを読んでいると、
Smalltalkの説明に対してだけ、丁寧な言葉でお礼が書き込まれることが多い。
この傾向が、とても面白いと思う。

188 ：

> 関数型言語由来の機能で便利なところってのはクロージャとラムダ。
> それはもう手続き型言語で普通に使える。
体験するにはどういう言語がいい?知っている範囲では、
C++11: lambdaはあるが、スコープにかんするオプションがいっぱいあって
　頭痛がしてきた。
Fortran: Intel拡張に限り、内部手続きが渡せるのでクロージャが部分的に
　はあるといえる。うっかり使ってしまうとSparcマシンに移したときに
　がっくりくる。

189 ：

結局はどの言語を使うかではなく、関数型的な考え方書き方が出来るかどうか、が問題になってくんだろうかね？

190 ：

できなくても、ほとんど問題がないのが現実

191 ：

>>166
Smalltalkといっても、実験的要素の多いSqueakやPharoとかばかりじゃなく、
VisualWorksとかDolphinみたいに商用志向の比較的作り込んである処理系もあるよ。

192 ：

マルチスレッドでオブジェクト指向型言語の限界が見えてきたから、関数型言語が注目されだしたんじゃなかったっけ
まあ、遅延評価とマルチスレッドプログラミングは相性が悪いらしいので、最適化でマルチスレッドの時だけ正格評価にしようかという話はどっかで見た気がするが
それでも、純粋な関数に関しては

hoge リスト１ リスト２ = (force リスト１) `par`
　　　　　　　　　　　　　　　(force リスト２) `par`
以下は普通のhoge関数と同じ
force [] = ()
force (x:xs) = x `pseq` force xs
これでおｋ
※ghcバージョンによって、par/pseq関数を読み込むモジュールの場所がまちまち・・・
マルチスレッドの時だけ正格評価になるなら、force関数書かなくて良くなるだけで、たいした手間でもない
同期もデッドロックも気にしなくて良いのが楽
（スレッド数は実行ファイルにランタイムへの指示として指定する）

193 ：

>>192
実行ファイル単位でしかスレッド数を決められないのか
イマイチだな…

194 ：

一応増やせはするんだけど、
一度増やすと今度は減らせないんだよねえ・・・
そのうち改善はされるかもしれないのだけど

195 ：

一般に一旦プロセスに割り当てたリソースをひっぺがすのは難しい

196 ：

並列計算でスレッド数をcpuのコア数以外にすることがあまりないので、
よくわからないのだが、OpenMPのようにいったんスレッドを畳んで、
スレッド数を指定して再度スレッドを起動するのは難しいのかな。
リストなので単純にはいかないとおもうが、
!$omp parallel map
ys = map f xs
!$omp end parallel map
とかできるようになると結構うれしい。

197 ：

ユーザスレッドを駆動するネイティブスレッド数の話だろ？
なら、動的な変更はそれほど必要ないんじゃ？

198 ：

不毛だな

199 ：

ふもっふ

200 ：

catコマンドって、意外と奥が深いんだな・・・
こんなの見つけたんだけど(haskell)、他の言語だとどう書くの？
A cat in Haskell
http://madscientist.jp/~ikegami/diary/20050728.html#p01
ちなみに、このページはここからリンクされてた
Haskell
http://pub.cozmixng.org/~the-rwiki/rw-cgi.rb?cmd=view;name=Haskell
cat（オプション付き)って所

201 ：

>>200
オプション無しの、単純に引数のファイルを繋いで出力するだけのものなら
AWK、Perl、Ruby辺りはアホみたいに短いな
(コマンド名含めて数バイト)
流石に複雑なオプション含むとそこまで差は出ないかも知れんが

202 ：

>>200
正規表現を並べただけだけど、Perl だとこんなかんじ。
http://ideone.com/BCiGc
とりあえず -u と -v のメタ表示以外サポート(もとの Haskell でも
サポートしてなかったので)。

203 ：

ちなみに Snow Leopard の cat には -A -E -T が存在しなかった。
Lion 以降?

204 ：

>>201
オプション無しだとスクリプト言語よりは長いものの、静的型言語としては短いだろうな
と言うか、ここの一番上のruby版catは短すぎてなにやってるのか分からん
下2つのcatコードの方がコードの意図を読み易いな
http://www2.atwiki.jp/kmo2/m/pages/17.html

import System.Environment
main = getArgs >>= mapM readFile >>= putStrLn.unlines
奇しくも、do構文で見えにくい状態移管が見えやすい形になった

205 ：

とりあえず >>200 のバグ。
1. -v と -t の結果が同じになる。本物の cat は -v では TAB を変更しない。
2. 入力が改行で終わっていないときに、勝手に改行を追加してしまう。
3. -e をつけたときに、入力が改行で終わっていなくても最後に $ をつける。

206 ：

>>204
いや、静的だろうが何だろうが、この半分の長さで書けるでしょ。
もともとの >>200 が、シンプルに書く気がないみたいだし。

207 ：

>>204
> while gets do puts $_ end
これのことか？Perlじみた動きをするコードだね
getsは一行入力する
EOFならnil、入力があればそれを文字列型として
グローバル変数 $_ に突っ込むと共に、戻り値としても返す
Rubyの文字列型は必ず真であり、逆にnilは必ず偽なので
while gets は「EOFになるまで毎行を $_ として繰り返す」イディオムになる
あとはそれをputsで出力してるだけ

208 ：

>>207
それ自体は分かるよ
スクリプトだからなんだろうけど、標準入力とファイル読み込みの区別が無くて戸惑う
どこでファイル読んでるの？って

209 ：

昔はプログラム側でファイルを開いたりしないものだったので、
たんに伝統的なやり方とも言える。

210 ：

>>208
？ 標準入力とファイル読み込みの区別はむしろしっかりされてるコードだと思うけど…
ファイルからの読み込みならいきなりgetsなんて書かないよ
その場合はファイルを開いて、それに対してメソッド呼ぶのが基本
標準入力から読むからこそいきなりgetsを書く
まあ確かにgetsの読み先をファイルに繋ぎかえることも出来るし
逆に標準入力をIOオブジェクトとしてメソッド呼ぶとかも出来るけど
このコードではそんなことしてないっしょ？

211 ：

ああ、ごめんそゆことか
標準入力じゃなくてARGFからの読み込みの話だったね
ええとgetsは既定ではARGFから読む
んで、その内容はファイルを渡していないなら標準入力、渡されればそのファイルを全て繋いだものになる

212 ：

多分Perlの<>辺りがARGFの由来だろうなあ

213 ：

>>211
HPに説明があったから良かったものの、所見であのコードだけ見てたら混乱してた
個人的には、>>204のページ探してるときに見つけた
http://uch-x40.seesaa.net/article/22908221.html
こっちのページのやり方の方が好きかな
このページのprintをputsにするだけで問題解決するんじゃないか？と思ったので、久しぶりにruby入れて試してみたら、
予想通り解決した
puts ARGF.read
これで、
>ruby cat.rb mycat.hs myecho.hs
import System.Environment
import System.IO
main = getArgs >>= mapM readFile >>= putStrLn.unlines
import System.Environment
main = getArgs >>= putStrLn.unwords
Haskell版と、ちょっと挙動が違うけど・・・
（Haskell版のputStrLnをputStrに変えれば同じになるけど、どっちが正しい挙動なんだろ)

214 ：

あー・・・ごめん
ruby版、問題解決してないや
EOFで改行されないから、
import System.Environment
import System.IO
main = getArgs >>= mapM readFile >>= putStrLn.unlines[EOF]<-ここにEOFがある
この条件だと下のような表示になる
import System.Environment
import System.IO
↓ここから次のファイルが始まる
main = getArgs >>= mapM readFile >>= putStrLn.unlinesimport System.Environment
main = getArgs >>= putStrLn.unwords

215 ：

実行結果の書き直し・・・半角スペースは消えるんだった・・・orz
import System.Environment
import System.IO
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　↓ここから次のファイルが始まる
main = getArgs >>= mapM readFile >>= putStrLn.unlinesimport System.Environment
main = getArgs >>= putStrLn.unwords

216 ：

>>213-215
率直に言う
　関数型言語が使える使えないうんぬんの前に、常識的な(日本語の)文章表現を使えるようになれ
単にコードをコピペしただけで、自分の意図が相手に通じると考えるな
まともなヤシなら以下のような推論を自然に行って、それを文章で表現できる
・.... を期待して ..... という条件で (* 仮説1 *)
・..... というコードを試したが.....となり、期待にそぐわなかった -- (* 実験1 *)
・おそらく ..... が原因ではないかと思う (* 帰納1 *)
・そこで、新たに .... を期待して ..... という条件で (* 仮説2 *)
・..... というコードを試したところ .....となり、期待どおりの結果を得た -- (* 実験2 *)
ここまで言って分からなければ、お前さんは重症の「ハスケラ症」患者であり、
本人には自覚できない深刻なコミュニケーション不全の状態にある
とっとと隔離病棟(=Haskell本スレ)に戻ってRーでもしてるのがお似合い

217 ：

このスレが隔離病棟だという認識がない、ってあたりが重症だなw

218 ：

型は制約 #プログラミング初心者のミス
↑
Zermeloを初心者呼ばわり、ワロスｗ

219 ：

型付集合論自体がラッセルの逆説を回避するための制約ですし．

220 ：

disることでしかアイデンティティを保てない可哀相な奴なんだよ。

221 ：

オブジェクト指向 ＃プログラミング初心者のミス ←これとか

222 ：

いやオブジェクト指向は糞

223 ：

そうそうクラスとかインスタンスとかメソッドとかの用語を使う言語は100%糞！

224 ：

いまどきは、組み込みみたいなリソースの厳しい案件でも使うけどな。

225 ：

オブジェクト指向言語は使わなくても、設計では使うだろ

226 ：

制御系やっているけど、OSはRedHatなのに、言語はCとアセンブラだ。

227 ：

俺はよく知らんのだが、関数言語アンチとんの連中なの？
twitterやブログでも写真でもいいから見せてくれないか？

228 ：

オブジェクト指向とは別名スパゲティ指向だと言われてる。

229 ：

ねーよ
オブジェクト指向でスパゲティにするような奴は、ループ構文使おうが、例外を使おうが
スパゲティを作るんだよ。馬鹿は何を使っても同じ。

230 ：

gotoやグローバル変数全盛時代、スパゲティコード生産しまくってた連中は
自分達がスパゲティ製造者だという自覚がなかったという
gotoでスパゲティにするような奴は、関数呼び出しを使おうが
スパゲティを作るんだよ、とか言ってね

231 ：

お前ら立派なスパゲティ職人になれよ。
一芸に秀でりゃ食っていける。

232 ：

関数型言語は別名ゴルフ指向言語と言われているなｗ

233 ：

>>230
>gotoでスパゲティにするような奴は、関数呼び出しを使おうが
>スパゲティを作るんだよ、とか言ってね
いや、まさにその通りだろ。

234 ：

スパゲティで塩やきそばを作ると結構いける

235 ：

>>230
スパゲッティ・コードというのは、ウケ狙いの後付表現に過ぎないからな。
gotoを使ったからスパゲッティになった、なんていう理屈だと、
あと10年くらいして改善された手法が一般的になったら、
今コード書いてる連中は殆どスパゲッティメーカーになってしまう。

236 ：

スゲパティシエ

237 ：

>>235
いや、だから関数型言語使ってる連中がOOP使ってる連中に
「お前等スパゲティコード書いてるぜ」って言ってるんだろ？

238 ：

スパゲティコードは読み辛く、読み解ける人は限られていた
一方、関数型言語のコードはそもそも読める人が限られていた
広まるといいですね関数型言語

239 ：

関数型だって普通にスパゲッティになるしｗ

240 ：

haskellのdo内はなぁ。。。 関数型スパゲティの宝庫だね。
ナポリタンにしますか？ミートソースにしますか？それとも、カルボナーラにします？

241 ：

何故Haskellのdo内でスパゲティになるか
理由を>>240は説明できないだろう

242 ：

関数型言語に馴染まないものを無理に突っ込んだ悪足掻きだからさ
生まれ付いての汚れ役だね

243 ：

doはただの関数合成の構文糖なんだが
関数の合成が関数型言語に馴染まないとは面白いことを言うなぁ
まあ、>>242はdo構文を普通の関数合成の表記に
書き直す事すらできないだろうけど

244 ：

流石は関数型言語ユーザー様
上から目線が板に付いてますねｗ

245 ：

永遠に学習しない態度が板に付いている奴はほんとカスだな

246 ：

>理由を>>240は説明できないだろう
>書き直す事すらできないだろうけど
>永遠に学習しない態度が
決め付けも大好きみたいすねｗ

247 ：

構文糖衣が必要なのは相性が悪いからじゃないの？

248 ：

良く使うから構文糖が用意されるって話は分かるが
相性が悪いから？なにそれ？
じゃあ何か。C言語で x=x+1 を x++ と書けたり
*(x+1) を x[1] と書ける構文糖が用意されてるのは、
C言語がインクリメントや配列と相性悪いからか？

249 ：

>>248
> じゃあ何か。C言語で x=x+1 を x++ と書けたり
その２つが同じセマンティクスだと思っているのなら
もう二度とコードを書かないほうがいいぞｗ

250 ：

x86ならおんなじじゃないの？

251 ：

>>249
ああごめん。++xだったね

252 ：

>>251
大分近くなったが、まだセマンティクスは完全に一致してないのだが…
マジでプログラマやめたら？

253 ：

xが整数かポインタかで細かいところは変わるし、そこまでこだわる理由も無いように思うがw

254 ：

Cリファレンスマニュアル5th edition読む限りでは ++x と x+=1 と x=x+1 は
等しいと読めるし、今手元に無いから記憶だけど規格書でもそうだった気がするが...
xが整数かポインタかで変わる？ありえんだろ

255 ：

整数ならインクリメント命令にできるが、ポインタだとそうはいかない。
>>249 は x=x+1 において x の評価が 2 回起きる、と言いたいらしいが、
ここでは x は任意の式ではなくて、ただの変数なので、その違いは無い。
結論。>>249 は今すぐプログラマをやめて、一生 2 ちゃんねるもプログラムも書くな。

256 ：

>>255
ポインタでもできるよ？何言ってんの？

257 ：

そりゃ 4 増える「インクリメント命令」がありゃ、int を指してるポインタでもできるが。

258 ：

ん？今は x=x+1と++xの違いの話だろ？
どっちもxがポインタなら sizeof(*x) だけ増加する

259 ：

>>255
> ここでは x は任意の式ではなくて、ただの変数なので、
なにか鬼畜なマクロかもしれませんよ。小文字一字なマクロは私の好みではありませんが。

260 ：

仮に (1+1) に展開されたら ++ なんてできない。以上

261 ：

>>255
ねえ、君、本当にプログラマ？
プログラミングで給料取れるレベルじゃないよ。

262 ：

>>259
マクロの引数だったりすると、小文字一文字はよくある話だなｗ

263 ：

結局具体的には全く反論できないんだなw >>261

264 ：

セマンティクスの話してるときに
字句レベルの置き換えであるCマクロ持ち出す馬鹿は
プログラマに向いてないから辞めた方が良い
まともに言語規格書読めないだろ
例えば
#define double int
とされてたら double x; でも x はdouble型とは言えない、
とか言い出すレベルでバカなわけで

265 ：

セマンティクスとしては x の評価を 2 度する、というのは変わらんじゃないのかな。
その評価が状態に対して idempotent かどうかという違いであって。

266 ：

>>249
その２つのセマンティクスの違いって何なの？
そろそろ答え教えてくだしあ

267 ：

結論： 教えてクレクレ君は二度とコード書かないほうがいい馬鹿

268 ：

>>264
> セマンティクスの話してるときに
ダウトｗ
構文の話をしていた>>248にセマンティクスを持ちだしたのが>>249だｗｗｗ
あまりにも馬鹿すぎるｗｗ

269 ：

>>248
> 良く使うから構文糖が用意されるって話は分かるが
> 相性が悪いから？なにそれ？
> じゃあ何か。C言語で x=x+1 を x++ と書けたり
↓これがいつのまにか
>>264
> セマンティクスの話してるときに
> 字句レベルの置き換えであるCマクロ持ち出す馬鹿は
> プログラマに向いてないから辞めた方が良い
構文糖って「字句レベルの置換え」だよねｗ
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い

270 ：

構文（syntax）と字句（lexical）の違いも分からないとか
マジ終わってんな
yaccとlexも知らんのか

271 ：

>>267
じゃあ僕が良いこと教えてあげる
>>249のようなレスしても論理的な説明しなかったら説得力0なんだよ^^

272 ：

教えてクレクレ君とバカにすれば、どんな間違いを言っても逃げきれると思っているバカが一人w

273 ：

>>270
へー、字句解析に手を入れずに構文糖衣かw
馬鹿が考えることは壮大だねえww
お前、完全にプログラマー失格。

274 ：

プログラマ失格のバカはどう見てもおまえだw

275 ：

>>274
いいから涙を拭けよ
見ていて痛々しすぎる
そうやって涙目で必死に弁解するぐらいなら
本当にプログラマー辞めればいいのに

276 ：

その言葉が自分にあてはまってると気付かないあたり、完全に重篤の患者ですなw

277 ：

>>276
どうしてプログラマーになろうなんて思っちゃったの？
間違いを正すのは恥ずかしいことじゃないよ。
だから今すぐ辞表を書きなさい。

278 ：

>>277 >>277

279 ：

最近の関数型言語は辞表も書けない

280 ：

そうやって無限退行することしかできないんだな

281 ：

なんか気持ち悪いのに粘着されてんな
つーか書き込みから漂うドカタ臭で鼻が曲がるから
もうちょっとマトモな職に就いてから書き込んでくれ

282 ：

pythonpython言ってた人はどこ行ったの?

283 ：

人口が少ない言語。一人減っただけでとたんに静になる。

284 ：

結局、蓮ケラはx=x+1とx++の区別がつかないのねｗかわいそｗｗ

285 ：

>>265 が理解できないならプログラマやめたほうがいいよ

286 ：

ところで何故にセマンティクスの話をし始めたの？

287 ：

構文糖って言葉を聞きかじって、使ってみたかったんだろ。察してやれｗ

288 ：

検索してみたらセマンティクスって言い出したのは
>>249のアホじゃん

289 ：

x=x++++++1

290 ：

>>289はこう解釈されます
x=((x++)++) + +1

291 ：

出来るやつならどっちも使える上に、C++のほうを好むと思うがね。
どっちもできるけどC言語のが良いってヤツ存在してんの？

292 ：

Linus

293 ：

お前らプログラマなの？

294 ：

>>290
x++はsequence pointじゃない
ひとつのsequence pointに複数のside effectsを含むのは
未定義動作

295 ：

>>292
レベルの低いヤツに合わせるためにあえてCを使ってるだけで、Cの方が良いってわけじゃないんでは？

296 ：

Cの方がいいに決まってるだろｗ

297 ：

関数型言語は遅いからね。
C言語に比べて100倍以上遅い。

298 ：

やっぱりx=x+1と++xは式としてのセマンティクスが違うんだね。
納得。

299 ：

そりゃそうだろう。
そもそも++というのはなんで存在するか。
まず1追加するというのはプログラムでよく出てくる処理。
ならばそれを高速にしようと、専用のアセンブラ命令(INC)を作った。
足し算はADD
昔のコンパイラは馬鹿だから+1を++に変換するなんてことはしない。
+1と書かれていたらADD、++と書かれていたらINCに
単純に置き換えるのみ。

300 ：

さらに、CPU によっては命令の実行ごとにレジスタが自動的にインクリメントされるアドレッシングを備えるものもあった。

301 ：

んで、ここ何のスレだっけ

302 ：

>>298>>299
Cとは何かを決めてるのは言語規格書
違うというなら規格書を引用して説明しろよ

303 ：

こんなトリビアルなピープホール最適化を「昔のコンパイラは馬鹿だから」だなんて
言っちゃうのは、コンパイラのことを全く知らないド素人です、と大声で宣伝するに等しい。

304 ：

>>302
一番最初にCが作られた時に
言語規格書なんてないよｗ
規格書は後から作られたものです。

305 ：

ピープホール最適化なんてのは
Cが一番初めに作られたときはなかったな。

306 ：

> 規格書は後から作られたものです。
だから何。
規格を作る時に既存の実装を無視して作ったとでも思ってるおバカさん？

307 ：

>>306
頭が悪いね。
（規格がない時代の）既存の実装がどうしてそうなっているか。
C言語は高級アセンブラと言われるように、
アセンブラを記述する代わりとして使えるように
コンピュータよりで仕様が作られている。ポインタとかね。
で、その一つが++という命令。CPUがインクリメントを速く実行できる
命令があるのなら、それに対応した文法をC言語に持たせるの自然な発想。
Cが作られたのは1971年だぞ。どんだけコンピュータが遅かったか。
その時代に、時間がかかる最適化処理をコンパイラにやらせるわけないじゃないか。
当時は人間が頑張ってC言語上で最適化する時代だったんだよ。

308 ：

1973年だった。

309 ：

現時点で規格書があるのに、それを無視して
昔はこうだったと言い出す奴は100%仕事できないだろうな

310 ：

どうしてそうなっているかという
過去の話をしているのだから、同然だろ。

311 ：

規格書を引用すればすむ話なのに？

312 ：

そうそう企画なんて後付け、企画？

313 ：

>>311
すむと思うなら自分でやってみれば？

314 ：

そりゃ違う言い出したほうが出すべきだろ
書いてあるんだろ？違うって

315 ：

「規格書に書いてある」と言い出した人はだれですか

316 ：

規格書がない時代から++はあるのに、
規格書で決まってるんだから〜って
言ってる奴は間抜けだなｗ

317 ：

規格書に書いてなかったら同じとも違うとも言えんだろ
馬鹿じゃないの？

318 ：

>>316
>>309

319 ：

>>317
ほう。つまり君は規格書に書いてあると言いたいわけだな？
引用して見せてよ。

320 ：

>>319
規格書に書いてなかったら「未定義」だ
でも「違う」と言い切ったんだろ？だったら書いてあるんだろうが

321 ：

>>318
だからね。規格書がない時代にどうして++が生まれたかの話をしてるんだよ。
規格書は後から作られたもの。
教科書にそう書いてあるから正しいんだとか言うなよ？
恥ずかしいからｗ

322 ：

>>320
もしかして「セマンティクス」の意味がわかってないのかな？

323 ：

>>321
> だからね。規格書がない時代にどうして++が生まれたかの話をしてるんだよ。
>>249から読み直したが、全然そんな話じゃなかったぞ
それとも>>249は規格書がない時代のCの話をしてたのか？

324 ：

とんでもない間違いを何度も晒されてしまう>>248がかわいそうすぎｗｗ

325 ：

> Cが作られたのは1971年だぞ。どんだけコンピュータが遅かったか。
> その時代に、時間がかかる最適化処理をコンパイラにやらせるわけないじゃないか。
> 当時は人間が頑張ってC言語上で最適化する時代だったんだよ。
嘘八百をご苦労さーんw
世界最初のFortranコンパイラが、「コンパイラなんてそんなものか」と
バカにされないために、最適化に苦心した、という話とか、最適化を
勉強していれば普通は常識。

326 ：

結局、シンタックスシュガーの話をしているところに
規格書がない時代のセマンティクスの話をしだして
>もう二度とコードを書かないほうがいいぞｗ
とかドヤ顔で言っちゃったということか

327 ：

よう、俺に振り回された気分はどうだい？ｗ

328 ：

事の発端はこれか。確かにこれは馬鹿すぎる。
>>248
> 248 名前：営利利用に関するLR審議中＠詳細は自治スレへ [sage]： 2012/04/07(土) 01:20:29.83
> 良く使うから構文糖が用意されるって話は分かるが
> 相性が悪いから？なにそれ？
>
> じゃあ何か。C言語で x=x+1 を x++ と書けたり
> *(x+1) を x[1] と書ける構文糖が用意されてるのは、
> C言語がインクリメントや配列と相性悪いからか？

329 ：

スレタイすら読めない奴って、他スレで負けて逃げてきた連中だろうな。

330 ：

自分が負け続きで逃げっぱなしなので、必死でそのように思い込もうとしているのですねわかります

331 ：

リーナスがこのスレに書き込みしてるのか？

332 ：

セマンティクスとは「データの意味」のことであり，

333 ：

適材適所

334 ：

>>328
これって、聞いた話だと、とあるCPUにレジスタの値を＋１するだけの特化命令があって
その命令に対応させるためだけに作った構文なんだってね
むかしは、構文木とかもメモリがないから、一行分づつに作って、マシンコードを生成してたから
そういう命令が必要だったんだとか

335 ：

>>334
最後の行訂正
命令→構文

336 ：

とあるも何も、大抵のCPUにはインクリメント命令ぐらいあるだろｗ
しかも、x += 1はステートメントじゃないしｗバカすぎｗ

337 ：

最近のCPUは特化命令としてはないんじゃないの？
もちろん、命令デコードの段階で判断して、高速に実行するだろうけど

338 ：

昔のCPUと違って、アセンブラ用コードに一対一で対応したマシン語で実行してる訳じゃないからなあ。

339 ：

++とか--が用意されたのは
「アドレスレジスタが指す領域の値を参照/更新したあと、アドレスレジスタをインクリメント/デクリメントする」
「アドレスレジスタをインクリメント/デクリメントしたあと、アドレスレジスタが指す領域の値を参照/更新する」
上記あたりを1命令で実行可能なCPU向けに
最適化とか無しに上記の命令へダイレクトに解釈されるプログラムを書けるよう
用意されたものだと思ってた

340 ：

大昔のPDP-11の頃はそうだったかもしれない、けど、1980年頃にはどうでもよくなって
たんじゃないかと思うけど。
後置の場合に変化前の値が式の値のなる点を除いて。

341 ：

-----------まとめ----------
「馬鹿は死なねば治らないのであり、だからこそアナトール・フランスは
『愚かな者は、邪悪な者よりも忌まわしい』と言ったのだ。
　邪悪な者は休むときがあるが、愚かな者はけっして休まないからである。」
(ホセ・オルテガ・イ・ガセット 1883〜1955)
http://toro.2ch.net/test/read.cgi/tech/1336122899/247
＞ゲームは作らんから知らんが、
224 == 247 == 704 == 717 == http://logsoku.com/thread/toro.2ch.net/tech/1335361193/46
口癖はコンポジション、ミサイルとホーミングミサイルの設計について1ヶ月間も考え続けてる
http://toro.2ch.net/test/read.cgi/tech/1336122899/772
＞ゲーム作らなくてもお前よりマトモ
タスクの実行順序を意識しないとゲームが作れない（笑）
http://toro.2ch.net/test/read.cgi/tech/1336122899/767
敵機　→　プレイヤー　の順序でタスクを実行するとタスクがぶっ壊れる
OOを得意げに語っているつもりが、やっている事が20年前のC言語だったという事実
バイナリの書き換えがわからない
コンパイラ言語のことをコンパイル言語とか言っちゃう
タイプミスの数々、右手の人差し指と中指をケガしてる模様
http://toro.2ch.net/test/read.cgi/tech/1336122899/190
http://toro.2ch.net/test/read.cgi/tech/1336122899/297
http://toro.2ch.net/test/read.cgi/tech/1325246820/837-839
http://toro.2ch.net/test/read.cgi/tech/1336122899/318-320
http://toro.2ch.net/test/read.cgi/tech/1336122899/332-334
http://toro.2ch.net/test/read.cgi/tech/1336122899/818
http://toro.2ch.net/test/read.cgi/tech/1336122899/956

342 ：

なんで関数型の人は他パラダイムを全部「命令型」と呼ぶの？
こないだPrologまでリストに含めて「命令型」と呼んでる人がいて
ツナマヨ思いっきり噴いちゃったヨ

343 ：

そいつが素人あるいはニワカなだけだろ
実際、そのカキコは誰からも相手にされていなかったしね
例外的な馬鹿一人をつかまえて、すべてが同じと考えるのもいかがなものかと

344 ：

SQLは何言語になるのかね

345 ：

ドメイン特化言語

346 ：

確かに関数型言語が汎用である必要は無いのかもね。
汎用言語って括りだと、コンピュータの動作原理を考えても、
やっぱ手続き型が主流になるのは目に見えてるしな。
SQLみたいに何かに特化してしまってよいのかも。

347 ：

関数型言語はアホには理解できないという意味で
汎用的じゃないな

348 ：

つまり研究用に細々と使われるのがお似合いということ

349 ：

>>346
と言うか手続き型で全部やることすら本来なら旧世代の考え方かと
(それが今も濃く残っちゃってるのだけど)
インラインアセンブラみたいな形で
本質的に手順を必要とする部分は手続き型、本質的に式を必要とする部分は関数型、
本質的に論理を必要とする部分は論理型、ごく低レベルな処理を必要とする部分はアセンブラ…
ってやればいいのではないかと思う

350 ：

普通にCとHaskellを組み合わせて使ってる

351 ：

バカは、他人がみんなバカということにしないと気が済まないから、
>>348 のような発想を、よくするんだよな。
80年代に、BASICさえ使えれば万全、とか言い張ってた人にそっくりだ。

352 ：

つまり関数型言語を理解出来ないバカは少数ということ
それなのにユーザーが少ないのは使えない玩具だから

353 ：

>>352
自分がその少数のバカに属する気分はどう？

354 ：

へたくそな煽り乙ｗ

355 ：

ふむ。関数型言語が理解できるって強がり言わないだけ素直でよろしい
バカの上に嘘つきで意地っ張りとか救いようが無いからね

356 ：

関数型言語が理解できるって言うと、強がりになるの？

357 ：

理解してない奴が言ったらそうなるだろう
関数型言語に限らずOOPLでも数学でも何でも

358 ：

理解できない人って居るのかなぁ。
副作用がない分、簡単なんでしょ？

359 ：

>>358
> 副作用がない分、簡単なんでしょ？
これ疑問系で訊くってことはお前は理解できてないんだろ
だから理解できない奴は居るよ。お前のことだよ

360 ：

それ言ったらアセンブラだって簡単だよ
概念自体は理解できても、やりたいこと実現するとこまでいけないのが大概でしょ
手続き型でもそういう初心者が居るように
手続き型に慣れてても関数型という新たな概念に触れた人は関数型初心者になる
関数型のコードに慣れない内は「無理！わからん！」になるのは何らおかしくはない

361 ：

でも関数型って基本的に手続き型から副作用を取ったものだから、
手続き型が出来れば関数型も出来るよ。
むしろ手続き型のほうがあれこれ副作用に頭を悩ませなければならないから
使いこなすのは難しいと思う。
そりゃ関数型で無理に副作用っぽい物を表現しようとすると難しいけど、
それは使い所を間違っているだけだからねぇ。
副作用を狙う箇所は手続きで書けば済む話だし。

362 ：

ていうか OCaml 使えよ、っていう話だろ

363 ：

だって、関数型が難しいって論調だったから。

364 ：

ルーピーで関数型を気取られても

365 ：

関数型って気取るものなのですか？

366 ：

手続き型言語での状態書き換えを、「副作用」と呼ぶ事自体が迷走の始まり。
手続き型と同じアプローチで関数型言語を無理やり使おうとすると、関数型言語にとって副作用でしかないものが必要になるだけの事。

367 ：

おっとScalaを勘違いして採用した現場の悪口はそこまでだ

368 ：

勘違いして使ってりゃ、悲惨なことになるのは何でも同じだな。

369 ：

>>367
Twitter社のことか

370 ：

関数型コミュ、特にハスケラのdisり大好きっぷりを見ていると、
こいつらメジャーになったら速攻で内ゲバ始めるのが目に見えるから
距離を保つことにしたｗ

371 ：

距離を保つも何も、お前が近づけたことなど一度も無いだろ

372 ：

>>9
の
＞関数型言語が普及しない理由 - 偏見プログラマの語り！
＞http://d.hatena.ne.jp/kura-replace/20111114/1321236695

これ、俺がググって偶然そいつのその記事見つけたとき
＞　というわけで本稿を書くわけですが（ヤメテ！そんな冷たい目で僕を見ないで！）、
＞関数型言語*1についてはよく知りませんので、決して真に受ける事無く、
＞オブジェクト指向言語をようやっと使っている底辺プログラマのぼやきということで了解いただければと思います。（ヤメテ！その前置きはズルイとか言わないで！）
この発言にブチギレそうになった奴の記事だわ

なんで>>9は明らかに初心者みたいな奴のブログ引用してんの？
引用に見せかけた晒し？
関数型はやっぱ流行らないな

373 ：

22 ：uy [sage] ：2012/06/13(水) 16:53:41.38
　静的言語はゴミでしかない

374 ：

>>366
手続き型言語には元々、「副作用」なんて無いしな。
あるのは、状態書き換え。

375 ：

printfが標準出力に出力するのも状態書き換えっていうの？

376 ：

最終的にはストレージの書き換えやパイプバッファの書き換えになるんじゃね

377 ：

そこらへんひっくるめて値を返す以外のことは副作用と呼んだらすっきりしていいじゃないか
手続き型であっても有用な概念だ

378 ：

>>371を読んでしまえば>>370に賛同するしかないだろうよ

379 ：

>>378
2chで世間が判った気になり始めたら、色んな意味でヤバイな。

380 ：

>>377
Prologをやってる立場から言うと、手続き型の中で副作用なんていって欲しくない。

381 ：

>>379
2chで世間が判った気になって他人にヤバイなとか言ってるバカｗ

382 ：

殴ったら殴り返されただけだろ？
どっちもどっちだよ

383 ：

どうしてあんなにdisるのが大好きなんだろう？依存症？

384 ：

uyはどっかのスレで、コテではいかに相手を苛立たせるかに心血を注いで、
普通の内容は名無しで書くみたいなことを言ってたな。
昔は単なる馬鹿だったが、最近は馬鹿の一つ覚えで○○も知らない奴らが〜○○位は当然〜みたいなことを言い出して、ウザさに磨きがかかってきたな。

385 ：

自己紹介乙

386 ：

each_slice
transpose
chunk
inject
cycle
すら使えない奴らって生きてる価値ないと思う
例えば
10.times.cycle do |n| p n end
によって0~9をプリントする処理を無限ループなわけだけど、貴様らちゃんと扱えていますか？

387 ：

mapM_ print $ cycle [0..9]

388 ：

javaやC#に代数的データ型を導入して欲しい
関数型言語を使う気にはなれないけど、あれの素晴らしさには反論出来ない

389 ：

関数型の人たちって、どうしてあんなに上から目線でdisるのかな？

390 ：

静的型付け型の人たちって、どうしてあんなに上から目線で(動的型付けを)disるのかな？

391 ：

だって関数型言語を批判してる連中（の大部分）って
物凄く低能で、批判も的を射てないんだもん。
しかも批判しといて反論されたら上から目線でdisるな、とか言い出すし。
ホント馬鹿の上に品性まで劣ってるよな。

392 ：

だって動的型付け言語を批判してる連中（の大部分）って
物凄く低能で、批判も的を射てないんだもん。
しかも批判しといて反論されたら上から目線でdisるな、とか言い出すし。
ホント馬鹿の上に品性まで劣ってるよな。

393 ：

排他的なのは大抵ニワカ

394 ：

上から目線とか言っちゃう人は、永遠に底辺にいればいいと思うんだ。
向上心が欠片もない人間を引き上げてやる義理は無い。

395 ：

引き上げてやるだってｗおもしろすぎｗｗ

396 ：

自分の脳味噌を観察したほうが面白いと思うぞ

397 ：

「上から目線」って言葉を聞いて「自分は上なんだ」と思うのがおもしろいんだが、そこが分からないとは…

398 ：

上から目線と言い出す奴は
自分より下に居るんだなぁ、と思うだけだが

399 ：

争いは同レベルの相手同士でなければ起き得ない(AA略

400 ：

>>398
その発想が興味深いんだよ

401 ：

バカが言う「興味深い」って、単に理解できてないだけだよなw

402 ：

>>401
この場合の「上から目線」ってのは、馬鹿にされてるんだよ

403 ：

バカに馬鹿にされても、何とも思わないけどな

404 ：

バカにされているのは>>403だということに気付けｗ

405 ：

ズレてね？

406 ：

ズレてるよなw

407 ：2012/10/21