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

1 ：11/11/08 〜 最終レス ：12/01/26

関数型言語は学習コストが高すぎる。
玩具として、研究者や学生の自己満足として、
教科書や黒板を賑わすアクセサリーとして、
あるいは頭の体操としての価値は認める。
だが、仕事ではほとんど使い物にならない。
やれば作れる、実際に作った、そんな言い分は聞き飽きた。
主要なソフトウェアのほとんどは非関数型で書かれている。
関数型がプチブームだが、爆発的に採用が増えているとも考えられない。
いずれ関数型のブームは去るだろう。
仮に関数型が生き残ることがあったとしても、
手続的な言語における一部の機能としてだろう。

2 ：

はいはい
アイちゃんアイちゃん

3 ：

バカに教えようとしたのがまずかったんだ

4 ：

人間の日常的な思考は全く関数的でない。
業務の手順等も全く関数的でない。
「まずこれをやって、それからこうして、
それでこうなるから、これをこうする」的な考え方をするのが普通の人間。
もしそれを自動化するプログラムを書こうとした場合、
それを素直に書ける言語のほうが普通は楽にできる。
仮に関数型のほうが簡潔に書けたとしても、
関数型に脳内変換しなければならない時点で負担は大きい。
関数型なら生産性が向上するという主張は、
一部個人ではそういうこともありうるが
社会全体としてはむしろ生産性の低下につながる。
関数型が使えないのは頭が悪いからだというのは、まぁある程度正しい。
だったら頭の良い人が自己満足で使っていればよいのであって、
他人様を巻き込む必要はない。

5 ：

京都大学霊長類研究所では、未知の感染症が蔓延し、
感染した研究員はどのスレッドにも同じコピペを
繰り返すといった症状が報告されています。
研究員によると思われる書き込みがあっても
近づかないようにしてください。
　　　　　　　　　　　　　　　　　　京都大学

6 ：

【萌え画像】子猫にブルマーをはかせてみた。。。(*´Д`)ﾊｧﾊｧ
http://toki.2ch.net/test/read.cgi/cafe60/1270834077/

7 ：

時々の状態を覚えておかないといけない
クライアントアプリケーションに関数型の適用は不適切だと思う
Webサーバアプリは大きく見ればフィルタと見なせるから
組みやすさは別として関数型が使える分野だと思う
使ったことはないが

8 ：

流行るということは馬鹿と貧乏人が手を出すということだ
よって関数型言語は流行りようがない

9 ：

黒板とな

10 ：

>>1
流行らないから安心しろ。
分かる人間だけが細々と使っていき、その成果が手続き型に取り込まれていくだけ。
もし流行るなら、もっとマシな世界になってる。

11 ：

このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

12 ：

>>1
スレタイ間違ってるよwww
誤：【アンチ】関数型言語は使えない【玩具】
正：【アンチ】関数型言語が使えない【玩具】

13 ：

>>1
CやRubyより覚える事少ないと思うんだが。。。

14 ：

というか>>1は関数型言語を知ってる側の人間だろう

15 ：

>>12,14
>>1は典型的なハスケラ症の患者
>366 名前: デフォルトの名無しさん Mail: sage 投稿日: 2011/10/26(水) 12:25:43.06
>>>365
>それはハスケラ特有の症例で、心の病の一つ
>
>ハスケルという言語を使っていると、世の中のあらゆる事柄すべてが
>ハスケルを中心に廻っているように見えるらしい
>従って、あらゆる関数型言語は静的実行かつ静的型付けでなければならないし、
>遅延評価が常識であり、一切の副作用は認めようとしない
>
>ハスケラにとって関数型言語とはハスケルのことであり、
>その窓から見える世界が彼らのすべて
誤：【アンチ】関数型言語は使えない【玩具】
正：【アンチ】ハスケルは使いものにならない【玩具】

16 ：

代数の基礎を一応は学んでいる理工系の人なら自然だと思うが
プログラム書くのはそういう人達だけじゃないからな

17 ：

OCamlだけは認める。

18 ：

>>16
一次関数二次関数習ってれば、十分覚えられるだろ

19 ：

感情的な毛嫌いをするような人たちに彼らの能力の対極
にある言語を使えるわけがないわな。

20 ：

>>13
学習コストと暗記量は比例しない。
覚えることが少なくても
使いこなすのが難しければ
学習コストは高い。

21 ：

かつてのプリントごっこで出来る事はプリントごっこでやればいいし、印刷機必須のものをプリントごっこでやろうとすると悲惨なことになるのと同様。

22 ：

>>20
使いこなす事も簡単だと思うけど。。。。
自分、yesコマンドとか、haskellでは作れても、Cやrubyで書けへんねん

23 ：

>>22
せやな

24 ：

>>20
それを言っちゃ。。。。
お里が知れる。

25 ：

>>22
無限ループ内でひたすらyes\n出力してフラッシュじゃだめなん？

26 ：

ruby -e"begin; loop{puts ARGV[0] || 'y'}; rescue Interrupt; puts; exit 0; end"
こんな感じ？ 恥ずかしながらyesコマンドって初めて知った

27 ：

まあ、シェルスクリプトですら滅多に使わないからなあ

28 ：

>>25
ごめん。
たぶん、作れる。
作り方もそれで合ってると思う。
確実に作れないのはクイックソートをCでは作れないなw
配列でってだけで、どうすれば良いのか分からんw
昔、Cのクイックソート読んだけど、全然何やってるのか分からんかったｗｗｗ
>>26
Haskellの入門書（日本人の書いた「入門Haskell」の方）に乗ってて、ちょっと前に、コマンドライン版じゃんけんゲームのテスト用に思い出しながら書いた
じゃんけんゲームは別にCでもRubyでも書けるんだけどね…

29 ：

>>24
別に間違ったことは言ってないだろ。
Common LispのほうがSchemeより使いやすいと感じる。
Schemeは覚えることは少ないが、理論に走りすぎ、
ミニマム主義が度を越していて、再帰を強要しすぎで、
実用性ではCommon Lispより劣る。
Common Lispは関数型のような手続き型だと言えなくもないが、
あれくらい節操が無くて何でもありのほうが
過剰にテクを要求されないので書きやすい。

30 ：

ハスケルって学校の実習でしか使われてないんでしょ？

31 ：

>関数型が使えないのは頭が悪いからだというのは、まぁある程度正しい。
>だったら頭の良い人が自己満足で使っていればよいのであって、
そのロジックなら「頭の良い」人が集まる会社は関数型を使うべきだよね
個人的には、その意味で「頭の良い」人はプログラマ人口の50%を超えると思う

32 ：

>>31
> そのロジックなら「頭の良い」人が集まる会社は関数型を使うべきだよね
え？その論理能力で関数型分かってるとか自称するの？
対偶を取っても、「頭の良い人は関数型を使える」であって、「使うべきだ」にはならんぜ？

33 ：

>>32
書いてからそれ思った
言い訳をすると、使えるなら使う方が良いというのは
「だったら〜使っていればよい」から読み取れないこともないよね

34 ：

>>33
色々な言語や環境を使ってみて自分で評価するのは大事なことだよね。
でも、「使うべき」という言葉からは、微妙に排他的なニュアンスを感じなくもない。
昔のオブジェクト指向もそうだったけど、これから盛り上がろうという言語や環境は
得てして独善的になったり排他的、攻撃的になったりしがちだから、
気をつけたほうがいいかもね。

35 ：

>>34
俺自身が「使うべき」と主張してる訳じゃないからな、一応言っておくと

36 ：

>>35
あ、すまん、勘違いしてた。吊ってくるわ。

37 ：

>>34
誤った用法：
>これから盛り上がろうという言語や環境は
>得てして独善的になったり排他的、攻撃的になったりしがちだから、
正しい用法：
>ハスケラは
>得てして独善的になったり排他的、攻撃的になったりしがちだから、

38 ：

それは「正しさ」をウリにしているパラダイムの宿命かもなｗ
ただし、Haskellのコードが本当に正しいのかは疑問が残る。
証明うんぬんとか言うが、全てのコードが正しさを証明されているわけじゃあるまい。
ましてや、仕様自体の無矛盾性まで証明されているわけでもあるまい。

39 ：

http://d.hatena.ne.jp/morchin/20110614/p1
[一般] なぜ関数型言語は普及しないか - プログラミング日記
言語を利用するための条件は以下の３つになると思う。つまり、言語が普及するための条件とも考えられる。
* 使用するための必要条件を満たしているか
* その言語を使用するメリットがあるか
* デメリットはないか

40 ：

いわゆる関数型っていうより宣言型の趣きが強い言語はキツイ

41 ：

関数型はコードが美しいけど、オブジェク指向は構造が美しい。
ツールでUML生成してニヤニヤするのがいいんじゃないか

42 ：

UMLってなんかおっさん臭い印象がある。

43 ：

Haskellを実プロジェクトに使うのは現状無理だな
メモリ消費が予測不能すぎ
ML系のほうが扱いやすいよ

44 ：

金融周りのツールで使われてるイメージ。あとはtwitter。
ってか、関数型のメリットってオブジェクトを持たない（状態を持たない）から
変数周りでバグが出にくいってメリットがあるんじゃないの？
後は型推論とか可読性とか
javaが読み辛いすぎるだけの気もするけれど

45 ：

関数型言語ってそもそも入出力どうしてんの
DB操作とかどうすんの

46 ：

関数型言語で tail -f って書けるの？

47 ：

Hello, worldができるんだから同じ要領であらゆる入出力ができるし、Cも呼べる

48 ：

>>47
君がstatもselectもepollも使ったことがないのは分かった

49 ：

は？
もしかしてC関数にポインタを渡せるかを心配してるの？
HaskellやOCamlなら当然できるよ

50 ：

>>45
http://www.nslabs.jp/haskell-rdbms.rhtml
>>46
キャッシュにしか残ってなかった
http://webcache.googleusercontent.com/search?q=cache:qYwvNDCRuyEJ:ja.doukaku.org/195/nested/+haskell+%26%26+unix%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89+%26%26+%22tail+-f%22&cd=1&hl=ja&ct=clnk&gl=jp
自分が書いたじゃんけんプログラム見ればわかりやすいと思うけど、３１行より前は関数的、後は手続的に書かれてる
http://codepad.org/9mTpxBrA
一方で、自分が書いた独自自然数（と、それで計算するための関数・演算子は、すごく簡単に書ける
http://codepad.org/0WvSpM7o
手続的な処理が特に苦手と言うわけでもない
手続的な処理は、手続型言語と大差ないってだけ

51 ：

>>46
てきとーに書いたら手続き型っぽいコードになった
let rec tail_f filename where =
  let c_in = open_in filename in
  let size = (Unix.fstat (Unix.descr_of_in_channel c_in)).Unix.st_size in
    seek_in c_in where;
    Stream.iter print_char (Stream.of_channel c_in);
    flush stdout;
    close_in c_in;
    Unix.sleep 1;
    tail_f filename size
let tail_f filename = tail_f filename 0
let _ = tail_f "foo.txt"

52 ：

>>51
せめてfilenameじゃなくてc_inを渡す感じにすりゃいいのに。毎回opencloseする意味ないし、selectで待機できるだろ

53 ：

「関数型言語で手続き型言語っぽい記述もできる」
「手続き型言語で関数型言語っぽい記述もできる」の両方が真なら、
本質的な違いは制約の多さだけだな。

54 ：

手間掛ければまあ何でも出来る
細部が重要だ
破壊的代入のたびに一々　:= だの　! だの書く気にならなんよ

55 ：

>>53
どうしてこんなキーワードがあるの？
http://d.hatena.ne.jp/kazu-yamamoto/20080904/1220495854
より、引用を抜粋（ややこしいｗ）
ちゃぶ台をひっくり返すようなまとめ
「なぜ Haskell は重要か」の一部を翻訳して、この記事のまとめとします。
(関数型言語と)同じ程度とは言えないが、命令を並べる方式でも抽象化していくとこはできる。
命令型言語では、新しいキーワードと標準ライブラリを導入することで抽象化する。
たとえば、多くの命令型言語は、プログラマーがループを実現する仕事から解放されるように、少しずつ動作が異なる複数のキーワードを用意している。
しかし、命令型言語は、命令を並べる方式に基づいているため、そこから完全に逃れることはできない。
命令型言語では、命令の並びに対し、抽象化のレベルを上げる唯一の方法は、さらなるキーワードや標準関数の導入である。
そして、言語はゴチャゴチャになる。
引用を抜粋、終わりｗ
まさに、OOPの事だな。
http://codepad.org/0WvSpM7o
のコードでは、dataと、deriving (Eq,Ord,Show,Read)、あと|（OR演算子だったり、ガードだったり）以外は、言語としてのキーワードは使ってない。（機能としては、パターンマッチも使ってるけど）
そのまま、数学の定義を持ってきてるだけ
手続型言語だと、キーワードはこんなに少なくできない

56 ：

あ、==もか
まあ、キーワード少ないのは変わらないか

57 ：

>>55
制御構文がムダに多いのは自然言語もそうだし、別に問題ないだろ。
制御構文が異常に多くなって呪文みたいになった言語なんてPerlくらいしか知らんよ。

58 ：

>>52
関数型とか関係なくselectじゃ待てんだろ

59 ：

>>57
そうは言うが、例えばRubyの入門書を読んだだけでは>>55と同じ動作のコードを書けるようにならない。
入門書では、Haskellと同じ抽象度を表現できるキーワードが揃ってない事になる。
が、このコードはプログラミングHaskellという入門書を読破もしてない自分が書いたものだ。
この差は、何だろうな。
一方で、副作用のある処理をしようとすると、HaskellでもHoogleなどで調べる回数が極端に増える。
関数型でも手続型でも、副作用がキーワードを生んでいる。とも言えるのかもしれない。

60 ：

>>58 は本当に入出力を知らないんだな…。
int select(int nfds, fd_set *readfds, fd_set *writefds,
fd_set *exceptfds, struct timeval *timeout);
最後の引数が何か分かるか？

61 ：

>>59 は TMTOWTDI とか聞いたこともなさそうだ。

62 ：

これから>>60がselectでtail -fを書くスレになりました

63 ：

>>62
GNU coreutils のsrc/tail.c が実例だ。 俺が書く必要はかけらもないな。

64 ：

selectで待機できるのはパイプやソケットやpty等であって
通常のファイルには役に立たない
（ファイルの終端に達してもファイルディスクリプタは読み取り可能として扱われるから）

65 ：

>>63
inotifyはLinux限定ですよ

66 ：

>>1 プログラマは資格もなにもいらないから能力のない奴がいっぱいいる。
言わばヤブ医者がいっぱい病院立てている状態。当然頭のわるい奴には
最新の医学なんて理解できないからいつまでも古い治療法を続けている。
そんな状態では高度な医学は流行っていないと観測される。
おれはどんなに少数派でも最新の医学を理解している医者のいる病院にいきたいな。

67 ：

じゃあその最新の医学とやらの例を挙げて欲しいな
名ばかり最新では困ります

68 ：

>>303
2chも書き込むのに資格が要らないんだが、気付いて無かったようだ。

69 ：

関数型が広まらないのは、難しいからじゃなくて
「OOP？デザインパターン？馬鹿じゃねーの？ｗｗｗ」って雰囲気を
醸し出してるから。
そりゃ関数型言語以外のプログラマには反発されるよね。

70 ：

OOPって呼び方なんとかならないか
俺英語の感覚が染み付いてるからウープって読んじゃうわー
俺英語の感覚が染み付いてるからー

71 ：

>>69
ああ、本物のプログラマーは・・・とか、そんな感じのね
本当は、初心者でも割と簡単に複雑なプログラム組めるのにね・・・
初心者がいきなり初日にLength関数作れる言語って、Haskellに限らず、（多分）関数型言語だけだよ

72 ：

C#でも多分作れるぞ

73 ：

そんな情緒的なことで決まるか？
○○は仕事で普通に使うこれが仕事の標準の道具だ。
○○は豊富なライブラリが揃っていて環境もある。おまけに、つかいては
わんさかいる。
こんなところだろうよ。

74 ：

It is true that OOP is oops! :-)

75 ：

>>72
初心者が初日で？

76 ：

>>69
誤：関数型が広まらないのは、難しいからじゃなくて
　　「OOP？デザインパターン？馬鹿じゃねーの？ｗｗｗ」って雰囲気を
　　醸し出してるから。
　　そりゃ関数型言語以外のプログラマには反発されるよね。
正：ハスケルが広まらないのは、難しいからじゃなくて
　　「OOP？デザインパターン？馬鹿じゃねーの？ｗｗｗ」って雰囲気を
　　醸し出してるから。
　　そりゃハスケラ以外のプログラマには反発されるよね。

77 ：

手続き型スタイル
def length(x):
    n = 0
    while x != []:
        n += 1
        x = x[1:]
    return n
関数型スタイル（？）
def length(x): return reduce(lambda n,_: n + 1, [0] + x)

78 ：

そもそも、手続き型言語でリストのLengthを実装したいと思ったことがない件。

79 ：

javaでいうcollectionくらい使ったことがないの？>>78

80 ：

>>79
size()メソッドが既にあるだろう。 使うだけならなんで自分で実装する必要があるんだよ

81 ：

length xs = sum [1|_ <- xs]
def length(xs): return sum([1 for _ in xs])
カレーの圧勝だな

82 ：

関数型言語では遅延評価があるから、集合のlengthを求めるのに再帰が必要って話を
そもそも再帰しなくても標準ライブラリでデータのリストを扱う手続き型言語にもってくるから話がおかしくなる。
手続き型言語が持ってる、集合の最もシンプルなインタフェースは
Javaでいう Iterable だろうが、Javaでこれを生で扱う機会がそもそも多くないからな。

83 ：

reduceやリスト内包やsumを使ってて
再帰なんて使ってない件

84 ：

>>83
全要素のスキャンを行ってるのは同じだろうに。
組み込み演算子ならOK、って理屈は、javaなら標準ライブラリにsizeがあるってのとどう違うんだ？

85 ：

情報科学業界の知人らに
C#er なので　再帰はなるべく避けようと思います
っていったら何言われるかわからなくて怖い

86 ：

・Haskellプログラマ
lengthはあくまで一例であって、そういう機能を自分で実装する際に
どれだけ楽に書けるかに注目している。
・Javaプログラマ
標準ライブラリにsizeがある、で思考停止。
基本的にライブラリの機能を呼び出す事しか考えないドカタ気質。

87 ：

c#はx86とx64,DebugビルドとReleaseビルドで末尾最適化の有無が変わる恐ろしい世界

88 ：

>>86
よく分からんけど車輪の再発明が好きなの？

89 ：

lengthって例が適切ではないのを棚に上げて

90 ：

>>88
ライブラリに無い機能があったらどうする？という当然の可能性を考慮できないのがドカタ。

91 ：

前にどこかのスレで見た、下のコードのJava版は冗長すぎて笑ったｗｗｗ
pyths n = [(x,y,z) | x <- [1..n], y<-[1..n], z<-[1..n], x^2+y^2 == z^2]

92 ：

こういう対立は収束するまで関わりたくないので
vimとかemacs とかいじってます

93 ：

>>91
楽しい言語スレだね
書き出しは私
他の言語だとどうなん？って聞いたらScalaやOCaml、Python、Javaが出た
Rubyが真っ先に来ると思ってたけど、結局来なかった

94 ：

Rubyプログラマは勝てる（短く書ける）勝負にしか参戦しないよ
護身完成してるから

95 ：

関数型は関数向きのコード書けると気持ちいいよね

96 ：

>>86
int[] array = new int[100];
配列というのは当然、領域を確保する時にサイズを指定するわけです。
array.size() というものがなければ、どうやってサイズを取得するのでしょうか。
int getSize(int[] array) {
...
}
この関数を再帰でもループでも、size() を使わずにどうやって書きますか？
教えてください。

97 ：

int[] array = new int[100];
int n = 0;
for (int i: array) n++;

98 ：

その for の停止条件に size が使われています。

99 ：

つまり、>>97 はこれと等価です。
int n = 0;
for (int i = 0; i < array.size(); i++) n++;

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
・　次のスレ
25: こんなライブラリは嫌だ！ (81)
27: VB.NET質問スレ(Part38) (172)
29: 【SICP】計算機プログラムの構造と解釈 Part2 (795)
30: ふらっとC#,C♯,C＃（初心者用） Part84 (731)