関数型言語は何故普及しないのかを考える

1 ：デフォルトの名無しさん：2010/06/22(火) 23:05:06

きっと、Lisp厨とHaskell厨が声高に演説してくれるでしょう。

2 ：デフォルトの名無しさん：2010/06/22(火) 23:13:59

手続き型、関数型という区分け自体が既に時代遅れ
最近の言語はどれも中間的な言語になっている

3 ：デフォルトの名無しさん：2010/06/22(火) 23:14:12

人間の思考が手続き型だから。

コンピュータの話に限らない。
文章だって長々と一文で書くより、
分けて書いたほうがわかりやすいだろ？
それと同じ。

4 ：デフォルトの名無しさん：2010/06/22(火) 23:38:22

数学の抽象的な議論が普及しないのと同じ

5 ：デフォルトの名無しさん：2010/06/22(火) 23:39:16

読みやすさの基準
数式＜＜＜関数型＜＜＜手続き型＜英語＜日本語＜＜＜＜＜＜映画（字幕スーパー）

6 ：デフォルトの名無しさん：2010/06/23(水) 01:31:10

以上、算数に私怨のある素人仕分け人の皆さんでした。

7 ：デフォルトの名無しさん：2010/06/23(水) 01:42:25

いや、そんなことどうでもいいから
何で普及しないのか書けよ。

8 ：デフォルトの名無しさん：2010/06/23(水) 05:36:36

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

9 ：デフォルトの名無しさん：2010/06/23(水) 07:40:28

>>7
布教活動がふぬけているからに決まってる。

関数型言語でゲームを「いっぱい作った」実績を見せたり、
業務アプリを「素早く作った」実績を見せたりすれば、
誰もが注目し、ちゃんと普及する。

それなのに、薦める奴らは何で実績を見せないんだろうな。

たまに実績を示す奴でも、海外の誰々という研究者が
GUI のエディタを関数型で作ったとか、
日本の誰々がグラディウスを移植したとか、そんな話ばっか。

「おまえでも」そういうアプリが作れるという実積を見せなきゃ、
誰も感銘なんて受けないのに。

10 ：デフォルトの名無しさん：2010/06/23(水) 09:09:31

なんで >>9 にとって、モナディウスの作者が「おまえ」でないかを考えるスレになりました

11 ：デフォルトの名無しさん：2010/06/23(水) 09:10:20

関数型を色々参考にして普及したのに関数型に分類されない言語がたくさんある
分類がふぬけている
分類が時代遅れ

12 ：デフォルトの名無しさん：2010/06/23(水) 10:19:01

手続き型か関数型かとかより
キーワードやブロックの記述が C と似てないのは
覚えるのがめんどくさい。

13 ：デフォルトの名無しさん：2010/06/23(水) 12:37:41

>>10
勘違いさせたしまったようで悪かった。

俺が言いたかったのは、
関数型も実用的だよと言って薦めてくる「作者以外の奴ら」の事。
モナディウス作者はこの話の中に限れば、どうでもいいんだよ。

「モナディウスも作れるんだぜ、だから関数型は凄いよ、使えるよ」
という奴らに対して「君は何を作ったの？何を作れるの？」と訊くと、
たいていは答えられない。
ちゃんと答えられる布教者が何人も出てくると、
普及する兆しがちょっと出てくる。

14 ：デフォルトの名無しさん：2010/06/23(水) 13:14:05

卵と鶏

15 ：デフォルトの名無しさん：2010/06/23(水) 13:40:16

美味そうな卵はぜんぶ食われてしまった。
でも、売れ残った卵から生まれたやつらは、自分達が生存競争に勝ってると思ってる。

16 ：デフォルトの名無しさん：2010/06/23(水) 20:15:56

>>13
お前は手続型で何を作れるの？

17 ：デフォルトの名無しさん：2010/06/23(水) 20:53:21

自社のゲームを作った（正確にはその一部）
自社内の製品管理システムを作った
自社内のテクスチャエディタを作った
その他色々、挙げきれない

18 ：デフォルトの名無しさん：2010/06/23(水) 20:53:58

それって凄いソフトなの？

19 ：デフォルトの名無しさん：2010/06/23(水) 21:24:33

凄いという意味が分からん。
利用者がやりたいことを（ある程度）実現するソフトウェアを作っただけだ。

おまえの中ではどういうのを凄いと言うんだ？

20 ：デフォルトの名無しさん：2010/06/23(水) 21:32:33

関数型言語を選んだからにはその特徴を大いに利用して、
それでいてかつ、それなりの規模があるソフトである必要はあるだろうな

21 ：デフォルトの名無しさん：2010/06/23(水) 21:40:23

普及させたいがコモディティ化は気に入らないという、ありがちな話

22 ：デフォルトの名無しさん：2010/06/23(水) 21:58:04

特徴を大いに利用するのは手段であって目的ではないな。
目的にしてしまっては普及は不可能だ。

あくまでも目的は、ある要求に対して
これくらい早く簡単にプログラムできる、
これくらい分かりやすくプログラムできる、
「小規模なら熟練者じゃなくてもソフトウェアが作れる」
ということをちゃんと示す事。
そのために関数型言語の特徴を利用する。

ソフトウェアの規模は、普及させる初期段階では
それほど必要ではないと思うし、
関数型言語はまだ初期段階にすらなってないように感じられる。

23 ：デフォルトの名無しさん：2010/06/23(水) 22:57:16

メリットがないのに流行るわけないから
特長の利用は目的と言っても過言ではないよ

24 ：デフォルトの名無しさん：2010/06/23(水) 22:58:22

関数型言語に波長が合う人が少ないのが原因
性能が劣っているというこてゃない。むしろその逆

25 ：デフォルトの名無しさん：2010/06/23(水) 23:27:51

>>23
仮にメリットがなくて互角だとしても、どっちかが偶然に流行るわけだが
そっちが偶然を信じないなら、あっちが不戦勝だ

26 ：デフォルトの名無しさん：2010/06/23(水) 23:45:26

副作用がないからテストが楽とか言うけど
そのあたりを大きな規模の具体的なプログラムで説明しないから
実感湧かないんだと思うぜ

27 ：デフォルトの名無しさん：2010/06/24(木) 00:03:33

具体的な例を挙げても抽象化されたコードにアレルギーがある人には無理なんだって

28 ：デフォルトの名無しさん：2010/06/24(木) 00:14:51

『一般人は俺等みたいに思考が自由じゃないから、どんなに価値がある物でも
本質を理解しようとせず、無闇矢鱈と意味も無く闇雲に嫌っているだけで、
どうやったって救いようが無いから、原因を考えたって無駄だって言っただろ。
奴らが関数型言語のメリットを理解するには後500年は掛かるぜ。』

↑みたいな意見が出るかと思ったら意外とそうでもなかったね。

29 ：デフォルトの名無しさん：2010/06/24(木) 01:23:40

思考が自由かどうかは別として思考が異なるから理解できないのは事実

30 ：デフォルトの名無しさん：2010/06/24(木) 03:30:40

『関数型言語の実装がこれだけあるのにも関わらず使ってない人たちは先を見通す力の
無い人たちなんだから、一々相手にしなくていいでしょ。使いこなす能力を持ってる人が
便利に使えばそれで良いだけ。関数型言語を理解出来ない人がどれだけいようと、
俺等には関係無いし、普及するのがそんなに大事な事か疑問だね。』

↑こういう意見も無かったな。

31 ：デフォルトの名無しさん：2010/06/24(木) 03:40:58

先を見通す力が無いかは別として、一般に使いこなせる人の絶対数が少ないから、企業の開発などではなく
個人のサーバーサイドプログラミングなんかで使える人が使えばいいというのは事実

32 ：デフォルトの名無しさん：2010/06/24(木) 12:23:39

処理すべき現実世界の事象が関数型的ではないから

33 ：デフォルトの名無しさん：2010/06/24(木) 13:36:58

その時々で最適な方法を選べたらそれで良い

34 ：デフォルトの名無しさん：2010/06/24(木) 17:15:36

http://www.indeed.com/jobtrends?q=Lisp,SML,Haskell,Scala,OCaml
Scalaの求人は急激に増加し、すでに他の関数型言語を上回りました。
「関数型言語は普及しない」はScalaには当てはまりません。

Scalaは非常に豊富なJavaライブラリを利用できます。
また、手続き型風にも関数型風にも書けます。
純粋関数型言語が普及しない原因はライブラリ不足と
関数型では書きにくい処理があるためと考えられます。

35 ：デフォルトの名無しさん：2010/06/24(木) 21:37:56

>>34
>すでに他の関数型言語を上回りました。

が何で

>「関数型言語は普及しない」」はScalaには当てはまりません。

に繋がるの?

人気のある普通の言語と比べないと意味無いじゃん

36 ：デフォルトの名無しさん：2010/06/24(木) 22:09:00

それはともかく、純粋関数型言語の Haskell に、
他の人気のある言語には普通にある類のライブラリが欠けている事はたしかだ。

さっさとスタンダードと言える GUI ライブラリを整備して欲しい。

これが無いままなら、普及なんて絶っっっっ対にムリだよ。

37 ：デフォルトの名無しさん：2010/06/24(木) 22:18:36

普及する事が全てだという価値観ならそうかもな

38 ：デフォルトの名無しさん：2010/06/24(木) 22:20:45

何故普及しないのかを考えるスレなんだから、
普及する事が全てだろ

でなきゃスレチじゃないか

39 ：デフォルトの名無しさん：2010/06/24(木) 22:57:56

そういう意味では Haskell がスレ違いだな

40 ：デフォルトの名無しさん：2010/06/25(金) 21:05:08

Haskellは普及してるって意味？

41 ：デフォルトの名無しさん：2010/06/25(金) 22:59:49

【手続き型小説】
吾輩は猫である。
名前はまだ無い。
どこで生れたかとんと見当がつかぬ。
何でも薄暗いじめじめした所でニャーニャー泣いていた事だけは記憶している。
吾輩はここで始めて人間というものを見た。

【関数型小説】
人間というものを始めて見た薄暗いじめじめした所でニャーニャー泣いていた事だけは記憶しているがどこで生まれたかとんと見当がつかず名前がまだ無い猫である吾輩。

どっちが読みやすい？

42 ：デフォルトの名無しさん：2010/06/25(金) 23:09:11

前者の方が圧倒的に読みやすい

ところで、関数型小説がそのようになる根拠を示してくれ
どあたりが「関数」なんだ？

43 ：デフォルトの名無しさん：2010/06/25(金) 23:13:23

>>42
関数型言語で3重ループとか書いてみればわかるよｗ

44 ：デフォルトの名無しさん：2010/06/25(金) 23:15:54

どちらにしろ例えとしては無理があるな

45 ：デフォルトの名無しさん：2010/06/25(金) 23:22:37

面白いと思って書いたんだろ。分かってあげなよ。

46 ：デフォルトの名無しさん：2010/06/25(金) 23:25:39

>>42
大昔のコピペだから、それ
小説っつってるから文体(と言うのか？)を見て「関数」かどうかは無視してるんだろ。

関数型言語でも結果を毎回一時変数にbindすれば見た目手続き型と同じになるだろうけど、
そうしないで書いちゃうこと多いから見づらいと感じる人が多いんだろうね。

47 ：デフォルトの名無しさん：2010/06/25(金) 23:34:38

手続き型だってメソッドがチェーンする様に書く事も出来るし、
Smalltalk のカスケードも変数を介さないで複数の式を繋げる
手法の一つ。それらが見辛いとは思わないね。

48 ：デフォルトの名無しさん：2010/06/25(金) 23:40:35

結局手続き型風な書き方をするから
関数型言語は普及しないと。

49 ：デフォルトの名無しさん：2010/06/25(金) 23:48:59

コピペを貼るにもセンスが必要だってことだな

50 ：デフォルトの名無しさん：2010/06/26(土) 01:06:10

>>43
関数型言語で3重ループってなんだよ。

関数型は Haskell しか使ったことないが、
3重ループなんて見たことないぞ。

51 ：デフォルトの名無しさん：2010/06/26(土) 01:29:40

種類我が輩 = 猫
名前我が輩 = undefined
記憶我が輩 = [薄暗いじめじめした所でニャーニャー泣いていた]
経歴我が輩今 = ここで始めて人間というものを見た

52 ：デフォルトの名無しさん：2010/06/26(土) 11:11:43

Haskellでも手続き型風に書けばいいのか

53 ：デフォルトの名無しさん：2010/07/18(日) 02:25:57

作ってる奴らが普及させる気が無いからだろ。
具体的に言うとWindowsで使わせる気が無いのが悪い。
普及させたければ何よりもWindowsユーザーを最優先しないといけない。

54 ：デフォルトの名無しさん：2010/07/18(日) 02:39:52

あほにレヴェルあわせるとあほになるお

55 ：デフォルトの名無しさん：2010/07/18(日) 03:11:38

ぷｗ
閉じた世界にいるくせにレベルとかお笑いだな。

56 ：デフォルトの名無しさん：2010/07/18(日) 09:04:04

>>53
そのとおりだ。関数型プログラミングのウリはモジュール性なのに、
全部一から作るつもりかよ。

57 ：デフォルトの名無しさん：2010/07/19(月) 22:47:58

数学の公式がそのまま使えて凄い簡潔に書ける！みたいなのをどこかで見たけど
手続き型のコードを一つ一つ追っていく方が読み易いのは俺だけなんだろうか

58 ：デフォルトの名無しさん：2010/07/19(月) 23:13:07

手続き型では長年の数学の成果を応用する機会を見逃してしまいそうだね
もったいなくて数学を捨てられないタイプの人は関数型の方が安心だろうね

59 ：デフォルトの名無しさん：2010/07/19(月) 23:16:41

すみません
手続き型でも関数型でもどちらでもよいのですが
たとえば
1 + 2 + 3 + ... + n
を計算するプログラムを書くときに
ちゃんと
Σn
の公式にに発想をチェンジしてくれる言語はありますか？

60 ：デフォルトの名無しさん：2010/07/20(火) 02:13:32

制約のある言語に頼らないと思考を最適化できんのか

61 ：デフォルトの名無しさん：2010/07/20(火) 03:25:02

BASICしか知らない奴にCで簡潔に書ける！と説いたところで馬耳東風だろ

62 ：デフォルトの名無しさん：2010/07/20(火) 08:49:19

>>59
APLを求めてるのか？

63 ：デフォルトの名無しさん：2010/07/20(火) 15:36:56

詳しく知らないけどMathematicaとかで出来んじゃね？

64 ：デフォルトの名無しさん：2010/07/20(火) 15:40:55

平たく言えば逆コンパイラだな

65 ：デフォルトの名無しさん：2010/07/20(火) 15:44:04

HPFの自動ベクトル化のことかも

66 ：デフォルトの名無しさん：2010/07/20(火) 19:11:21

関数型言語で飯が食えるようになればあとは趣味の問題だ。
とりあえず、飯を食べれるようにするべきだろ今は。

67 ：デフォルトの名無しさん：2010/07/20(火) 19:31:49

今のところはアクロバティックに食うしかないな

68 ：デフォルトの名無しさん：2010/07/21(水) 10:02:38

普及してきたじゃないか

69 ：デフォルトの名無しさん：2010/07/21(水) 21:10:16

ある程度波に乗れているときに、飯を食えるように整備しておかないと結局元に戻る。
あまたある理論よりも、自分のキャリアの終わりまで飯が食えるというのが最も強い。

70 ：デフォルトの名無しさん：2010/07/23(金) 20:32:49

>>59
「ＡをＢに発想をチェンジ」の意味をも少し詳しく説明してくれ

文字通りに受け取るなら、ＡとＢをここに書き込んでる時点で
お前は既に発想をチェンジしているはずだが

71 ：デフォルトの名無しさん：2010/07/24(土) 02:02:56

？？？？
回答者チェンジで

72 ：デフォルトの名無しさん：2010/07/25(日) 00:00:27

つまり、>59は等差数列の和を求めるプログラムを書いたら等差数列の和を公式に基づく最適化をしてくる言語はあるかと聞いているのだろ。
同値の和のループを積に最適化するくらいなら普通のCコンパイラでも最適化してくるけど、等差数列はどうなんだろね。

73 ：デフォルトの名無しさん：2010/07/25(日) 00:34:09

ドラえもんの世界のコンパイラなら。。。

74 ：デフォルトの名無しさん：2010/07/25(日) 00:35:18

>>72
等差数列の和を求めるプログラムである事が分かるためには、
その数列の各項の数値が分からなければならないんだが、
それが分かれば和を公式にしなくても、合計はコンパイル時に分かると思うぞ

75 ：デフォルトの名無しさん：2010/07/25(日) 04:45:11

つまり Erlang 最強ってことか

76 ：デフォルトの名無しさん：2010/07/27(火) 00:44:22

>34
http://www.indeed.com/jobtrends?q=Lisp%2CSML%2CHaskell%2CScala%2COCaml%2CC%23&l=

関数型はゴミのようですね。グラフが一本しかないので何か入力を間違えたのかと思いましたｗ

77 ：デフォルトの名無しさん：2010/07/27(火) 01:15:59

情報系以外の学部、
特に理学部で教えないからでしょ。
物理系はFortran,化学系はGaussian,生物系はperlとか分担あるからね。
数学科はgapか。入り込む余地がない。

関数型のkiller用途って何よ？
情報系だけの用途で自己満足してる気がする

78 ：デフォルトの名無しさん：2010/07/27(火) 06:54:41

物理も化学も生物も工学も、ライブラリがあれば問題ない。
っていうかライブラリがないだけ（にわたまだけど）。

数学科はむしろ関数の本家だろ。

79 ：デフォルトの名無しさん：2010/07/28(水) 00:11:45

関数型だと圧倒的に便利、他では代替が効かない
というくらいの用途をCS以外の分野では聞かないのだよ。

ライブラリがあったとしても
わざわざ関数型使うって言うのは、一歩間違えると手段と目的を
取り違えてるんではないか？

勉強、パズルとしてはおもしろいよ。
しかし、それ以外の実利的幸せを得られるという話を聞いたことがない。

ベクトル型スパコンの言語を関数型にすると性能が倍になるとか
開発工数やテスト工数が8割減になるとか、
そんな例があれば起爆剤になると思うんだが。

80 ：デフォルトの名無しさん：2010/07/28(水) 01:16:17

つか、手続き型と関数型を上手く繋ぐインタフェースっていうか、いいとこ取り的なことが出来る環境は無いの？

81 ：デフォルトの名無しさん：2010/07/28(水) 01:30:25

>80
つF#、Scala

82 ：デフォルトの名無しさん：2010/07/28(水) 02:17:52

Erlang

83 ：デフォルトの名無しさん：2010/07/28(水) 07:21:33

>>80
そもそも手続き型、関数型それぞれの良いところってどこだ？

84 ：デフォルトの名無しさん：2010/07/28(水) 09:34:09

手続き型　馬鹿でも使える
関数型　自慢できる

85 ：デフォルトの名無しさん：2010/07/28(水) 22:54:17

http://jp.rubyist.net/magazine/?0017-Hotlinks

この人Haskellに結構詳しい人(Ruby界では神レベル)だと思うんだけど、
> 青木　うーん、面白いとは思うけど、書きたいとは思わないなぁ。
って言ってる。理論的には優れてても、実際使うとそうでも、、ってことかな。
確かに俺もHaskellの言語仕様は大体わかってるつもりだけど、実際Haskellで
ある程度のもんは作ったことない。

関数型でGUIとか作り始めたら、モナドだらけになって実質手続き型になるし、
オブジェクト指向だって、他の下位オブジェクトに処理をデリゲート(つまりモナド
に囲い込む)して、自分自身は参照等価っぽいオブジェクトにするってことはよくある。

結局同じだから、ハイブリッドな言語が生き残るのかもね。

>>80
ん?最近の手続き(オブジェクト指向)言語は関数型の概念も取り入れてるぞ。
たとえば俺の得意なRubyだとブロックとか。
[1, 2, 3].map {|x| x * 2 }
で[2, 4, 6]ができるし、
lam = -> x, y { x * y }
って書けば関数オブジェクトが代入される。

あまり知らないけど、C#も関数型を取り入れてるって聞いた。

86 ：デフォルトの名無しさん：2010/07/29(木) 01:32:25

C#なら
new []{1,2,3}.map(x=>x*2)で[2, 4, 6]なふうになる（出来る）

87 ：デフォルトの名無しさん：2010/07/29(木) 03:23:27

個別的な利点じゃなくて、どのぐらい使われるかどうかというところが問題なんだ。
UNIXのC言語、EXCELマクロのVBA、動的Webサイト作成のためのいろんな言語しかり、
まずプラットフォームを提示しなきゃダメだ。それこそめちゃ難しいが。

あと、いわゆる関数型パラダイムを強調すればするほど人が離れていく。
特にメリットが説明出来ない作法については適当に崩していくべきだよ。

88 ：デフォルトの名無しさん：2010/07/29(木) 13:01:12

手続き型では難しいことを簡単に書けるのが関数型。
手続き型では簡単なことを難しく書けるのが関数型。
って、ばっちゃが言ってた

89 ：デフォルトの名無しさん：2010/07/30(金) 21:06:59

関数型言語では原則手続き的なプログラミングをすることにすれば万事オーケー。
奇特な人は関数型プログラミングをすればいい。

90 ：85：2010/07/30(金) 21:16:05

>>86
そのコード見てC#おもしろそうだな、と思った。色々調べてみたら結構アジャイル
意識する言語なんだな。Windows onlyなのが残念すぎる。

しかし、C#みたいなメインストリームが関数型のいいところを取り入れてること
を考えると、本物の関数型はますます普及し辛くなるんじゃないか？

91 ：デフォルトの名無しさん：2010/07/30(金) 21:25:14

> Windows onlyなのが残念すぎる。

つ Mono

92 ：デフォルトの名無しさん：2010/07/30(金) 21:34:48

>>91
おおお、ﾄﾝｸｽ

C#ちょっとかじってみるかな夏だし。しかし、互換性とか大丈夫なのだろうか。
てか互換性の前にVSがないじゃんかああああ。

93 ：デフォルトの名無しさん：2010/07/30(金) 22:06:40

MonoDevelop?

94 ：デフォルトの名無しさん：2010/07/30(金) 23:19:12

C++みたいに一旦普及させてからパラダイムの方向を変えていけばいいじゃん。

95 ：デフォルトの名無しさん：2010/07/30(金) 23:21:57

文字列を置換するプログラムを書け。
ただし、VC++を使うこと。

さて、大きく分けていったい何種類のやりかたが存在するのだろうか・・・

96 ：デフォルトの名無しさん：2010/07/31(土) 14:59:05

C#が関数型取り入れるのは大いに結構つーか勝手にしろって感じだが
Javaではやらないでほしいな、Javaはシンプル路線で進んでほしい

97 ：デフォルトの名無しさん：2010/07/31(土) 15:12:51

シンプルは使いにくい

98 ：デフォルトの名無しさん：2010/07/31(土) 15:29:27

今、Windows + Haskell + GUI で全章が構成されている易しい本を書いたら、
ヒットする足がかりを Haskell は絶対に得る。

逆に言えば、それがなければ一般大衆には絶対に普及しない。

ただし、wxHaskell や Gtk2Hs などを直接使うような低レベルのライブラリではなく、
その上に一段被せる wxFruit や Grapefruit、FG などで解説しないと意味は無い。

99 ：デフォルトの名無しさん：2010/07/31(土) 17:45:13

一般大衆はHaskellなんか使わんだろ。いや他の言語も使わんだろうけど。

100 ：デフォルトの名無しさん：2010/07/31(土) 20:59:36

いや、使うって

うぁGUI簡単じゃん、おもしれーよ
ってなったら絶対に使うよ

101 ：デフォルトの名無しさん：2010/07/31(土) 21:04:45

VBA最強。GUIも簡単。

102 ：デフォルトの名無しさん：2010/07/31(土) 22:20:16

VBとVBAて何がﾁｶﾞｳﾉ?

103 ：デフォルトの名無しさん：2010/08/01(日) 07:50:48

>>100
どんなに凄いライブラリ用意しようが、VisualStudioみたいなIDEを作らないと絶対無理。

104 ：デフォルトの名無しさん：2010/08/01(日) 13:06:58

EclipseでHaskellの開発できるみたいだぞ。
どこまで使えるかわからんが。

105 ：デフォルトの名無しさん：2010/08/01(日) 13:52:02

関数型のIDEって大したもんできなさそうだよなぁ。
型推論のせいでインテリセンスがきかないんじゃねえの。

106 ：デフォルトの名無しさん：2010/08/01(日) 14:16:14

型推論の機能がどのようにインテリセンスを阻害するのか気になる

107 ：デフォルトの名無しさん：2010/08/01(日) 14:58:47

引数の型を明示的に指定できないのだから
例えば、引数がレコード(Cの構造体みたいなもん)だった場合
IDEは型がわからないからレコードのフィールド名を補完できないんじゃないの。

108 ：デフォルトの名無しさん：2010/08/01(日) 17:54:05

>>107
関数型言語のIDEは、IDE自身もコンパイラと同じ様に型推論するだろ普通。
でなければ関数型用のIDEなんて、とてもじゃないが呼べない。

ただ、Haskell の場合、コード中の前の方で使用している型の定義とかが
それより後ろで定義されていても全く問題なくコンパイルできる。
だから、テキストエディタでそのようにプログラマに記述されると、
その型を初めて使用する段階では型名が分からず補完できない場合もある。

109 ：デフォルトの名無しさん：2010/08/01(日) 18:40:26

関数型は単独で表舞台に立つよりも、他のパラダイムの言語に侵食して
わかりにくいとかウザいとかいわれるのが似合ってるんだろうな

110 ：デフォルトの名無しさん：2010/08/01(日) 18:59:57

>>108
いや、だからいつ型推論するのｗ
型推論するには一度は人間がその型が何なのかわかるように書かないとダメじゃん。
つまり、補完の効かない状況で書かないといけない。
一度その引数を使えば以降は補完できるようにはなるかもしれないが
明らかに使い勝手は悪くなるねえ。
補完なんてのはそもそもメソッド名なりフィールド名なりがわからないから必要なんであって
調べなきゃいけないのなら有り難味はほとんどないな。

111 ：デフォルトの名無しさん：2010/08/01(日) 19:20:55

コンパイラが型推論してくれるのと同じレベルでIDEも型推論できるだろ.
コンパイラにも明示的に型を指定するかそうでなければそもそもジェネリックになってんじゃねーの？

112 ：デフォルトの名無しさん：2010/08/01(日) 19:26:56

関数型言語でも、この変数は○○型って
定義すれば良いんじゃね？

手続き型でも最初に変数定義してるじゃん。
関数型でも変数定義すればいいんだよ。

113 ：デフォルトの名無しさん：2010/08/01(日) 20:48:49

型推論じゃなくなりますね＾＾；

114 ：デフォルトの名無しさん：2010/08/01(日) 22:13:00

>>109
明らかに侵食しているにもかかわらず華麗にスルーされるというのに美学がある。

115 ：デフォルトの名無しさん：2010/08/01(日) 22:36:51

>>110
たとえば GHCi は関数名やモジュール名を書きかけて Tab を押すと、
補完してくれたり候補を表示してくれるよね。
あれは、ロードしたモジュールと、今まで定義した関数に関しては、
ちゃんと機能してくれる。

当然だけど、後で定義するつもりの関数に関しては機能しない。
（しかしそれは他言語でも同じ。Haskell の場合それでもコンパイルできるというだけのこと）

ついでに、:t コマンドを使えば VS で言うパラメータヒントみたいなことも、
もっと賢くやってくれる。

俺は IDE の「補完や候補表示」はあれくらいで十分だと思う。

それ以上の機能を持った補完や候補表示って、たとえばどんなのがあるの？

116 ：デフォルトの名無しさん：2010/08/01(日) 23:26:02

>>115
>当然だけど、後で定義するつもりの関数に関しては機能しない。

の件はそもそも GHCi はインタプリタだから関係なかったな。
すまん、蛇足だった。

何が言いたかったのかというと、関数は一度定義すれば、
人間が明示しなくても型推論はできて補完もできるだろ、
という事を GHCi を例に挙げて言いたかった。

117 ：デフォルトの名無しさん：2010/08/05(木) 03:53:25

んで、Eclipseの機能も知らず、かといって自分で開発環境など作れるはずもない人間が
「ぼくちんの考える最適な補完機能」について語る、と。

なかなかスレタイ通りのレスが続いているじゃないかｗ

118 ：デフォルトの名無しさん：2010/08/05(木) 09:30:39

eclipseがどうやって補完してるのか教えてくれ

119 ：デフォルトの名無しさん：2010/08/06(金) 01:50:34

>>118
ファイル中にある似たような単語を
一覧表示しているだけだよ。

120 ：デフォルトの名無しさん：2010/08/11(水) 16:54:14

こんな変態言語、普及せん。秋葉原の言語だ

121 ：デフォルトの名無しさん：2010/08/11(水) 19:12:00

秋葉原の言語というより、研究室の言語でしょ。

122 ：デフォルトの名無しさん：2010/08/11(水) 19:25:53

秋葉原に事務所があるような会社で使ってるところがいくつか出てきているようだよ。

123 ：デフォルトの名無しさん：2010/08/11(水) 20:06:52

すぐやめるよ。そのまま続けると業績悪化が待っている．

124 ：デフォルトの名無しさん：2010/08/11(水) 20:36:50

なんでそう世間知らずなのをこんなところで発表したいの? 心底メイワクなんだが。

125 ：デフォルトの名無しさん：2010/08/12(木) 10:11:42

オブジェクト指向も90年代のはじめごろに雑誌とかで紹介されるようになって、
2000年くらいでやっと「Javaって実用になんの?」みたいな扱いだったもんな。

今の関数型は90年代はじめごろのオブジェクト指向とおなじような空気を感じる。
普及はすると思うけど10年以上はゆうにかかる。

126 ：デフォルトの名無しさん：2010/08/12(木) 10:18:33

関数型は100年早すぎるんだな

127 ：デフォルトの名無しさん：2010/08/12(木) 10:24:29

prolog もそういわれていたな。そういえば lisp も。

128 ：デフォルトの名無しさん：2010/08/12(木) 14:40:08

今の人類が使いこなせないからといって
未来の人類が使えるとは限らない
機械人間やアンドロイド、網膜に情報が表示されるような
時代にならないと無理かもしれない

129 ：デフォルトの名無しさん：2010/08/12(木) 14:55:21

ぉーそうなのか。ツッコミありがと。
あとで試してみます。

130 ：デフォルトの名無しさん：2010/08/12(木) 20:41:13

おれも100年たったら試してみよう。

131 ：デフォルトの名無しさん：2010/08/13(金) 18:32:19

むしろ、OOが理解出来ない人向けの言語として需要が存在していると思う。
OOのようにモジュール性を持たせた設計をしたい、でもOOは理解出来ないから
関数による分割で学習意欲がない人にもそれなりのプログラムがかけるように
なるパラダイムです、って難しい部分を全部割愛して紹介すればいいと思うんだよね。

132 ：デフォルトの名無しさん：2010/08/14(土) 00:07:11

日本には昔から面従腹背のパラダイムが存在しているらしいです
パラダイムを軽く受け流すパラダイムです

133 ：デフォルトの名無しさん：2010/08/14(土) 01:11:46

オブジェクト指向は GUI みたいな
向いてる現場があったけど関数型言語にはそういうのないだろ。

134 ：デフォルトの名無しさん：2010/08/14(土) 02:14:05

オブジェクト指向はすべてを内包している

一番上がクラス。これはオブジェクト指向。

その次が関数（メソッド）
クラスは関数の集まりでできている。
構造化言語だ。

そして関数の中身、そこに関数型言語が使われる。

135 ：デフォルトの名無しさん：2010/08/14(土) 05:08:07

いわゆる関数型言語で採用されている、宣言的なプログラミング技法だと
宣言的であるがゆえに、状態を分割して閉じ込めるという
OOP的なアプローチが成立しない、というような主張は読んだ記憶がある
CTMCPだったっけ？

あと効率。なんだかんだ言いつつ無視はできない局面は多い

関数型パラダイムは（少なくとも部分的に）有効なのは間違いないし
実際に用いられている所も数多いとは聞くが、
全面的に適用できるほどではない、という辺りが現状か

136 ：デフォルトの名無しさん：2010/08/14(土) 07:39:18

>>134
let over lambdaはすべてを内包している
一番上がlet
その次がlambda

137 ：デフォルトの名無しさん：2010/08/14(土) 15:06:12

OOPの場合、状態を持つこと「も」できるってだけで
状態を持たない関数型っぽいスタイルも内包してるもんな

138 ：デフォルトの名無しさん：2010/08/15(日) 23:19:37

別にいまOOPで行われている仕事をすべて関数型に入れ替えるというわけじゃないよ
OOPには不得意だけど、関数型なら得意という領域をみつけられればいいわけじゃん。
考えられるシナリオとしては、棲み分けて生き延びるというのが妥当なところだと思う。

139 ：デフォルトの名無しさん：2010/08/15(日) 23:26:00

なんでもアリのOOPが最上のプログラミング手法、というのはどうも変な気がする。
なんでもアリの自由度の高さ故に、実務レベルで使いづらい点というのが逆に出る
ものじゃないかと思う。
ガチガチの制限も分野によっては使いやすさにつながることもあると思うし。

140 ：デフォルトの名無しさん：2010/08/16(月) 00:24:29

OOPは制限が少なくて
関数型言語は制限が多いってことかい？

それはいいとして、作るソフトウェアの種類で
こういうソフトはOOP、こういうソフトは関数型なんて
分けることはできないんだよ。

できるとしたら、一つのソフトのうち、この部分はOOP（GUIとか）
この部分は関数型（アルゴリズムとか）のような感じだな。

何が適しているかはソフトウェアではなく
作る部分によって決まるので、適したものを選ぼうとしたら、
一つの言語で、OOPであり手続き型であり関数型言語のような
なんでもありな言語を使うことになるんだよ。

141 ：デフォルトの名無しさん：2010/08/16(月) 02:23:01

javascriptは関数型？

142 ：デフォルトの名無しさん：2010/08/16(月) 09:56:32

>>140
はげどう！　ピュアななんとか言語くらい使い難いものは無い。

>>141
今普及してるから関数型では無い。関数型は100年早いと前レスにあった。

143 ：デフォルトの名無しさん：2010/08/16(月) 10:09:22

>>142
Rubyですねわかります

144 ：デフォルトの名無しさん：2010/08/17(火) 00:11:54

>>140
今のところなんともいえないけれど、やれることをやたら多くしてしまうと
プロフェッショナルなプログラマーはいいとして、別にそうでもない人たちには
使いづらいものなんじゃないかと思うんだよね。
ソフトウェア開発に関わる人達が全員プロフェッショナルでなんでもありな
道具を使いこなせるというのなら、そのなんでもありな言語を使うべきというのは、
確かにそうなんだけど、現実はそういうわけではないだろう、と。

145 ：デフォルトの名無しさん：2010/08/17(火) 00:20:15

ちなみに、自分が想定する関数型言語の使い方はVBみたいな使い方。
学習コストがやたら高いことは原則行わない。
結局使えるものじゃないと意味ないし。

146 ：デフォルトの名無しさん：2010/08/17(火) 06:16:52

VBが使いたいならVBを使えばいいと思うよ。

147 ：デフォルトの名無しさん：2010/08/17(火) 06:21:16

手続き型と比べてどうかとかいうことよりも、
googleとかが本格的に使い始めれば流行るんじゃないの。

148 ：デフォルトの名無しさん：2010/08/17(火) 19:58:30

断言するがgoogleが使っても流行らない。
流行るのは100年後だ。

149 ：デフォルトの名無しさん：2010/08/17(火) 20:21:34

100年後は外部記憶と脳内妄想プログラミングが主流になってる。
妄想した段階でプログラミングは完了してる。

150 ：デフォルトの名無しさん：2010/08/17(火) 22:31:50

>>148
マシン語は永遠に不滅です。

って言っていた奴が昔よくいたよな。

151 ：デフォルトの名無しさん：2010/08/18(水) 06:28:28

>>150
> マシン語は永遠に不滅です。
今の形のコンピュータがある限り不滅。

152 ：デフォルトの名無しさん：2010/08/21(土) 21:58:30

黒い白鳥見つけないと。

153 ：デフォルトの名無しさん：2010/08/21(土) 22:01:24

どこにいるのか黒い白鳥。

154 ：デフォルトの名無しさん：2010/08/22(日) 15:38:10

オーストラリア

155 ：デフォルトの名無しさん：2010/08/24(火) 16:08:16

関数型言語がなぜ普及しないのか、
それは作業割り当てが難しいからだよ。
UMLみたいに図でわかりやすく設計書が書けないからだよ。

156 ：デフォルトの名無しさん：2010/08/24(火) 17:04:45

コーディングレベルのレイヤーを図で仕様書書いてるのかよ。

157 ：デフォルトの名無しさん：2010/08/24(火) 17:57:51

>>156
はぁ？

158 ：デフォルトの名無しさん：2010/08/24(火) 18:12:23

>>155
なぜ関数型言語だと作業割り当てが難しいのか、
なぜ図でわかりやすく設計書が書けないのか、非常に興味深い。

極小の簡単なサンプルで、関数型言語で無ければできるのに、
関数型言語だからできないという状況を示してくれないだろうか。
それを使っていろいろ調べてみたい。

159 ：デフォルトの名無しさん：2010/08/24(火) 18:32:23

>>157
「関数型言語だと図でわかりやす仕様書が書きにくい」

コーディングレベルで仕様書を書いてるとしか解釈できません。
しかも図で。

160 ：デフォルトの名無しさん：2010/08/24(火) 18:46:05

図といえばフローチャートのことなんだろこの人には。

そんでもってソースコードと1:1に対応するフローチャートしか書けないタイプの。

161 ：デフォルトの名無しさん：2010/08/24(火) 19:22:55

>>158
君は大規模アプリを設計するときどうやってるの？

162 ：デフォルトの名無しさん：2010/08/24(火) 20:12:34

>>161
プログラム系の業務経験はないから、
大規模アプリを設計したことがない

163 ：デフォルトの名無しさん：2010/08/24(火) 20:41:36

>>162
じゃあ、プログラムを作るときに設計をすることはある？
もしあるならどういう設計手法を使っている？

164 ：デフォルトの名無しさん：2010/08/24(火) 20:59:14

>>163
ちょうど今 Haskell で簡単なブロック崩しゲームを作ってるんだけど、
普通に設計してる。

パドルの動き、ボールの動き、ブロックの動き（動かないという仕様）、
それら同士で衝突イベントが発生した時の反応、
などの各ゲームオブジェクトの仕様と、スコアなどのシステム仕様を個別に決める。

次に、タイトル画面、ゲーム画面、クリア画面、ゲームオーバー画面など、
ゲームの各シーンでやることを個別に決め、シーン毎の繋がり方（遷移）を決める。

＊＊手法という名前は知らないけど、ざっとこんな感じ。

あとは個別に決めたものをそれぞれ yampa のシグナル関数で表して
繋げたらできるんじゃないかと思ってる。
というか、今そう期待して作りかけてる。

165 ：デフォルトの名無しさん：2010/08/24(火) 21:02:13

>>164
状態遷移図だけで設計してるの？

166 ：デフォルトの名無しさん：2010/08/24(火) 21:03:47

設計の成果物はどういう風にまとめているの？

167 ：デフォルトの名無しさん：2010/08/24(火) 21:14:39

巨大なソフトウェアになってくると、どうしても一人では手が追いつかなくなってくるよね。
そうなってくると今度は開発者同士の連携が重要になる。
自分の意思を相手にすばやく正確に伝えるための定型的なメソッドが無いとやっていられないよね？

168 ：デフォルトの名無しさん：2010/08/24(火) 21:19:00

>>165
簡単なブロック崩し程度ならシーンの状態遷移図と、
各ゲームオブジェクト間の繋がりを四角と線で表せば十分だと思った。

後は、衝突イベントとかキー入力イベントとか、時間切れイベントとか、
そういう各イベントに対してどのオブジェクトがどう反応するのか、
その表を書き表せば、この程度のゲームなら作れるだろと思ってる。
（作りかけなので、設計不足で完成できないかも知れんが、まだ分からん）

>>166
ノートに手描きしてまとめてるが、どういう事が聞きたい？

と言うか、関数型だと設計図描きにくいのは何故？という話に、
プロでもない俺の拙い設計の話なんか聞いて面白いか？

169 ：デフォルトの名無しさん：2010/08/24(火) 21:30:57

>>168
ソフトウェアに関してはプロもアマもないよ。
それに、関数型言語に関してはまだ十分研究されていないのだから、
もしかしたらアマ研究者が面白い設計手法を考えているかもしれない。

170 ：デフォルトの名無しさん：2010/08/24(火) 21:48:20

結局、設計が書きにくい理由って何だったの？

171 ：デフォルトの名無しさん：2010/08/24(火) 21:56:47

コードに一対一で対応するような詳細なクラス図とか書いて、
あとはそれをコードに起こすよな開発スタイルを想定してて、
関数型の言語にはオブジェクト指向に対するUMLのようなものが
ないから仕様もおこせないし、分割もむずかしいと。

そういう感じなんでしょ? >>155 は。

で、>>156以下で、そんなスタイルそのものがナンセンスだって
ツッコミが入ったけど、さらにツッコミが入るのにビビって、
「じゃああんたらは、仕様書とかどう書いてるの」って質問に
質問を返すような反論しかできなくて、具体的に関数型はどう
割り当てが難しいかとか、仕様書を書くのが難しいかとか
説明できないと。

172 ：デフォルトの名無しさん：2010/08/24(火) 22:11:44

>>171
しっくり来る方法がないことは難しいことじゃないのか。

173 ：デフォルトの名無しさん：2010/08/24(火) 22:32:10

>>172
しっくりくる方法って、コードに一対一で対応するような図の仕様書を
書く方法?

そういうのナンセンスだってツッコミが入ってるんだから、
いやそれは有用だって反論しないと話が先にすすまないじゃん。
(具体例あげて)

自分の言ってるのはそういう仕様書じゃなくて、こういうのだって
話なら、それ言えばいい。

174 ：デフォルトの名無しさん：2010/08/24(火) 22:34:46

LISP系ならフローチャートで仕様をもらっても割りとそのまま実装できんだけどな。

175 ：デフォルトの名無しさん：2010/08/24(火) 23:18:02

>>173
オブジェクト指向開発におけるUMLのような位置づけの設計技法だよ。
関数型言語での開発における○○はあるの？

176 ：デフォルトの名無しさん：2010/08/24(火) 23:19:47

>>174
フローチャートはアルゴリズムを書くのには適しているが、
アーキテクチャを書くのには適していないね。

177 ：デフォルトの名無しさん：2010/08/24(火) 23:21:19

>>175
クラス図みたいにオブジェクト指向べったりのやつ以外はふつうに使えるじゃん。

178 ：デフォルトの名無しさん：2010/08/24(火) 23:24:33

フローチャートでアルゴリズムを書くとかだめすぎるだろ。

179 ：デフォルトの名無しさん：2010/08/25(水) 07:19:04

>>175
逆に聞きたいが、UML の中で関数型では使えないものって、
どれくらいあるんだ。

使えないというのは、使っても
使わなかった時に比べて生産性が上がらないという意味。

180 ：デフォルトの名無しさん：2010/08/25(水) 10:15:30

>>167
巨大なオープンソースでは、意思を伝えるメソッドはほとんど無いね
たまたま同じ意思を持っていた人が集まってくる
stand alone complexのようなもの

181 ：デフォルトの名無しさん：2010/08/25(水) 10:28:36

例えばコールグラフなんかは命令型宣言型を問わず有効だな。
純粋な関数型なら副作用がないのでむしろ手続き型よりも合っている。

182 ：デフォルトの名無しさん：2010/09/13(月) 23:26:06

やっぱりオブジェクト指向のデータ構造をオブジェクトの中に隠蔽して、
オブジェクトへのアクセスを少数のメソッド群で行うってのが強力なんじゃないか？

Haskellでもハイレベルなデータ構造を抽象化する機能はあるけど、データ構造とそれを
扱う関数をパッケージ化しないから、実際プログラム書くときに、どの関数を使えばいいのか
わからないみたいな。

183 ：182：2010/09/13(月) 23:29:32

あーでもモジュールごとにきっちり分けて書けば、そんなことにはならないか。
オブジェクト指向の多態性の方が、型クラスによる多態性より直感的なのかなー。

184 ：デフォルトの名無しさん：2010/09/13(月) 23:57:55

オブジェクト指向の多態性と、型クラスによる多態性の差異をかいてくれ。

185 ：デフォルトの名無しさん：2010/09/15(水) 03:19:08

代表的なのだと、JavaのequalsとHaskellの型クラスEqの==とか？

186 ：デフォルトの名無しさん：2010/09/20(月) 13:07:25

今、F#の説明見てたら、まるでBASICみたいなんだよ。
なんなんだこれ。

厨房のころBASICからC言語に進んだ時、
わざわざmainという特殊名を使ってでも、
すべてを関数でという理念に感動した。
その感動が関数型じゃねーの？って話。
BASICに戻ってどうするよ。
型推論？ってスクリプト用ですか？

MSが取り入れたから何かあると思ったんだが、
亡霊でも見てしまったような気分。

187 ：デフォルトの名無しさん：2010/09/20(月) 13:15:53

>>186
素人が騒ぐな。お前が言ったところで説得力はない。

お前が素人であるという根拠は基本的なこと、
C言語は関数型でないことを知らないからだ。

188 ：デフォルトの名無しさん：2010/09/20(月) 13:24:15

>>186
> 今、F#の説明見てたら、まるでBASICみたいなんだよ。
ん？どの辺がBASIC？？
後の文を読んでもいまいちよくわからない。

> 型推論？ってスクリプト用ですか？
動的言語ではなく、静的でありながら型推論をするのだからCよりは賢いよね。

189 ：デフォルトの名無しさん：2010/09/20(月) 13:51:00

>>186
>今、F#の説明見てたら、まるでBASICみたいなんだよ。

Wikipediaの解説あたりを見ているのかな？
そういった解説は、理解しやすいよう、ごく短いコードを例にしているから、
「まるでBASICみたい」と感じてしまうんだと思う。
もしもある程度の長さのF#コードを見たなら、また別の感想を持つと思うよ。

>BASICに戻ってどうするよ。

F#は関数型言語だから、(BASICと違って)C言語のような関数定義や関数呼び出しは
可能だよ。さらに、C言語ではソース(xxx.c)単位でしかコードをモジュール化できないけど、
F#には「抽象化データ」という(C言語よりも)高度なモジュール化の仕掛けが用意されている。

>型推論？ってスクリプト用ですか？

確かに、データ型宣言が不要だからスクリプト用途には便利だね。ただ、型推論という技術は、
スクリプト用途にも便利だけど、大規模なプログラム開発になればなるほど生きてくる。

たとえば、C言語を知っていれば標準ライブラリのsort関数は知っていると思う。
このsort関数は、引数として2つの要素の大小関係を返す(比較する)関数へのポインタを渡す。
そして、ソートする要素のデータ型は目的によってまちまちだから(整数であったり文字列だったり)、
引数渡しの際にはキャスト(型変換)が必須になる。C言語のキャストが不正アドレス参照エラー
(いわゆるヌルポ)を引き起こす原因になりがちだというのは、よく知られている事柄だと思う。
でも、F#であれば(強力な型推論機能があるから)型宣言が不要であるばかりか、
もしデータ型の不一致があれば、それをコンパイル時に検出してくれる。
これは、大規模プログラム開発であれば、とても大切なこと(助けになる仕組み)なんだ。

今見ているものとは別の解説書を読んでみる事を勧めるよ。

190 ：デフォルトの名無しさん：2010/09/20(月) 13:55:17

>>189
大規模であれば設計が重要。
特に紙に図として描けて俯瞰的に見られる設計法がなくてはね。
現在大規模設計に適しているのはオブジェクト指向だけだよ。
関数型言語はまだ設計法が発達していない事が理由で大規模な開発にあまり適用されていないんだよ。

191 ：デフォルトの名無しさん：2010/09/20(月) 14:00:13

>>190
その意見については全くその通り(大賛成)なんだけど、
彼(>>186)の問いかけという文脈に対しては不適切ではないかと

192 ：デフォルトの名無しさん：2010/09/20(月) 14:08:10

> わざわざmainという特殊名を使ってでも、
> すべてを関数でという理念に感動した。
> その感動が関数型じゃねーの？って話。

その時点で完全に間違ってる。
C言語は関数型じゃない（そういうデマを広げてる本は何冊かあって、
ウェブ上では酷い状態だが）。

193 ：デフォルトの名無しさん：2010/09/20(月) 14:08:23

>>187
C言語の関数は関数型言語の関数と意味が違うんだ。
どういうこと？
違う概念なら、同じ言葉にしてしまったのはミス？

>>188
変数に明示的宣言がなくて、行頭からプログラムが開始。
括弧が省略されて見た目もBASICの命令文ぽい。

静的型推論のメリットがわからない。
型があいまいでもコンパイルが通るなら想定外のデータに
どう対処するの？
動的なら便利だろうけれども。

そこにそんなメリットがあるなら、
静的型推論言語に改名した方がいいのでは？

194 ：デフォルトの名無しさん：2010/09/20(月) 14:18:46

>>189
詳しくありがとう。
定義された関数がデフォで
C++のTemplateになってる感じだろうか。

195 ：デフォルトの名無しさん：2010/09/20(月) 15:02:56

>>193
>C言語の関数は関数型言語の関数と意味が違うんだ。どういうこと？

関数(function)という用語は数学に由来するんだけど、数学の世界に副作用は存在しない。
副作用(side-effect)というのは、定義の途中で変数の値が変化(mutate)することを指している。
関数型言語では、この数学における意味を忠実に守っている。
でもC言語の関数は、その定義の中で代入操作で変数の値を変えることができるから、
(見た目は数学の関数と似ているけど)数学における関数とは意味が違ってくる。だから、

>違う概念なら、同じ言葉にしてしまったのはミス？

という指摘は正しい。C言語の場合は、手続き(procedure)と呼ぶべきだったんじゃないかと思う。
ただ、C言語が設計された大昔の時代は、一般的に(プログラム言語に対して)数学的な意味の
厳密性は求められなかったから、この問題についてC言語設計者を責めるのは酷ではないかと思う。

>型があいまいでもコンパイルが通るなら想定外のデータにどう対処するの？

もし型があいまいであれば(あるいは矛盾していれば)、コンパイルは通らない。(コンパイルエラーになる)
だから、想定外のデータ記述は、すべてコンパイル時に弾かれることになる。
(0割り算エラーやI/Oエラーのような実行時エラーは、コンパイル時には検査できないけどね)
それが「静的型検査(type checking)」言語の特徴。そして、静的型検査の為には
(一致/不一致を判定するために)型宣言が必須になるけど、それを(ある程度まで)省略できるように
するのが「型推論(type inference)」と呼ばれる機能。

>動的なら便利だろうけれども。

鋭い指摘だよ。すでに書いたように静的型検査はプログラムの安全性(バグを減らす)という意味では
便利な仕組みだけど、たとえばGUIやプラグイン機構のように、オブジェクトの動的な生成/消滅や
構成の動的変更が本質的に起こりえるプログラミングでは、ガチガチすぎて使いづらいという批判がある。
理想は「動的言語と型推論機能の融合」なんだけど、そこまでプログラム言語理論が進化していないのが現状。

196 ：デフォルトの名無しさん：2010/09/20(月) 15:07:53

>>194
今は、そのTemplateという比喩による認識でOKと言っておくよ。
厳密には違うんだけど、それは関数型言語の理解が進めば、自然と分かってくるようになると思う。

197 ：デフォルトの名無しさん：2010/09/20(月) 16:10:25

>>195
たぶんC言語で手続きを関数と呼んじゃったのはFORTRANのFUNCTION文に由来すると思う。

198 ：デフォルトの名無しさん：2010/09/20(月) 16:11:28

違うな、FORTRANじゃなくてPASCALのFUNCTIONに由来するのかな。

199 ：デフォルトの名無しさん：2010/09/20(月) 16:44:57

>>198
BCPL -> B -> C
と続いていくが、Bの時点ですでに関数って呼ばれてたみたい。
BCPLは知らん。

200 ：デフォルトの名無しさん：2010/09/20(月) 17:27:34

>>195
つまり、参照渡しが使えないということか？
確かにCで渡した変数が変化して帰ってくるのには、違和感あった。
Cの関数では入力と出力があいまい化してるといわれればそうなるか。
そうすると、ポインタ廃止論ともかぶってくるのかな。

しかし、関数(Function)という言葉の普及度を考えると、
関数型言語という名前で主張しちゃうのはどうかな。

数学的に純粋な関数は言い換えれば、写像だから、
「写像（Mapping）志向言語」とか分けてくれた方がありがたいねえ。

>>196
C++のTemplate関数と、const参照渡しのみ使用する。
までわかった。

しかし、代入がないってすごい変革だわ。
変数名をつど用意する行儀の良いプログラムになりそう。
いい意味で。

201 ：デフォルトの名無しさん：2010/09/20(月) 17:30:06

>>200
> つまり、参照渡しが使えないということか？
> 確かにCで渡した変数が変化して帰ってくるのには、違和感あった。

C++ で、だよね？

202 ：デフォルトの名無しさん：2010/09/20(月) 17:42:49

副作用といったら代表的なのは i++ とかだろ。参照渡しも確かに値は変わるけど。
iの値を返すことに対して、値が1増えるのが副作用。

203 ：デフォルトの名無しさん：2010/09/20(月) 18:24:31

>>200
>つまり、参照渡しが使えないということか？

その通り。あと、>>202が書いているC関数内の局所変数への副作用も禁止されるし、
もちろん大域変数も値を更新できない。

ただし、デフォは不変(imutable)だけど、可変(mutable)であることを明示的に宣言すれば、
限定的に変数が更新できたりする。これはF#のベースになったMLという言語から引き継いだ特徴。
(副作用の無い)純粋さは大切だけど、時には性能/効率も優先されるべきだよね、という思想。
この考え方は、(副作用を完全に禁止した)純粋関数型言語を推す一派から、不純だという批判を受けることも。

>関数型言語という名前で主張しちゃうのはどうかな。

関数型言語のルーツはLISPといって、FORTRANやCOBOLとほぼ同時代に誕生し、
その頃から関数型言語という名前で呼ばれてた。だから今さら....という感じ。

>「写像（Mapping）志向言語」とか分けてくれた方がありがたいねえ。

写像はいくつかある関数の特徴の一つであって、他にもxxxxとかyyyyyみたいな特徴が
あったりするから、限定されすぎな命名では？という人もいるんじゃないかな。
あと、関数型言語には、「関数に式を作用(apply)させる」という計算モデル的な視点から、
「作用型言語」という別名がある。ちなみに同じ視点で、手続き型言語は「命令型言語」と。

>しかし、代入がないってすごい変革だわ。

でしょ、でしょw、自分も最初に知った時、同じ事を感じた。
こりゃ面倒かもしれないけど、安心したプログラミングができるなって。

204 ：デフォルトの名無しさん：2010/09/20(月) 18:45:07

>>202
おそらく>>200は「ポインタ渡し」を言ってるのじゃないかと。
呼び出し側は f(&x); で、呼ばれた関数側で int *px; と宣言するような形式ね。

純粋なC言語の世界だと、「ポインタ渡し」と「参照渡し」は同義語だったりする。
少なくとも自分の周囲では、「参照渡し」という表現で誤解が生じることはないよ。
だから、>>200が間違いとは感じなかった。

C++の世界では、オブジェクトを引数にする場合と明確に区別するために、「ポインタ渡し」と
「参照渡し(=オブジェクト渡し)」は、きちんと使い分けるのがルールだったかな？

205 ：デフォルトの名無しさん：2010/09/20(月) 18:58:24

C言語は全て値渡しなんだが。

C++ にそういう概念があるように、参照渡しというものがきちんと別にある以上、
言語仕様上存在してないものの名前を使うのは感心しない。

206 ：デフォルトの名無しさん：2010/09/20(月) 19:43:00

>>205
手間をかけさせてスマンが、Wikipediaの「引数」というページにある
「ポインタ渡し」とその周辺の記述を読んでみておくれ。

あと、>>186から始まった「F#に関するQ&A」という文脈の中で、登場する主要言語はF#/C/BASIC なんだ。
たまに C++ が登場するけど、その時には「C++の」というように明示的な句を付けていた。
デフォがC言語なんだから、「ポインタ渡しという俗名や参照渡しという誤った用法 (by Wikipedia)」も
「F#に関するQ&A」という文脈の中では些細な(=枝葉な)要素にすぎないと思うんだ。

それなのに、(お呼ばれされていない)C++をいきなり振りかざして、

・C++の言語仕様上はxxxなんだから、それに従わない表現は感心しない

と主張されても、ポカーンなんだけど。厳密な言語論を討議してる訳じゃないんでね。あー疲れる。

207 ：デフォルトの名無しさん：2010/09/20(月) 19:45:28

で、お前らのお話は関数型言語がなかなか普及しない話にどうやってつながるんだ？

208 ：デフォルトの名無しさん：2010/09/20(月) 19:46:48

そのあとの所に

> （これは言語側が勝手に行う。Cのように明示的にアドレス演算子を使うものは参照渡しとは呼ばない。）

とあるだろ。なんで間違った言葉を使うわけ？

209 ：デフォルトの名無しさん：2010/09/20(月) 19:52:46

>>208
だから>>206で、それは些細な問題だろ(揚げ足取りじゃねえのか)、と言ってる訳だが。
というか、F#なり他の関数言語なりの話でツッコんで欲しいんだよな....。ふぅーー

210 ：デフォルトの名無しさん：2010/09/20(月) 20:11:24

>>202
えーと、

・単なる質問小僧ではない、自分なりの考え方を持った初心者からの疑問であれば、
　それに対して丁寧に誘導してあげることこそ、関数型言語の地道な普及活動につながる

というのは、強引かなw

正直な話、最近Haskellスレでreverse関数に関する議論が続いていて、それをずっとROMしてたんだけど、
問題を提示した(初心者と思われる)reverse君に対するスレ住人の雰囲気が「郷に入れば郷に従うのが当然！」、
あるいは「Haskellの言語仕様はこうなんだから、それ以外の発想は一切認めない！」に見えたんだ。
あと、相手の知識に合わせて返答するという(初心者に対する)配慮も感じられなかった。
で、これじゃスレを覗いている他の初心者(未来のHaskeller候補生)達も、うっかり質問できる空気じゃねえし、
これじゃHaskellが一般の(=普通の)プログラマに普及するのは難しいんだろな、と。

だから、Haskellについては自分も初心者だからその議論に口出しはできなかったけど、
せめて自分ができる範囲で、やれることをやりたかった。それが、このスレの丁寧すぎるかもしれない
一連の返答につながっている。

211 ：210：2010/09/20(月) 20:13:16

アンカミスを訂正。>>202は間違いで、>>207が正しい。

212 ：デフォルトの名無しさん：2010/09/20(月) 20:16:25

関数型言語スレには、手続き型言語に関してはデタラメを言ってもいいというルールがあるのか。
すごいな。

213 ：デフォルトの名無しさん：2010/09/20(月) 20:33:28

>>210
Haskellスレのは俺も見ていたけど、
あれはHaskell言語批判が目的のようだったから反撃されただけのような。

214 ：デフォルトの名無しさん：2010/09/20(月) 20:50:19

>>203
>写像はいくつかある関数の特徴の一つ
数学だと関数のほうが写像の一種だな。
数値をとって数値を返すもののみに限定される。

215 ：デフォルトの名無しさん：2010/09/20(月) 21:39:27

>>213
Haskell言語批判、大いに結構じゃないのかな。技術的視点による批判であれば。
少なくともあのreverse君のカキコは、荒らしとか粘着ではなくて、彼なりの考え方を持った意見だったと思う。
態度が横柄だとか、口調が上品ではないってのは2chなんだから、よくある話で、
意見に批判的な内容が含まれるからといって感情的な反撃をするのはいかがなものかと。

自分に限定すると、文章の表面的な口調はまるで気にならないね。
発言者に自分なりの考え方という知性を感じる事ができれば、それで十分だ。逆に、
・単なる質問小僧
・感情的な短レスしか返すことのできない人
・文脈の本筋から外れた箇所について執拗に付きまとう人
であれば、スルーするか、あるいはこちらも厳しい口調で反撃する。でもreverse君は、そうじゃなかった。

あの場合、reverse君の主張の中で、正しいという部分については、まずそれを認める(肯定する)こと、
たとえば「確かに効率も大事だね」とか「双方向リストによる実装という選択肢もありかもしれないね」などと。
その上で、「でもHaskellの設計思想はxxxxだから、yyyyのようになっているんだよ」と反論すれば、
彼のHaskellに対する印象も変わったものになったのではないかと。
一般社会生活の中であれば、誰でも自然と実践できているはずのことなのに....と思う。

そして、もしHaskell熟練者達が初心に返って「reverse君の考えではなく、このような設計思想になったのは
ナゼなのか」を自問自答できるようになっていれば、reverse関数話も単なるQ&Aにとどまらず、深い意味のある
議論へと変化していったのでは？と想像してしまう。

216 ：デフォルトの名無しさん：2010/09/20(月) 21:54:47

もし双方向だとすると、コンシングが馬鹿みたいに高コストになるというのはlispなんかを
齧っていないと直感的に想像するのは難しいのかもしれないね
そういえば、著名なlisp本でも生成コストと（単方向）リストの関係を扱ってるものはそうそう無いなあ

217 ：デフォルトの名無しさん：2010/09/20(月) 21:57:11

>>216
別にLispを知らなくてもCとアルゴリズムとデータ構造を勉強した人なら想像出来るだろ。

218 ：デフォルトの名無しさん：2010/09/20(月) 22:06:15

>>217
そりゃそうだけど、(:)とcons , headとcar, tailとcdrその他もろもろの関係性から、「直感的」にいうことでね

219 ：デフォルトの名無しさん：2010/09/20(月) 23:10:25

>>210
> これじゃHaskellが一般の(=普通の)プログラマに普及するのは難しいんだろな、と。

普及しない理由の一つとしては妥当だが、それは関数型言語だからなのか？
このスレではどの言語でも繰り返し行われてるやりとりに見えたが。

220 ：デフォルトの名無しさん：2010/09/21(火) 00:16:00

>>203
> 写像はいくつかある関数の特徴の一つであって、
> 他にもxxxxとかyyyyyみたいな特徴が
> あったりするから、限定されすぎな命名では？という人もいるんじゃないかな。

えー、なにその特徴？

関数だけの特徴というと、解析学とかイメージしてしまうが、
プログラムの関数で微積分してもしょーもないから違うかｗ

数学の話だと、関数と写像に違いはないよね。
あえて言うなら、逆に写像のほうが集合論という概念を含んだ
より大きな概念で、関数の方が写像の一種と言えなくもないよーな。

まさか超関数・・・いや何でもない。

とにかく写像は数学ではより新しくて大きな概念だから、
「写像指向言語」という言葉で、ぜんぜん問題ないと思うな。

221 ：デフォルトの名無しさん：2010/09/21(火) 00:57:53

うん。素人にはF#がBASICに見えてもしょうがない。
何せ違いが分からないのだからｗ

222 ：デフォルトの名無しさん：2010/09/21(火) 01:25:43

>>195
>便利な仕組みだけど、たとえばGUIやプラグイン機構のように、オブジェクトの動的な生成/消滅や
>構成の動的変更が本質的に起こりえるプログラミングでは、ガチガチすぎて使いづらいという批判がある。
>理想は「動的言語と型推論機能の融合」なんだけど、そこまでプログラム言語理論が進化していないのが現状。
GUIにはFunctional Reactive Programmingが10年前からあるし、
プラグイン機構が何を指してるか正確には分からないけど、
型クラスやGADTで表現できない程高度なものじゃないでしょ。
「普及してない」なら分かるけど、「プログラム言語理論が進化していない」っていうのは言いすぎじゃないかしら。

223 ：デフォルトの名無しさん：2010/09/21(火) 22:28:39

＞＞１
haskellスレには博士以外書き込めないから。
//お前ら試してみろよ、書き込めないから
下流pgは帰れと罵倒されるから

224 ：デフォルトの名無しさん：2010/09/21(火) 22:38:59

関数型言語周りのノウハウが整備されていないのに、
自分で研究して設計法とかノウハウとか編み出せない下流プログラマが
いきなり触ったら「関数型言語使えねー」ってことになるのは目に見えているので、
ある程度知識のある人以外は触るなってことでしょ。
俺らが使えるようにしてやるからおとなしく待ってろって事がわからないの？
オブジェクト指向だっていろいろ整備されるのに時間がかかって、その間は
オブジェクト指向なんて重いだけのカスと言われ続けてきた歴史があるわけだし。

225 ：デフォルトの名無しさん：2010/09/21(火) 22:57:50

だいたい、アルゴリズムとデータ構造やλ計算などの基礎すら知らないような連中が
モナドやアローや遅延評価などの根っこの部分を理解できるとは思えないし、
表層的に理解できたとしてもサンプルに毛を生やした程度の拙いコードしか書けずに
関数型言語クソとか言って放り出すに決まってる。
そんな程度の低い連中にもわかるように噛み砕いてわかるようにノウハウを積んでいくのが
知的水準の高い博士以上の人間なんだよ。

226 ：デフォルトの名無しさん：2010/09/21(火) 23:18:26

>>225
それがHaskeller達の本音(マジレス)だとしたら、彼らは現時点でのHaskellの普及を望んでいない、
ということになるね。漏れ達が噛み砕き終えるまで庶民プログラマを待ってろ、みたいな。
だとしたら、このスレの存在意義である「何故」が無意味になるんだけど。
他人に知性の放棄を強要する態度は、「知的水準の高い博士以上の人間」にはふさわしくないと考えるよ。

227 ：デフォルトの名無しさん：2010/09/21(火) 23:24:56

世の中に必要なのは、理解しなきゃならない概念じゃなくて、
簡単高機能な便利なライブラリです。

228 ：デフォルトの名無しさん：2010/09/21(火) 23:27:08

>>226
「全力で成功を回避する」というのがHaskellの非公式スローガンだからねｗ
Haskell自体は普及しなくて良い。
研究場であるHaskellで培った成果を他の言語でより良い物に育て上げれば良い。

229 ：デフォルトの名無しさん：2010/09/21(火) 23:33:32

まぁ再帰もポインタもローカル変数も理解しなくてよいのが良いプログラミング言語だ、
と考えてるような奴等は見捨てるしかないと思うよ。

230 ：デフォルトの名無しさん：2010/09/21(火) 23:35:12

そうだね。全部アセンブラで書くべきだね。

231 ：デフォルトの名無しさん：2010/09/21(火) 23:41:54

>>228
ああ、そんなスローガンがあるのだとしたら納得だw
だとしたら、これほどまで世間の注目を浴びてしまった現実にとまどってるのかも。

Haskellに関しては、他のプログラミング言語と同列に比較すべきじゃないのかも、
って最近考え始めている。教育とか、方式設計工程での検証を目的とした
使い捨てプロトタイピングとか、アルゴリズムの研究といった限定された領域で
(一般プログラマには普及せず)細々と生き残っているみたいな。
現在のPrologと似た位置付けかな。

で、個人的に関数型言語普及の本命は、ML系の言語ではないかと思っているw
Windows環境なら、先日このスレで話題になったF#が、そうなのかもしれない。

232 ：デフォルトの名無しさん：2010/09/22(水) 00:21:35

とりあえずF#で実際のアプリに使うライブラリとか使い始めたが、本当に関数型らしく描くまではベターC#程度のものになってしまいそうな予感(´・ω・｀)

233 ：デフォルトの名無しさん：2010/09/22(水) 00:49:48

C#でいいと思うけどな。
散々上でも言われている通り、MLなんて研究用の言語で成果を既存言語にフィードバックできればそれでいいような。
F#だって元々はそんな位置づけだったはず。

234 ：デフォルトの名無しさん：2010/09/22(水) 00:54:46

>>233
F#が研究用ならVSに入るわけがないしdotNET対応も意味が無いでしょ

235 ：デフォルトの名無しさん：2010/09/22(水) 01:12:40

>>232
それでいいんじゃないかと。自分はF#は使ってないから一般論になってしまうけど、
理屈先行型の頭でっかちもダメだし、結果的に動くプログラミングしかできないのもダメ。
関数型言語の勉強という理屈とプログラミングという実践を繰り返し続けること、
言い換えると「抽象化(理屈) <-> 具体化(実践)」の反復プロセスが大切だと思う。

その全体像は螺旋階段(スパイラル構造)のようであり、成長度の傾きはごく緩やかで、
暗闇の中で階段を一歩一歩上ることは焦りや不安が常につきまとうものだけど、
ある時、ふと下界を眺めてみると、過去の自分が別人のように見えることに気付く。
自分の経験になるけど、新しいパラダイムの勉強と成長とは、そんなものだと思う。

236 ：デフォルトの名無しさん：2010/09/22(水) 01:23:16

>>233
Haskellはプログラミング言語研究を目的に開発された言語かもしれないけど、MLはそうじゃないよ。
LCFという定理証明器というアプリケーションの開発という、実用性を目的に設計された言語。
また、ML系の言語 mini-Caml は、教育目的であるけれど、レンダリングのような領域を限定すれば、
実用的な(C言語に匹敵する)性能を叩き出すコンパイラがコンパクトに記述できることを証明してみせた。
更に、これまたML系の言語 SML# プロジェクトは、実用的な処理系開発を目標の一つにあげている。

237 ：デフォルトの名無しさん：2010/09/22(水) 02:52:19

寝れんのでチラ裏。

流行らないのは、関数型の適した問題が
手続き型のそれと比べて少ないからじゃなかろうか。
特に、データベースやネットワークも含めて
IOが絡むと手間なことが多いし、
GUIの記述も適しているとは言えないと思う。

238 ：デフォルトの名無しさん：2010/09/22(水) 08:09:14

>236
HaskellとMLの差はどこから来るの？
Pureにこだわるか否か以外にもある？

239 ：デフォルトの名無しさん：2010/09/22(水) 08:29:52

GoogleマップでJavaScriptが見直されたような感じで、
関数型言語でも何かすごいプログラムが出てこないと普及しないんじゃないの？

240 ：デフォルトの名無しさん：2010/09/22(水) 09:38:22

同感だね
関数型言語にもキラーアプリケーションが登場すれば状況は一変するかも
RubyはRailsがあったから人口が爆発的に増加したし、
(アプリじゃないけど)UNIXがあったからCはPascalを圧倒することができた

241 ：デフォルトの名無しさん：2010/09/22(水) 10:00:40

完全に自転車置き場だな

242 ：デフォルトの名無しさん：2010/09/22(水) 11:20:06

Lisp系は副作用があるからステートマシンをわりと作りやすいけど。
Haskellとかの副作用がない関数型はどやってるの？

243 ：デフォルトの名無しさん：2010/09/22(水) 11:21:22

ステートモナド

244 ：デフォルトの名無しさん：2010/09/22(水) 11:28:11

ちょっくらみてくる！

245 ：デフォルトの名無しさん：2010/09/22(水) 12:06:32

>>231
Prologは遅いからという納得できる理由がある。
Haskellはそんなことはないし、いまひとつわからない。

246 ：デフォルトの名無しさん：2010/09/22(水) 12:15:00

>>238
純粋/非純粋、遅延評価/非遅延評価、そして静的型検査/動的型検査という３つの視点で評価しています。
Haskellは「純粋かつ遅延評価かつ静的型検査」な言語で、ML系は「非純粋かつ非遅延評価かつ静的型検査」ですね、
３つの視点は組み合わせ(直積)ですから、「非純粋かつ遅延評価かつ静的型検査」な言語もありえるでしょう。

ただし、数学の世界は「純粋かつ遅延評価(正確には評価順序が無いと言うほうが適切か？)かつ静的」ですから、
「純粋かつ遅延評価かつ静的型検査」な言語であるHaskellは他の言語と区別する、言い換えると
「Haskellとその他の関数型言語」という分類で単純化してかまわないと思います。

247 ：デフォルトの名無しさん：2010/09/22(水) 12:40:07

>>237
>流行らないのは、関数型の適した問題が

この文中の関数型というのは、(>>246で書いた「純粋かつ遅延評価」な)Haskellだけに当てはまり、
それに続く問題はHaskell特有の問題だと思う。データベースやネットワークはIOモナド、
GUIの状態遷移はステートモナド等、副作用が発生する箇所はすべてモナド・モナド・モナド・......。
何かと言えばモナドが必要で、モナドだらけになったコードは読みづらい。

それに対して、Haskell以外の言語であれば、IO関数はコードの流れに沿った評価順序が保証されているし、
状態遷移も状態変数を可変(mutable)属性で宣言すれば状態値の更新操作で実現できる。
さらにOCamlのようなオブジェクト指向を導入した言語であれば、一般(=手続き型)のOOPＬと
同様なGUIプログラミングスタイルによる記述が可能です。

まとめると、「純粋かつ遅延評価」ではない関数型言語であれば、適した問題の領域が手続き型と重なる、
言い換えると、今まで手続き型言語で実現していた問題解決を関数型言語で置き換えられる可能性がある、
と考えています。

248 ：デフォルトの名無しさん：2010/09/22(水) 12:53:22

>>247
> 何かと言えばモナドが必要で、モナドだらけになったコードは読みづらい。

モナドの扱いにつきまとう面倒やややこしい所を
プログラマに極力意識させないライブラリは作れると思う。
たとえば GUI だったら Fudgets とか結構優れているのではないか。

249 ：デフォルトの名無しさん：2010/09/22(水) 12:53:41

>>242
このカキコをそのままHaskellスレへコピペしてみるというのはいかが？
そのほうが詳しい説明をもらえる可能性が高いと思うし、
個人的には、あのスレの住人達がどういう反応(対応)するのか興味があったりするw (<-- いじわるダナァー)

250 ：デフォルトの名無しさん：2010/09/22(水) 12:57:59

>>249
さんざん語りつくされた話題だから一瞬で答えが出るよ

251 ：デフォルトの名無しさん：2010/09/22(水) 13:01:36

それって>>243ですか？

252 ：デフォルトの名無しさん：2010/09/22(水) 19:13:06

>>245
まず、言語の実行効率については、(>>246でレスしていますが)「現実世界における実用性評価の視点」として
考慮していません。(評価の優先度が他の視点より低いという意味。) もしプログラマの負担よりも実行効率が
優先されるとしたら「アセンブリ言語最高！」となりますから。

また、Haskellの実行効率ですが、スクリプト言語であるRuby/Pythonよりは速いものの、(純粋性と遅延評価が
ネックとなって)ML系言語にはとうていかなわない、という認識でいます。自分の知る範囲で、過去のある時点における
最速Haskell処理系と最速ML処理系のベンチマーク比較で、一度としてHaskellが速かったことは無い、という意味です。
特に、アッカーマン関数や最小公倍数計算といった単純なベンチであれば同等かあるいは僅差でHaskellが速いことは
ありえますが、ソート/レンダリングといった実用性があり大量のデータを処理させるベンチであれば、
HaskellはMLに圧倒されているはずです。もし「そんなことはない」と反論されるなら、ソースを提供してください。

さらに、Prologは遅いとのことですが、今時の多くの人はインタプリタでPrologを実行させるくらいで学習を止めてしまい、
その印象から遅いというイメージを持ちがちです。実際には、適切なカット、モード宣言の厳守、そして商用最適化コンパイラ
といった実用目的の環境を整える事ができたなら、(初歩的なインタプリタ実行に対して)驚く程の性能を叩き出せます。
もちろん(C言語で解けるレベルの問題について)CコンパイラとPrologコンパイラを比較すればC言語が圧倒するし、さらに
自分はPrologとHaskellのベンチを測定した事も見た記憶もないので、Prologについては主観的な比較にすぎない訳ですけど。

253 ：デフォルトの名無しさん：2010/09/22(水) 20:21:53

>>248
Haskellについては詳しくないのですが、その Fudgets というライブラリを使えば、手続き型言語のGUIプログラミング技法、
具体的には、GUI部品(ウィジェット)を組み立て、イベント待ちループに入り、コールバックでアクションを実行という、
いわゆる「イベント駆動プログラミング」によって、HaskellでもGUI開発が可能になるという意味でよろしいでしょうか？

あと気になったのは「作れる」とありますが、これは未来を指している、言い換えると、現時点ではまだ存在していない、と
いうことを意味しているのでしょうか？もしそうなら、評価の対象から除外しなくてはなりません。
未来を前提に加えてもかまわないとしたら、未来は誰にも予測できないのですから、あらゆる言語で未来には可能になるはず、
という論法を許すことになってしまいますから。

同様に、性能(実行効率)についても「次期GHCが登場したあかつきには、MLなど圧倒してくれるはずだ」とか、
「メニーコア時代になれば、評価順序の決まっていないHaskellのほうが最適化に適しているから逆転するはずだ」といった
未来を前提にした主張があったとしても、(自分は)その主張を詭弁として却下します。

254 ：デフォルトの名無しさん：2010/09/22(水) 20:27:40

>>253
> 評価順序の決まっていないHaskell
それは非正格のことを言っているのかチャーチロッサーの定理のことを言っているのかどっち？

255 ：デフォルトの名無しさん：2010/09/22(水) 20:29:17

>>252
> Haskellの実行効率ですが、スクリプト言語であるRuby/Pythonよりは速いものの

であれば、Ruby や Python で作られている実用アプリは、
処理速度的には Haskell でも余裕でこなせるということになる。
処理速度的には普及していてもおかしくないレベルだと思う。

また、Ruby や Python で作られている実用アプリを
Haskell で作るためのライブラリは十分に揃っているし、
必要なら作ればいい。

にもかかわらず全く普及が進まないのは、
そういうアプリの作り方を教える人間がいないからだと思う。

256 ：デフォルトの名無しさん：2010/09/22(水) 20:38:45

>>254
人を試す良い質問だｗ

257 ：デフォルトの名無しさん：2010/09/22(水) 20:46:11

>>253
「現時点」で一般的な GUI アプリが作れます。
ベント待ちループの仕組みはライブラリの裏に隠されています。
プログラマはウィジェットと自作のイベントハンドラを
ケーブルで接続するようにプログラムしていくことで、GUI を組み立てていきます。

ただ例に挙げた Fudgets はかなり古いライブラリです。
主な機能は 1996 年で開発完了、あとはメンテ状態。
しかし、設計思想は優れてます。
関数型言語らしく（宣言的にという意味） GUI アプリを作れます。

今なら FRP を利用した GUI ライブラリが盛んに研究されていますが、
私が試したことがある範囲ではどのライブラリもまだバージョン 1.0 未満ですので、
こちらは残念ながら「未来」の話ですね。

ただ、試した範囲では、どれも >>247 で懸念されているような
「モナドがウザイ」なんて状況は皆無でした。
むしろモナドって何だっけというくらいモナドは表に出てきません。

258 ：デフォルトの名無しさん：2010/09/22(水) 21:04:40

>>254
この文脈は、(ラムダ計算の計算可能性ではなく、)ラムダ計算のコンピュータ上での実現方法について
説明しているのですから、チャーチロッサーの定理です。
（理論面は不勉強なので間違ってるかもしれませんが....）

259 ：デフォルトの名無しさん：2010/09/22(水) 21:31:10

HaskellのGUIライブラリは沢山作られるが，メンテはされない。
特にwindows環境では簡単に利用できるものはない。

まあこの点はMLも同様だけど（ちょっとましか）

260 ：デフォルトの名無しさん：2010/09/22(水) 21:36:41

>>255
>処理速度的には普及していてもおかしくないレベルだと思う。

いいえ、その考え方は間違っていると思います。>>252で「プログラマの負担よりも実行効率が優先されるとしたら....」と
書いているように、いくら処理速度的にHaskellがスクリプト言語より優れているとしても、生産性が比較になりませんから、
Haskellがスクリプト言語を置き換えるような事態は、決して起こりえないでしょう。もしも>>255の考え方が
正しいとしたら、「VC++(Visual C++)はVB(Visial Basic)よりも圧倒的に速いのだから、VBは不要だ。
すべてのVBプログラムをVC++で置き換えるべきだ。」という主張が正しいということになります。(実は正しかったりして....)

物事の一面(一つの視点)だけで考えて、大局的な結論を誤るという典型例であると言えるでしょう。

自分は静的関数型言語が勝負すべき相手は、RubyやPythonのような簡易言語などではなく、
C/C++/C#/FORTRAN/COBOLといった、コンパイラベースの本格的な言語であり、真っ向勝負できると考えています。
低レベルな相手との勝負に勝って、満足(思考停止)したくはありません。

261 ：デフォルトの名無しさん：2010/09/22(水) 21:45:14

>>259
> 特にwindows環境では簡単に利用できるものはない

英文のインストールマニュアル通りインストールすれば、
拍子抜けするほどあっさりとインストールできるし、
これまた英文のチュートリアルを実践すれば、
簡単に利用できるようになるよ。

たとえば Gtk2Hs なら 0.11.0 以降のインストールは
install instructions に従うだけでいいし、
最初は Tutorials や Examples を改造していればいい。

なのに、「windows環境では簡単に利用できるものはない」
という印象を与えてしまうのは、>>255 でもちょっと言ったが、
日本語で教えてくれる人がいないからだよ。
まして日本語で丁寧にチュートリアルを示してくれる人なんていない。
偉そうに言う私も、人にわかりやすく教えられるほど Haskell を修めていないし。

262 ：デフォルトの名無しさん：2010/09/22(水) 21:54:33

>>260
「処理速度的には」と２度断ったはずだが

普及するためには様々な要素が必要だけど、
少なくともその中の処理速度という要素に関しては、
Ruby などで作るアプリもこなせるレベルだろと言っている。
（調べればわかるが、Ruby や Python でもそうとう実用的なアプリが作られている）

でも普及しないのは、他の要素が書けているからではないかと推論できる。
当たり前だが繰り返すと、普及するために必要な要素は処理速度だけではないからだ。

その他の書けている要素の一つとして私が「大きい」と思っているのが、
「教える人の存在」だと言っている。

って、ほとんど >>255 の繰り返しだが

263 ：デフォルトの名無しさん：2010/09/22(水) 22:04:42

>>261
> 英文のインストールマニュアル通りインストールすれば、
> 拍子抜けするほどあっさりとインストールできるし、
これはこれで誤解を生みそうだな。
MinGW環境を整えて、gtk2を入れて…と、言うほど楽ではない。
cygwin環境が存在していたら干渉を避ける必要があるし、gtk2も適切なものを探す必要がある．

264 ：デフォルトの名無しさん：2010/09/22(水) 22:37:21

>>263
使えるまでのステップ数は確かに少なくはなく、面倒かも知れん。

しかし、言われた通りの手順を踏むだけで問題なくインストールできる環境は、
haskell 入門者、中級者ほど多いと思う（単に私の周りだけかもしれんが）。

たとえば、Windows XP 以降の環境で GHC をインストールし、
今まで Haskell の入門書で勉強していた人が、
次のステップとして GUI に挑戦してみたいというよくある状況なら、
install instructions に従ってそれぞれ最新のものをインストールしていけばいい。
こういう状況なら、そもそもcygwin環境の干渉とか適切なバージョンとか、
気にする必要もない。

CUI で入門して次に GUI に挑戦なんて良くあるパターンだろ。

でも、たいていの人は、挑戦してみたけど面倒そうに「見えて」諦めるんだ。
教えてくれる日本人が見当たらないから。
GUI 開発環境の構築方法を説明した入門書も何故か無いしね。

265 ：デフォルトの名無しさん：2010/09/23(木) 00:17:04

>>240
普及っていう意味では確かにキラーアプリは必須だな。

俺はRubyistだけど、Ruby周辺ではHaskellみんな勉強してる (Haskellの本出したRubyistもいる)
でも、誰もRubyを捨ててHaskellにいかないのは何故だろう？そこら辺に鍵があると思う。

もし本当に使いやすい言語なら、キラーまでいかなくても、もっとアプリ出てくると思うんだよ。
あーわかんねー。素晴らしい言語って感じはするんだけどなーっ。

266 ：デフォルトの名無しさん：2010/09/23(木) 00:25:31

「関数型」って名前がいけないんだよ。
見るからに文系は使いたがらないでしょ。
「オブジェクト指向」みたいに犬猫の例でバカでも読めそうな本を
沢山出すとか、Javaみたいなモダンなイメージで変なキャラが
ブラウザ中飛び回るような戦略使わないと。
Javaはコーヒーだからビール発泡酒辺りを使って大人っぽさを
印象付けたらどうかな。

267 ：デフォルトの名無しさん：2010/09/23(木) 00:26:52

文系が使えたらプログラマの地位が下がるだろうが。

268 ：デフォルトの名無しさん：2010/09/23(木) 00:27:16

よっぱらいでもプログラミングできる！って触れ込みで
酔っ払いの生徒と酔っ払いの講師で説明していくの。
読者も酒飲みながら読める。
なんだか楽しそうじゃない？

269 ：デフォルトの名無しさん：2010/09/23(木) 00:27:49

どうだろ？
単純に、そこまでして関数型を使いたいかという話で、
そうではない人が多いだけのような気がする。
関数型言語のメリットは便利だと思うけど、今必要なのはそれじゃないというか。
やってみれば問題なくインストールできるものを、試してみる人が少ないのは、
そもそも存在を知らないか、魅力が無いか、そういうことなんだろうと思う。

入門者なら特に、熱心な関数型言語のファンでもないしな。

270 ：デフォルトの名無しさん：2010/09/23(木) 00:29:25

なぁ、お前ら、いい加減SIer有利な現体制を破壊すべきだと思わないのか？
底辺プログラマが大量辞職して一部の優秀なプログラマだけが残った世界を作りたくないのか？

271 ：デフォルトの名無しさん：2010/09/23(木) 00:29:35

失礼。
>>269は>>264へのレス

272 ：デフォルトの名無しさん：2010/09/23(木) 00:33:11

>>269
誰でも使えるとかそういうのは素人に毛を生やしたような奴らを集めた人海戦術では
良い選択だが、それではいい製品は作れないよ。
やっぱり優秀な少数精鋭でやらなきゃね。
NTTデータとかのSIerのやり方じゃ日本のIT産業は衰退するだけ。
アホの指揮のもとアホと天才を一緒くたに扱ってゴミみたいなソフトを作ってる現状をなんとかしなきゃいけないだろ。
言語面からもそういうクソ体制に圧力をかけなきゃいかん。

273 ：デフォルトの名無しさん：2010/09/23(木) 01:34:44

>>269
> 魅力が無いか

魅力を魅力的に語れる人間が欲しいな。
魅力的とまでは行かなくても、
関数型でこんなことできるぜと、
ある程度長期に語り聞かせられる人間。

ちょっと違うかも知れんが、たとえば
「猫でもわかる」の関数型版とか。
あれで Win32API を学んだ日本人は多いと思う。
学んだ人間がまた別の人間に紹介する。

Haskell とかでもああいうのがあると、
プログラマが増えそうな気がする。

274 ：デフォルトの名無しさん：2010/09/23(木) 01:36:26

>>273
増えなくていいｗ

275 ：デフォルトの名無しさん：2010/09/23(木) 02:11:35

>>273
細かい定義は置いておいて、一般的なプログラムで、
「手続き型言語と比べて、これだけシンプルに書けます」的な資料があると、
あぁ、いいなぁと感じるかもね。

これとか http://ja.doukaku.org/18/nested/ 見てても、
プログラムが小さすぎて、結局ライブラリ次第としか見れないんだよなぁ。

276 ：デフォルトの名無しさん：2010/09/23(木) 06:44:52

haskellのメジャーな成果って何？
Perl6は知ってる
他は？

277 ：デフォルトの名無しさん：2010/09/23(木) 10:42:22

>>276
成果ってのは？

278 ：デフォルトの名無しさん：2010/09/23(木) 10:51:44

>>276
つ　Monadic IO
つ　Arrows
つ　monadius
つ　YAWS
etc..

279 ：デフォルトの名無しさん：2010/09/23(木) 11:27:52

「メジャーな」

280 ：デフォルトの名無しさん：2010/09/23(木) 11:30:56

メジャーの定義は？

281 ：デフォルトの名無しさん：2010/09/23(木) 11:31:38

ブラジャー

282 ：デフォルトの名無しさん：2010/09/23(木) 11:38:48

仕方がないからメジャーを定義しておくね。
メジャーとは、この業界に1年もいれば嫌でも目や耳に入るもの。
下手すれば新卒でも知ってて面接のネタにするようなもの。
判りましたかー？

283 ：デフォルトの名無しさん：2010/09/23(木) 11:44:37

>>282
Monadic IOはもう誰の耳にも入ってるな

284 ：デフォルトの名無しさん：2010/09/23(木) 11:52:08

馬の耳だけどな！

285 ：デフォルトの名無しさん：2010/09/23(木) 11:59:22

馬いこと言うね

286 ：デフォルトの名無しさん：2010/09/23(木) 12:04:56

あいやー、鹿りするネ！

287 ：デフォルトの名無しさん：2010/09/23(木) 12:07:07

>>282
そういうお子ちゃまは一生BASICでもやってなさい

288 ：デフォルトの名無しさん：2010/09/23(木) 12:09:30

この流れ、鹿と拙者が見届けたでゴザル！

289 ：デフォルトの名無しさん：2010/09/23(木) 12:12:15

Haskellで学士論文書いたけど、Haskellの旨みはあまり理解できませんでした。

290 ：デフォルトの名無しさん：2010/09/23(木) 12:14:09

人生の時間を無駄にしたね？
それが後々ジャブのように効いてくるんだよ・・・

291 ：デフォルトの名無しさん：2010/09/23(木) 12:16:10

>>282
ついでに「成果」も定義しとけよ

単にプログラム言語として Haskell を用いて作られたアプリケーションを指しているのか、
Haskell の思想や実装方法、文法などを参考にして生まれたパラダイムや
他言語の新機能まで含めるのか

それとも、もっと別の意味なのか

292 ：デフォルトの名無しさん：2010/09/23(木) 12:17:56

>>289
読みたい、どこかにアップしてください

293 ：デフォルトの名無しさん：2010/09/23(木) 12:18:45

>>292
あまりに恥ずかしい論文なのでアップすると死にます

294 ：デフォルトの名無しさん：2010/09/23(木) 12:19:05

成果＝プログラマ以外にとって価値のあるものを作れたかということ

295 ：デフォルトの名無しさん：2010/09/23(木) 12:30:38

Haskellは潜在能力が高くてそのままでもフレームワークとかそんなに必要ないんだよね。
そもそもプログラム自体が仕様レベルでそのまま書けるから、
下手な抽象化をするよりそのまま書いたほうがキレイにまとまる。

296 ：デフォルトの名無しさん：2010/09/23(木) 12:38:51

>>290 死ねよ

297 ：デフォルトの名無しさん：2010/09/23(木) 12:48:02

>>295
じゃあ聞くけど
仕様記述言語は何故普及しないのか

298 ：デフォルトの名無しさん：2010/09/23(木) 12:51:57

>>297
下流プログラマに理解出来ないからじゃないかな

299 ：デフォルトの名無しさん：2010/09/23(木) 12:52:43

下流を切り捨てるだけでずいぶん妥協せずに済むよ

300 ：デフォルトの名無しさん：2010/09/23(木) 13:16:49

Haskellからモナドを取れば、それはMirandaだからなあ。
全体からすれば関数型言語研究の成果の結実なんだけど、
Haskell固有の成果は何か？と問われると、やっぱりモナドしか残らない。

301 ：デフォルトの名無しさん：2010/09/23(木) 13:20:56

「実装の隠蔽」と言われることから分かるように
「何を記述するか」ではなく「何を記述しないか」ばかり考えている
だから何も生み出せない
隠したり消したり切り捨てたりすることしか考えてない

302 ：デフォルトの名無しさん：2010/09/23(木) 13:55:11

すごいな。抽象化を1レスでばっさり切ってしまった。

抽象化がなければ現代社会の何物も存在しなかったであろうに...

303 ：デフォルトの名無しさん：2010/09/23(木) 14:01:53

>>302
お前ってその調子で普段から重要な単語を聞き漏らしたりして怒られてるだろ？ｗ

304 ：デフォルトの名無しさん：2010/09/23(木) 14:21:00

>>301が言いたいのは、理屈ばかりゴネていないで、
そろそろ外の現実世界に踏み出そうよ、ってことじゃないかと

GUIライブラリの例であれば、新しい方式を考案してはメンテせず消え去ることを繰り返すのではなく、
安定したリリースの継続を真剣に考えなければ、現実世界では相手にされないよ、と。

305 ：デフォルトの名無しさん：2010/09/23(木) 14:26:03

>>304
ちゃんと研究分野では一定の需要があるよ。
今までいろんなライブラリが出ては消えたが、あれは研究目的で作られたもので
実際のビジネスを主眼に入れた開発ではないんだよ。
研究目的なら過去のものを捨て去るのは日常茶飯事。

306 ：デフォルトの名無しさん：2010/09/23(木) 14:28:12

Haskellのライブラリで過去に話題になったいくつかのライブラリを調べてみなよ。
大抵論文がくっついてくるから。

307 ：デフォルトの名無しさん：2010/09/23(木) 14:28:53

>>276
darcs

308 ：デフォルトの名無しさん：2010/09/23(木) 14:36:30

現状での関数型言語はポテンシャルは高そうだから、
みんなで有効な活用法を模索しましょうよって言う段階だと思うよ。
だから現状で何か成果が出ていなくても問題なし。
別にどうぞ使ってくださいお願いしますと頼んでいるわけじゃないから、
成果が出ていなくても文句を言われる筋合いはないし。
現状は成果を出す段階ではなくて、オブジェクト指向でいうUMLとかデザインパターンのように
ある程度まとまったノウハウを積んでいく事が重要だと思う。

309 ：デフォルトの名無しさん：2010/09/23(木) 14:38:23

「現実世界」とかそういう言葉を振り回す「お客様」を大事にしたところで、
たいていロクなことにはならないからな。

310 ：デフォルトの名無しさん：2010/09/23(木) 14:42:42

>>309
Javaは便利になったと思うけどなぁｗ
Javaが糞だという奴の主張をブログとかでよく見かけるけど、
そういう奴の主張っていまいちはっきりと納得できないんだよな。

311 ：デフォルトの名無しさん：2010/09/23(木) 14:54:56

>>309
Javaはappletで大コケして誰もが消え去るを思っていたのが、EJBの登場によってサーバ向けに奇跡の復活。
JavaScriptは誰もが使えないオモチャ言語だと思っていたのが、AJAXの登場で復活。
Rubyは日本発のマイナー言語だったのに、Railsの登場によって全世界規模でメジャーな存在に。

お客様うんぬんかんぬんじゃなくて、現実世界を見る事は普及を考える上では大切

「もっと現実を見ようよ」by ドラエモン AA略

312 ：デフォルトの名無しさん：2010/09/23(木) 14:59:47

>>311
今のアプレットはかなり高速起動してFlashと比べても違和感ないぞ。

313 ：デフォルトの名無しさん：2010/09/23(木) 15:01:53

普及のために魂を捨てろとか言われても「それ無理」で終わりだから。

314 ：デフォルトの名無しさん：2010/09/23(木) 15:06:14

>>311
少なくともHaskellの現実世界は研究用途だな。
Monadなどの試験的な機能を意欲的に実装していることからもわかるだろ。
普及させるのが目的ならF#みたいになる。

315 ：デフォルトの名無しさん：2010/09/23(木) 15:13:06

Haskellで気に入らん事があるなら、オープンソースの特徴を活かして
自分でプロジェクト始めたらどうなの？
対価を払っているわけでもないのに人にあれしろこれしろというのはマナー悪いよ。

316 ：デフォルトの名無しさん：2010/09/23(木) 15:18:21

そうだな
何故普及しないのかを考えるだけのスレで
普及しろ普及しろというのはスレ違いだ

317 ：デフォルトの名無しさん：2010/09/23(木) 15:41:57

>>315,316
他人にあれこれしろとか、普及しろなんてカキコは(ほとんんど)見当たらないんだけどな。
何故普及しないのかとか、その原因(背景)を探ろうとするカキコはあるけど、それは批判じゃないし。

自分達が普段からそういう発想で考えているから、きっと他人もそうに違いないと思っているのではないかと

318 ：デフォルトの名無しさん：2010/09/23(木) 15:46:13

自分の目が節穴という可能性は考えたことないの？

319 ：デフォルトの名無しさん：2010/09/23(木) 15:58:07

ないね

そういう発想しかできない人を気の毒にと哀れむことはあるけど

320 ：デフォルトの名無しさん：2010/09/23(木) 16:21:06

きっと抽象化だよ
具体的に誰かが言ったわけじゃないが
抽象化すると見えない世論が見えてくるんだ

321 ：デフォルトの名無しさん：2010/09/23(木) 16:22:54

>>318
とりあえず、普及しろと言っているようにあなたが感じたレスを挙げてくれ

その中に俺のレスがあったら、そうではないと誤解を解いておきたい

322 ：デフォルトの名無しさん：2010/09/23(木) 16:55:05

まぁ実際の開発に使うなら副作用許容して無いと書くのめんどくさすぎるよね(´・ω・｀)

323 ：デフォルトの名無しさん：2010/09/23(木) 17:28:17

scala使おうぜっ！

324 ：デフォルトの名無しさん：2010/09/23(木) 18:07:11

何でもHaskellで…じゃなくて
関数型向きな用途って無いの？
手続き型が組みやすいところは手続き型で
関数型で組みやすいなら関数型で
そんな風に協力し合うような流れは無いのかな

325 ：デフォルトの名無しさん：2010/09/23(木) 18:38:22

> 関数型向きな用途って無いの？
一部のアルゴリズム系。

だがアルゴリズムだけでソフトは作れない。
インターフェースが必要。

だから関数型言語の考え方・仕様を取り入れた
オブジェクト指向言語というのが増えている
関数型専用言語は、所詮実用言語のための研究用言語。

326 ：デフォルトの名無しさん：2010/09/23(木) 20:06:55

レイプの被害届け出せない女性みたいな

327 ：デフォルトの名無しさん：2010/09/23(木) 20:10:02

>>257
Fudgets ですが、たしかに興味深い存在ですね。
自分なりに、以下のように整理してみました。
・状態付きプロセスのストリーム計算定義によりGUIを記述
・各プロセスを３種類のコンビネータ(直列合成/並列合成/フィードバック)で相互に接続
・ストリーム上でfudgets自身を送受信する高階fudgetsによって、GUIの動的構成変更が可能
ストリームによるプログラミングは、並列論理型言語のGHC(Guarded Horn Clause)でも
重要な要素であり、以前にストリーミングによるウィンドウシステムの記述などにも
興味を持っていた事があったので、関数型言語でも同様な考え方を発見できて嬉しくなりました。

ストリーミングは、そこを具体的なデータやイベントが流れるという姿をイメージしやすいので、
関数間の依存関係を静的に記述するモナドやアローと比べると、
手続き型言語に慣れた普通のプログラマには理解しやすいと思います。
また、その定義を図によって視覚化しやすいことも、GUI設計技法として発展する可能性があります。

ただ、モナドが考案される以前の時代には、関数型言語でもストリーミング方式のI/Oは
研究されていたのに、モナドの登場によって、研究者の関心が一気にモナドへ移っていまい、
その後の進展が見えません。Fudgets にしても、開発が終了してしまったのは残念に思います。

それはともかく、良い物を教えてもらいました。「モナドがウザイ」という表現は取り消します。

328 ：デフォルトの名無しさん：2010/09/24(金) 01:09:52

>325
F#最強ってことでいいですか？

329 ：デフォルトの名無しさん：2010/09/24(金) 09:06:12

>>324 (関数型向きな用途って無いの？)
OS

330 ：デフォルトの名無しさん：2010/09/24(金) 12:49:08

>>276
Parsec

331 ：デフォルトの名無しさん：2010/09/24(金) 12:52:12

>>330
このアイデアはいろんな言語に移植されてるな

332 ：デフォルトの名無しさん：2010/09/24(金) 13:39:13

手続き型のPythonのような簡単な関数型言語が出たら普及すると思う。

333 ：デフォルトの名無しさん：2010/09/24(金) 13:42:35

>>332
pythonが関数型言語って初耳なんだけど。

334 ：デフォルトの名無しさん：2010/09/24(金) 13:44:01

>>333
お前、かわいそうなくらい読解力が欠如してるな。

335 ：デフォルトの名無しさん：2010/09/24(金) 13:49:04

>>334
お前の表現力が低いんだよ。

手続き型の、Pythonのような簡単な関数型言語
手続き型のPythonのような、簡単な関数型言語

どちらともとれる。

336 ：デフォルトの名無しさん：2010/09/24(金) 13:59:49

ScalaにせよHaskellにせよ、とにかく今ある関数型言語は難しすぎるのが普及を妨げていると思う。

337 ：デフォルトの名無しさん：2010/09/24(金) 14:00:37

>>336
下流を切り捨ててプログラマの地位向上を狙うべき

338 ：デフォルトの名無しさん：2010/09/24(金) 14:02:06

そもそもちゃんとした基礎勉強もしたことないやつを1ヶ月勉強させて
いきなりプロジェクトに投入して成り立ってる業界とかありえないし。
そんな奴らに理解できる言語など不要

339 ：デフォルトの名無しさん：2010/09/24(金) 14:04:41

ベテランのための言語であっても、簡単な事を難しくやる必要はなく、難しい事を簡単に表現できる言語が理想という事。

340 ：デフォルトの名無しさん：2010/09/24(金) 14:05:22

そんなに難しいかな
最初に勉強した言語じゃなかったから評価が難しいけど、
何がやりたいのかは使ってるうちに直ぐ飲み込めたよ

強いて言うなら遅延評価は慣れが必要だとか
ポイントフリーみたいな難読化が流行してて勉強しにくいとか
そう言うのはあるけど

341 ：デフォルトの名無しさん：2010/09/24(金) 14:08:52

私みたいなアフォには難しい。
言語の使い方で頭を悩ます。本来作っているものの中身で悩みたい。

342 ：デフォルトの名無しさん：2010/09/24(金) 14:10:34

目的と手段を入れ替えたい人向け

343 ：デフォルトの名無しさん：2010/09/24(金) 14:13:00

慣れれば、目的をそのままコードに落とし込むだけなんだけどな

344 ：デフォルトの名無しさん：2010/09/24(金) 14:19:55

>>340
ポイントフリーって処理の流れが分かりやすいと思うぞ

345 ：デフォルトの名無しさん：2010/09/24(金) 14:32:28

>>335
後付けは墓穴を掘る。ｗｗ
どちらとも取れるものを一方だけ取ってレスした>>333は池沼。

346 ：デフォルトの名無しさん：2010/09/24(金) 14:34:00

池沼とか言い出す奴ほどバカ。

347 ：デフォルトの名無しさん：2010/09/24(金) 14:38:28

>>346
言えてる

348 ：デフォルトの名無しさん：2010/09/24(金) 14:39:24

>>344
全部引数一つならともかく、
引数複数個とかでもほいほいポイントフリーにしてるサンプルが多いんだよね
更にそれを複合させるからドットだらけflipだらけのカオスソースが……

349 ：デフォルトの名無しさん：2010/09/24(金) 14:42:22

関数型言語のほうが単純だと思うが、
単純だから簡単かと言われると、かなり疑問

350 ：デフォルトの名無しさん：2010/09/24(金) 14:46:53

まず型付けを止めることから始めよう

351 ：デフォルトの名無しさん：2010/09/24(金) 14:50:34

>>345
後付けしようとして失敗してるんだよな。
「手続き型の」の被修飾語がないから、上はそもそも文が成り立ってない。

352 ：デフォルトの名無しさん：2010/09/24(金) 15:13:25

ループの何か簡単な良い構文は無いものか…

353 ：デフォルトの名無しさん：2010/09/24(金) 15:29:30

>>352
R言語では無名関数での再帰を実現するためのRecall関数が存在する。
Yコンビネータのほうがラムダ計算的に忠実なんだけどね。

> (function(n){if (n <= 1) return(n) else return(n * Recall(n - 1))})(10)
[1] 3628800

354 ：デフォルトの名無しさん：2010/09/24(金) 15:30:59

Haskellは自分で再帰実装するくらいだったら高階関数使えってノリのような気がする

355 ：デフォルトの名無しさん：2010/09/24(金) 15:33:06

まぁ実際Haskellで再帰を使わなきゃいけない場面ってのがすぐに想像できないな

356 ：デフォルトの名無しさん：2010/09/24(金) 15:40:14

なるほど。再帰はほとんど使わないのか…

357 ：デフォルトの名無しさん：2010/09/24(金) 15:51:13

時間出来たら関数型言語作ってみようかな
関数型言語には、この機能は最低限必要というのはある？

358 ：デフォルトの名無しさん：2010/09/24(金) 16:06:43

・レキシカルスコープの(局所or無名)関数
・末尾呼び出しの最適化(が可能なような言語設計)
・文の概念がなくてすべてを式で表現できるように(あるいは式の中に文を入れられるように)
・GC(か、それに代わる自動or半自動メモリ管理)

これくらい？

359 ：デフォルトの名無しさん：2010/09/24(金) 16:09:25

あんまり考えずにまずは何か簡単なものを作ってみるのがいいと思うぞ

360 ：デフォルトの名無しさん：2010/09/24(金) 16:14:27

Haskellって末尾再帰最適化ってあったっけ？

361 ：デフォルトの名無しさん：2010/09/24(金) 16:16:44

>>360
あるよ
規格で決まってたかどうか知らないけど、GHCとHugsはちゃんと最適化する

362 ：デフォルトの名無しさん：2010/09/24(金) 17:49:04

最適化というより、仕様に含まれてないとヤバイってレベルじゃないのか

363 ：デフォルトの名無しさん：2010/09/24(金) 18:18:39

>>331
アイデアが抽象され、純粋関数型の言語仕様は捨象されてる
これが抽象化だ
ざまあ見ろ

364 ：デフォルトの名無しさん：2010/09/24(金) 19:32:17

>>362
多くのケースで最適化可能であっても、
全てのケースで最適化を保証するのはかなり難しいらしい
言語仕様で最適化の保証があるのは、Schemeぐらいじゃないの？

365 ：デフォルトの名無しさん：2010/09/24(金) 19:50:07

かなり難しいって
どんなケースがあるんだね？言ってみなさい

366 ：デフォルトの名無しさん：2010/09/24(金) 19:58:09

難しい「らしい」って言ってんだから噂レベルの知識なんだろ
自分で調べろって事だ

367 ：デフォルトの名無しさん：2010/09/24(金) 19:59:45

とりあえず「Proper Tail Recursion and Space Efficiency」を一読したぐらいだと
よくわかんないぐらい難しい。

368 ：デフォルトの名無しさん：2010/09/24(金) 20:08:55

>>364
luaも仕様に入ってる
はじめから入れようと意識するなら別に難しいことでもない
「かなり難しい」って情報はどこから得たのかね

369 ：デフォルトの名無しさん：2010/09/24(金) 20:10:14

>>367
お前がアホなだけだよw

370 ：デフォルトの名無しさん：2010/09/24(金) 20:12:22

関数型言語は何故普及しないのか

・手続きが、人間の一番自然な考え方だから
問題を解決するとき、その手順によって説明されるのが一般的で、問題ドメインと解決レンジの写像として説明されることはまれ。

・純粋関数型言語の副作用のないモデルは、現実世界の解釈と相性がよくない
データベースのアクセス順序や、ネットワークの通信手順、ユーザインターフェイスなどは、実際にはそれぞれ異なる世界に影響を及ぼす。
一方、設定ファイルの読み込みなどは、実用上副作用のある処理とは考えないが、純粋関数型言語では、IOモナドを導入してモデル化しなければならない。
そのほか、手続的な言語に比べ、現実の計算機上での計算量をイメージしにくい。

・非純粋関数型言語の特徴は、他の言語に取り込まれつつある。
わざわざマイナーな関数型言語を使う必要がない。

371 ：デフォルトの名無しさん：2010/09/24(金) 20:15:07

ML系も末尾再帰おｋだよね？
CommonLISPも仕様には含まれてないけど最適化すると大抵末尾再帰になる
仕様に含めないのはデバッグトレースが難しくなるからじゃないかと

372 ：デフォルトの名無しさん：2010/09/24(金) 20:27:56

「難しい」の使い方は2通りある

・量が多いとか時間が無いとかで困難
・わかってる人には簡単だが、その「理」に辿りつく下地がない、崖の下にいる様

373 ：デフォルトの名無しさん：2010/09/24(金) 20:54:40

>>370
人間の思考方法とは合わず、現実世界の解釈との相性も良くない。
計算量をイメージしにくいし、成果は他言語にパクられ続けてる。

にもかかわらず、なぜ純粋関数型言語の研究は続けられているのか？
どうせパクられるんなら、それを前提に純粋関数型の考え方だけを研究すればいいのに、
なぜわざわざ独立した一つのプログラミング言語として研究が続けられているのか？

374 ：デフォルトの名無しさん：2010/09/24(金) 21:05:28

>>373
もともとは、純粋関数型に沿った考え方などを研究するんだろうけど、
よいところがあれば、それは他方面にも応用される。

純粋関数型にしか応用できないようなことしか考えないというのは、応用性がなくむしろ不自然な方向性だし、
後の世でどんな風に活用されるか、分からないことは多い。

375 ：デフォルトの名無しさん：2010/09/24(金) 21:09:50

数学みたいなもんだ
なぜか分からんが、びっくりするぐらい現実に応用が効く……こともある

376 ：デフォルトの名無しさん：2010/09/24(金) 21:17:03

人間の思考方法ってのは、考え方が人それぞれ違うって事ではないかと。

377 ：デフォルトの名無しさん：2010/09/24(金) 21:19:58

>>335

つ文脈

378 ：デフォルトの名無しさん：2010/09/24(金) 21:29:48

>>374
いや、だからさ。
それなら遅延評価や型推論などのレベルで研究していればいいんであって、
Haskell というひとつのプログラミング言語レベルで
これほど多くの人間が研究し続ける必要はないだろ。
98 -> 2010 とHaskell をバージョンアップさせていく必要もないだろ。

人間の思考と合わず、現実世界の解釈と相性もよくないものを誰が求めているのだ？
世の中から求められていないのに、なぜ Haskell がバージョンアップするんだ？

ということを >>370 のレスを読んで感じた

379 ：デフォルトの名無しさん：2010/09/24(金) 21:59:00

>>378
Haskell というひとつのプログラミング言語レベルで、どれだけの人間が研究してるのかは、よく知らないけれど、
計算機科学としては、理論的アイデアを実機上で実現してみることに、意義はあると思う。
その土台として、今あるHaskellを使うのはいいんじゃない?

>98 -> 2010 とHaskell をバージョンアップさせていく必要もないだろ。
Haskellで、実用のアプリケーションを作ったりするひともいるわけだし、バージョンアップさせるのはいいことだと思うよ。

>人間の思考と合わず、現実世界の解釈と相性もよくないものを誰が求めているのだ？
実は自分はHaskellは素晴らしい言語だと思うし、世の中から求められてないなんてことはないと思う。
関数型言語は、手続きを考えないで問題をより簡潔で抽象的に記述できるよい言語だけれども、
広く受け入れられていくかは、別問題だと考えている。

380 ：デフォルトの名無しさん：2010/09/24(金) 22:11:07

変な概念を強制しないと全く使えない言語が広まるわけがない。
そういう意味ではオブジェクト指向言語よりもかなりハードルが高い。
オブジェクト指向なら最悪擬似手続き型として使える。
VB使いがJavaに転向できるレベルにならないとな。
VB使いが今のHaskellに転向できると思うか？

381 ：デフォルトの名無しさん：2010/09/24(金) 22:21:16

Schemeあたりなら擬似手続き型として使えるけどな

382 ：デフォルトの名無しさん：2010/09/24(金) 22:23:35

>>379
>>370 とは別人？

> 世の中から求められてないなんてことはないと思う。

求められてはいるのに普及しないというのは、いささか考えにくくないか。
それなら単に世の中に求めている人が少なすぎると考える方がまだ自然なような気がするが。

それとも、求められてはいるのに普及しないと思う根拠が >>370 なのか？

別人だったらすまん

383 ：デフォルトの名無しさん：2010/09/24(金) 22:50:06

>>378
○○言語で何ができるかなんていう研究なんて、できました論文しか書けないよｗ
研究してる人はもっと広い視野で研究してるｗ
そのためにHaskellを題材に使っているだけ。

384 ：デフォルトの名無しさん：2010/09/24(金) 23:02:02

>>383
純粋関数型などの仕組みや考え方などを材料、道具として研究に使うのなら分かる。

でも研究成果を Haskell というプログラミング言語の形で発表してるのは、
>>370 から考えると何故って疑問に思わないか？

385 ：デフォルトの名無しさん：2010/09/24(金) 23:06:55

>>382

370と379と私は同じ人。

関数型言語を知った上で求めている人は、現状のとおりで、プログラマー人口でいうと比較的少人数と思う。

その他は、関数型言語を知らないか、思考方法を理解できないといった370に書いた理由で、利点を理解できないまま、求めていない人たちなどと思う。

386 ：デフォルトの名無しさん：2010/09/24(金) 23:26:15

>>385
要するに、関数型言語は手続きを考えないで
問題をより簡潔で抽象的に記述できるよい言語で、
関数型言語を知った上で求めている人たちへは普及している。

しかし >>370 の理由により、関数型言語を知らないか、
利点を理解できないまま求めていない人たちへは普及しない、
ということか？

もしそうなら、普及しない根本原因は >>370 ではなく、
今まで多くの人たちに関数型言語を教えてこなかった、
利点を理解させてこなかった事にあるのではないか。

現に、>>370 であるにもかかわらず、関数型言語を知って
利点を理解できた人間も少なからずいるのだから。

387 ：デフォルトの名無しさん：2010/09/24(金) 23:26:35

関数型言語だと計算量をイメージしにくいと考えたことは無いなぁ
Haskell のようなデフォルトが遅延評価な言語だとたしかに直感とややずれることもあるけど

388 ：デフォルトの名無しさん：2010/09/24(金) 23:29:23

Haskellの空間計算量の分かりにくさは尋常じゃない
特にスペースリークを作ってしまったときにデバッグが面倒
この一点だけでもデフォルトで遅延評価する戦略は糞

389 ：デフォルトの名無しさん：2010/09/24(金) 23:38:57

>>386

そりゃまあ、すべての人間があらゆる理論を理解して、実践できる世界なら、問題は別かもしれないけれど、
「手続きが人間の一番自然な考え方だから、関数型言語の考え方が理解されにくい」という事自体が、
普及しないことの問題点のひとつだと考えているんだから、
もしそれが現実として克服されるなら、世界は大きく代わると思うよ。

>>387
Haskellを想定して、純粋関数型言語について書いた。

390 ：デフォルトの名無しさん：2010/09/24(金) 23:47:07

純粋だからって遅延評価とは限らないけどな

391 ：デフォルトの名無しさん：2010/09/24(金) 23:49:57

>>388
というか、スペースリークを作ってしまったことに気づくのが困難な事も多い

392 ：デフォルトの名無しさん：2010/09/24(金) 23:54:15

>>389
では聞くが、あなたは何故 Haskell の利点を理解できた？
なぜ Haskell はよい言語だと気づくことができた？

393 ：デフォルトの名無しさん：2010/09/25(土) 00:07:19

>>392
Haskellに限定するつもりもないけれど、興味の方向性と考え方によるんじゃないかな。

他人と自分の考え方や能力の種類が違うように、万人にそれが適用できるわけじゃないだろうけど。

>>390
純粋で正格評価みたいに、遅延評価じゃない処理系があるなら、アイデアを教えてほしいな。Cleanとかもよく知らないし。

394 ：デフォルトの名無しさん：2010/09/25(土) 00:23:22

スペースリークって何？

395 ：デフォルトの名無しさん：2010/09/25(土) 00:44:25

>>393
>興味の方向性と考え方による

それなら、あなたが代表するように、今までは興味が向いており、かつ、
考え方に馴染む人にしか普及していなかったと考えられる。
（論理的ではないが）逆にそういう人たちには
既にある程度普及できていると考えても大きな間違いではないと思う。

しかし、そこで普及が鈍化している。

であれば、興味が向くように魅力を伝え、独特の考え方を丁寧に説明すれば、
>>370 のように難解でも、普及の歩みは止まらないのではないか？

今まで日本でそのようなことが行われていたかと言うと、
入門書の数や Web サイトの記事の内容から考えても、
とてもそうだとは思えないから、もし行われれば
むしろ普及のペースは加速するのではないかと思うのだが・・・

396 ：デフォルトの名無しさん：2010/09/25(土) 01:03:38

で、スペースリークって何？？？

397 ：デフォルトの名無しさん：2010/09/25(土) 01:25:48

>>396
Real World Haskell でも読みな

398 ：デフォルトの名無しさん：2010/09/25(土) 01:35:53

>>394
>>396

http://encyclopedia2.thefreedictionary.com/space+leak

399 ：デフォルトの名無しさん：2010/09/25(土) 02:09:19

リンクしか貼れないゴミはすっこんでろ

400 ：デフォルトの名無しさん：2010/09/25(土) 02:27:34

>>399
リンク先を読めば一目瞭然だろ
１年もしないうちに消えてしまうこのスレで
リンク先と同じ事を説明してどうする

401 ：デフォルトの名無しさん：2010/09/25(土) 02:41:54

英語がNGなら、素直に「日本語のページはねえのかよ、このボケナス！」と反応すればカワイイのにw

402 ：デフォルトの名無しさん：2010/09/25(土) 07:49:34

必ずしも良いものが普及するとは限らない。
Dennis Ritchieも、言語が普及する要因は
社会的なところが大きい、みたいなこと言ってたしな。

403 ：デフォルトの名無しさん：2010/09/25(土) 10:29:40

じゃあ社会的な努力が足りないんだな

404 ：デフォルトの名無しさん：2010/09/25(土) 11:08:59

>>401
日本語のページはねえのかよ、このボケナス！

405 ：デフォルトの名無しさん：2010/09/25(土) 13:39:48

あらカワイイ

406 ：デフォルトの名無しさん：2010/09/25(土) 13:46:38

つたない自分の業務経験から考えると
WebアプリケーションやWindows GUIアプリケーションとして開発するような業務アプリケーションでは
要件を実現するのに必要なことは文字列操作と四則演算程度です
その程度ができる言語で
「人集めしやすい」「開発環境がメジャーなところか出ている」
言語なら業務アプリケーション開発に採用される言語になれると思います

個人的な感触ですがC#普及期は
「VBやっていればC#もわかるだろう」
みたいな雰囲気があったと思います

関数型言語では「○○やっていれば関数型言語もわかるだろう」
とはなかなかならないように感じます

407 ：デフォルトの名無しさん：2010/09/25(土) 13:55:20

あとSQLの操作もです

408 ：デフォルトの名無しさん：2010/09/25(土) 14:32:55

>>404
きゅんときた
だがそんなページはねーよ、残念だったな

かいつまめば、遅延評価システムのために、
評価待ちデータがメモリ内に長く居座り
解放されないことをスペースリークと言う。
解放し忘れている訳ではない。

関数（計算）を表現するデータが居座ると、
その環境もまた同時に居座るから、やっかいだ。

ちょっとした計算順序やアルゴリズムを変えたり、
正格評価に変えるだけ簡単に改善できる場合もあるが、
考え方自体を変えなきゃ改善できない場合もある。

おまえはこれくらいの理解でガマンしていろ

409 ：デフォルトの名無しさん：2010/09/25(土) 15:07:11

手動で発火させれば済む話なんだけどね
それ副作用じゃんって言われるからね
そもそも、GCに不要なオブジェクトを破壊させるのも (手動でやったら) 副作用だし

410 ：デフォルトの名無しさん：2010/09/25(土) 16:08:13

高校数学やってればHaskellわかる……かな？

411 ：デフォルトの名無しさん：2010/09/25(土) 16:14:46

根本をどの程度まで理解出来るかは努力次第だけど、とりあえず使えるレベルにはなれると思う。

412 ：デフォルトの名無しさん：2010/09/25(土) 18:38:00

「関数型は理解できないけどSQLは使いこなせる」なんてありえるかな？
SQLも使いこなせてないんじゃない？

413 ：デフォルトの名無しさん：2010/09/25(土) 18:41:56

以下の式を計算すると、このスレの皆さんが普段から欠かさない数が出てきます。

992÷1375

この数の存在をどう思いますか？

414 ：デフォルトの名無しさん：2010/09/25(土) 18:43:23

415 ：デフォルトの名無しさん：2010/09/25(土) 18:45:03

>>412
SQLはプログラミング言語ではないよ。

416 ：デフォルトの名無しさん：2010/09/25(土) 18:46:00

>>410
やらなくても十分解るし普通に使える

実際に知人の息子（中２）は俺らが教えたら使い始めた
数学の知識は教えた覚えはない
（知らないうちに教えて他かも知れんが、少なくとも明示的には教えてない）

417 ：デフォルトの名無しさん：2010/09/25(土) 18:50:37

>>413
有理数か

418 ：デフォルトの名無しさん：2010/09/25(土) 19:19:25

>>413
無限自慰数というやつか

419 ：デフォルトの名無しさん：2010/09/25(土) 19:40:32

>>416
いや高校数学が必要条件だというつもりは全然ない
>>406の「VBやっていればC#もわかるだろう」を受けて、「高校数学やってれば」と書いただけ

420 ：デフォルトの名無しさん：2010/09/25(土) 19:51:58

Haskell の場合、むしろ他言語にあまり触れていない方が理解されやすいな。
さっきの息子も小学生の時に学校で Basic を少しやったくらいだったから、
Haskell をすんなり受け入れてもらえたし、楽しんでもらえてる。

ある問題を C/C++ だったら解決しにくいけど Haskell だとこんなら簡単だよ、
という教え方はむしろ逆効果の様な気がする。
それは C/C++ も Haskell もある程度扱い慣れて初めて理解できることだろう。

Haskell を教えるなら、「Haskell なら～できる」じゃなくて、
「プログラミングって楽しいよね」というのを Haskell を題材に伝える、
というスタンスで向わないとダメだろうな。

421 ：デフォルトの名無しさん：2010/09/25(土) 20:30:53

ちょっと視点を変える。
産業界は最終的にはコスト的に有利なものに流れていくものなので、
20年以上も経て全く使われないところをみると、コスト高の言語なの
だろう。

422 ：デフォルトの名無しさん：2010/09/25(土) 20:36:04

いかしたあの娘はエイリアン

423 ：デフォルトの名無しさん：2010/09/25(土) 20:49:06

>>406
誰もレスしてないから返すけど、この指摘には重い意味が含まれていると思う。

まず、このスレの住人達の大半は「業務アプリ開発における関数型言語の普及」なんて、考えてもいない。
Python や Ruby といったスクリプト言語は人気があるけど、業務アプリ開発では、まず使われない。
でもこのスレでは、それら言語が関数型言語に置き換わる/押しのけて普及するかには、強い関心を示す。
だから、業務アプリの話題(>>406)が華麗にスルーされている、というのが現実。次に、

>その程度ができる言語で ....

とあるけど、それは画面/帳票等の業務アプリに必須な周辺のフレームワーク/コンポーネント一式が
開発環境やサードパーティから提供されているからこそ、プログラマは「文字列操作と四則演算程度」の
ロジック設計に専念できている、と言える。言い換えると、それら環境一式を揃えた言語でなければ、
(関数型に限らず)業務アプリ開発では採用されない。まぁ、当たり前の話だよね。
しかも「メジャーなところから開発環境が出る」とくれば、もう残る解答は一つ --- F# --- しかない。
少なくとも「VB/C#やっていればF#も同じ開発環境(VisualStudio)だから楽だよね」という雰囲気になれる。

ここまできて、ようやく「VB/C#等をやっていた業務アプリプログラマはF#を使えるようになるか？」という
本題に移れる(あー疲れたw)。で、それは>>406自身が F# を触ってみてから考えればいいじゃないかと。

424 ：デフォルトの名無しさん：2010/09/25(土) 20:52:26

統合開発環境の存在はやっぱ大きいよなぁ
だからこそのJava, C#なんだし
leksah頑張れ!!

425 ：デフォルトの名無しさん：2010/09/25(土) 20:52:33

>>406
あなたの会社の業務内容はなんですか？
SIer系ですか？
だとしたら話になりませんよ。

426 ：デフォルトの名無しさん：2010/09/25(土) 20:55:04

>>423
SIer系だったらオブジェクト指向でズブの素人が一瞬で覚えられる言語ならなんでもいい。
そういう会社は技術的なイノベーションがないからそれでうまくやっていけるんだよ。

427 ：デフォルトの名無しさん：2010/09/25(土) 21:01:21

>>420
>>Haskell の場合、むしろ他言語にあまり触れていない方が理解されやすいな。

それはどの言語でも似たようなもんだ。
pythonスレやrubyスレでも「javaの○○みたいな機能はありませんか？」って質問よくある話。
(よくあるのはにjavaの静的なコードをまんまpythonやrubyのような動的言語に置き換えようとする人)

そんなんやって出来なくはないけどpython(ruby)的には別のアプローチとったほうがいいよって
フォローもあんま聞く耳持たないというか理解できないのか
しまいには「このpython(ruby)はjavaじゃない糞言語だフンガー！」って切れる奴もたまにいるし。

428 ：デフォルトの名無しさん：2010/09/25(土) 21:03:13

まともなライブラリが無いから

これ以上どんな理由があると言うのだろうか

429 ：デフォルトの名無しさん：2010/09/25(土) 21:07:18

ひとつ言えることはperl素敵

430 ：デフォルトの名無しさん：2010/09/25(土) 21:15:02

Perlはゴミだろ。

431 ：デフォルトの名無しさん：2010/09/25(土) 21:17:33

>>430
お、言ったな。
ゴミだと思うということは何らかが劣っていると思っているんだろう。
何が劣っていると思うの？

432 ：デフォルトの名無しさん：2010/09/25(土) 21:19:05

>>428
まともなライブラリとはどのようなライブラリか

まともなライブラリには備わっていて、
関数型言語のライブラリには備わっていないものは具体的に何か

433 ：デフォルトの名無しさん：2010/09/25(土) 21:21:29

Haskell(コミュニティ)にはもう一通り備わってる気がする

434 ：デフォルトの名無しさん：2010/09/25(土) 21:31:36

Perl……スクリプト言語のくせにC言語とかけ離れた言語仕様のせいで
覚えるのに手間がかかるにもかかわらず、なぜか初心者に大人気な言語Perl……

435 ：デフォルトの名無しさん：2010/09/25(土) 21:46:51

>>434
確かに覚えるのは手間だなｗ
shift or die とか書かれても最初意味分からんもんな。
orは左から順番に1が出るまで評価していって1が出たら右の値は無視するという特性を
利用しているなんて初心者はすぐに気が付かないからな。

436 ：デフォルトの名無しさん：2010/09/25(土) 21:47:43

あと省略の美学というやつも良くないと思う。

437 ：デフォルトの名無しさん：2010/09/25(土) 21:55:55

しかし言語だけ綺麗にしても、ライブラリがうまく馴染んでない感じがするとダメだな

438 ：デフォルトの名無しさん：2010/09/25(土) 22:02:07

>>424
あ、そうか、Javaは業務アプリ開発で使われてるから、Scalaも解の一つになるね。
Scala忘れてた。

>>426
オブジェクト指向をズブの素人が一瞬で覚えてコーディングできるとは、とても信じがたいんですけど。
というか「業務アプリ開発における関数型言語の普及」と>>426がどう結びつくのか、まるで見えない。

439 ：デフォルトの名無しさん：2010/09/25(土) 22:05:47

>>438
業務アプリ開発には技術的イノベーションはない。
だから今までのやり方を進歩させる必要がない。
OK?

440 ：デフォルトの名無しさん：2010/09/25(土) 22:10:12

>>439
>業務アプリ開発には技術的イノベーションはない。

えっ！？、それは>>439の所属しているSIerの話でしょうか？

441 ：デフォルトの名無しさん：2010/09/25(土) 22:10:29

>>402
コミュニティのいる*人*がキモイからなー

442 ：デフォルトの名無しさん：2010/09/25(土) 22:11:09

論文？書いてる？だけだからなぁ…

443 ：デフォルトの名無しさん：2010/09/25(土) 22:14:10

天下のオブジェクト指向でさえインピーダンス・ミスマッチに悩まされているらしい
関数型ならなおさらだ

444 ：デフォルトの名無しさん：2010/09/26(日) 01:54:30

>439　土方(・ω・｀)乙　これは乙じゃなくてポニーテールなんだからね！

445 ：デフォルトの名無しさん：2010/09/26(日) 02:00:49

おかしいな、なんでCOBOL案件なんかが高給なんだろう

446 ：デフォルトの名無しさん：2010/09/26(日) 02:07:33

>>434
Perl は
sh, awk, sed でスクリプト組んでるけど、これらじゃ不満。
C も知ってるが書き散らすには不便。
という人に便利に使えるスクリプト言語だと思う。

447 ：デフォルトの名無しさん：2010/09/26(日) 02:18:26

>>446
そう、どっちかいうとシェルスクリプトの延長なんだよな
だからこそ、それをシェルスクリプトに触ったことのない初心者に薦めるのもどうかなぁと思う

448 ：デフォルトの名無しさん：2010/09/26(日) 02:44:37

どんな時にシェルスクリプト使うの？
Perl,Python,Rubyなんかで全部すませないの？

449 ：デフォルトの名無しさん：2010/09/26(日) 02:54:17

>>447
けど、じゃあ初心者に C を薦める？ sh を薦める？ Python も Ruby も知らな
ければ、消去法で Perl でしょう。

普及の話をすると、人は今使ってるものより少し良い、けど似ているもの、に
流れ易いように思う。Perl から Ruby とか。もちろんどこが良いかは個人によっ
て違うだろうけどね。

>>448
シェルスクリプトで済むなら、シェルスクリプトで。
普段使っているシェルから思考の切り替えが必要ないので、手軽な気がする。

450 ：デフォルトの名無しさん：2010/09/26(日) 05:41:37

>>415
プログラミング言語としての要件に欠けるものがあるのかい?

451 ：デフォルトの名無しさん：2010/09/26(日) 07:38:16

>>450
プログラムを作れない。

452 ：デフォルトの名無しさん：2010/09/26(日) 10:05:29

>>451
どういうのがプログラムなんだ？

453 ：デフォルトの名無しさん：2010/09/26(日) 10:48:08

>>450
SQLはチューリング完全ではない

454 ：デフォルトの名無しさん：2010/09/26(日) 12:03:46

>452
まぁとりあえずSQLだけで帳票アプリとか作ってみれば？

455 ：デフォルトの名無しさん：2010/09/26(日) 13:15:16

>>454
嫌だよ、SQL ほとんど使ったこと無いし、
作れるかどうか検証するために学習するなんて面倒だ

それとも何か、帳票アプリとか作れるのがプログラムである必要条件なのか？

456 ：デフォルトの名無しさん：2010/09/26(日) 13:17:04

定番としてはbrainf*ckの処理系を作ることかな
一応SQLでもできるとは聞くが

457 ：デフォルトの名無しさん：2010/09/26(日) 13:38:24

>>456
ソースきぼん

458 ：デフォルトの名無しさん：2010/09/26(日) 14:15:50

>>454
>>453

459 ：デフォルトの名無しさん：2010/09/26(日) 14:28:13

チューリング完全でなければならないプログラムとは言えない、ということ？

460 ：デフォルトの名無しさん：2010/09/26(日) 14:31:34

>>459
すまん、日本語が変すぎる

チューリング完全でなければプログラムとは言えない、ということ？

461 ：デフォルトの名無しさん：2010/09/26(日) 15:16:50

SQLは再帰（ループ）書けないからなあ。

462 ：デフォルトの名無しさん：2010/09/26(日) 17:38:52

SQLがプログラミング言語だとか言ってる馬鹿を相手にする意味あるの？

463 ：デフォルトの名無しさん：2010/09/26(日) 17:41:39

ないんじゃない？

464 ：デフォルトの名無しさん：2010/09/26(日) 17:42:21

PL/SQLとかTransact-SQLとかって意味ならプログラム言語だろう。

465 ：406：2010/09/26(日) 17:50:55

>>425
私自身は小さい人売り会社を何社か転々としました
業務内容をざっくり言うと
物流系、金融系で
1つの現場でメンテと称して何年かやり
手を汚す側の人間として、調査、バグ対応、小さい機能追加、修正、大きな開発のメンバに参加と
とやってます

>>423
完璧な説明をありがとうございます
F#に関してはCodeZineの記事を少し読んだ程度の理解しかありません
その上で印象を言うと
(pros)
説明にもある通り、MSや3rd Partyのフレームワーク/コンポーネント一式が使えるのは非常に有利
MSのIDEでサポートされたことも非常に有利

(cons)
C系やVB系と比べてF#の文法に違和感が大きいのではと思う

例えばC#で「@""」やラムダ式なんかを書いて
自分では大したことないつもりで書いてても、ギョッとされることがある
その様な感覚からするとF#の文法は、何かの延長線上から想像できるものではなく
カルチャーショックなんではないしょうか

466 ：デフォルトの名無しさん：2010/09/26(日) 17:51:11

コンピュータに動作を指示するための人工言語という素朴な定義に従うなら、
SQL はプログラミング言語ではないな。

動作を指示している対象が「コンピュータ（計算機）」ではないから。

467 ：406：2010/09/26(日) 18:11:59

なんとなく「学歴うんぬん」と「でも社会ではなあ」みたいな気がしてきました

468 ：デフォルトの名無しさん：2010/09/26(日) 18:19:59

ぎょっとするかどうかなんて、そんなに大きくないと思うけどな
C系言語しか使ってこなかった人からすればシェルスクリプトやPerlもぎょっとすると思うぞ(逆もまたしかり)
使うと便利だとコンセンサスが成立しさえすれば、そこまででもないんじゃ

469 ：デフォルトの名無しさん：2010/09/26(日) 19:10:57

>>461
いまどきなに言ってるんだ？
sql 再帰あたりでぐぐって見てから言ってくれ。

470 ：デフォルトの名無しさん：2010/09/27(月) 00:06:24

世の中的にはプログラムなんかしないで人生を終わる人の方がどうみても多いような気がする件
そして、そっちのほうが幸せな人生を送れてるのではないかという気がする件

471 ：デフォルトの名無しさん：2010/09/27(月) 00:33:51

そんなけんけんいうなや

472 ：デフォルトの名無しさん：2010/09/27(月) 01:10:24

> 413 名前：デフォルトの名無しさん[sage] 投稿日：2010/09/25(土) 18:41:56
> 以下の式を計算すると、このスレの皆さんが普段から欠かさない数が出てきます。
>
> 992÷1375
>
> この数の存在をどう思いますか？

一見すごいように見えるが、
ただ単に、0.721454545････という
循環小数を語呂合わせで作って分数に直しただけ。
語呂合わせで作ったすべての循環小数は分数に直せる。

循環小数を分数になおす方法はここなんかを参考にして。
http://homepage1.nifty.com/ishituka/math/heihokon/junkan/junkan.htm

473 ：デフォルトの名無しさん：2010/09/27(月) 15:50:31

関数型言語じゃなくてラフなマルチパラダイム言語のperlが一番いいと思う。

474 ：デフォルトの名無しさん：2010/09/27(月) 18:20:16

>>465
周囲の目を気にしすぎ(自意識過剰？)のように見える。(ぎょっとしたり、ショックを
受けるといった人達という)下を見るよりも、もっと上を見ると気が楽になるよ。
まずは、自身が関数型言語に慣れること、一通り使いこなせるようになることに集中しよう。

で、そんな人達に対して、「相手にわかる言葉で」分かり易く説明できるようになれば、
関数型言語について、ある程度のレベル(境地)に到達できたと判断できるだろう。
自分では(=頭の中では)分かったつもりになっていても、他人に(自分の言葉で)説明できないのは、
実は理解が中途半端だから。人に(分かり易く)教えることは、自身の成長の為でもあったりする。
（このスレの>>186-203で F# に関するQ&Aがあったから、参考になるかもしれない。）
そんないきなり無茶な！と思うかもしれないけど、それは自分のペースで学習すればいい。
（孤独な学習については、このスレの>>232-235が参考になるかもしれない。)

475 ：デフォルトの名無しさん：2010/09/27(月) 19:49:59

>>467
>なんとなく「学歴うんぬん」と「でも社会ではなあ」みたいな気がしてきました

「学校の勉強は大変よくできていたはずけど、社会に出てみると役に立たない人」みたいな....。
このスレであれば、>>254,256 のように、せっかく難しい関数型言語の理論について知識があるのに、
「人試し」や「攻撃(暴力)の武器(？)」といった発想でしか、その知識の使い道を見い出せない人達を憶い出した。

まぁ、そんな他人の事は置いといて、自身が学習した関数型言語に関する知識を日常業務の中で活かせないか、
言い換えると「日常業務の中で【関数型脳】をどう活用するか」について考えよう。前を向いたほうが気が楽になる。
たとえば、業務アプリの受注伝票入力画面や月次売上集計出力帳票をじっくり見て、
それらの論理的な構造を関数型言語の代数的データ構造である
・直積(direct product) -- 組合せ関係にある要素、[例] <受注区分> * <受注日> * <受注明細一覧>：<受注伝票>
・直和(direct sum) -- 排他関係にある要素、[例] "新規注文" | "再注文" | "注文取消"：<受注区分>
・列(sequence) -- 同一種類の要素の集まり、[例] seq_of <受注明細>：<受注明細一覧>
という三種類のデータ型で表現してみよう。(上の例の中で、<XXXX> はデータ型を意味している)
表現できたら、そのコードが正しく(エラー無しに)処理系で読み込めるか確認しよう。(実行はまだまだ先の話だよ)
これら入力画面や出力帳票は、GUI開発におけるModel-View-ControllerアーキテクチャのViewに対応するよね。

これが「関数指向設計技法」の最初の一歩になる。実は、関数型言語に適した(OOPではOMT/UMLに相当する)
設計技法については、このスレでもたびたび話題になっているんだけど、汎用的な(=万能な)設計技法は難しい、
でも、対象領域を(設計ロジックの比較的単純な)「業務アプリ開発」に限定すれば、(OOD以前の古典である)
データフロー図、代数的データ構造図(=ジャクソン構造図)、関数階層図(=機能階層図)、状態遷移図を
わずかに修正することで、対応できるんじゃないかと妄想していたりする。

476 ：デフォルトの名無しさん：2010/09/27(月) 20:23:27

ある人の言葉(1974年)を引用

　実際的な仕事と理論的な仕事を別々にするのは不自然だし、有害であるというのが、
　ずっと以前からの私の考え方である。ソフトウェアの設計にしろハードウェアの設計にしろ、
　コンピュータの分野でなされてきた実際的な仕事のほとんどは、あやしげで見苦しい。
　なぜならそれを行った人間は、自分の仕事の基礎となっている基本的な原理について、
　なんら理解していないからである。抽象数学や理論数学の仕事の多くは役に立たない。
　なぜならそれは実際のコンピュータの分野となんの接点も持たないからである。

477 ：デフォルトの名無しさん：2010/09/27(月) 20:48:15

ブール代数なしに計算機を設計できたら認めてもいいと思うよその発言。

てか、誰の言葉？

478 ：デフォルトの名無しさん：2010/09/27(月) 20:56:26

>>475
前半は余計だと思う。

後半、かなり興味あるからちょっと質問したい。

これは関数指向設計技法の話なんだよね。
関数型言語を用いてプログラムする前の段階、設計の段階の話だよね。

直積や直和、列の話は分かった。
受注伝票入力画面などで使いたいとリストアップした「データ」を
それら３のカテゴリで分けて表現するように考える。
ここまでは言いたいことは解ったが、その後が解らない。

> そのコードが正しく(エラー無しに)処理系で読み込めるか確認しよう。

これは具体的にはどういうことなんだ。
プログラム前の設計の話ではないのか。
たとえば「エラーが出て正しく読み込めなかった」というのは、
この関数指向設計技法の話ではどういった設計ミスによるものなんだ。

まだいくつか疑問点があるが、
残りは詳しく話を聞いて考えてから質問することにする。

479 ：476：2010/09/27(月) 20:58:32

>>477
http://en.wikipedia.org/wiki/Christopher_Strachey

480 ：デフォルトの名無しさん：2010/09/27(月) 21:20:35

何でも屋がいないわけじゃないが
分類できないし、どこにも所属しないし、特徴がない
だから統計の対象にならない

481 ：475：2010/09/27(月) 21:31:36

>>478
>前半は余計だと思う。

かもしれない。無視してくれ。

>これは関数指向設計技法の話なんだよね。
>関数型言語を用いてプログラムする前の段階、設計の段階の話だよね。

そう、設計段階の話。要求分析よりも後工程だけど、詳細設計よりも前の(中盤の)設計工程。

>> そのコードが正しく(エラー無しに)処理系で読み込めるか確認しよう。
>これは具体的にはどういうことなんだ。

入力画面や出力帳票に表れる用語と、それら用語の論理的な構造(関連)は、システムをblack-boxとして見た
外部仕様、あるいは機能仕様(の一部)に相当する。この様な外部仕様というのは、開発の現場では、Word/Excel/Visioなどで
作成した文書のレビュー＆手直しを繰り返すことで設計を進めるのが一般的。けれども、その設計課程で生じた
「仕様の誤り/矛盾/曖昧さ/欠落」といった要素は自然語とお絵描き図に埋もれてしまい、明白なミスは指摘できても、

・外部仕様について、少なくとも(構造的な、あるいは構文/文法的(syntax)な)エラーは存在していない

ことまでは証明できない。(意味的(semantic)なエラーについては、ここでは考えない。難しいから.....)
これを解決するため、自分はこれまで yacc(bison) や racc といったパーザジェネレータによる構文検査(syntax cheking)を
試行してきたが、この

・外部仕様の構文検査に、代数的データ型に関する強力な型検査/型推論機能が適用できるのではないか

と考えている。特に、これまでのパーザでは「データ型」という概念では検査不可だったのが、可能になる点に期待している。

482 ：デフォルトの名無しさん：2010/09/27(月) 21:41:38

VDM-SLみたいな方向に行こうとしている？
それともCafeOBJみたいな代数仕様をめざしてる？

483 ：478：2010/09/27(月) 21:46:17

>>481
曖昧な点をはっきりさせておきたい。
これまでのパーザではデータ型という概念では検査不可だったのが、
「＊＊＊」の活用・運用によってデータ型という概念で検査可能になることを期待している。

この＊＊＊に入る言葉は、関数指向設計技法なのか。
それとも Haskell の Parsec などの具体的なパーザジェネレータなのか。

484 ：475：2010/09/27(月) 22:02:52

>>482
いいえ。Z/VDM/OBJといった、いわゆる形式的仕様記述(formal description)への発展は考えていません。
この関数型設計技法の指導者が、それら形式的手法を身につけていることは望ましいことですし、
おそらく指導者は(頭の中では)数式という形式的なイメージを持っていることでしょう。
ただし、そのイメージを、開発の現場にいる「普通の(あるいは、庶民的な)」プログラマへ直接的に語っても
理解してはもらえません。ですから、そんな「普通のプログラマにも分かる言葉で説明する」必要があります。
（>>474を参照。）その言葉というのが、>>475の最終段落に書いた「古典的な構造設計図群」です。

485 ：475：2010/09/27(月) 22:12:07

>>483
＊＊＊に入る言葉は、ズバリ「関数型言語の処理系」です。言語としては、代数的データ型と静的型検査/型推論機能を
備えていれば(SML/F#/Haskell/SCala ...etc)どれでもかまいません。特定の言語には依存しません。
ですから、>>475の[例]に書いた言語は、架空の仕様記述言語です。（たとえば字句やシンボルに日本語を許しています。）

「これまで yacc を使っていたのを、(たとえば) ghic の活用によって．．．」という意味になります。

486 ：デフォルトの名無しさん：2010/09/27(月) 22:14:57

pascalでも十分かと

487 ：478：2010/09/27(月) 22:25:04

>>485
直積や直和などで表現したデータ間の関係を
直接プログラミング言語のソースに記述する。
それを処理系（コンパイラなど）に読み取らせる。
その結果、エラーが出なければ正しく分類できたと言える。
エラーが出れば、正しく分類できなかったと言える。

こういうことなのか。

488 ：475：2010/09/27(月) 22:44:15

>>487
おおよそ、その通りです。与えられた要求仕様に対して、仕様の実装漏れは存在するかもしれないけど、
・仕様の不一致 ==> データ型エラー
・仕様の不足 ==> 未定義エラー
・構造の誤り ==> 文法エラー
については、(処理系を通過したことで、)ミスは存在しない、と言える。

ということです。たったこれだけでも、従来のワープロ＆作図ツールと目視確認に頼った現状の設計技法よりも、
ソフトウェア品質向上が期待できると思いませんか？

489 ：475：2010/09/27(月) 23:05:22

>>486
>pascalでも十分かと

Pascalって「タグ付き共用体」を定義できましたっけ？
これが無いと(あるいはこれに相当するものが無いと)、直和の実装が厳しくなります。
もしAdaであれば、直和を素直に表現できます。

プログラミング言語以外のデータ定義言語であれば、ASN.1、あるいはXDR(External Data Representation)でも可能。
もちろん、XMLスキーマ系の言語でも無問題です。

このように、データ型検査「だけ」なら静的関数型言語でなくとも、いくつかの選択肢があります。

490 ：478：2010/09/27(月) 23:05:39

>>488
それができれば凄いと思う。
ソフトウェア品質向上に繋がるかどうかは、私はまだわからない。
というのも、その手の便利なツールが既にありそうな気がするから。
（わざわざ関数型脳にならなくても、関数型脳の人と同じ仕事がこなせるツール）

ところで、それを実現するにあたって代数的データ型が必要なのはわかる。
コンパイル時に検査するから、静的型検査機能が必要なのもわかる。

しかし型推論機能はどこで必要になる？
これが必要になるシーンがいまひとつ思い浮かばない。
なので、なぜ関数型言語が有利なのかがまだわからない。

491 ：475：2010/09/28(火) 00:20:22

>>490
>しかし型推論機能はどこで必要になる？
>これが必要になるシーンがいまひとつ思い浮かばない。
>なので、なぜ関数型言語が有利なのかがまだわからない。

その部分については、まだ説明していませんでしたからね。
以下で、関数指向設計技法の第二歩(>>475の続き)を解説します。

>>475では、入力画面や出力帳票といったMVCアーキテクチャのViewの論理的な構造を
代数的データ型で記述しました。次に、この論理構造を元にしてModelを定義します。
この部分は、既存の設計技法を流用しましょう。たとえばModelがEntity-Relationshipを
ベースとしているなら、リレーショナル論理/代数の正規化技法(第n正規化)、あるいは
T字型E-R設計技法が、Object-RelationshipをベースとしているならOO設計技法です。

ポイントは、最終的なModelが提供するサービス仕様である
・Create - 生成(INSERT), Read - 読み出し(SELECT), Update - 更新(UPDATE), Delete - 削除(DELETE)、
という、いわゆる
・CRUD操作の論理的な構造について、代数的データ型を入出力とする関数で定義する
事です。たとえば、以下は「当月の全店における受注レコードの検索処理」というRead系関数の
データ型である<全店受注レコード一覧>定義の一例です。

　set_of <全店受注レコード>：<全店受注レコード一覧>;;
　<支店区分> * <受注日> * <受注金額>：<全店受注レコード>;;
　"札幌支店" | "東京本社" | "名古屋支社" | "関西支社" | "広島支店" | "福岡支店"：<支店区分>;;
　Date：<受注日>;;
　Integer：<受注金額>;;

（長いので以下へ続く）

492 ：デフォルトの名無しさん：2010/09/28(火) 00:32:22

ipadが普及しない
*BSDが普及しない
関数型言語が.....

493 ：デフォルトの名無しさん：2010/09/28(火) 00:34:18

>>440
SIerの業務アプリ開発から生まれたイノベーションって何だ？
研究所とかでなく。

494 ：デフォルトの名無しさん：2010/09/28(火) 00:36:07

型推論の役目は型のミスマッチによるエラーを防止することだろ

495 ：デフォルトの名無しさん：2010/09/28(火) 00:38:16

wikipediaぐらい見てから質問しろよ・・・
匿名とはいえ2chよりもwikipediaのほうがまだ信頼度高いんだからさ。

496 ：475：2010/09/28(火) 01:03:18

（>>491の続き）

また、<月次売上集計出力帳票>というViewについては、>>475で既に定義していました(...と仮定します)。
だとすれば、「全店の月次売上集計出力帳票の印刷処理」は、以下の関数型として定義できるはずです。

　<全店受注レコード一覧>　->　<月次売上集計出力帳票>：<全店の月次売上集計出力帳票の印刷処理>;;

この関数は、代数的データ型から代数的データ型への写像(map)にすぎませんから、
関数型プログラミングに慣れた人であれば、必要な副関数に分解するなりして、容易に定義できるでしょう。
ただし、それを単純なプログラムコードとして提示したのでは【関数脳】に慣れていない
「普通のプログラマ」にとって(コードが)魔術書にしか見えない可能性があります。このショックを和らげる為、
情報処理技術者試験で馴染みのある古典的設計技法である、JSP法（Jackson Structured Programming,
通称「ジャクソン法」）を用いて「関数の入出力データと関数自身の論理的な構造」を視覚的に提示します。
JSP法については、以下を参照してください。(日本語の良い解説サイトがあれば、どなたか紹介してやって下さいませ。)

　http://en.wikipedia.org/wiki/Jackson_Structured_Programming

(まだ続く。次で終了の予定。)

497 ：475：2010/09/28(火) 01:04:29

（>>496の続き）

ここでのポイントは２つです。
（１）関数の入出力データについて、JSP法の4要素を代数的データ型の3要素(直積/直和/列)+基底型に対応づけて説明する。
　　　具体的な対応関係を以下に示します。
・[JSP] 基礎　-->　[関数指向] 基底型 -- Integer, Float, Boolean, String, Date, Time等
・[JSP] 逐次　-->　[関数指向] 直積 -- タプル(組)、レコード
・[JSP] 選択　-->　[関数指向] 直和 -- 列挙、タグ付き共用体
・[JSP] 反復　-->　[関数指向] 列 -- リスト
（２）副関数群への分解手順(アルゴリズム)について、JSP法の考え方に沿って(JSP法を模倣して、あるいは
　　　JSP法の用語を使って)、指導者が普通のプログラマへ説明する。

(2)については、いくらか曖昧な表現になっています。これは、現実の業務アプリに含まれる定型的な処理パターンを整理し、
それぞれについて(関数型プログラミングとして)最適な分解手順を検討し、カタログ化する必要があるからです。

MVCアーキテクチャについて、最後にContorollerが残りましたが、(もう眠いので)今晩はこれで終わりにします。

498 ：デフォルトの名無しさん：2010/09/28(火) 01:35:08

>>439
> 業務アプリ開発には技術的イノベーションはない。
と
>だから今までのやり方を進歩させる必要がない。

が繋がってないよ。

仮に「業務アプリ開発から生まれるイノベーションがない」のが正しいとしても、
他の研究や開発などから生まれたイノベーションを使ってやり方を進歩させないと
競合他社に勝てないもん。

ま、そんな話は置いといて、とりあえず >>475 の話は興味深い。
続きが楽しみ。

499 ：デフォルトの名無しさん：2010/09/28(火) 01:39:51

>>496
このあたりはPrologでやれば、それまでではないか?

500 ：478：2010/09/28(火) 07:31:45

>>491
>>496
>>497

型推論機能がどこで使われるかと質問したが、まだ答えてもらっていない。
最後に残った Controller で使うのだろうか。

設計をミスったときに、そのことを型推論機能によって発見するのが、
型推論機能付き関数型言語を使う目的なんだよね。

ある設計をしようとして、本来はＡと設計するはずが、
Ｂと設計してしまったために、プログラムのＸの部分において
型推論によってＹというエラーが発生した。

具体的でごく簡単な実例を使ってこのように示してくれないか。

501 ：デフォルトの名無しさん：2010/09/28(火) 08:35:44

型推論は、明示的に型を記述しなくても整合性が取れているかをチェックしてくれる機能であって、
"型推論によってＹというエラーが発生した。"とはならんでしょ。

むしろ型を記述しないことで、より抽象的に記述することを可能にさせる機能。もちろん型推論での記述者はその型について念頭におくことが必要になるけれど.

502 ：デフォルトの名無しさん：2010/09/28(火) 08:36:34

>>476 ストレイチーの言葉ということはありがとう。で、出典は？

503 ：478：2010/09/28(火) 12:54:28

>>501
もし型推論機能がそれだけのことしかしないのであれば、
型シグネチャを明示すれば型推論機能は全く不要となる。

しかし、型を明示せず >>475 の様な考え方をソースコードに落とし込むことが想像できない。

>>475 のようにデータ間の関係を直積などで表現するように思考し、
その正しさをコンパイラで検査するためにソースコードに落とし込む者が、
型シグネチャを省略なんてするだろうか。
そのようなソースコードは嬉しいことにドキュメントの役割も果たしているため、
むしろ型シグネチャは注意深く明記すると思うのだが。

なので型推論機能の出る幕がないように思える。
少なくとも >>488 のエラーを検出するのに型推論機能は要らない。

しかし、>>475 は必要だと言っている。
であれば、当然仕様に関する何かのエラーを検出するためだろう。

504 ：デフォルトの名無しさん：2010/09/28(火) 13:24:47

推論で特定した型で許されない操作が含まれてたらエラーになるでしょ
動的型だと実行時エラーになる場面でも、
型推論を持つ性敵方ではコンパイル、あるいは実行前にはじける

505 ：デフォルトの名無しさん：2010/09/28(火) 13:46:22

>503
型シグネチャの明示を避けるために（も）型推論は使われるのに、明示すれば型推論はいらないってどんだけ(´・ω・｀)
型推論はそれをもって何か機能を与えるものではなく、省力化の一手段。
その副作用としてより抽象的な記述ができるというもの。この辺は好みあると思うが、自分は好み。

506 ：デフォルトの名無しさん：2010/09/28(火) 14:22:51

明示しても、エラーの検出のために型推論はする必要があるし、
原理的に型推論できないから明示が必要な場合もあるし、
なんか話が変に飛んでないか？

507 ：デフォルトの名無しさん：2010/09/28(火) 14:25:40

>>498
> 他の研究や開発などから生まれたイノベーションを使ってやり方を進歩させないと
> 競合他社に勝てないもん。

それは進歩ではなく追従

508 ：デフォルトの名無しさん：2010/09/28(火) 14:29:00

>>503
> 型シグネチャを明示すれば
それをし忘れるのが人間でしょが

509 ：デフォルトの名無しさん：2010/09/28(火) 14:36:05

もっと正確に言えば、まちがった型シグネチャを"明示"しちゃうんだよねぇ。
C言語だとChar型なのに変換なしに四則演算できちゃったり、
そういう人間によるおかしな操作をしちゃって、なまじコンパイルが通るから
どこで間違いが発生しているのかバグ追跡が極めて難しくなってくる。
（最近のコンパイラなら少しは賢くなっているが理論的な保証は何も無い）
型推論をすればそういうバグが理論的になくなる。
強い静的型付きの言語なら型推論可能だということが理論的に保証されているから、
Cなどのコンパイラよりずっと賢く型推論できる。

510 ：デフォルトの名無しさん：2010/09/28(火) 14:39:05

そもそも副作用があると型理論による保証がなくなるから、純粋関数型言語でないと
型推論の理論的保証はないんだけどね。

511 ：デフォルトの名無しさん：2010/09/28(火) 14:42:15

>>510みたいな勘違い君の声がでかいからふきゅーしないのは判った

512 ：デフォルトの名無しさん：2010/09/28(火) 14:43:21

>>511
俺勘違いしてる？
ごめん、正しい知識を教えてください。

513 ：デフォルトの名無しさん：2010/09/28(火) 14:45:28

wikipedia見てきたけど、これおかしいよねｗ
> 型推論（かたすいろん）とはプログラミング言語の機能の1つで、
> 静的な型付けを持つ言語において、変数や関数の型を宣言しなくても
> それを導くのに使われた関数の型シグネチャなどから自動的に型を決定する機構のこと。
> 主に関数型言語で用いられる。

型推論は補完機能とはちがうんだぞっと。

514 ：デフォルトの名無しさん：2010/09/28(火) 14:46:45

型推論と型検査を混同してる奴がいるな

515 ：デフォルトの名無しさん：2010/09/28(火) 14:48:50

>>513
どこもおかしくないように見える

516 ：デフォルトの名無しさん：2010/09/28(火) 14:50:14

俺が勘違いしていました。すみませんでした。

517 ：デフォルトの名無しさん：2010/09/28(火) 14:50:56

でも型推論なんて型検査のオマケでしょ

518 ：デフォルトの名無しさん：2010/09/28(火) 15:16:47

>>512
OCamlにもF#にも型推論はある。後は分かるな

519 ：478：2010/09/28(火) 18:31:05

>>509
> もっと正確に言えば、まちがった型シグネチャを"明示"しちゃうんだよねぇ。

一般的な場合のそれはよくわかるし、私もよく間違ったりする。

しかし、>>475 の様に関数指向設計技法に基づいて必要なデータ間の関係を直積などで考え、
それを関数型言語のソースコードに落とすという状況を考えた場合、
「間違った型シグネチャを明示したことによって発生するコンパイルエラー」
というのは、たんなるコードの記述ミスであって「設計ミス」ではないと思う。

それとも、やはりこれでも「設計ミス」が検出できるのだろうか。

あと私は >>501 を受けた >>503 で
「もし型推論機能がそれだけのことしかしないのであれば」と断りを入れた。
それだけのことというのは、

> 型推論は、明示的に型を記述しなくても整合性が取れているかをチェックしてくれる機能

の事。

520 ：デフォルトの名無しさん：2010/09/28(火) 18:55:58

しかしHaskellでプログラミングしていると小さい関数を大量に作るから、
いちいち型を記述するのは面倒くさいぞ。
関数の中のwhere節で関数を作るときなんか型をいちいち書いていたら見苦しくて仕方ない。
無名関数でも型推論を信じていちいち型宣言はしない。
分かりきったことを自動化するのはコンパイラの役目だと思う。

521 ：デフォルトの名無しさん：2010/09/28(火) 19:26:38

>>520
型シグネチャから書く癖がついてるから、全然面倒に思わん。

ある計算をしたいと思った時、全体の計算をするには
どのような部分的な計算をする関数が必要かを考える。
次にそれらの関数の型シグネチャを記述して、
計算を完成させるパイプラインの外観を考える。
それから初めて各関数の中身を考えて記述する。

自動化も何も、考える順番として型シグネチャが先に来るから、
「いちいち」型宣言をするという感じはないな。

522 ：デフォルトの名無しさん：2010/09/28(火) 19:48:01

予想ではIOじゃないと思ったけど、実はIOだった
いつも同じものを返す関数 a -> b だと思ったけど
実は毎回微妙に違うものを返さないといけなかった a -> IO b

523 ：デフォルトの名無しさん：2010/09/28(火) 19:48:23

>>521
無名関数の型シグネチャも先に書くの？

524 ：デフォルトの名無しさん：2010/09/28(火) 20:19:21

>>521
型宣言をめんどくさくないと感じているだけで、型推論の恩恵は受けてるんでしょ。

525 ：デフォルトの名無しさん：2010/09/28(火) 20:32:04

>>523
無名関数の型シグネチャなんかソースに書けないよ
少なくとも俺が普段使ってる Haskell では書けない
書ける言語も知らない

Haskell の無名関数は map とかの高階関数の引数で使うんだよ
関数同士のパイプラインを考える一環で型シグネチャを考えるんだから、
map に入れる無名関数を考える時点で既に map の型シグネチャが出来上がってるよ

>>524
そりゃ受けてるよ、当たり前だ
それが Haskell のいいところなんだし

526 ：デフォルトの名無しさん：2010/09/28(火) 20:32:25

右辺が不定な何かでなければそれを受ける左辺は確定するっていう・・・
こんなんじゃだめなんかいね？？

527 ：デフォルトの名無しさん：2010/09/28(火) 20:37:07

>>525
(\x->x+1) :: Int -> Int
無名関数の型シグネチャってこういうのを想定してた

528 ：デフォルトの名無しさん：2010/09/28(火) 20:40:18

>>527
そんなの書いたことない

529 ：デフォルトの名無しさん：2010/09/28(火) 20:44:33

Maybeかと思ったらEitherだった

530 ：デフォルトの名無しさん：2010/09/28(火) 21:10:31

>>528
\ (x :: Int) -> x + 1
と書くこともできるぞ

531 ：デフォルトの名無しさん：2010/09/28(火) 21:11:57

>>525
main :: IO ()
という型シグネチャが出来上がってるよ。

532 ：デフォルトの名無しさん：2010/09/28(火) 21:15:45

>>530
それは書けることは知ってるけど、書かないな

>>527 のように書けることは今日初めて知った
でも今後も書くことはないだろうなぁ
少なくとも今の俺のやり方を続けていれば書くことはない

533 ：デフォルトの名無しさん：2010/09/28(火) 21:18:08

>>531
俺の発言の何に対するレスなのか全くわからん
反論なのか同意なのかもわからん

たのむ、詳しく解説してくれ

534 ：デフォルトの名無しさん：2010/09/28(火) 21:21:19

scoped type variablesはquickcheck使うときにべんり
あとwhere節の中の定義でトップレベルの定義内で使われてる型変数を参照したり
こんなもん使うことないだろうと思ってたが、他人の書いたコードを解析する為の実験用の書き捨てコードなどで
山程使ってた、不思議!!

535 ：475：2010/09/28(火) 21:43:52

>>475です。関数指向設計技法のアイデアについて、昨晩の続きをカキコしようと思ったら、
なんともタイミングが悪く、DION恒例のアクセス規制が始まってしまいました。........orz
（このカキコは、カキコ代行人さんに依頼してもらっています）
個人的にはカキコするならするで、怒濤のカキコをしたく。
あまり代行人さん達に迷惑をかけたくないので、規制が解除されるまでROMに落ちます。最後に、

>>526-534
Haskellには専用の隔離スレがあるから、固有の議論をしたかったら、そこへ逝ケ！！ウザイよ

536 ：デフォルトの名無しさん：2010/09/28(火) 21:46:04

>>475
いつも一言多い奴だな。お前こそウザイぞ。

537 ：デフォルトの名無しさん：2010/09/28(火) 21:49:26

>>535を隔離したほうが遥かによさそうだ

538 ：デフォルトの名無しさん：2010/09/28(火) 21:50:34

>>535
だよな、ここは関数型言語は何故普及しないのか、
その理由を考えるスレのはずだよな

普及の方法や設計方法を考えたりする場でもなかったな

539 ：デフォルトの名無しさん：2010/09/28(火) 23:03:13

rLeft :: a -> Either b (Either a c)
rLeft = Right . Left

rrLeft :: a -> Either b (Either c (Either a d))
rrLeft = Right . Right . Left

まさかこんなコードの保証人になった理論家はいないよな?

540 ：デフォルトの名無しさん：2010/09/28(火) 23:19:08

Rightを男
Leftを女にすべき

541 ：デフォルトの名無しさん：2010/09/28(火) 23:56:41

Haskellには多相ヴァリアントがない
そんなふうに考えていた時期が

542 ：デフォルトの名無しさん：2010/09/29(水) 02:31:20

>>538
Haskell屋が語ったインタビューが『言語設計者たちが考えること』に載ってる
これが正しいかはともかく、彼らがどう考えているかという参考にはなる
まあ一部だけ転載

―― 関数型プログラミング言語が主流になっていないのは、なぜだと思いますか？
Simon Peyton Jones: マーケティングが下手だからでしょう！
これはプロパガンダという意味ではありません。そういった取り組みは今まで十分やってきました。
マーケティングとは、対象となるニッチ市場を注意深く選択した後、
そのニッチ市場に関数型プログラミングを訴えかけるための最も効果的な手段を適用し、
確固たる地位を築いていくということです。

古き良き80年代には、我々は関数型プログラミングがあらゆることに向いていると考えていました。
しかし、この新テクノロジを「あらゆることに向いている」と称することは、「特に向いているものは何もない」
と称することと同じだったのです。（後略）

Paul Hudak: 私は、関数型プログラミングが、いわゆる従来のプログラミングとは大きく違うからだと考えています。
これにより受け入れられにくく、習得しづらく、サポート（ライブラリや実装など）も難しいものと
なってしまうのでしょう。

543 ：デフォルトの名無しさん：2010/09/29(水) 20:10:03

個人的には、他の言語と同じ土俵で戦うことを前提にしすぎていると思うんだよね。
基礎的な理論があるというのはやっぱり強みであるわけで、ただ、その理論の適用
範囲を無意識にプログラムに限定してしまっているというのがまずいと思うんだ。

なんというか、例えば、型の理論をプログラム以外に適用することはできない。＝＞真
が暗黙に承認されている気がする。

544 ：デフォルトの名無しさん：2010/09/29(水) 20:17:52

いやプログラム言語なんだからプログラムで戦うんだろ
他の分野への応用ならそういう言語を作ればいいけど、
それはいわゆる関数型言語とは別のものになるんじゃね

545 ：デフォルトの名無しさん：2010/09/29(水) 20:47:25

関数型言語が真価を発揮するのはIsabelle/HOL系統の自動証明器やモデル検査器の流れを組む開発支援環境が整ってからだろう
今のままでは関数型言語の要素もかじった手続き型OOPL with IDEの土俵に立った時点で負け
これから先さらに複雑になって人間の頭だけじゃ到底扱えないような複雑、精密なシステムが出てくれば
自と先に挙げた流儀は主流になってくる筈
それにはまだまだ研究によって解決されるべき問題があるからまぁ果報は寝て待てというか、
これから先も変わらないような土台となる部分からさらっていくべきとかいろいろ

546 ：デフォルトの名無しさん：2010/09/29(水) 21:10:01

>>544
これは関数型言語的だ！と判断する要素だけ抽出して（難しいけど）移し替えれば
多分プログラムに限定する必要はないと思う。
別にすべての関数型言語好きが、"プログラムである"＆"それは関数型的"で
あることを要求しているとは限らないよ。”プログラムである”という部分を
抜いてしまって、別のものに置き換えてしまっても案外満足してしまうかもしれない。

>>545
大きく強固な土台があった上の一分野としてはありかもしれないけれど、
それだけで戦うのはきつすぎるだろ。自分で高い山の頂上だと思っている
ところだけを地上に持ってきてもそれは高い山の頂上だとは一般的に思われない。
545自身それが至高だと思うのは対比するべき部分あってのことじゃない？

547 ：475：2010/09/29(水) 22:06:53

冷静に考えてみると>>538の言う事はもっともなので、>>497の続きは中止します。
ただ、いくつか質問をもらっているので、それらだけレスして、今度こそ最後とします。

>>499
Prologの型検査は動的ですので、この「静的型検査を活用した設計支援」という目的には適しません。
なお、「型付き論理型言語」については、もし機会があればPrologスレに新ネタを投入するつもりです。
>>500
型推論の有効性は関数定義における記述の省力化もありますが、(map/filter/fold等に代表される)
パラメタ多相による高階総称関数を「安全に記述できる」事が最大の利点だと考えています。
>>502
「IEEEソフトウェア’88 岩波書店(1988年), 絶版」という書籍(論文集)に収録されている論文
「プログラミング - 魔術か科学か？ C.A.R. ホーア」(原題 Programing: Sorcery or Science?)で引用されている一節です。
>>519
たとえ話として、Wordを使って自然語で書いた仕様書にスペルミスがあり、これの見落としが原因で重大な障害(バグ)が
発生したとします。この場合、このスペルミスは単なる「記述ミス」でしょうか、それとも「設計ミス」でしょうか？

548 ：デフォルトの名無しさん：2010/09/29(水) 22:50:02

関数型言語を好む人は関数型プログラミングを行っている際に
”関数型的な思考プロセス”でプログラムを組んでいる、と言われる。
（これはある程度承認される言明のはず）

次に、関数型を押す人の内なるモチベーション、というか欲求としては
プログラミング自体よりも実のところその”関数的な思考プロセス”
というところに重きを置いていると個人的考えとして思う。

というわけで、>>546の補足として、関数型的な人は実は”関数的な思考プロセス”
を取ることができる対象であれば、別にプログラムでなくても充分満足できるのでは
ないか、と思うんだ。

もし、実用性がないおもちゃみたいなものだ、という疑念が根深くあるならば、
逆に、本当に子供向けおもちゃにしてしまうという手もあると思う。
世界的に売れる余地があって、実際売ることができれば、それはそれでひとつの勝利
だと思うし。子供に刷り込みを行って拡大するという古典的な手が使える。

549 ：478：2010/09/29(水) 23:02:55

>>547
> 型推論の有効性は関数定義における記述の省力化もありますが、(map/filter/fold等に代表される)
> パラメタ多相による高階総称関数を「安全に記述できる」事が最大の利点だと考えています。

だから、そのパラメタ多相を使って設計をコードに落とし込んだ例を
私は一度も見せてもらっていないし、解説も聞いていない。
だから最大の利点と言われても、関数指向設計技法という文脈において
どう有利に働くのかほとんど想像できない。

> たとえ話として、Wordを使って自然語で書いた仕様書にスペルミスがあり、これの見落としが原因で重大な障害(バグ)が
> 発生したとします。この場合、このスペルミスは単なる「記述ミス」でしょうか、それとも「設計ミス」でしょうか？

それだけの情報しか与えられないのなら、私ならそれは記述ミスと判断する。

アホか、>>538 の皮肉が本当にもっともだと思ってるのか？
普及の方法や設計方法を考えれば、それが足りないために普及しなかった、
と結論づけることもできるだろ。

消えるのは構わんが、自分が始めた議論は責任を持って終わらせてから消えろ

550 ：デフォルトの名無しさん：2010/09/29(水) 23:19:03

>>548
そもそも、関数型的な思考プロセスってどういうものですか

自分は Haskell が好きで、今はアルゴリズムデザインを勉強中ですが、
プログラムを組み立てている時に特に意識するのは、
引数に関数を適用して評価して戻り値を返すという順ではなく、
戻り値を引っ張ってくるために引数に関数を適用して評価するという順で考えることです。

でもこれは遅延評価という Haskell 特有のものなので、
関数型的な思考プロセスという枠で括るには狭すぎる考え方だと思います。

関数型的な思考プロセスって何なんですか？

551 ：デフォルトの名無しさん：2010/09/30(木) 00:00:21

まず、納得出来る答えを返すことはできない。ただ、自分の意図を述べると、
関数型言語を使うコミュニティでなぜかうまく会話が成立する考え方という意味。

具体的ではないし、分かりにくいのではあるけれど、例えば、考え方が共通の集団において
内容としては全然違うんだけれど、なぜか同じ考え方に属する概念だなと感じて
実際ちょっとがんばって理解してみようと思うとわかりやすいというような概念があると
思うんだ。
具体的区別の基準を超えてしまって、ある種のまとまりの中になぜかまとめてしまう。
考え方＝思考プロセスというものはなぜかそういうことをしてしまうものなんだ、
という前提に自分は立っていて、その前提からの発言。

そういう意味で、自分は>>550の考え方は関数型的な思考プロセスだと感じる。

552 ：550：2010/09/30(木) 07:32:24

>>551
でも、>>550 で例に挙げた「引数を引っ張ってくる」という考え方は、
たとえば OCaml や F# では通用しないんですけど・・・
（遅延評価のライブラリなどを使えば部分的には使えますがデフォでは違う）

553 ：デフォルトの名無しさん：2010/09/30(木) 13:02:42

IO や Maybe の有無 (有っても困らないが、無いと困るかもしれない) を
設計段階で決めつけてしまうのは非常に危険。
柔軟性のない設計は、ほんの少しのミスで破綻してしまう。

ただし、副作用が強いか弱いかとか、失敗する確率が高いか低いかのような
「雰囲気」を表現することは有用。

設計段階での「強い静的型付け」は普及しない。
設計で決められるのは「雰囲気」だけだ。

554 ：550：2010/09/30(木) 20:11:29

>>551
「関数型言語を使うコミュニティでなぜかうまく会話が成立する考え方」の例を、
誰でもいいんですけど、いくつか挙げていただけないでしょうか。

それらの例を元にして、>>548 の
> 関数型的な人は実は”関数的な思考プロセス”
> を取ることができる対象であれば、別にプログラムでなくても充分満足できるのでは
> ないか、と思うんだ。
というのがどういう事か考えてみたい。

555 ：デフォルトの名無しさん：2010/09/30(木) 23:33:56

親和性がいい概念って一度会ってしまうと、そもそも初めから存在していたもので
たまたま自分が失念していた、自分がアホで知らなかった、という解釈をする傾向が
高いように感じる。（なぜか遡及して存在を認めてしまう）
なので、例をあげてもそうであるのかどうか多分分からないと思う。

というわけで、言えることは、そういうことがあるということに気をつけて物事に
接していると結構高い頻度でであえるはずだ、ぐらい。

556 ：デフォルトの名無しさん：2010/09/30(木) 23:43:31

訳:

どうせ554にはいってもわからん。

557 ：デフォルトの名無しさん：2010/09/30(木) 23:58:53

妥協が早すぎるな。そんなのはダメだ。

いい例が思いついた。人工知能。
Lsipと人工知能って一緒に語られることが多いけれど、あれってよくよく考えると
ギャップ大きすぎるよね。最初から人工知能を作ることが目的の人が必要に迫られて
Lispをやるから一緒に語られることが多いというのならわかるけれど、
どうも、Lispをやっていてなぜか人工知能に目覚めるという人が結構いるようだ。
なんでLispやってていきなり人工知能やろうってなるのよ？

558 ：550：2010/10/01(金) 00:19:24

>>555
関数型的な思考プロセスとはそんな曖昧で捕らえどころのないものなのですか。

>>548 はそんなものを指して「ある程度承認される言明のはず」と言い、
関数型を押す人の内なるモチベーションをこれで説明し、
関数型的な人はプログラム以外でもこれを適用できる対象があれば満足、
などと持論を展開していたのですか。

Ａを使ってＢを論ずるのに、そのＡがこれほど曖昧では、Ｂ対して誰も
「それは一理あるかも」とも「それはどうかな」とも言えなくないですか。

この場合Ａ（>>548 の言う「関数型的な思考プロセス」）は
はっきりした文章で定義できなくとも、少なくともいくつか事例を挙げて
認識を共有しないと、Ｂはちゃんと議論できないと思うのですけど・・・

559 ：デフォルトの名無しさん：2010/10/01(金) 00:45:57

そんな土俵で話をしても意味ない。
議論を基軸に考えすぎ。仮にその方向で話を展開していっても、大した結論でないよ。

560 ：550：2010/10/01(金) 07:28:27

>>559
では議論するのは止めてもいいです。
ただ純粋に >>548 の言っていることをちゃんと理解したいだけなんです。

とにかく、関数型言語を好む人の「関数型的な思考プロセス」というのが
少なくとも自分にはあまりに漠然としすぎていて分からないため、
>>548 が言いたいことがほとんど理解できていない状況です。

561 ：デフォルトの名無しさん：2010/10/02(土) 11:58:39

「関数脳」って言葉はたまに見る。
だから何って訳でもないケド

562 ：デフォルトの名無しさん：2010/10/03(日) 23:56:04

ハードウェア記述言語Lava
ttp://raintown.org/lava/

こいつは化ける

563 ：デフォルトの名無しさん：2010/10/04(月) 00:52:46

化けたら、そのときまた知らせてくれ

564 ：デフォルトの名無しさん：2010/10/04(月) 00:59:20

>>562
[fun of programming] （和訳：[関数プログラミングの楽しみ]）
この本のトピックのひとつで Lava の考え方が学べる

565 ：デフォルトの名無しさん：2010/10/04(月) 01:30:44

関数型言語が普及しないのは使える素養を持った人が少ないからでFAですよね

566 ：デフォルトの名無しさん：2010/10/04(月) 01:58:15

いいえ、使える箇所が小さいからです。
アプリ全体（GUI、入出力、ファイル処理、通信）を考えると
どうしても関数型言語でやるべきないようじゃなくなるのです。

567 ：デフォルトの名無しさん：2010/10/04(月) 07:58:25

いいえ、GUI、入出力、ファイル処理、通信を関数型言語でやるべきでないという誤解が蔓延しているからです。

568 ：デフォルトの名無しさん：2010/10/04(月) 08:30:06

>>567
はげどう
私はパーサーコンビネーター、FRP、STM, Iterateeのような技には感動した

569 ：デフォルトの名無しさん：2010/10/04(月) 11:36:26

STMは確かに

570 ：デフォルトの名無しさん：2010/10/04(月) 12:52:42

>>568
同じく

というか、関数型に限らずたいていの言語は
「どうしてもその言語でやるべき」という状況は無いと思うが

>>566 には「使える箇所が小さい」という根拠を示してほしいな

571 ：デフォルトの名無しさん：2010/10/04(月) 13:31:30

>>570
どうしてもという状況が無いなら、低コストの言語が選ばれる。
コストが高くなると、採算がとれる箇所は減る。

572 ：デフォルトの名無しさん：2010/10/04(月) 17:15:25

関数型素人の俺からすると
副作用ﾀﾞﾒｾﾞﾀｰｲ
みたいな先入観があるかな。

573 ：デフォルトの名無しさん：2010/10/04(月) 17:21:22

関数型言語玄人なら先入観とは言わないだろう。

574 ：デフォルトの名無しさん：2010/10/04(月) 17:21:27

Cとかでも副作用なしの関数って使いﾔｽｨだろ？
それの延長上にあるんだよ

575 ：デフォルトの名無しさん：2010/10/04(月) 17:35:37

副作用がないということはスレッドセーフってこと。

576 ：デフォルトの名無しさん：2010/10/04(月) 17:56:12

副作用ダメ絶対はOOとは相容れないのかな？

577 ：デフォルトの名無しさん：2010/10/04(月) 18:15:46

>>571
関数型の方がコストが高いのは、>>565 の
「使える素養を持った人が少ない」からだよな

なんかニワタマループに陥るな

578 ：デフォルトの名無しさん：2010/10/04(月) 18:17:05

関数型でもステートマシンが作れるように
OOぐらいできるよ

579 ：デフォルトの名無しさん：2010/10/04(月) 20:04:09

>>576
副作用は、引数と戻り値の型を無視するバックドアだから型理論を台無しにする

OOは、クラスとメソッドの名前だけ決めて型は後で考えるという設計もできるので
副作用があっても平気なのだ

580 ：デフォルトの名無しさん：2010/10/04(月) 21:10:27

>>576
上手ーくやれば何とかならんでも無いかも
生成時点から状態が変わらないオブジェクトなら関係ないしな
…まあコンストラクタがかなりカオスなことになりそうだがw

581 ：デフォルトの名無しさん：2010/10/04(月) 22:37:55

>>577
＞「使える素養を持った人が少ない」からだよな
明らかに自惚れ。使える素養を持った人は山ほどいるだろ。
物理系でもCSの他分野でも応用数学でも、優秀なやつはいくらでもいる。
そしてそういう優秀な奴らは、HaskellだのLispだの、
わざわざ小難しいマニアックな道具なぞ選択しない。そんな馬鹿じゃない。

手続き型だと圧倒的に難しいというアプリがあるわけでもないし、
その状況でわざわざ小難しい道具を選択すること自体、
なんていうか、筋が悪い。

582 ：デフォルトの名無しさん：2010/10/04(月) 22:51:49

>>581
>そしてそういう優秀な奴らは、HaskellだのLispだの、
>わざわざ小難しいマニアックな道具なぞ選択しない。そんな馬鹿じゃない。

ダウト

583 ：デフォルトの名無しさん：2010/10/05(火) 07:18:02

>>581
君は使える素養を持ってないから、
わざわざ小難しい道具と感じてしまうんだよ

584 ：デフォルトの名無しさん：2010/10/05(火) 11:06:18

＞手続き型だと圧倒的に難しいというアプリがあるわけでもないし、

わざわざ注意が必要なもの使わずに関数型でやったほうが楽なものが多数あるんだが。

585 ：デフォルトの名無しさん：2010/10/05(火) 11:36:10

>>581
手続き型「だけ」関数型「だけ」で書くという発想こそ、たいへん筋が悪い

586 ：デフォルトの名無しさん：2010/10/05(火) 11:53:51

>>585
安全のためには「純粋」関数型「だけ」でないとダメという事だろう

個人的には、何が安全で何が危険かを自分の頭で考えず
えらい人に定義してもらうやり方は嫌いだ
そういうことをすると、頭の中がコンプライアンス不況になる

587 ：デフォルトの名無しさん：2010/10/05(火) 12:12:41

>>586
自分の頭で考えていないと思う根拠は？
お前はただの先入観でそう思っているだけじゃないのか？

588 ：デフォルトの名無しさん：2010/10/05(火) 13:07:17

>>584
型や参照透明性のレベルで議論できる安全性なんて、JavaやC#の
ちょっとした書き方の工夫で簡単に達成できるだろ。。。
いつまでもそのようなプリミティブなレベルに拘泥してるから、
プロダクト開発者たちと議論がかみ合わない。

589 ：デフォルトの名無しさん：2010/10/05(火) 13:15:36

Haskell の安全性を簡単に達成できる「JavaやC#のちょっとした書き方の工夫」を
示してから言えw

590 ：デフォルトの名無しさん：2010/10/05(火) 13:21:59

工夫しなきゃいけないのと、何も考えずにできるのとではどっちが優れているのかｗ

591 ：デフォルトの名無しさん：2010/10/05(火) 13:26:52

>>587
考えるなら人と違うことを考えないと意味ないから

592 ：デフォルトの名無しさん：2010/10/05(火) 13:28:46

>>591
人と違うことを考えるだけではまったく意味が無い
その考えが他の人にも広く採用されるようになって初めて意味がある。

593 ：デフォルトの名無しさん：2010/10/05(火) 13:57:31

>588
そーだねーオブジェクト指向とか関数型とかもCで書き方工夫すれば出来るもんねー
じゃぁ速そうだから全部Cで書けばいいんじゃない？

594 ：デフォルトの名無しさん：2010/10/05(火) 15:28:15

いや、>>588は「ちょっとした」書き方の工夫で「簡単に」達成できる、と言っている。
単にできるできないじゃなくてね。

だから、たとえばHaskellのSTMのような安全性を、簡単に達成できるちょっとした
書き方の工夫を、どうやればいいのかぜひ示してほしいんだけど。

595 ：デフォルトの名無しさん：2010/10/05(火) 16:09:21

副作用なしにコンソールに文字列を表示したりできるっけ？

596 ：デフォルトの名無しさん：2010/10/05(火) 16:34:27

>>595
main::IO ()
がミソ。
遅延評価だからmain関数がIOモナドをいきなり世界に返すことで実行開始。
実行開始してから必要な評価が行われる。

597 ：デフォルトの名無しさん：2010/10/05(火) 16:35:47

遅延評価はプログラミング初心者がC言語のポインタを理解するよりも感覚的に難しいと思う。

598 ：デフォルトの名無しさん：2010/10/05(火) 18:14:05

>>597
そりゃ教え方が悪いんだよ
講師がいるのか書籍なのか知らんが

遅延評価の方が遙かに直感的だ

599 ：デフォルトの名無しさん：2010/10/05(火) 18:49:33

>>598
遅延評価を理解しようと思ったらクロージャの実装について理解しなきゃいけない。
完全に理解するためには一度遅延評価機構を実装してみないと難しいぞ。

600 ：デフォルトの名無しさん：2010/10/05(火) 19:05:02

なぜ静的型付け＋遅延評価なんだろう？
C++のテンプレートは全く逆だ
ダックタイピング＋コンパイル時にすべて評価される

601 ：デフォルトの名無しさん：2010/10/05(火) 19:09:33

>>599
「完全に」理解する必要なんて無いよ

>>597 は「プログラミング初心者がC言語のポインタを理解する」
のと比較してるんだから
プログラミング初心者が入門書なんかを読んで、
ポインタで何ができるのか、どうやってできるのか、
そういう基礎を学ぶことと比較してるんだよ

「その程度」の遅延評価を理解を得るのに
同じような程度にポインタを理解するよりも感覚的に難しいというのなら、
それは教え方が悪いとしか言いようがない

602 ：デフォルトの名無しさん：2010/10/05(火) 19:16:11

ポインタを理解するためにはメモリの構造とかハードウェアの諸概念を理解しなきゃいけないだろ。

603 ：デフォルトの名無しさん：2010/10/05(火) 19:17:21

悪いけど、俺理系だから使い方だけ勉強するっていうのでは納得できないんだわ。
文系なら使い方だけちゃちゃっと覚えるんだろうけどさ。

604 ：デフォルトの名無しさん：2010/10/05(火) 19:22:43

>>602
だから何だというんだ？
反論であるならば、最後まできっちりと喋りきってくれ

まさか、プログラミング初心者が学ぶための入門書に
載っているレベルのメモリ構造やハードウェア諸概念が、
>>599 の言うクロージャの実装と同レベルなんて言わないでしょうね

605 ：デフォルトの名無しさん：2010/10/05(火) 19:32:54

ポインタ概念ってハードウェアのレベルよりももう一段高レベルなんじゃないか？
・ヒープ領域に確保するということ
・間接参照の概念
・ポインタ演算の意味
これくらい分かっとけば大体使えるだろ。

606 ：デフォルトの名無しさん：2010/10/05(火) 19:44:13

>>605
そうだよ
「これくらい分かっとけば大体使えるだろ」
これがプログラミング「初心者」の理解するC言語のポインタだよ

だから「これくらい分かっとけば大体使えるだろ」という程度に遅延評価を理解するのも、
本来それほど難しいものではないと言っている
（この程度の理解なら）むしろ遅延評価の方が直感的ですらある

難しさで比較するなら、どちらも同じ程度で比較しなきゃ比較の意味が無い
そして >>597 の提示した理解度はプログラミング初心者のそれ

なのに、なぜか遅延評価の方だけより深く理解する難しさで比較したがる輩がいる

607 ：デフォルトの名無しさん：2010/10/05(火) 19:45:11

>>605
例えばNintendoDSではヒープとスタックでそれぞれ速度が10倍違うメモリを使っていて
パフォーマンスを追求するにはハードウェアの仕組みについても理解しなきゃいけないんだよ。
ポインタを利用するということはどこからどうやってデータを入出力するかってことで、
効率との戦いなんだ。

608 ：デフォルトの名無しさん：2010/10/05(火) 19:45:59

>>606
すまん、言葉が足らんな

> 難しさで比較するなら、どちらも同じ程度で比較しなきゃ比較の意味が無い

難しさで比較するなら、どちらも同じ程度の理解度で比較しなきゃ比較の意味が無い

609 ：デフォルトの名無しさん：2010/10/05(火) 19:46:50

>>606
毎度おなじみ「使える」のレベルの違いでもめているね。
終わらない論争になるから、早いところ落とし前付けてね。

610 ：デフォルトの名無しさん：2010/10/05(火) 19:55:38

>>609
今回の「使える」のレベルはそれほど曖昧ではないだろ

>>597 がプログラミング初心者と言っている以上、
プログラミング初心者が入門書程度のプログラムを実行した時に
その動きが予測できる程度が、今回の「使える」だろ

そして >>597 によれば、Ｃ言語ならポインタを使ったプログラムだ
なら、遅延評価も同程度の「使える」で判断すればいいのではないか

プログラミング初心者が「使う」ということに関して、
これ以上に理にかなった解釈があればぜひ提示して欲しい

611 ：デフォルトの名無しさん：2010/10/05(火) 20:00:41

仕組みを理解しないで使い方だけ理解できる人なんているのだろうか？

612 ：デフォルトの名無しさん：2010/10/05(火) 20:07:23

>>611
それは「理解」の程度によるよ
使い方に関して低い程度の理解でよければ、
仕組みを理解しなくても問題ない

たとえば emacs の仕組みを理解してなくても、
ファイルを開き、テキストを編集し、保存する
という程度の使い方を理解できている人は大勢いるしね

613 ：デフォルトの名無しさん：2010/10/05(火) 20:30:26

仕切りたがるくせに無責任なんだよな
責任取る気がないなら、もっと自由な言語を使わせてあげればいいのに

614 ：デフォルトの名無しさん：2010/10/05(火) 21:00:07

初心者レベルなら、式が計算されずに返されてて
必要なときに評価されてます、程度の認識と
あとは無限リストとかの扱い方を覚えれば大丈夫じゃないか？

ポインタは未だによく解らない、というか
C言語のポインタが解りにく過ぎると思う
Delphiにもポインタ自体はあるが、悩んだ記憶ないんだがなあ

615 ：デフォルトの名無しさん：2010/10/05(火) 21:07:28

>>614
CPUの構造を勉強すれば直ぐわかるよ。

616 ：デフォルトの名無しさん：2010/10/05(火) 21:07:53

遅延評価の詳しい仕組みや原理を知る、いい資料ってあります？

617 ：デフォルトの名無しさん：2010/10/05(火) 21:16:23

SICPの3,4章あたりのストリームの話題とか
introduction to functional programming using haskellの後半の章とか

618 ：デフォルトの名無しさん：2010/10/05(火) 21:24:34

後者の本って、WHNFについて書いてありますか？

619 ：デフォルトの名無しさん：2010/10/05(火) 21:25:37

OCamlはだめですか？

620 ：デフォルトの名無しさん：2010/10/05(火) 21:28:25

>>617
どうもです。
>introduction to functional programming using haskellの後半の章とか
これは7章のとこでしょうか？

621 ：デフォルトの名無しさん：2010/10/05(火) 21:39:32

ここまで>>592の自演

622 ：デフォルトの名無しさん：2010/10/05(火) 21:43:33

http://en.wikibooks.org/wiki/Haskell/Laziness
こことかここの最後のReferenceから辿れるページの方が詳しいかと

623 ：デフォルトの名無しさん：2010/10/05(火) 21:49:18

>>622
ありがとうございます、読んでみます。

624 ：デフォルトの名無しさん：2010/10/05(火) 23:00:34

>>614
なんだ、ポインタ程度も理解できずに議論してたのか
まだ遅延評価は早いんじゃない？

625 ：デフォルトの名無しさん：2010/10/05(火) 23:01:22

>>616
小飼弾ｗ
http://blog.livedoor.jp/dankogai/archives/50996734.html

626 ：デフォルトの名無しさん：2010/10/05(火) 23:23:29

ほとんどの言語は関数型言語をほぼ内包していて、
書こうと思えば関数型言語風に書くことが可能。

オブジェクト指向言語で関数型言語風に
コードを書くことはできるが、関数型言語で
オブジェクト指向風にコードをかけない。
そんなことできないのが関数型言語というものだから。

できることが、
オブジェクト指向言語＞関数型言語
なので関数型言語は普及しない。

627 ：デフォルトの名無しさん：2010/10/05(火) 23:36:31

こりゃまた強烈な阿呆が沸いて出たなｗ

628 ：デフォルトの名無しさん：2010/10/05(火) 23:43:37

>>1
マルチコアマルチCPU環境下でスケールするための有効な手法、
っていうことで皆騒いてるんだと思ったけど

スケールした実例があるかは知らん

629 ：デフォルトの名無しさん：2010/10/05(火) 23:55:33

>>627
あ、マジマジ。

例えば関数型のforと同じように動くfor関数を
作ることができる。オブジェクト指向では。

でも関数型で、オブジェクト指向のforのような
動きをするものは作れない。

630 ：デフォルトの名無しさん：2010/10/06(水) 00:17:17

まぁそもそもオブジェクト指向と関数型を二項対立のように扱っている時点でお里が知れるかと。

631 ：デフォルトの名無しさん：2010/10/06(水) 00:31:59

○○について知らない奴ほど○○について語りたがる、という例の法則だな

632 ：デフォルトの名無しさん：2010/10/06(水) 00:44:57

オブジェクト指向の for てどんな動きするの？

633 ：デフォルトの名無しさん：2010/10/06(水) 00:47:35

>>626
関数型言語風とはどのようなものだ？
生憎とそれらしいものを見たことがない、関数型のforの意味の分からんし
（C言語でもオブジェクト指向ができる、というレベルのものだったら話にならん）

C/C++ や Java、C# などで簡単なプログラムを書き、
その関数型言語風とやらを実演して見せてくれ

関数型言語の何をどのように真似て、どのような効果が得られたか、
文章で解説を添えてくれるとなお助かる
>>626 には無理だったら別の人でもいいが

634 ：デフォルトの名無しさん：2010/10/06(水) 03:01:02

OOって、言語機能として見たら1～2割程度なんだよな。
だからCでもOO指向モドキができると言い張る輩が存在する。
気の利いた言語ならライブラリレベルで実現できる。

しかし関数型は言語機能で見ると7割以上を占めるから、
他の言語では中々真似ができない。
例えばCではクロージャが作れなかったり、
末尾呼び出しをループの代わりにするなんて発想はできない。

635 ：デフォルトの名無しさん：2010/10/06(水) 03:19:24

末尾再帰最適化ってさ、普通の再帰から末尾再帰とかいう可読性の悪い形にしてまで
ループを無理やり再帰の形に直す意味が無いだけなんじゃ……

636 ：デフォルトの名無しさん：2010/10/06(水) 03:20:05

あ、非関数型系の言語に末尾再帰最適化が入らない理由ね。

637 ：デフォルトの名無しさん：2010/10/06(水) 03:33:51

可読性は参照透過性と合わせてむしろ良くなるんだが
まあ理解できないんだろうな

638 ：デフォルトの名無しさん：2010/10/06(水) 07:40:16

BASICならGOSUB ほげ:RETURNという命令の並びをGOTO ほげ、に変えて
簡単に最適化できるけどなw

あとHaskellだと末尾再帰だからといって効率が良いとは限らない。

ループのほうが可読性が高いと思ってる奴はFORTRANでも使ってろ。

639 ：デフォルトの名無しさん：2010/10/06(水) 10:08:36

これまたすごいのが湧いてきたな
>>626

640 ：デフォルトの名無しさん：2010/10/06(水) 10:49:00

ループはブロック渡し、つまり高階関数です
高階関数と再帰はどちらが可読性が高いですか？

641 ：デフォルトの名無しさん：2010/10/06(水) 11:00:25

>>640
状況に依って使い分けてる。
Lisp だけど、返り値を使いたいときは map 系使って、返り値に興味ないときはループ。

642 ：デフォルトの名無しさん：2010/10/06(水) 11:59:22

>あとHaskellだと末尾再帰だからといって効率が良いとは限らない。

え、限らないんだｗ
どういうことなの・・・

643 ：デフォルトの名無しさん：2010/10/06(水) 12:49:16

>>642
ttp://d.hatena.ne.jp/kazu-yamamoto/20091122/1258899591

644 ：デフォルトの名無しさん：2010/10/06(水) 13:00:51

なるほど・・・わからん・・・

645 ：デフォルトの名無しさん：2010/10/06(水) 13:22:27

hasell使うとハゲそう
それだけは判った

646 ：デフォルトの名無しさん：2010/10/06(水) 13:25:43

Haskellでも末尾再帰で書けば、必ずスタック消費なしでループできるよ
末尾再帰でもヒープを消費することがあるってのは事実だけど、
それを言ったらCのwhileだってループ内でmallocすればどんどんメモリを使う

それから、末尾再帰でリストを先頭から構築したいときは、(:)で末尾から逆順で構築していって、
最後にreverseするのが常套手段
だから>>643の(++)を使った例は恣意的

647 ：デフォルトの名無しさん：2010/10/06(水) 13:28:59

非正格だと評価順序が関係なくなるのは理解できるんだが、
アセンブリとかVMとかへのコードの出力を考えた時に、
何が起きてるのか予想ができない。
つまりデバッグできるんかいそれ！

648 ：デフォルトの名無しさん：2010/10/06(水) 13:31:26

例えばhaskellのデバッガでステップ実行する時ってどこで止まるわけ？
モナドらへん？それってモナドデバックしてるのとちゃうんかい！

649 ：デフォルトの名無しさん：2010/10/06(水) 13:33:59

余再帰とか、このスレでも俺の書き込みが初出やないか！
おまえらほんんんとに判ってんのか？

650 ：デフォルトの名無しさん：2010/10/06(水) 13:34:34

>>647
評価順序がどうでもいいってことは、自分の好きな順序で評価されると思って良いってことだよ

具体的な評価順を知りたければ必要呼び(call by need)を調べればいい
ただしコンパイラが最適化のために勝手に評価順を変えることはある

>>648
ghciでステップ実行すると、部分式を評価し始めるたびに止まる

651 ：デフォルトの名無しさん：2010/10/06(水) 13:41:29

じゃあ実質実装ごとに評価順序あるんじゃん
それで非正格ユーザーは納得してんのか？
なんでこんなとこで止まるねん、こいつおかしいで！とかないの？

652 ：デフォルトの名無しさん：2010/10/06(水) 13:44:41

>>647
> 非正格だと評価順序が関係なくなるのは理解できるんだが
ダウト

653 ：デフォルトの名無しさん：2010/10/06(水) 13:46:22

な、なにー
もうええわ

654 ：デフォルトの名無しさん：2010/10/06(水) 13:46:37

>>651
どういう順序で評価しても結果は変わらないから問題ない
(もちろん、非正格な関数は非正格に振る舞うようにしないといけない
遅延評価なら計算できる式を無限ループさせてしまうような評価順は駄目だし、そういうことをするコンパイラは欠陥品)

655 ：デフォルトの名無しさん：2010/10/06(水) 13:51:35

評価順序が関係なくなったら、例えば1234という順にプリントすることすらできなくなるじゃないかｗ

656 ：デフォルトの名無しさん：2010/10/06(水) 13:56:08

遅延評価は「必要になったら評価する」という事だから評価順序が関係ないということにはならないよ

657 ：デフォルトの名無しさん：2010/10/06(水) 13:57:50

じゃあその1234はどういう順でって、どこで決めてんの？

658 ：デフォルトの名無しさん：2010/10/06(水) 13:58:41

>>655
「評価順序が決まってなくても、決まった順序で入出力できる」ための仕組みがIOモナド

>>656
そりゃそうだ
遅延評価は評価順序の一つ
Haskellは非正格な言語で、非正格性を保つ限り評価順序は自由であり、遅延評価をベースとした処理系が多い

659 ：デフォルトの名無しさん：2010/10/06(水) 13:59:10

pが表示関数だとして
(p 1) (p 2) (p 3)を
((p 1) (p 2)) (p3)とやっても
(p 1) ((p 2) (p 3))とやっても
どちらもプリントするっていうアクションが返されて(評価時にプリントされるわけではないので)
それをプリントするため、どちらも同じ表示結果になる
この順番を制御してるのはIOモナド

660 ：デフォルトの名無しさん：2010/10/06(水) 14:00:11

じゃあIOモナド、俺が判るように説明してみてな

661 ：デフォルトの名無しさん：2010/10/06(水) 14:01:35

純粋関数型言語では値のメモ化を自動化できる。
つまり、副作用がないので入力が同じなら常に出力も同じになることが保証されているから
同じ入力が来たときに評価をすっ飛ばして以前の結果だけを返すこともある。
だから常に関数の中身が評価されるとは限らない。

662 ：デフォルトの名無しさん：2010/10/06(水) 14:03:57

IOモナドは、haskellで別の手続き型言語のコードを記述するのと全く同じです
その手続き型言語のコードでバグがあったら、手続き型言語の手順でバグ取りします
つまりhaskellは手続き型言語です

663 ：デフォルトの名無しさん：2010/10/06(水) 14:05:03

>>657
main関数が返すIOモナドの内包順だよ。
不正確な俺のイメージで表現すると、
玉ねぎのように何重もの皮に包まれていて、それをめくっていくように評価される。
最初にmain関数が返すIOモナドは一番外側の皮しか見えないが、
評価されるたびに中身の皮が作られていく、イメージｗ

664 ：デフォルトの名無しさん：2010/10/06(水) 14:05:46

>>646
リストを先頭から食べながら、先頭から返してくように書かないと、
「逆順で構築していって、最後にreverse」は無限リストに使えないし。

665 ：デフォルトの名無しさん：2010/10/06(水) 14:06:43

このスレでモナドのベールをバリバリ剥がしていかないか
やらないか

666 ：659：2010/10/06(水) 14:09:45

理解の怪しい俺による説明
モナドってのは数学的には、結合法則と単位元があるもの
>>659の説明は、まんま結合法則が成り立つよっていうことを言ってる
単位元ってのは(x+単位元)がxと同じになるってこと
IOモナドでいえば、
モナドを使わない世界で何も無いデータを表示することと、
IOの世界で何も表示されないってことが同じってこと

IOモナドによって副作用がないとかよく言われるけど、あれって、モナドのおかげって言うよりも
IO処理が第一級の値になってるから、だと思うんだよね
違ったら教えてください詳しい人

667 ：デフォルトの名無しさん：2010/10/06(水) 14:10:39

>>644
無限リストに使えないのはその通り
それを承知の上で末尾再帰で書きたいケースもある
IOモナドの中とか

いずれにしても(++)はひどい、と言いたかっただけ

668 ：デフォルトの名無しさん：2010/10/06(水) 14:14:57

>>666
>IO処理が第一級の値になってるから、だと思うんだよね
これよ！
これの説明でなんか判りそうな気がする！
もうちょい詳しく！単位元とか判らん！

669 ：デフォルトの名無しさん：2010/10/06(水) 14:15:42

Scalaを覚えようかと思ってるんだけど、
そもそも関数型言語がさっぱりなので入門にいい言語教えて。

670 ：デフォルトの名無しさん：2010/10/06(水) 14:16:44

うん、モナドとは何かというのはあんまり関係ない
IO aという型があって、それを作るためにreturn、(>>=)、putStr、exitWithなどなどの関数が用意されているというのがポイント

IO型についてはこれがおすすめ
ttp://web.archive.org/web/20080202180610/www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/haskell_io.html

671 ：デフォルトの名無しさん：2010/10/06(水) 14:18:41

モナドのプリミティブな源は何か？ってのが判れば、理解できると思うんだわ。
単に「モナド」と言われても判らんのよ。普通はモナカのお菓子の仲間か何かですか？
って思うわけじゃん？

672 ：デフォルトの名無しさん：2010/10/06(水) 14:20:09

ゼノブレイドの主人公の剣だと思います

673 ：デフォルトの名無しさん：2010/10/06(水) 14:21:27

IOモナドを理解したい時は、モナドを理解しようと思わない方がいいよ
IOという名前の抽象データ型があって、それを操作するAPIは…のように考えるといい

674 ：デフォルトの名無しさん：2010/10/06(水) 14:23:05

HaskellのモナドとF#のComputation Expressionsってほぼおなじ？

675 ：デフォルトの名無しさん：2010/10/06(水) 14:23:06

haskellを日本に輸入する時に、「モナド」をカタカナじゃなくて、
ちゃんと日本語に訳すればよかったんだよ
次元波動超弦励起縮退半径跳躍重力波超光速航法みたいな

676 ：デフォルトの名無しさん：2010/10/06(水) 14:24:57

IOモナドを実行すると副作用です
ただ、実行しないから副作用じゃないもんキャンペーン中は副作用がありません

677 ：659：2010/10/06(水) 14:27:10

>>668 なんか、役に立ったみたいなのでもうちょっと語る

とりあえずの理解の仕方としては、何かをプリントする、みたいなIO処理(副作用)がアクションに評価されて
アクションをくっつけるのに使ってるのが>>=や>>などのIOモナド的な記法
んで、Main関数は、そのくっつけられたアクションを受け取って実行する関数、みたいに思うと理解しやすいと思う
俗にHaskellではIOの実行をperformと言っていて、評価(evaluate)という用語とは分けて使ってる

678 ：659：2010/10/06(水) 14:34:51

Haskellでは「評価した」≠「実行した」なのが混乱の原因じゃないかな

評価した結果はアクションで、これは好きな順番にくっつけたり、複製したり削除したり、まぁ好きに扱える
なので副作用がない。Mainに渡すと実際に副作用が起きる

679 ：デフォルトの名無しさん：2010/10/06(水) 15:06:20

Scalaでいいと思うよ。
関数型言語がさっぱりなら尚更。

680 ：デフォルトの名無しさん：2010/10/06(水) 15:09:32

ああああ・・・・ちょっと遠のいたかな・・？
でもラピュタ王並に読める！読めるぞ！
なんつーか、C++における例外機構みたいな、別の経路があるんだよね？？？

681 ：デフォルトの名無しさん：2010/10/06(水) 15:19:44

>>669
そりゃもちろんSchemeでしょ。
そんでもって計算機プログラムの構造と解釈を教科書に勉強するのがセオリー。

682 ：デフォルトの名無しさん：2010/10/06(水) 15:37:18

>>679,681
どうも。入門サイトで比較して見ようと思います。

683 ：デフォルトの名無しさん：2010/10/06(水) 15:47:01

CommonLispの仕様は
肥大化しすぎと言われるC++の仕様の1.4倍のページ数がある事実について。

684 ：デフォルトの名無しさん：2010/10/06(水) 15:58:32

関数やマクロがあほみたいに多いから？

685 ：デフォルトの名無しさん：2010/10/06(水) 16:01:58

なんでCLはライブラリ豊富なのにSchemeはほとんど無いんだろう？

686 ：デフォルトの名無しさん：2010/10/06(水) 17:03:07

あんまり豊富にすると免疫がついてPerlの魅力に気付いてしまうからね

687 ：デフォルトの名無しさん：2010/10/06(水) 17:09:51

確かにperlは魅力的だが

688 ：デフォルトの名無しさん：2010/10/06(水) 17:10:40

結局、この世には3つの言語しか必要ない
Cとperlとjavaだ。

689 ：デフォルトの名無しさん：2010/10/06(水) 17:14:33

perl脳の恐怖

690 ：デフォルトの名無しさん：2010/10/06(水) 18:44:04

perlの良いところは省略文化だが、悪いところも省略文化だな。

691 ：デフォルトの名無しさん：2010/10/06(水) 18:50:28

PERLのソースは1年触らないと見ただけでもめまいがする。
それが（PERLなりに）保守性の高いコードだとしても。

692 ：デフォルトの名無しさん：2010/10/06(水) 19:44:15

そもそもスクリプトの役割って使い捨てだろ？

693 ：デフォルトの名無しさん：2010/10/06(水) 19:48:50

公開停止したバイナリと思って付き合うしかないよね

694 ：デフォルトの名無しさん：2010/10/07(木) 01:28:55

haskellの話題に戻すが、
このスレできっちりモナドについて噛み砕いた説明ができれば認めてやろう

695 ：デフォルトの名無しさん：2010/10/07(木) 01:42:30

haskellスレpart1みたいな話題はもうやめてくれ。
Haskellにおけるモナドについてはもう語り尽くしただろ。
初心者にも分かりやすい説明もあればブログも本もあるからそっちを嫁

696 ：デフォルトの名無しさん：2010/10/07(木) 03:42:40

>初心者にも分かりやすい説明もあればブログも本もあるからそっちを嫁
せめてそういうこと言うならそれぞれリンクでも貼れよ
嫁、じゃねーよボケ

697 ：デフォルトの名無しさん：2010/10/07(木) 05:23:05

ググれば結構出てくるんじゃないかなぁ

対称性という観点からすると、
副作用のある手続きはMonadで書くよりもArrowで書いたほうが美しいと思うんだがどうか

698 ：デフォルトの名無しさん：2010/10/07(木) 05:28:06

それ、俺に聞いてんのか？
正気か？
ならMomadとArrowがどうチガウのか説明してみ？

699 ：デフォルトの名無しさん：2010/10/07(木) 05:42:43

Arrowの方がより抽象的。っていうか大体これ↓でよくね？
http://www.aya.or.jp/~takuo/arrow_for_2ch/arrow_for_2ch.pdf

美しいというのはコードが綺麗にかけるとかそういう事よりも、数学的対称性の美というか。
上のpdfの6～7ページでもMonad、Arrowの両方でStateを実装しているけど、Arrowのほうが対称的っぽくない？
MonadはListやMaybeなどと形式を合わせるために歪な形に変形しているように見える。

700 ：デフォルトの名無しさん：2010/10/07(木) 20:10:22

Unixなどのストリームとフィルタに例えると、
Monadの目的はストリームにフィルタをbindすること。
Arrowはフィルタだけを組み合わせる。

701 ：デフォルトの名無しさん：2010/10/07(木) 20:27:38

IOArrowがあるとしたらどんな感じになる？
やっぱStateArrowっぽい感じ(A×S→B×S)になんのかな

702 ：デフォルトの名無しさん：2010/10/07(木) 21:59:57

なんつーかぼやけてるんだよなあ
モナドにしろアローにしろ肝心のことが書かれてない気がするんだよ
おれがいまだに理解できてないからな

703 ：デフォルトの名無しさん：2010/10/07(木) 22:03:08

カタカナの専門用語とか使わないで、
非正格言語でなぜ副作用を扱えるのか、
原理を説明して見せてくれないかな

704 ：デフォルトの名無しさん：2010/10/07(木) 22:06:33

>>702
肝心のことって何？

705 ：デフォルトの名無しさん：2010/10/07(木) 22:07:02

非正格言語じゃないとダメなのか（非正格は明らかに効率悪いよな？）
一般的な正格言語でも同じように参照透過性を維持しつつ副作用を組み込めないのか
実現できるとしたらどんな形か
辺りかなあ

706 ：デフォルトの名無しさん：2010/10/07(木) 22:09:26

できればコード例があるならschemeで書いてくれ
これは演算子の優先順位とかが無くて誤解が少ないからな
ちなみにSICPぐらいは読んでるから

707 ：デフォルトの名無しさん：2010/10/07(木) 22:28:59

>>702
お前の理解のためになんで俺らがエネルギー使うの。
関数型言語すげーって言っとけばいいんだよ。
理解したいならブログとかHaskellスレの過去スレ読め。

708 ：デフォルトの名無しさん：2010/10/07(木) 22:29:48

>>703
正格性と副作用は関係ないと思う

関数の引数が未定義ならばその関数の値も未定義であることを正格という

関数の中で、その関数の外の環境を変化させることを副作用という

709 ：デフォルトの名無しさん：2010/10/07(木) 22:41:15

>>707
だからどこ読めば理解できるのか示せっての
自分で説明してみろ

>>708
だったらなんでML系でモナドやらアロー使わないんだよ
下手糞な用語説明なんか要らないの

710 ：デフォルトの名無しさん：2010/10/07(木) 22:47:35

(define (>>= m f) (lambda () ((f (m)))))
(define (putStrLn x) (lambda () (write x) (newline) #t))
(define m (putStrLn "Hello World"))
(define f (lambda (_) m))
(define main (>>= (>>= m f) f))
;;ここまで副作用なし

(main) ;;副作用あり

711 ：デフォルトの名無しさん：2010/10/07(木) 22:47:52

; IO命令をschemeで実装するにあたり、無引数の手続きとして表現する

; 何もせずにxを返すIO命令(副作用なし)
(define (io-return x) (lambda () x))
; IO命令aを実行し、結果vを得た後、IO命令(f v)を実行するIO命令(命令を作る手続き自体には副作用なし)
(define (io-bind a f) (lambda () ((f (a)))))
; 文字を読むIO命令
(define io-getchar (lambda () (read-char)))
; 文字cを書き、nilを返すIO命令(命令を作る手続き自体には副作用なし)
(define (io-putchar c) (lambda () (write-char c)))

; IO命令の実行(Haskellでは処理系が暗黙に行うが、Schemeはそれをしないので必要)
(define (run-io io) (io))

; 使用例
; 入力を一行読み、逆順に出力するIO命令(この定義自体に副作用はなし)
(define io-revline
(io-bind io-getchar
(lambda (c)
(if (eq? c #\Newline)
(io-return 'nil)
(io-bind io-revline
(lambda (_)
(io-putchar c)))))))
; io-revlineを実行した後改行するIO命令(定義に副作用なし)
(define haskell-main
(io-bind io-revline
(lambda (_)
(io-putchar #\Newline))))

; 実行(副作用あり)
(run-io haskell-main)

712 ：デフォルトの名無しさん：2010/10/07(木) 22:50:13

かぶった、ごめんよ

713 ：デフォルトの名無しさん：2010/10/07(木) 22:54:28

>>710-712
こういうの待ってたのよ
あんがとね
何が違うのか考えてみるわ

714 ：デフォルトの名無しさん：2010/10/07(木) 23:07:55

>>711を見て思った。
関数型言語はコメントと同じようにかけないんだ。
これが手続き型などなら、コメントを英語にしたのと
同じようにかけるが、関数型言語では
コメントとかけ離れたコードになる。

715 ：デフォルトの名無しさん：2010/10/07(木) 23:11:37

>>714
Haskellだとbindが中置だしdo記法があるから、かなり手続き型っぽい見た目になるよ

あと、Haskell風IOをむりやりSchemeで実現している>>711を見て、関数型言語のスタイルをどうこう言うのは的外れだと思う

716 ：デフォルトの名無しさん：2010/10/07(木) 23:29:25

>>709
だからHaskellの過去スレ読めって言ってんだろ。
ドコドコのどこを読めばいいかなんていちいち覚えてるわけ無いだろうが。
自分で調べろ。
お前が楽して勉強するために俺がめんどくさい事する理由なんてないね。

717 ：デフォルトの名無しさん：2010/10/07(木) 23:30:32

関数型言語がなぜ普及しないのかという議論に参加したいなら
最低限下地を揃えてから出直しな。
ここはお前が勉強するためのスレじゃないんだよ。

718 ：デフォルトの名無しさん：2010/10/08(金) 00:02:01

>>716-717
おんなじことしか言えないアホはもうだまれ
お前らが普及しない理由だｗ

719 ：デフォルトの名無しさん：2010/10/08(金) 00:04:25

>>718
・スレタイ読め
・過去スレを当たれ
・ググレカス
当たり前の２ｃｈの常識しか言ってないぞ。
これができないなら半年ROMれと言われる。

720 ：デフォルトの名無しさん：2010/10/08(金) 00:12:40

実質おれの疑問に答えるスレになってるからいいじゃん
これでも普及しない要因を探ってるつもりだよ？

話を戻すと、
要するに関数の評価が必要になる順番を利用しながら
副作用のパスを矛盾がないように構築して後で実行するってことね
ひとまず理解できましたよ？

721 ：デフォルトの名無しさん：2010/10/08(金) 00:21:20

>>720
で、戻した話から導かれる「関数型言語が普及しない理由」とは何か？

探っている途中なら、考えの途中まででいいから説明してみてくれないか

722 ：デフォルトの名無しさん：2010/10/08(金) 00:22:47

printf("%3d", 1) を関数型言語で記述してみればわかる。

723 ：デフォルトの名無しさん：2010/10/08(金) 00:26:34

>>722
では Haskell で

printf "%3d" 1

724 ：デフォルトの名無しさん：2010/10/08(金) 00:39:37

Common Lispだとどうなるかなあ

(format t "~3D" 1)

正直、どれも大差ないような

725 ：デフォルトの名無しさん：2010/10/08(金) 00:40:10

てかこのアホちんこだろ

726 ：デフォルトの名無しさん：2010/10/08(金) 00:59:35

俺の大好きなprintfデバッグってできるの？

727 ：デフォルトの名無しさん：2010/10/08(金) 01:14:35

print系はCLどころかCですら混沌とした言語内言語でしょう

728 ：デフォルトの名無しさん：2010/10/08(金) 07:15:17

>>726
Haskell は IO モナド内ならお前の大好きな printf デバッグができる
IO モナド内でなければ、そもそもお前の大好きな printf デバッグする必要がない

729 ：デフォルトの名無しさん：2010/10/08(金) 08:37:54

IOモナドの外だったらDebug.Traceを使うよ

730 ：デフォルトの名無しさん：2010/10/08(金) 09:57:04

>>675
伝統的にはmonadは単子と訳すがそれで分かりやすいか？？

731 ：デフォルトの名無しさん：2010/10/08(金) 10:27:42

モナドよりはいい
串にささって単子、単子

732 ：デフォルトの名無しさん：2010/10/08(金) 10:34:38

訳されても解りにくいのは変わらんだろうなw

733 ：デフォルトの名無しさん：2010/10/08(金) 13:24:51

輪廻転生とか

734 ：デフォルトの名無しさん：2010/10/08(金) 13:51:28

概念的には
「モナド化する関数」(\a ->M b)をつなげていくことができるもの
だからな。すごく言語化しづらい。

フィルタそのもののArrowの方がまだ説明しやすいわ

735 ：デフォルトの名無しさん：2010/10/08(金) 14:06:39

>>709
モナドの概念自体はMLどころかJavascriptとかでも作れる
http://d.hatena.ne.jp/m-hiyama/20060419/1145432492

普及しないのは、普通のプログラミング言語だと
副作用のある関数を簡単に作れるからじゃないかな。
そういう関数が途中に交じるとモナドの利点が台無しになってしまう。

あと今のままだと教えるのが面倒くさいし。
名前の問題もそうだけど、もっと理解しやすい形にしないといけないのかも。

736 ：デフォルトの名無しさん：2010/10/08(金) 14:16:47

追加。上のURLのコードは
特にJavascript特有の言語機構を使ってないので大体の手続き型言語で再現できるはず
構造体っぽいのがないと厳しいかも知れんけど

737 ：デフォルトの名無しさん：2010/10/08(金) 14:43:07

>>735
お前らの大嫌いな言語内言語を使えば、副作用が途中に交じらない。
SQL も正規表現もそうやって普及した。

738 ：デフォルトの名無しさん：2010/10/08(金) 14:46:33

>>737
というか、モナドそのものが言語内言語を作る機構とも言えるよな
Persecとか

739 ：デフォルトの名無しさん：2010/10/08(金) 14:47:24

Parsecだった……

740 ：デフォルトの名無しさん：2010/10/08(金) 14:52:33

ParsecはHaskellの言語仕様に基づいたフレームワークだよ。
言語内言語というのは何らかの解釈機構が必要だけど、
Parsecには解釈機構はない。

741 ：デフォルトの名無しさん：2010/10/08(金) 22:18:54

関数型言語って副作用がある関数を作れないの？

742 ：デフォルトの名無しさん：2010/10/08(金) 22:23:28

>>741
Haskellには一応副作用がある関数を作る機能はあるし、
FFIを使えばC言語の副作用がある関数を呼ぶこともできるが、危険。
なぜなら、>>661がその理由。
複雑になるとどの関数がどの順番に呼ばれるか予想が難しい。

743 ：デフォルトの名無しさん：2010/10/08(金) 22:32:03

あと、schemeには!付きの関数など副作用がある関数はいっぱいある。
camlも副作用ある関数はいくつもある。

744 ：デフォルトの名無しさん：2010/10/08(金) 22:40:17

いえ、副作用がある関数がいっぱいあるかどうかではなく、
副作用がある関数が作れるのかってことですよ。

作れるのはわかりましたが、
もしかして作りにくいんですか？

745 ：デフォルトの名無しさん：2010/10/08(金) 22:44:22

文字通りの副作用のこと？
それとも入出力を伴う関数のこと？

前者は>>742が言うように危険。別に作りにくいということはない
後者はHaskellの初歩。日常的に作る

746 ：デフォルトの名無しさん：2010/10/08(金) 22:45:39

>>745はHaskellの話ね
OCamlやSchemeなら日常的に副作用のある関数を作る

747 ：デフォルトの名無しさん：2010/10/08(金) 22:46:58

というか、
副作用を持つ関数も、
副作用を持たない関数も
同じように作れる、手続き型言語、オブジェクト指向言語

と、

副作用を持つ関数が危険な言語では
後者、つまり関数型言語が普及しないのは
当たり前でしょという話です。

748 ：デフォルトの名無しさん：2010/10/08(金) 22:50:16

入出力を伴う関数とそうでない関数は性質がだいぶ違う
この二つに異る型を当てるか、同じ型として扱うかは一長一短の設計判断
Haskellは前者を選び、CやOCamlは後者を選んだ

749 ：デフォルトの名無しさん：2010/10/08(金) 23:01:18

>>747
でも、>>747 の言う手続き型言語やオブジェクト指向言語は、
逆にその副作用の危険性を、入門を抜けた人でもあまり意識しないから、
それがバグを生んだりすることは多いんだよ

関数型は入門の時から強制的に意識させられて、
副作用の扱い方を基礎から自然と学ぶ

まぁ、だから関数型は面倒で普及できないというのには同意

750 ：デフォルトの名無しさん：2010/10/08(金) 23:01:36

> 入出力を伴う関数とそうでない関数は性質がだいぶ違う

それは関数型言語だけでは？

751 ：デフォルトの名無しさん：2010/10/08(金) 23:02:51

>>749
関数型言語でも、副作用の有る関数を使う以上、
バグは同じように生まれる。

752 ：デフォルトの名無しさん：2010/10/08(金) 23:04:26

>>750
そんなことはないよ
例えばJavaScriptで、

var f = function (x) { return g(99) + x; };

を、

var _g = g(99);
var f = function (x) { return _g + x; };

に最適化して良いのは、gが副作用を持たない時だけ

753 ：デフォルトの名無しさん：2010/10/08(金) 23:05:15

関数型言語で、RDBMSを操作するコードを教えてください。

754 ：デフォルトの名無しさん：2010/10/08(金) 23:06:03

>>752
それはコンパイラ内部の話であって、
ユーザー（プログラム言語使用者）にとっては
関係ない話ですよね。

755 ：デフォルトの名無しさん：2010/10/08(金) 23:06:30

Haskellの場合、副作用がある関数があるかどうかは
ソースコード中のunsafeという文字列を検索すれば一瞬で突き止められる。

756 ：デフォルトの名無しさん：2010/10/08(金) 23:06:54

突き止めてどうすんだよｗ

757 ：デフォルトの名無しさん：2010/10/08(金) 23:07:13

モナドとモサドってどう違うの？

758 ：デフォルトの名無しさん：2010/10/08(金) 23:07:44

>>753
自分で書けｗ
人に頼むな。
本当にわからないなら該当スレで質問しろ。
ここは素人が紛れ込んでいいスレじゃないんだよ。

759 ：デフォルトの名無しさん：2010/10/08(金) 23:08:16

>>754
関数型言語とかreal worldにはあまり関係のない話しですよね

760 ：デフォルトの名無しさん：2010/10/08(金) 23:08:38

>>758
なぜ書けといったのか理解できませんでしたか？

関数型言語が普及しないのは、
RDBMSを操作するコードを見れば分かるってことですよ。

761 ：デフォルトの名無しさん：2010/10/08(金) 23:09:39

>>760
だったらお前が書け。
そしてコードの比較解説を自分でやれ。
やらないなら出てくるな。

762 ：デフォルトの名無しさん：2010/10/08(金) 23:10:07

なんだこれw

763 ：デフォルトの名無しさん：2010/10/08(金) 23:13:24

＞自分で書けｗ
＞だったらお前が書け。

お断りだね！

764 ：デフォルトの名無しさん：2010/10/08(金) 23:14:31

関数型でRDBMSを使ったら
副作用のあるコードばかり書かないといけなくなる。

そうなると、関数型言語を使っている意味が無くなる。

765 ：デフォルトの名無しさん：2010/10/08(金) 23:15:05

二人で書いたら良いだろ。

766 ：デフォルトの名無しさん：2010/10/08(金) 23:19:02

>>753
HaskellDBのサンプルを探したけど消えてるっぽいのでGoogleキャッシュで
http://webcache.googleusercontent.com/search?q=cache:ryssnqUKVx8J:www.haskell.org/haskellDB/example.html+haskelldb+sample&cd=1&hl=ja&ct=clnk&gl=jp [+]

>>764
それは誤解
関数型言語の利点は便利な言語機能がたくさんあることであって、
副作用の隔離は比較的どうでもいい

767 ：デフォルトの名無しさん：2010/10/08(金) 23:19:25

>>764
副作用とは関数の入出力以外の作用の事を言うんだよ。
純粋関数型言語では副作用なしにIOアクションを行う。
IOアクションは副作用ではないよ。

768 ：デフォルトの名無しさん：2010/10/08(金) 23:20:01

>>749
グローバル変数の副作用は殆どの言語で意識されたが、
auto(死語)やprivateにすれば安全だというのが多数派の結論。
それに対し、まだ安全ではないと主張する少数派が関数型言語だな。

769 ：デフォルトの名無しさん：2010/10/08(金) 23:21:23

安全まだまだこれからだ

770 ：デフォルトの名無しさん：2010/10/08(金) 23:21:58

>>751
>>749 では、普段から意識するかどうかの違いを言いたかった。

意識する事で、まずバグそのものが減る。
意識する事で、バグが出ても、どこでどのようなバグが出てるのか、
把握するまでの時間が比較的短くなる。

771 ：デフォルトの名無しさん：2010/10/08(金) 23:24:03

>>767
IOアクションばかり使っていたら、
結局関数型言語を使う意味がなくなってしまう。

外部のサーバーとの通信やハードウェアへのアクセスなんか、
もろ関数の入出力以外の作用だしな。

772 ：デフォルトの名無しさん：2010/10/08(金) 23:24:17

>>768
クラスメンバ関数内でクラスメンバ変数の値を変更するのも、副作用だよ。

773 ：デフォルトの名無しさん：2010/10/08(金) 23:26:05

>>770
そりゃ意識すれば、どんな言語でもバグは減るでしょｗ

774 ：デフォルトの名無しさん：2010/10/08(金) 23:31:19

>>772
グローバル変数に比べて副作用が小さくなればそれでいい
全か無かを考えるのは一部の人だけ

775 ：デフォルトの名無しさん：2010/10/08(金) 23:34:18

やっぱ、関数型言語が普及しないのは、
関数型言語にとって、例外的な処理や危険な処理が
実用的なソフトでは主な処理だからなんだよな。

つまり実用的なものを作ろうとしたら、
関数型言語っぽくないコードになってしまう。

それなら関数型言語にする意味無いんじゃね？って話になる。

776 ：デフォルトの名無しさん：2010/10/08(金) 23:35:19

>>773
それは当たり前。
意識する訓練を受ける時間が関数型の方が長いよね、という話。

>>749 では、手続き型では副作用の危険性を
入門を抜けた人でもあまり意識しないと言った。
少なくとも、副作用の危険性を解説した入門書は見たことがない。

一方関数型は、入門書で副作用が何かをちゃんと解説してるものが多い。
副作用を伴わない計算という特徴を紹介してるのだから当たり前。

手続き型よりも関数型の方が、意識する事に慣れさせられる。

777 ：デフォルトの名無しさん：2010/10/08(金) 23:36:13

だから関数型言語にとって入出力は危険でも例外的でもないし、
関数型言語の利点が殺されることもないって言ってるだろ
自分に都合の悪いレスを無視するのはやめようぜ

778 ：デフォルトの名無しさん：2010/10/08(金) 23:38:20

いくら副作用の危険性を説いても、
世の中副作用が有る処理が主なんだから
どうしようもない。

教育用としてはいいんじゃね？
だけど実用的じゃないから
普及しない。

779 ：デフォルトの名無しさん：2010/10/08(金) 23:39:41

あんたら詳しいならサイトでも作って説明してくれよ

780 ：デフォルトの名無しさん：2010/10/08(金) 23:41:21

簡単に消せる破壊的更新は消すに越したことはない
簡単に消せないなら無理に消さなくてもいい

781 ：デフォルトの名無しさん：2010/10/08(金) 23:42:22

>>775
関数型っぽく実用的なものを作るために、
FRP などの技術や Monad、Arrow などの仕組みがある。

あと、関数型言語にする意味は関数型っぽく書くことではないような気がする。

少なくとも Haskell でプログラムする意味のひとつは、
副作用を伴う部分と伴わない部分をしっかりと分けられる事だと思う。
手続き型でも分けられるが、Haskell の方が分け方が綺麗だ。

782 ：デフォルトの名無しさん：2010/10/08(金) 23:45:50

Haskellの何が良いかと言ったら、パターンマッチ、型クラス、遅延リスト、各種のimmutableなデータ構造
副作用うんぬんはそれほど重要じゃない

783 ：デフォルトの名無しさん：2010/10/08(金) 23:48:50

>>781
確かに、しっかりと分けることは良いことだ
マジで頼むからlazyな部分とeagerな部分をしっかりと分けてくれ

784 ：デフォルトの名無しさん：2010/10/09(土) 00:25:38

>781
FRPとか使ったとして、副作用を分離して(ﾟдﾟ)ｳﾏｰとなるのとめんどくささとでTotalではどっちが勝ちますか？
OCamlぐらいが実用的なアプリには調度良い？

785 ：デフォルトの名無しさん：2010/10/09(土) 02:47:01

そろそろ視点を変えやるか
関数型はどれもこれもGC必須なんだよ
だから普及云々以前に使われない
ランタイムは必然的に大きくなる

機能とかは最低限あればどうでもいい
シンプルに書けて速度が出てバイナリが小さい事
そしてGCがないこと
これを満たした関数型が出てくれば変わるかもしれない

786 ：デフォルトの名無しさん：2010/10/09(土) 02:55:59

GC は別に関係ないだろ。
Java なり .Net 製のアプリとか普通に見かけるよね？
むしろ GC ありじゃないと使用者も少なくなるだろ。

787 ：デフォルトの名無しさん：2010/10/09(土) 03:26:10

大いに関係あるんだよ
JavaやC#は高々1言語の問題だが、
関数型を選ぶということはGCを外せない、
GCを使わないという選択自体がまるで無理という事
これはもう関数型の欠陥と言っていいだろうねえ

788 ：デフォルトの名無しさん：2010/10/09(土) 05:27:19

> GCを使わないという選択自体がまるで無理という事

そう言う場面は限られているので、普及しない理由とは無関係だと思う。

789 ：デフォルトの名無しさん：2010/10/09(土) 08:08:22

昔々に企業がMLとかLispをプッシュしてれば状況は変わってたんだろうなあ

790 ：デフォルトの名無しさん：2010/10/09(土) 08:12:33

MLっていうと、printfデバッグがやたら面倒だった記憶しかない
コンパイルが通るとまず間違いなく動くのは
確かに新鮮な驚きと感動だったけどさ……

791 ：デフォルトの名無しさん：2010/10/09(土) 09:09:10

> コンパイルが通るとまず間違いなく動く
バグの危険性を意識する訓練が足りないようだな。

792 ：デフォルトの名無しさん：2010/10/09(土) 09:35:38

少なくとも型に関するバグはありえないね

793 ：デフォルトの名無しさん：2010/10/09(土) 11:25:34

C++んときはスマートポインタとか参照カウンタごにょごにょしてやってたけど今更さして必要もないところで自前でメモリ管理とかまぞとしか言いようがない。

794 ：デフォルトの名無しさん：2010/10/09(土) 12:36:06

法則をモデリングするときは、関数型が適しているけど、
現実世界をモデリングするときは、オブジェクト指向が適している。
それだけの話。

795 ：デフォルトの名無しさん：2010/10/09(土) 12:40:00

関数型を法則とするなら、手続き型は手順、じゃないかな。
何かをするに当たって法則よりも手順を決めることが多いから
手続き型が直感的だと思う人が多いのだろう。

796 ：デフォルトの名無しさん：2010/10/09(土) 12:43:28

現実世界のモデリングってものすごくいろいろあるけど、どういうのを考えてるの？
力学的なシミュレーションとかそういう話？

797 ：デフォルトの名無しさん：2010/10/09(土) 13:14:11

>>796
3Dゲームの世界とか。
空があって地面があって木があって人がいてとかそんなの。

他にも電子メールソフトであつかうメールがどういう実態であるかとか、
Officeソフトのファイル形式とか
画像ソフトのフォーマット形式とか
そういう物体的なもの。

798 ：デフォルトの名無しさん：2010/10/09(土) 13:17:20

今目の前に携帯電話があるのだが、
これをオブジェクト指向で作ろうとしたら、
携帯電話クラスがあって、液晶クラスを内包していて、
キー入力クラスがあって、イヤホン端子があってとか
オブジェクト指向なら素直に表現できるが、
これが関数型言語だと難しい。

799 ：デフォルトの名無しさん：2010/10/09(土) 13:21:30

手続き型も関数型も一長一短なんだろうけど
"いかに人間が楽をできるか"ってのが一番重要なんじゃないの？
どっちもどっちなら関係ないけど。

800 ：デフォルトの名無しさん：2010/10/09(土) 13:23:25

>>797
3Dゲームは良く知らないけどオブジェクト指向の得意分野っぽいね

メール、Office、画像フォーマットについてはオブジェクト指向が適しているようには思えないな
良くて関数型言語と同程度じゃないか

801 ：デフォルトの名無しさん：2010/10/09(土) 13:26:16

メールソフトだって、画面の左にフォルダツリーがあって
上のほうにリストがあって、下にプレビューがあって。
そういう構成のソフトを作るときには
結局オブジェクト指向の方が得意だねってことになるんだよ。

802 ：デフォルトの名無しさん：2010/10/09(土) 13:34:12

>>798
キー入力関数があって, その入力を処理した結果が，宛先振り分け関数にわたって,
その一部が液晶制御関数にわたって...
同じじゃん

803 ：デフォルトの名無しさん：2010/10/09(土) 13:39:52

>>802
うん。だから
外枠の全体的なものを構成するものはオブジェクト指向で
関数はその中の一処理を担当するのがいいんだよ。

で、ものづくりをするとき、一処理だけで終わるなんてのはまず無く
製品として全体的な部分（GUIなど）がどうしても必要になるから、
一部分しか作れない（作りにくい）関数型言語は普及しないということになる。

804 ：デフォルトの名無しさん：2010/10/09(土) 13:42:58

だからなんで関数型言語がGUI苦手ってことになってんだよ

805 ：デフォルトの名無しさん：2010/10/09(土) 13:44:31

モナドとか関数型言語の世界から、
外界を分離するわけだが、確かにそうすれば
関数型言語の世界はそれでうまくいくだろう。

だけど、実際問題、外界はどうしても必要なわけで、
その外界を関数型言語でどうやってプログラミングするわけ？
これが関数型言語の限界なわけ。

806 ：デフォルトの名無しさん：2010/10/09(土) 13:45:57

>>804
じゃあ、関数型言語だけで ”実装された” GUIライブラリがあるわけ？
関数型言語で呼び出すんじゃない。GUIライブラリ側の実装の話。

807 ：デフォルトの名無しさん：2010/10/09(土) 13:47:53

>>803
関数型にも普通に GUI ライブラリがあって、
何も問題なく GUI （MVC の V と C の部分）を構築できる。

一部分しか作れない（作りにくい）関数型言語というのは、
単に GUI が問題なくできることを知らなかっただけなのでは？

もしそうであるなら、「知らない」という事が普及しない理由にならないか？

808 ：デフォルトの名無しさん：2010/10/09(土) 13:48:39

で、そのGUIライブラリは
何言語で作られているのか？

809 ：デフォルトの名無しさん：2010/10/09(土) 13:53:13

>>808
たとえば Haskell だと、
今のところ広く使われているのは、OS の API を呼ぶ部分は C 言語。
その上のマルチプラットフォーム用のインターフェースはたぶん C 言語。
その上に Haskell を被せている。

しかし、Haskell は OS の API を呼べるから、
直接 Haskell で基盤の部分を構築することもできる。

それをしないのは、マルチプラットフォームで動かすのに適していないから。

810 ：デフォルトの名無しさん：2010/10/09(土) 13:56:45

今メジャーなHaskellのGUIライブラリは二つあって、
それぞれgtk(C)とwxWidgets(C++)のHaskellバインディング

>>805
外界とやりとりするためのIOモナドじゃないか

811 ：デフォルトの名無しさん：2010/10/09(土) 13:56:59

Haskell は OS の API を呼べるから、
直接 Haskell で基盤の部分を構築することもできが
マルチプラットフォームで動かすのに適していないからしない。
そのせいで普及もしない。

812 ：デフォルトの名無しさん：2010/10/09(土) 13:58:56

>>797
そんなんじゃなくて、生産管理みたいな巨大なモデルだろう。

813 ：デフォルトの名無しさん：2010/10/09(土) 13:59:11

>>810
> 外界とやりとりするためのIOモナドじゃないか

だからやりとりはできるだろうが、
外界そのものだって作らないといけないんだよ。

外界は作りにくいから、モナドを使って
他の言語に任せた！じゃいけないでしょ。

814 ：デフォルトの名無しさん：2010/10/09(土) 14:02:39

クロスプラットフォームのGUIライブラリを作るのは大変な作業だよ
自前で作るよりC/C++から借りてこられるならその方が良い

クロスプラットフォームが必要ないなら直接winAPIやxlibを呼んでもいい
xmonadなんかはそうしてる

815 ：デフォルトの名無しさん：2010/10/09(土) 14:04:07

>>811
もしかして、意味をはき違えている？

マルチプラットフォームで動かすのに適していというのは、
Haskell で Windows の API を直接呼ぶプログラムを書いてしまうと、
Linux などの他のプラットフォームとソース互換性が取れないでしょ。
移植するのにソースを大幅に改変しないといけないから面倒。
だから、基盤の部分の上にインターフェースを被せる。

Java の GUI ライブラリが直接 OS の API を呼ばないのと一緒だよ。

あと、そもそも OS の API が C 言語から呼ばれることを前提として作られているのだから、
その上に各言語のインターフェースを被せるのはしょうがないよ。
Python や Ruby だって C 言語で書かれた GUI ライブラリの上に、
自身の言語のインターフェースを被せてるよね。

普及しない理由としては的外れだと思うよ。

816 ：デフォルトの名無しさん：2010/10/09(土) 14:05:25

>>813
外界を作るってどういう意味？
外界とやりとり出来るってのはOSのAPIを呼べるってことであって、
他の言語で出来る事は基本的になんでもできるんだが

817 ：デフォルトの名無しさん：2010/10/09(土) 14:24:33

>>816
外界ってのは、状態を持ったオブジェクトのことだよ。

818 ：デフォルトの名無しさん：2010/10/09(土) 14:31:52

>>817
それなら、関数型言語が状態を持ったオブジェクトを作れない/作りにくいってのは誤解
状態を持ったオブジェクトを必要以上に作らないようなスタイルが推奨されるけど、あくまで推奨

819 ：デフォルトの名無しさん：2010/10/09(土) 14:33:41

>>817
Haskell ならステートモナドや IORef などを使えば、
状態を持ったオブジェクトを作ることができるよ。

おそらく、それでは関数型らしくないから、結局手続き型みたいになって、
手続き型の方が有利だよね、だから普及しないんだよ、
と言いたいのだと勝手に解釈してみた。

でも、ステートモナドや IORef などの状態を伝播させる仕組みを、
何かアプリを作る Haskell プログラマが直接扱うことは多くないよ。
そういった仕組みは Haskell で作られたもう一段上のライブラリの中に隠されてる。
それを使う Haskell プログラマは十分関数型っぽく書けるんだよ。

820 ：デフォルトの名無しさん：2010/10/09(土) 15:17:19

>>817
haskellなら、外界に影響を及ぼすような状態オブジェクトならIORefやIOArrayを使えるし、
外界に影響を及ぼさないならSTモナド中でSTRefやSTArrayの中身をガリガリ更新しながら使えばいい
後者の場合、中では副作用の嵐であっても外からは純粋な関数として扱えるという利点がある

821 ：デフォルトの名無しさん：2010/10/09(土) 15:41:54

>>817
ちげーよｗ
外界っていうのはIOで分けれた内と外という意味の外のほうだよ

822 ：デフォルトの名無しさん：2010/10/09(土) 15:43:07

関数型言語はお行儀が良すぎるんだなぁ。
下品な庶民には使いこなせなくて当然だ。

823 ：デフォルトの名無しさん：2010/10/09(土) 15:44:29

>>822
使いこなす必要はないよ

窓の杜なんかでフリーアプリを公開してる連中だって、
C/C++ や C#、Java なんかを使いこなしてるとは思えん

824 ：デフォルトの名無しさん：2010/10/09(土) 20:32:23

haskellで書いてもメリットがないんで

825 ：デフォルトの名無しさん：2010/10/09(土) 20:33:31

>>823
使いこなしてるからアプリが作れるんだろｗ

826 ：デフォルトの名無しさん：2010/10/09(土) 21:23:19

そのアプリを作る程度には使いこなしてるってのが言えるだけだよ。
それ以上のことは、わからない。

827 ：デフォルトの名無しさん：2010/10/09(土) 22:33:46

オブジェクト指向プログラミングができる
関数型言語がほしいな。

828 ：デフォルトの名無しさん：2010/10/09(土) 22:36:23

OCamlをどうぞ

Haskellを使っててオブジェクト指向機能が欲しくなったことが一度もないので、
どういうときに便利なのか興味がある

829 ：デフォルトの名無しさん：2010/10/09(土) 22:39:01

つcommonlisp

830 ：デフォルトの名無しさん：2010/10/09(土) 23:04:08

F# も OOP できるよね

831 ：デフォルトの名無しさん：2010/10/09(土) 23:17:51

これからはOCamlやF#のような
関数型言語としての機能を持った
オブジェクト指向言語が普及する。

832 ：デフォルトの名無しさん：2010/10/09(土) 23:42:53

だいぶ前からあるよね・・・？
これから・・・？

833 ：デフォルトの名無しさん：2010/10/09(土) 23:57:59

オブジェクト指向は終わるよ。
プロセス指向に置き換わる。

834 ：デフォルトの名無しさん：2010/10/10(日) 00:37:39

いつまでも夢見てろやｗ

835 ：デフォルトの名無しさん：2010/10/10(日) 00:42:55

はい

836 ：デフォルトの名無しさん：2010/10/10(日) 01:26:21

基本的に過去に広く使われるようになった概念って消えないからなあ
関数型が広まったとしても、手続き型もオブジェクト志向も生きてるだろうな
そうなると終着点は関数的に使える手続き型OOPLや
続き的な処理も書ける関数型OOPLになるんじゃね

837 ：デフォルトの名無しさん：2010/10/10(日) 01:43:55

オブジェクト指向は完全にプロセス指向で置き換え可能だよ。

838 ：デフォルトの名無しさん：2010/10/10(日) 02:15:00

というか名前が変わっただけで、プロセス指向＝オブジェクト指向。
言語としては何も変わってない。

839 ：デフォルトの名無しさん：2010/10/10(日) 02:45:08

>>838
は？ｗ
お前プロセス指向とオブジェクト指向の違うも理解してないの？ｗ

840 ：デフォルトの名無しさん：2010/10/10(日) 06:27:27

そもそも一般的ではない
「プロセス指向」なんて
言葉を使われてもねぇ。

２ちゃんねるでもお前ぐらいしか
言ってないだろｗ

841 ：デフォルトの名無しさん：2010/10/10(日) 09:53:18

プロセス指向より手続き指向という名前の方がずっと普及しています。
手続き型言語の世界では設計時に何に注目するかによって
手続き指向、データ指向、オブジェクト指向に分かれます。
>>837は正しいですが>>838は間違いです。

842 ：デフォルトの名無しさん：2010/10/10(日) 09:55:14

オブジェクト指向とプロセス指向の違いをごく簡単に言えば
こういうことじゃないかな、違う？

・オブジェクト指向
目的を実現させるために協力する必要がある個々の要素の間の関係に注目し、
それをプログラム構造に反映させる手法。
主に役割でモジュールを分ける。

・プロセス指向
目的を実現させるために必要な機能やデータの流れに注目し、
それをプログラム構造に反映させる手法。
主に機能でモジュールを分ける。

>>833 の言う根拠は不明だけど

843 ：デフォルトの名無しさん：2010/10/10(日) 10:23:39

>842
その解説だとプロセス指向のやってることってまんま関数型の得意分野の気がするんだが..

844 ：デフォルトの名無しさん：2010/10/10(日) 10:55:40

>>842
違うよ。
オブジェクト指向と比較した場合のプロセス指向はマネジメントの言葉ではなくて、
技術的な言葉ですよ。

プロセス指向とは：
オブジェクトを実体的なプロセス（OSが提供するプロセスに非ず。あるいはグリーンスレッド。）
によって表現し、すべてのオブジェクト＝プロセスを並列に計算する。
メッセージパッシングはサイズが決まったキューを通す。
この方法のメリットは
・マルチスレッドでもデッドロック/ライブロックが起こらない
・意識しなくともマルチコアを有効利用できる
・CSPやパイ計算などの理論的背景を持つので矛盾がない
・オブジェクト指向の設計技法を利用出来る
・関数型言語と親和性が高い

845 ：デフォルトの名無しさん：2010/10/10(日) 10:57:48

>844　アクターモデルとどうちがうん？

846 ：デフォルトの名無しさん：2010/10/10(日) 10:57:59

ビジネスプロセスモデリングとかああいうやつ？

847 ：デフォルトの名無しさん：2010/10/10(日) 11:04:29

>>845
アクターモデル CSP pi-calculus
どれもよく似ているから、これらに基づいたプログラミングをプロセス指向プログラミングと呼ぶんですよ。
確かerlangの英語版リファレンスにこの言葉が出てきたと思う。

848 ：デフォルトの名無しさん：2010/10/10(日) 11:17:38

>>844
なるほど、そういうことか。
確かに関数型に合いそうだ。

その説明でキーワードが分かって色々調べるきっかけにはなったから良いけど、
それってオブジェクト指向と「比較」した場合のプロセス指向の説明なの？
自分でオブジェクト指向の設計技法を利用出来るって言ってるじゃん。
同列で比較できるものではないような気がするんだが

849 ：デフォルトの名無しさん：2010/10/10(日) 11:19:21

>>848
利用出来るよ。
詳しくは俺の博士論文を。

850 ：デフォルトの名無しさん：2010/10/10(日) 11:22:58

>>849
その博士論文へのリンクを貼ってくれないと読めないです

851 ：デフォルトの名無しさん：2010/10/10(日) 11:26:19

>>850
恥ずかしいので自分で探してください

852 ：デフォルトの名無しさん：2010/10/10(日) 11:29:57

>>851
論文の公開を恥ずかしがる人間の心理が全く分からないですが、
ここにリンクを提示できない理由があるのなら仕方がありませんね。

探してみますので、タイトルなど何かそれと分かるキーワードは無いでしょうか

853 ：デフォルトの名無しさん：2010/10/10(日) 11:32:01

2chに書き込んでるのがバレるのが恥ずかしいわけだが

854 ：デフォルトの名無しさん：2010/10/10(日) 11:36:29

>>853
じゃあ２ちゃんに来るなよ
はずかしいやつだな

855 ：デフォルトの名無しさん：2010/10/10(日) 11:36:34

>>853
では、論文のありかも示さないまま
>>849 で「詳しくは俺の博士論文を」と言った理由は？
少し矛盾してませんか

>>849 なんて初めから言わなければいいと思うのですが

856 ：デフォルトの名無しさん：2010/10/10(日) 11:38:19

自己顕示欲はあるが２ｃｈバレは恥。
その間の葛藤ってところかな。

857 ：デフォルトの名無しさん：2010/10/10(日) 11:47:14

そんな極個人的な葛藤をここに持ち込まんでほしいな
大人のくせに、博士のくせに

858 ：デフォルトの名無しさん：2010/10/10(日) 11:52:09

この世には大人も子供もいないよ。
あるのは年齢に関係ない知識と経験の差だけ。

859 ：デフォルトの名無しさん：2010/10/10(日) 14:41:20

仮に知識と経験があったとしても、根拠を示せなければ論外だろ。

860 ：デフォルトの名無しさん：2010/10/10(日) 15:04:20

淡々と引用すれば、本人とは思われなかったと思うな

861 ：デフォルトの名無しさん：2010/10/10(日) 16:17:27

プロセス指向とオブジェクト指向は、
共存する。
使う場所が異なるから。
野球チームの監督ができれば、
システムを組めるようになる。
選手の動作は、オブジェクト指向で定義して
選手同士の相互作用、すなわち
並列的なルール、ロジックはプロセス指向で組めるようになる。

862 ：デフォルトの名無しさん：2010/10/10(日) 16:39:38

共存は結構だけどこれも入れてあれも入れて、
ってなったらごちゃごちゃして分けわかんなくなったりしない？

863 ：デフォルトの名無しさん：2010/10/10(日) 16:45:32

>>861
使う場所は同じだろ。
全く同じ場所で使える。
オブジェクト指向はプロセス指向で置き換えられるが、
プロセス指向はオブジェクト指向で置き換えようとすると設計変更が必要になる。

864 ：デフォルトの名無しさん：2010/10/10(日) 16:46:19

どちらが優れているかは明らかだ。
プロセス指向があればオブジェクト指向は要らない。

865 ：デフォルトの名無しさん：2010/10/10(日) 17:27:33

普通はオブジェクトの分割単位がアクターの単位となるだろJK

866 ：デフォルトの名無しさん：2010/10/10(日) 18:57:23

オブジェクト指向が一番外にあって、
その中に手続き型、関数型、プロセス指向が
含まれるって感じ。

一番外のオブジェクト指向を使わないで
中だけ使う方法もあるが、ほかシステムとの連携なんかを
考えるとオブジェクト指向でラッピングしたほうがいい。

867 ：デフォルトの名無しさん：2010/10/10(日) 20:06:41

>>866
どう考えても逆だろ。
オブジェクト指向で組まれたシステムは一つのプロセスの中で動かしたほうが良い。

868 ：デフォルトの名無しさん：2010/10/10(日) 21:09:20

結局どっちなんだよ

感じとか、常識とかじゃなくって、
もっと論理的に話してくれ

869 ：デフォルトの名無しさん：2010/10/10(日) 22:22:25

論理的に話すような中身がないからこうなってるんだよ。
プロセス思考だとか言ってるのはただの一学生の妄想話。

870 ：デフォルトの名無しさん：2010/10/10(日) 22:48:20

>>869
いや、process-orientedでググッてみろよ。
論文とかでこの言葉を使ってる人は結構いるぞ。

871 ：デフォルトの名無しさん：2010/10/10(日) 23:37:02

プロセス　= イベントループ　＋　状態遷移マシン

なんだよ。
まあ、プロセスは、while(1)の無限ループつくって、そのなかでメッセージを
うけとる。システムで共有するqueueをつかってな。コンカレントキュー。
そのメッセージをプロセスがもってる状態遷移マシン、つまり
デザインパターンでいうステートにわたして適切な処理をする。

んで、プロセスとか、メッセージとかキューとかステートっていうのは
オブジェクトで作ると便利かな、っていう程度でオブジェクト指向をとりいれればいい。

872 ：デフォルトの名無しさん：2010/10/11(月) 00:07:11

オブジェクト指向は要らないよｗ
完全に独立した処理単位さえあれば不完全なオブジェクトなどいらんｗ

873 ：デフォルトの名無しさん：2010/10/11(月) 00:22:03

完全に独立した処理単位なんて普遍的にあるわけない。
不完全なものを組み立てるというところにも技術が出てくる。そのための工学。
オブジェクトはオブジェクトで必要なわけで、関数型がその領域に入り込む
余地があるかどうかというところが問題だ。

874 ：デフォルトの名無しさん：2010/10/11(月) 00:32:47

>>873
しかし、オブジェクトはすべて独立していて、
メソッド呼び出しによって内部の状態（フィールド）を書き換えるわけだろ？
問題はあるオブジェクトを処理中に別のオブジェクトの時間は完全にストップしていることで、
本来のオブジェクトの在り様とはは少し違うってことだね。
よりオブジェクトらしいオブジェクトをつくろうと思ったらプロセスになるんだよ。

875 ：デフォルトの名無しさん：2010/10/11(月) 00:38:43

>>872
Erlangで全部のインスタンスに1つのプロセスを割り当てるようにしてみたところ、
さすがに耐え難いパフォーマンスになったという報告が読んだことがあるような
粒度として、オブジェクト指向のオブジェクトは小さすぎるのだろう

876 ：デフォルトの名無しさん：2010/10/11(月) 00:39:58

>>875
読みたいからソースおしえて

877 ：875：2010/10/11(月) 00:41:46

うん。ソースが出せないから困ってる
どこで読んだんだ……？

878 ：デフォルトの名無しさん：2010/10/11(月) 00:46:32

>>875
さすがにリバーシをプロセス指向で設計する時に
StoneオブジェクトやPointオブジェクトを
そのままプロセスで実現しようとは思うまいｗ
もちろんそんな細かいオブジェクトもプロセスで表現可能だが、
やっぱりそこは考えなきゃいけないところだよねｗ

879 ：デフォルトの名無しさん：2010/10/11(月) 00:53:14

関数型言語にありがちな代数的データ型とか利用すれば
細かい系のオブジェクトは作らなくて済むよね

880 ：デフォルトの名無しさん：2010/10/11(月) 01:09:49

オブジェクト＝ハーバードアーキテクチャ
プロセス＝フォンノイマンアーキテクチャ

881 ：デフォルトの名無しさん：2010/10/11(月) 01:21:04

何故これほど話がかみ合わない

権威ある人の論文や記事を出して、
こういうことだとズバッと言えばすむ事ではないのか

882 ：デフォルトの名無しさん：2010/10/11(月) 01:28:36

虎の威を借りなければ何もできないのか？

883 ：デフォルトの名無しさん：2010/10/11(月) 01:35:26

独自の概念なのか、そうでないかが問題になってるんじゃないの
そうなると虎の威でも何でもないと困ると思うが

884 ：デフォルトの名無しさん：2010/10/11(月) 01:35:59

独自だと何が困るの？

885 ：デフォルトの名無しさん：2010/10/11(月) 01:37:07

>>882
ここの連中の数行しかない書き捨て文よりは、
論文の方がはるかに分かりやすくて信用できるとは思わんか

886 ：デフォルトの名無しさん：2010/10/11(月) 01:43:30

>>885
そこまで厳密性を求めていないでしょ。

887 ：デフォルトの名無しさん：2010/10/11(月) 01:49:03

>>872
昔、一部の人がエージェント指向をもてはやした事がありました。
あなたと同じ言い方でこうも言えます。
「プロセス指向は要らないよｗ
サーバから完全に独立したエージェントさえあれば不完全なプロセスなどいらんｗ」

オブジェクト指向は大規模ソフトウェア開発というニーズに答えて普及しましたが、
エージェント指向はソフトウェア業界にニーズがなく普及しませんでした。
プロセス指向もそれで解決できるニーズがないと普及しないと思うんですが、
プロセス指向はいったい何を解決できるのですか？

888 ：デフォルトの名無しさん：2010/10/11(月) 02:02:59

>>887
えっと、エージェント指向ってセルラオートマトンの一種を利用したプログラミングじゃなかったけな。
エージェント指向でぐぐったらITProの記事が出てきたけど、
ここに書いてあることって全部嘘っぱちだよね。

889 ：デフォルトの名無しさん：2010/10/11(月) 02:10:29

エージェント指向というのはすでに昔から実運用されている概念であって、
言葉が作られた時点ですでに普及していたんだよ。
ネットワークを介していろんなアプリケーションサーバが連携しあうのは、
今では普通のコトでしょ。

890 ：デフォルトの名無しさん：2010/10/11(月) 09:03:59

プロセス指向はなぜ普及しないのかを考えるスレになったな。

891 ：デフォルトの名無しさん：2010/10/11(月) 09:09:33

>>888
自分の頭にあることのほうが正しいと思いたがる動物の性を
まざまざと見せつけられましたｗ

892 ：デフォルトの名無しさん：2010/10/11(月) 09:39:36

>>881
話を噛み合わせるのは無理だ。というより、手法のすり合わせをするのは無理だ。
各個人ごとに思い入れのある手法やら現在研究している手法だかがあるわけで、
それを放棄しろといってるようなもんじゃん。
するべきは、どういう手法をとるかということじゃなくて、手法はなんでもいいけど
どういう方針でやっていくべきなのかを考えるべきだ。

893 ：デフォルトの名無しさん：2010/10/11(月) 10:28:22

まああれだ。
現実にあるシステムを
そのままの形でコンピュータ化するのが
一番分かりやすい。

目で見た物に対して、○○オブジェクトと
するだけで、コンピュータ化するときの
名前そのものになるオブジェクト指向が一番分かりやすいのさ。

894 ：デフォルトの名無しさん：2010/10/11(月) 10:32:45

もちろんある種の抽象は必要だけどね
今ならDCIか
そういやDCIはScalaと相性がいいらしいな

895 ：デフォルトの名無しさん：2010/10/11(月) 10:46:43

> 目で見た物に対して、○○オブジェクトとするだけ
MVCがVVVになるな

896 ：デフォルトの名無しさん：2010/10/11(月) 10:58:54

>>892
いや、かみ合わないとまずのではと思ってるのは互いの独自の手法ではなくて、
現在の話の文脈内における「オブジェクト指向に対してプロセス指向って何なの？」の事。

その根幹の部分が、関数型は何故普及しないのかという
会話をしている人間の中でちゃんと噛み合ってないと、
そのプロセス指向を知らなかったから普及しないのか、
プロセス指向が関数型に合わないから普及しないのか、
プロセス指向は合うけどそれを補うオブジェクト指向が合わないのか、
という話に一向に進まないよ。

現に、関数型の普及という話からは遠ざかってるじゃん。

だから、権威ある人の論文なり記事なりを出して、
とりあえずこの文脈の中だけでも「結局プロセス指向って何」を
仮定しておいた方が会話がより健全な方向へ進むと思うんだ。
（ここでグダグダ言い合うよりもね）

なんなら別に権威はなくても、、
審査をちゃんと通った博士論文でも良い。

897 ：デフォルトの名無しさん：2010/10/11(月) 11:02:42

現実にあるものの情報をそのままコンピュータに取り込めればいいんだけどね。

898 ：デフォルトの名無しさん：2010/10/11(月) 11:34:58

>>897
情報を「そのまま」送ると、クラスもオブジェクトもないoctet-streamになる。
「そのまま」では満足できない奴らがオブジェクトを発明した。

899 ：デフォルトの名無しさん：2010/10/11(月) 11:56:37

不要な情報は捨てて計算可能な単位に加工しないといけないわけね。

900 ：デフォルトの名無しさん：2010/10/11(月) 12:01:45

何を以って必要、不要とするか
エンドユーザーまたはドメインのエキスパートの認識を忠実にマッピングしてそれをベースにするのが
よさげってのがDCIのD
ただし、この認識が不変であるものじゃないと色々大変なことになる
だから初期のヒアリングが重要なわけね

901 ：デフォルトの名無しさん：2010/10/11(月) 12:06:46

>>893
だから、そのオブジェクト指向でのオブジェクトが
現実とはかけ離れたものだと言ってるんだよ。
あるオブジェクトにメッセージを送って帰ってくるまでの間、
他のオブジェクトはただじっとしているだけって不自然でしょ？
普通に考えてみなよ。
AさんとBさんが会話している間、Cさんはおとなしくしているわけがないでしょ？
それぞれ独立して計算しないとオブジェクトとは言えないでしょうが。
より独立性の高いオブジェクトがプロセスなんだよ。

902 ：デフォルトの名無しさん：2010/10/11(月) 12:22:36

>>901
AさんとBさんが会話している間、
Cさんはおとなしくしてもらってかまわないんだが、

人間が何かしているはずだからって
Cさんにも何かさせるのか？
CPUの無駄遣いじゃね？ｗ

903 ：デフォルトの名無しさん：2010/10/11(月) 12:25:11

要するにオブジェクト指向のオブジェクトを
すべて1スレッドとして生成すればいいだけ。

これもまたオブジェクト指向で実現可能なこと。
こういうのは、パターンと呼ばれる。

プロセス指向ってのは新たな言語とかオブジェクト指向を
置き換えるものではなく、ただのオブジェクト指向の
パターンの一つでしかない。

904 ：デフォルトの名無しさん：2010/10/11(月) 12:26:29

>>902
Aさんはマネジャ、Bさんは販売員、Cさんは造花職人
だったとしたら？
オブジェクト指向だったら
AさんがBさんに造花を売るように指示を出している間、Cさんは造花づくりをサボる。
AさんがCさんに造花を作るように指示を出している間、Bさんは店をほっぽり出すわけだ。

905 ：デフォルトの名無しさん：2010/10/11(月) 12:28:57

>>903
それじゃあもう既にオブジェクト指向とは呼べないねｗ
メッセージパッシングする相手が送りたい直接のオブジェクトじゃないんだから。

906 ：デフォルトの名無しさん：2010/10/11(月) 12:31:58

目的のオブジェクトにメッセージを送るためにゴチャゴチャとした中間者を通さなきゃいけない
ようなスタイルは屁理屈オブジェクト指向と呼ぼうｗ

907 ：デフォルトの名無しさん：2010/10/11(月) 12:36:07

プロセス指向なら単にABC3つのプロセスを作るだけで良い。
至極単純。
オブジェクト指向で並列パターンを設計する必要など無い。

908 ：デフォルトの名無しさん：2010/10/11(月) 12:41:28

>>902
Cさんは自分の仕事をするだけだろ。
仕事がなくなったら誰かが会話にくるまでおとなしく待っている。
その間はCPU時間を使わない。

909 ：475：2010/10/11(月) 13:00:27

アクセス規制でとっても遅レスになったけど、とりあえずカキコ

>>550
関数型という概念の特徴を一言で言えば「宣言的(declarative)かつ作用的(applicative)」です。
宣言的とは、物事を静的な関連として表現することを意味し、暗黙的な(時間の経過を含む)状態の変化を考慮しません。
宣言的ではない概念の代表が「手続き型(あるいは手順型、命令型)」であり、状態を変化させる命令の反復で表現します。
宣言的な概念には、関数型の他にも論理型や代数型などがあります。
宣言的な概念の一つである論理型は、物事の対象物(集合)の間にある関連を命題(言明)で表現します。
関数型は、関連のサブクラスである関数(写像)によって物事を表現し、関数に対象物を作用(適用)させる事が特徴的です。

次に例を示します。まず階乗(n！)のアルゴリズムを考えます。たとえば「x := 0; for i := 1 to n; x := x * n」と
「f(n) ::= if n = 0 then 1 else n * f(n - 1)」を比較して、直感的に後者の方が分かり易いと感じたなら、その人は
関数型的な思考プロセスの持ち主だといえるでしょう。

更に、関数型的な思考プロセスにもその抽象化レベルに差異(段位)があります。低レベルから高レベルへ列挙してみます。
・入門級：再帰関数による反復の抽象化(上で示した階乗計算)
・初級：　map/filterといった高階関数を利用した列構造処理の抽象化
・中級：　無限リスト(あるいは遅延リスト)を利用したストリーム指向/データフロー指向
・上級：　モナド/アローを利用した関数代数指向(圏論の応用)
・達人級：モナド/アローに変わる新しい概念を考案/設計できるプログラム代数/プログラム変換指向
この段位は、私の勝手な解釈ですので、異論/反論は大いに認めます。

ちなみに>>844が言うところの「プロセス指向」は、この関数型的思考プロセス段位であれば「中級」に相当します。

910 ：デフォルトの名無しさん：2010/10/11(月) 13:03:35

別にOOPでもスレッドにするだけだと思うんだけどな。
というか、両者はそもそも相反する要素なのか？

911 ：デフォルトの名無しさん：2010/10/11(月) 13:07:53

>>910
メッセージの方式が違うだけ。
キューに入れるか関数を呼ぶか。

純粋関数型言語だったら、キューは副作用があるから関数を使うべきだろうな。

912 ：デフォルトの名無しさん：2010/10/11(月) 13:10:06

>>910
オブジェクト指向にとってのスレッドって抽象化レベルでの異物だろ？
スレッドを扱うためには手続き的なロック/アンロック機構を使ってアトミック性を保障しなきゃいけない。
まずその段階でデッドロック/ライブロックの可能性に頭を悩ませながら、バグと戦わなければならない。
しかも並列化はオブジェクト指向にとっての異物だから、
それを扱うために設計レベル/実装レベルともに余計な複雑さが混入する。
プロセス指向ではそういった心配事から開放される上に、
メッセージパッシングによる本来の意味でのオブジェクト指向的な抽象化を実践することができるんだよ。
これを従来のオブジェクト指向に対してプロセス指向と呼ぶ。

913 ：デフォルトの名無しさん：2010/10/11(月) 13:10:55

>>911
スレッドセーフなキューの実装は存在するよ。

914 ：デフォルトの名無しさん：2010/10/11(月) 13:11:48

間違えた

スレッドセーフでIOのないキューの実装は存在するよ。

915 ：デフォルトの名無しさん：2010/10/11(月) 13:14:15

>>912
> オブジェクト指向にとってのスレッドって抽象化レベルでの異物
> 並列化はオブジェクト指向にとっての異物

それって「非プロセス指向にとってのスレッド」の間違いじゃないの？
ロック/アンロック機構が云々ってのもOOPに限った話じゃない。
要は「プロセス指向でないもの」に共通の話じゃないか。何故OOPと対比する？

916 ：デフォルトの名無しさん：2010/10/11(月) 13:15:22

>>915
並列化を考慮している抽象化技法は他にいくつもあるよ。
プロセス指向だけじゃない。

917 ：デフォルトの名無しさん：2010/10/11(月) 13:17:35

確かにロックはバグの温床であり、スレッドプログラミングを難しくしている原因だね。

918 ：デフォルトの名無しさん：2010/10/11(月) 13:17:53

>>916
そうすると尚更「OOPvsプロセス指向」の話でなくなってしまうんだけど。

919 ：デフォルトの名無しさん：2010/10/11(月) 13:21:50

話をまとめよう
一体お前らは何の話をしているんだ？
関数型言語はなぜ普及しないのかを議論しているんじゃなかったのか？

920 ：デフォルトの名無しさん：2010/10/11(月) 13:22:33

いっとくがオブジェクト指向とアクターモデルと関数型はすべて共存できるし、システムはそうなってたほうが自然。

921 ：デフォルトの名無しさん：2010/10/11(月) 13:26:50

>>920
> アクターモデル
アクターモデルはパラダイムではなくて理論。
プロセス指向を説明する理論はアクターモデルだけじゃなくて、
pi-calculusなどもあるし、ホーアのCSPもある。
他にもいろいろあるね。

922 ：デフォルトの名無しさん：2010/10/11(月) 13:31:52

少なくとも
「すべてはオブジェクトである」と言っているオブジェクト指向パラダイムと
「すべてはアクターである」と言っているプロセス指向パラダイムとでは、
相容れないことは明白だよねｗ

923 ：デフォルトの名無しさん：2010/10/11(月) 13:36:41

>>919
メッセージキューの重要性と、キューには副作用があるのかどうかについての話
OOPは、メソッド≒関数という立場を取っているために巻き添えを食らった

924 ：デフォルトの名無しさん：2010/10/11(月) 13:38:10

みんな語ってくれないな
XX指向って言ってる奴にかぎって, 数式与えてもまともなものが上がってこない
現実に付いては………

925 ：475：2010/10/11(月) 13:38:53

>>833から必死に「プロセス指向」を推しているヤシがいるけど、おそらく「Erlang Part2」スレで
「あらゆる並行プログラミング言語はプロセス指向である」と言い切ったのと同一人物なんだろね。
以下は「Erlang Part2」スレ#74からの引用

>> また、CSPを基礎理論とするOccamやGHC(KL1)等も
>> プロセス指向言語と呼んだほうが正しい分類なのか？
>
>そうだよ。

かなり思い込みの激しい性格らしい(自称：博士さん？)から、このレスに絶句したよ。
プロセス指向について議論を続けるなら、その前に「Erlang Part2」スレの#61-83を一読することを勧める。>>all

926 ：デフォルトの名無しさん：2010/10/11(月) 13:42:14

「>>all」

これがでるとは思わなかった
過疎板は一味違うなー

927 ：475：2010/10/11(月) 13:49:33

プロセス指向の「プロセス」という言葉に惑わされる人もいるだろうから、
元祖「Erlang」スレ(dat落ち)の#839にカキコした内容をコピペしておく。

>まず、一般的なプログラミング言語と比較すると、Erlangのスレッドは粒度が非常に小さい、
>言い換えると、スレッド生成やスレッド間通信のコストが極端に低いということを理解してくれ。
>普通の言語が関数(あるいは手続きやメソッドと言い換えてもいい)を呼び出すのと同じ感覚で、
>Erlangではスレッドが生成する。つまり、関数呼び出しとスレッド生成が(Erlang)では等価になる。
>
>次に、質問にあったTreeやListといったデータ構造を、Erlangではどのように処理するのか？という点。
>ちょうどWikipediaのErlangのページにListをQuickSortする処理が紹介されているから、それを嫁。
>あるListを受け付けたErlangスレッドのQuickSort処理内容を、以下に解説する。
>
>(1) そのListの先頭要素について、ある値(Pivot)より大きい部分Listと小さい部分Listに分割し、
>(2) それらを処理する2個の子スレッドを生成して、それら部分リストを渡し、
>(3) 子スレッドの処理結果(ソートされた2個の部分List)と値(Pivot)を結合して、それを処理結果として返す。
>
>普通のプログラミングでは関数呼び出しの箇所が、Erlangではスレッド生成に置き換えられていることが
>分かってくれるだろうか。Tree処理も同じだ。Treeの各ノードを辿りながら、そのノードに対応する
>子スレッドを次々に生成し、それら子スレッドの「協調計算」の最終結果がTree全体の処理結果になる。
>
>逐次言語に後付けでスレッド機構を組み込んだ、一般的なプログラミング言語に慣れた多くの人にとって、
>このような協調計算型プログラミングモデルの認知には、発想の転換が求められるよ。
>Erlangプログラマには、資源の排他制御などという原始的な仕掛けは見えないし、見る必要性が無い。
>プログラマは本質の平行処理・分散処理(=協調型計算)のアルゴリズム設計に集中できる。

>>878
StoneオブジェクトもErlang等ならプロセス(スレッド)で実現される。Pointオブジェクトは微妙だけど（w

928 ：デフォルトの名無しさん：2010/10/11(月) 14:01:08

>>922
でも実際のところ、OOPLでOOを徹底してる言語って少ないし
関数型でも純粋なものとそうでないものもあるワケだから
そこら辺うまく折衷してやれば相容れないってほどでも無いんじゃないか？

929 ：デフォルトの名無しさん：2010/10/11(月) 14:17:04

> プロセス指向ではそういった心配事から開放される上に、

ま、こういうのはたいてい嘘ｗ

ただし、○○の場合はって例外事項が出てくる。

930 ：475：2010/10/11(月) 14:20:22

>>919
もちろん個人的な見解だけど、Haskell流のモナドやアローの概念って、
普通の(手続き型言語思考に染まった)プログラマには理解不能だと思う。
おそらく、既存のモナドやアローを使った関数型プログラミングはできるようにはなるだろう。
でも、(彼らが)自分で直面した問題/課題に対して、独自のモナド/アローを新規に考案/設計できるか？となると
大いに疑問が残る。はっきり言って、圏論の概念を(直感的/感覚的でもいいから)理解していないと無理だと思う。
だから、このままじゃあHaskellが一般のプログラマに普及するのは絶望的である、と悲観視している。
もちろん、理解できるヤシだけが使えればいいという「選民指向」な発想もありだとは思うがね....。

それに対して、能動的なアクター(or オブジェクト)とそれらの間のストリーム(or データフロー)で
システムの振る舞いをイメージできる、(>>844が言うところの)「プロセス指向」は、
関数型的思考プロセス段位であれば「中級」に相当するレベルだから(>>909)、
一般のプログラマにも普及する見込みがあるのでは？と考える。

931 ：デフォルトの名無しさん：2010/10/11(月) 14:41:22

>>930
> でも、(彼らが)自分で直面した問題/課題に対して、独自のモナド/アローを新規に考案/設計できるか？となると
> 大いに疑問が残る。はっきり言って、圏論の概念を(直感的/感覚的でもいいから)理解していないと無理だと思う。
> だから、このままじゃあHaskellが一般のプログラマに普及するのは絶望的である、と悲観視している。

「独自の」モナド/アローを新規に考案/設計しなければ解決できない問題とは、
たとえばどんなものが挙げられる？

俺は、一般のプログラマがそういうものに出会う機会はそれほど多くないと思う。
まぁ「一般のプログラマ」の定義にもよるが、たとえば趣味でゲームを作ってる奴、
会社内で事務系ツールやアプリを作ってる奴らは、そういうものに出会うかな？

Yampa を使って FPS を作る例（The Yampa Arcade）がある。
独自にモナド/アローを新規に考案/設計しなくても、
既存の Yampa を使ってこれくらいのことは出来る。

932 ：デフォルトの名無しさん：2010/10/11(月) 14:46:51

>>931
間違えた

誤 The Yampa Arcade

正 The University of New South Wales School of Computer Science and Engineering

933 ：デフォルトの名無しさん：2010/10/11(月) 14:49:50

>>930
> もちろん個人的な見解だけど、Haskell流のモナドやアローの概念って、
> 普通の(手続き型言語思考に染まった)プログラマには理解不能だと思う。

逆もまた然り

934 ：デフォルトの名無しさん：2010/10/11(月) 14:54:59

>930
とりあえず数学的用語を使わずにモナドを説明したもので理解できるかどうかが鍵になると思われ

935 ：475：2010/10/11(月) 15:03:13

>>931-932
確かに、事務系アプリやゲームアプリの開発環境って、ほぼ部品(コンポーネント)がそろっているから、
それらを(VB系ならDrag&Drop操作だけで)組み合わせることで、大半は用が済むんだよね。

問題は、そのような現実世界の開発現場で利用できるモナド/アローが(現時点では)整備されていない点。
自分もモナド/アローと格闘中の段階だから、Yampaとか詳しく知らないけど、それって
開発現場で即利用できるパッケージ(たとえば帳票印刷パッケージとかバーコード表示コンポーネント等)ではなく、
(UNIX C であれば yacc&lex とかに相当するような)もっと低レベルな仕組みではないのかな？

936 ：デフォルトの名無しさん：2010/10/11(月) 15:07:57

そんな難しい概念を正確に理解することを要求していたら普及するわけないでしょ。
あれらはそれこそプログラムではない領域のため。

937 ：475：2010/10/11(月) 15:16:03

>>933,934
たとえば、Erlangのような(>>844が言うところの)「プロセス指向」であれば、
>>927 にカキコしたように、自分でも他人に(おそらく分かり易い)説明ができるんだ。
でも、Haskellスレは常時ROMしていて、たびたび「モナド/アローを分かり易く説明してくれ」という
要望は見かけるんだけど、まともなレスは皆無に近い。(「Arrowの紹介 for 2ch」は希有な存在)
おそらく、まだ誰も(他人に自分の言葉で簡潔に説明できるほど)理解してるヤシはいないんじゃないかと想像w

938 ：デフォルトの名無しさん：2010/10/11(月) 15:17:49

流れぶった切ってしまって申し訳ないけど、無意識的にだとは思うが、
教義化させようとするのはまずい。また閉じた世界にするのか？

939 ：デフォルトの名無しさん：2010/10/11(月) 15:20:04

arrowはパイプっていう感覚で使ってるな
モナドは結合ができるファンクタって感覚
使う上の理解じゃその程度で十分、つうかその程度の理解で使える設計のライブラリじゃねぇと誰も使えない

940 ：デフォルトの名無しさん：2010/10/11(月) 15:20:59

>>935
Yampa はアローを使用した FRP のひとつだ。
昔の FRP ではリークが起きるという問題/課題に直面し、
それを解決するために新規に考案/設計されたアロー（の応用）だ。
（それだけを解決するために作られた訳ではないが）

言いたかったのは、自分で作るひとはごく僅かで、
大半の人はその技術をライブラリという形で利用するということ。
現時点では整備が「まだ足りない」というのは同意。

しかし、君の考え
「圏論の概念を理解できないからHaskellが一般のプログラマに普及するのは絶望的」
というのは疑問だ。

> 問題は、そのような現実世界の開発現場で利用できるモナド/アローが(現時点では)整備されていない点。

という反論の仕方では、整備されれば「モナド/アローを深く理解しなくても」
普及できるかも知れないと言っているように聞こえるぞ。

941 ：475：2010/10/11(月) 15:25:14

>>936
えーと、>>935で書いた帳票印刷パッケージとかバーコード表示コンポーネントのような
事務系パッケージって、そのパッケージ開発ベンダにとってはプログラミングそのものなんです。
で、そういったパッケージ開発ベンダってのは大企業から中小企業まで現実に存在してるわけで、
そんな彼らは難しい概念を正確に理解しないとパッケージなんて設計できないはずですよ。
過去のオブジェクト指向の普及であれば、まだ手続き型言語思考の延長でしたからなんとかなったけど、
モナドやアローの設計ってそうはいかない(一から勉強し直し)のではないでしょうか？

942 ：デフォルトの名無しさん：2010/10/11(月) 15:30:53

なんか理論ばかり先行していて、
実際に動くものを作ったことある？
って質問したくなる奴がいるな。

943 ：475：2010/10/11(月) 15:35:06

>>940
>という反論の仕方では、整備されれば「モナド/アローを深く理解しなくても」
>普及できるかも知れないと言っているように聞こえるぞ。

>>935の冒頭で書いたように、業務パッケージが整備されればHaskellも普及すると思うよ。
でも、整備が終わるのは(今から数えて)１０年以上は必要になるんじゃないかと。

スレタイを「Haskellは何故【今普及していない】のかを考える」、あるいは
「Haskellは【今後数年のうちに普及するようになる】かを考える」と解釈すれば、NO だと考える。
もし「Haskellは【未来には(１０年以上先の世界では)普及している】かを考える」であれば、もちろん YES。

Haskell以外の関数型言語(たとえば F# や SMLなど)であれば、また話は変わるけどね。

944 ：デフォルトの名無しさん：2010/10/11(月) 15:36:16

プロセス指向とやらで、
猫オブジェクトをどうやって表現するの？

猫、鳴く、にゃーにゃー。
猫、名前、タマ

みたいなの。

945 ：デフォルトの名無しさん：2010/10/11(月) 15:37:34

ついでに関数型でも

946 ：デフォルトの名無しさん：2010/10/11(月) 15:41:43

動詞、名詞、形容詞、
言葉がなぜこういう風に分けられているのかを考えると、
こういう風に分けるのが理解しやすいからではないのだろうか？
関数型って全部動詞でしょ？

947 ：デフォルトの名無しさん：2010/10/11(月) 15:43:18

そんなの、構造体さえあればオブジェクト指向なんぞなくてもできるんじゃないのか
get_name(cat) => tama
みたいな。少なくともHaskellにはある

948 ：475：2010/10/11(月) 15:51:55

>>947
ところがぎっちょん、>>909で書いたけど、純粋な関数型言語は時間の概念が無いから、
get_nameから戻るとタマの存在は消えてしまうんだよね。"tama" という名前は残るけど。
だから、Haskellの場合だと、ステートモナドを使ってタマの存在が継続することを表現しなきゃならない。
ここでもモナド・モナド・モナド・モナド・モナド・モナド・モナド........。

949 ：デフォルトの名無しさん：2010/10/11(月) 15:54:06

結局は、インスタンスがモナドに名前が変わっただけ？

950 ：デフォルトの名無しさん：2010/10/11(月) 15:54:08

>>941
> そんな彼らは難しい概念を正確に理解しないとパッケージなんて設計できないはずですよ。

いや、それほど正確に理解しなくても作れる。
圏論の概念など直感的/感覚的にすら理解できなくても作れる。
IO モナドをどう使えば何が出来るか、何が出来ないか、
Arrow を使えばどう記述しやすくなるか、ならないか、
それを知っていれば作れる。

逆に訊くが、バーコード表示コンポーネントに
圏論の概念の何が必要か挙げてくれ。

951 ：デフォルトの名無しさん：2010/10/11(月) 16:00:03

>>944
perl製

use threads;
use Thread::Queue;

my $q = Thread::Queue->new;
my $th = neko($q);
$q->enqueue({command=>'namae'});
$q->enqueue({command=>'nake'});
$q->enqueue({command=>'sine'});
$th->join;

sub neko {
my $q = shift or die $!;

return threads->new(sub {
while (1) {
my $message = $q->dequeue();

if ($$message{command} eq 'namae') {
print "タマ\n";
} elsif ($$message{command} eq 'nake') {
print "にゃーにゃー\n";
} elsif ($$message{command} eq 'sine') {
print "ぎゃーーーーー\n";
last;
}
}
});
}

952 ：デフォルトの名無しさん：2010/10/11(月) 16:05:38

Perlはオブジェクト指向言語だっけ？

953 ：デフォルトの名無しさん：2010/10/11(月) 16:07:28

>>952
packageをクラスに見立ててオブジェクト指向は実現できるよ。

954 ：デフォルトの名無しさん：2010/10/11(月) 16:08:23

>>951
それ、nakeと命令したら、にゃーにゃーと言って、
sineと命令したら、ぎゃーと言って、
namaeと言ったら、タマと言う猫になってるよｗ

人語を話す猫はちょっと想定外ｗ

955 ：デフォルトの名無しさん：2010/10/11(月) 16:09:04

>>953
あぁ、Perlだからオブジェクト指向の例だったのね。

956 ：デフォルトの名無しさん：2010/10/11(月) 16:15:22

>>955
オブジェクト指向版
my $cat = neko->new;
$cat->namae;
$cat->nake;
$cat->sine;

package neko;

sub new {
my $self = shift or die $!;
my $hash = { namae => 'タマ' };
return bless $hash, $self;
}

sub namae {
my $self = shift or die $!;

print $self->{namae}, "\n";
}

sub nake {
my $self = shift or die $!;

print "にゃーにゃー\n";
}

sub sine {
my $self = shift or die $!;

print "ぎゃーーー\n";
}

957 ：デフォルトの名無しさん：2010/10/11(月) 16:15:33

>>948
get系メソッドで状態が変化するわけではないので
letかwhereで束縛するだけでいいのでは

958 ：デフォルトの名無しさん：2010/10/11(月) 16:17:34

>>954
>>944が作って欲しいのはこう言うのじゃないの？

>>955
いや、>>951はプロセス指向版

959 ：デフォルトの名無しさん：2010/10/11(月) 16:18:21

>>956
理解した！
スレッドつかったら、プロセス指向になるんだ！

960 ：デフォルトの名無しさん：2010/10/11(月) 16:19:33

さすがperl使いだな
仕事が早いｗ

961 ：475：2010/10/11(月) 16:20:28

>>950
>IO モナドをどう使えば何が出来るか、何が出来ないか、
>Arrow を使えばどう記述しやすくなるか、ならないか、

あ、スマンが、それを分かり易く、言い換えると「数学用語を使わずに」説明してくれないかな？
>>935で書いたけど、自分はモナド/アローと格闘中。で、一時的に敗北を認め、
今は代数の勉強からやり直しているところ(群と束までは何となくイメージが湧くんだけどね)。
だから、説明してくれるとすごく嬉しいね。

>逆に訊くが、バーコード表示コンポーネントに
>圏論の概念の何が必要か挙げてくれ。

バーコード表示コンポーネントなら不要かもしれない。スマン。
ただ、事務系処理と圏論の概念という話題は、>>475の関数指向設計技法の話と関連するかもしれない。
まだモヤモヤした状態なので、後からレスするよ。

962 ：475：2010/10/11(月) 16:21:47

>>957
えーと、変数 tama に「何」を束縛するの？

963 ：デフォルトの名無しさん：2010/10/11(月) 16:23:44

>>959
スレッドでもいいんだけど、ネイティブスレッドは非常に重いので、
今必死で各方面でerlangのような軽量プロセスを実装しようと試みている人がいるよ。
perはメモリ周りが柔軟なので、ネイティブだけど割と軽い。
Cと比べたら激遅なんだけどねｗ

あと、スレッドを使うだけではなくて、ロック機構を全く使っていないことに注目して欲しい。
メッセージパッシングにスレッドセーフなキューを採用している。

964 ：デフォルトの名無しさん：2010/10/11(月) 16:25:17

なんだ。結局プロセス指向って
オブジェクト指向言語での
書き方の一つなんじゃねーか。
紛らわしいｗ

965 ：デフォルトの名無しさん：2010/10/11(月) 16:26:33

>>964
いや、ちょっとまって、どこをどう見たら>>951と>>956がおなじに見えるの？

966 ：デフォルトの名無しさん：2010/10/11(月) 16:34:52

これだけは前提としてくれ

オブジェクト指向のインスタンスのメソッドをたたくことをメッセージというが
これは
プロセス指向のメッセージパシングのメッセージとはぜんぜん別物。

しかたがないから名前つけるか。
前者：オブジェクト指向メッセージ（略してOM)
後者：プロセス指向メッセージ（略してPM)

以上

967 ：デフォルトの名無しさん：2010/10/11(月) 16:39:46

もう少しだけ分かりやすいプロセス指向のコードをperlで書いてみた。
use threads;
use Thread::Queue;

my $q = Thread::Queue->new;
my $th = neko($q);
my $q2 = Thread::Queue->new;
my $th2 = neko($q2);
$q->enqueue({command=>'namae', namae=>'タマ'});
$q2->enqueue({command=>'namae', namae=>'シロ'});
$q2->enqueue({command=>'nero'});
$q->enqueue({command=>'nake'});
$q->enqueue({command=>'sine'});
$q2->enqueue({command=>'sine'});
$th->join;
$th2->join;

sub neko {
my $q = shift or die $!;

return threads->new(sub {
my $namae = '';

while (1) {
my $message = $q->dequeue();

if ($$message{command} eq 'namae') {
$namae = $$message{namae};
print "命名：$namae\n";
} elsif ($$message{command} eq 'nake') {
print "にゃーにゃー\n";

968 ：475：2010/10/11(月) 16:40:00

では、(>>844が言うところの)プロセス指向言語でもある GHC(KL1) で参戦w

% オブジェクト TAMA の定義

tama(InqueryStream, ReplyStream) :- tama(InqueryStream, ReplyStream, 'TAMA').

tama([namae | InqueryStream], [Name | ReplyStream], Name) :- tama(InqueryStream, ReplyStream, Name).
tama([nake | InqueryStream], ['NYA NYA' | ReplyStream], Name) :- tama(InqueryStream, ReplyStream, Name).
tama([shine | InqueryStream], ['GYA---' | ReplyStream], Name) :- tama(InqueryStream, ReplyStream, Name).

% オブジェクトTAMA の使い方。ここで、instream はキー入力(標準入力)に、outstream は画面出力(標準出力)に相当する。

?- instream(InqueryStream), tama(InqueryStream, ReplyStream), outstream(ReplyStream).

969 ：デフォルトの名無しさん：2010/10/11(月) 16:40:28

} elsif ($$message{command} eq 'nero') {
print "$namaeが寝ます。\n";
sleep(3);
print "$namaeが起きました。\n"

} elsif ($$message{command} eq 'sine') {
print "$namaeが死んでしまいました\n";
last;
}
}
});
}

970 ：967：2010/10/11(月) 16:45:13

よく見て欲しいのが$namae変数。
これは一つの関数のローカル変数に過ぎない。
関数型言語なら引数に与えて再帰することで状態を持たずに済むので、
プロセス指向は非常に関数型言語にとって有利な方法なんだ。

971 ：デフォルトの名無しさん：2010/10/11(月) 16:49:10

>>961
> あ、スマンが、それを分かり易く、言い換えると「数学用語を使わずに」説明してくれないかな？

IO モナドを使えば IO との入出力ができる。
印刷ライブラリも呼べる。
FFI を使って Haskell 用には書かれていないライブラリにも
IO モナドとしてアクセスできる。

バーコードを印刷するアプリの「モナド」に関しては
これくらい知ってるだけで基礎知識としては十分。
あとは自分でライブラリを探して利用することができる。

代数や圏論など出る幕ではない。

>>961
んだよ、じゃあ帳票印刷パッケージでいいよ
代数やら圏論やらの理解がどれほど必要だ？

972 ：デフォルトの名無しさん：2010/10/11(月) 16:51:06

>>971
> 帳票印刷パッケージ
そんなもんそのへんの乞食にやらしとけよｗ
１００円ぐらいやってくれるんじゃね？

俺らの仕事は数億円の仕事だからさｗ
一緒にしないでよｗ

973 ：デフォルトの名無しさん：2010/10/11(月) 16:51:35

>>971
おっとスマン

FFI を利用して外部ライブラリを呼ぶのなら、
メモリ領域破棄のタイミングについても知っていないと、
商用のアプリやライブラリとしてはちょっとお粗末だった。

でも、やっぱり代数や圏論の知識は要らんな。

974 ：デフォルトの名無しさん：2010/10/11(月) 16:56:53

>>932
俺じゃなくて、745 に言ってくれ。
彼が >>941 で自ら例を挙げたんだから。

彼は、君が乞食にやらしとけよと言うモノを作るのに、
代数やら圏論やら難しい概念を正確に理解することが必要なんだと言っている。

975 ：デフォルトの名無しさん：2010/10/11(月) 17:00:04

fizzbuzzがやっと書けるレベルでも印刷アプリぐらいつくれるだろｗ

976 ：475：2010/10/11(月) 17:01:57

>俺らの仕事は数億円の仕事だからさｗ
>一緒にしないでよｗ

事務系処理であれば、大企業の基幹システム開発とか銀行の勘定系システムだと、
ハード抜きソフト開発費だけで数億の案件なんてザラにあるんだよ。
君が言う100円くらいでやってくれるというCOBOLプログラマが奮闘している。

ところでHaskellで数億円って、どんなお仕事なの？教えて欲しいなーーーーw

977 ：デフォルトの名無しさん：2010/10/11(月) 17:02:13

１００円の仕事やらせるのに難しい知識なんていらないんだよ

978 ：デフォルトの名無しさん：2010/10/11(月) 17:04:33

>>976
鉄道関係でZ言語使って設計したよ。
実装は他の言語だがな。

979 ：475：2010/10/11(月) 17:17:37

>>978
Zは形式的仕様記述言語だろ。関数の概念も使うけど、それを言い出せば手続き型言語でも関数は使う。
レスとしては、適切ではないな。

で、HaskellでHaskellで数億円って、どんなお仕事なの？

980 ：デフォルトの名無しさん：2010/10/11(月) 17:21:55

君の仕事が乞食相当１００円の仕事だと言われたと思って怒ってるの？
それ以前にHaskellで商売してるって誰が言ってるの？

981 ：デフォルトの名無しさん：2010/10/11(月) 17:25:43

>>979
Zは述語論理の言語だよ。

982 ：デフォルトの名無しさん：2010/10/11(月) 17:29:48

475 は下らん奴らの相手をしている暇があるなら、
帳票印刷パッケージで代数やら圏論やら
難しい概念を正確に理解する必要性を説いてくれないだろうか。

バカの戯言など無視して集中してくれ

983 ：デフォルトの名無しさん：2010/10/11(月) 17:30:12

>>970
> よく見て欲しいのが$namae変数。
> これは一つの関数のローカル変数に過ぎない。
> 関数型言語なら引数に与えて再帰することで状態を持たずに済むので、
> プロセス指向は非常に関数型言語にとって有利な方法なんだ。

それは名前を取得しているだけだから
ローカル変数ですむんだろ？

function get_namae() {
　return "tama"
}
と同じこと。

現実的には、名前を決めるメソッドも必要。この場合はどうなるのさ。

984 ：デフォルトの名無しさん：2010/10/11(月) 17:31:52

>>983
オブジェクト指向では状態を持たないとやりたいことは実現できないよ。

985 ：デフォルトの名無しさん：2010/10/11(月) 17:41:14

>>983
> と同じこと。
ぜんぜん違う。
その方法ではオブジェクト指向的には、
タマバージョンとシロバージョンの２種類のクラスを別々に作る必要が出てくる。
一つのクラスでやろうと思ったら名前をつけるメソッドを用意して、
フィールドにnamae変数を用意しなければならない。

一方でプロセス指向ではフィールドに該当するものを持っても良いし持たなくても良い。
関数型言語を使うなら持たなくても良い。

986 ：デフォルトの名無しさん：2010/10/11(月) 17:50:01

>>984-985

それでプロセス指向ならどうするか
って答えがでてないよ。

987 ：デフォルトの名無しさん：2010/10/11(月) 17:55:20

>>986
>>967

コードを良く読んでいないでしょ？
実行すらしていないんじゃないの。

988 ：デフォルトの名無しさん：2010/10/11(月) 17:57:14

Queueは副作用あるから関数型じゃないし
オブジェクト指向はObserverパターンを散々推奨しておいて今更dequeue()はないだろ

両方とも詰んでるんだよ

989 ：475：2010/10/11(月) 17:57:52

>>971,973,982
>>475で始めた一連のカキコでは「関数指向設計技法」というものを提案した。
で、入出力データを代数的データ型で定義するところまでは説明したけど、
それら入出力集合間の写像(関数)をどのように定義する方法論については、以下のように
曖昧な表現で終わっており、それを>>500でツッコまれていた。

>>497
>（２）副関数群への分解手順(アルゴリズム)について、JSP法の考え方に沿って(JSP法を模倣して、あるいは
>　　　JSP法の用語を使って)、指導者が普通のプログラマへ説明する

実は、事務系処理は(100円でもやってもらえるような)比較的単純な機械労働のように
見られがちだけど、世界中のソフトウェア工学の権威が取り組んできていたにもかかわらず、
未だに解決できていない領域の一つだったりする。

上の写像定義であれば、入出力集合間の関係が準同形であれば比較的たやすい。
形式的な関数定義を導出することが可能。(言い換えると、プログラムの自動生成が可能。)
ところがそうでない場合、これをJSP法では「構造不一致」と呼ばれているが、
case-by-caseで、言い換えると設計者の「経験と勘」で対応せざるをえないのが現実。

JSPにおける構造不一致(structure clashs)については、以下の文献を参照してくれ。(英語だよ)

・The Jackson Development Methods (Michael A Jackson 1992)
　　http://www.jacksonworkbench.co.uk/resources.htm

(長いので続く)

990 ：デフォルトの名無しさん：2010/10/11(月) 17:59:29

>>987
そのコードのどこに、名前を変更する処理が入ってるのさ？
インスタンス生成時に、値設定しているだけじゃないか。

> タマバージョンとシロバージョンの２種類のクラスを別々に作る必要が出てくる。
それから、これ訂正すべきだな。

クラスは1種類（猫クラス）だけで十分。
インスタンスは複数必要だが。
事実プロセス指向とやらでも、インスタンスは複数あるよな。

> $q->enqueue({command=>'namae', namae=>'タマ'});
> $q2->enqueue({command=>'namae', namae=>'シロ'});

991 ：デフォルトの名無しさん：2010/10/11(月) 18:01:03

つまり、プロセス指向とやらは、
インスタンスを、その言語で定義されたインスタンスというもので表すか、
perlのようにハッシュをインスタンスとして使うかの違いでしかないのか？

992 ：デフォルトの名無しさん：2010/10/11(月) 18:02:55

手続き型言語では、データ（構造体）とそれを扱う関数が分かれていた。
プロセス指向は、その構造体をハッシュにすることで
構造体の型の定義を作らないですむようにしたもの。

これでいいのか？

993 ：デフォルトの名無しさん：2010/10/11(月) 18:09:31

C#にはクラスのインスタンス時のみに値を設定できるreadonlyって属性があるんだわ。
http://msdn.microsoft.com/ja-jp/library/acdd6hb7(VS.80).aspx

これを使えば、あと状態を変えることができなくなる。

プロセス指向ってのは、このように
状態を最初に設定することだけできて、
後から設定する変数を持たないようにしたクラスと同じ。

プロセス指向だけで、ソフトウェアが作れることはまずなくて、
状態をあとから変更できないようにしておけば、
バグが少なくなるよって考え方のことだろう。

994 ：475：2010/10/11(月) 18:15:26

>>988
えーと、>>968では副作用なんてありませんですよ。関数型言語じゃなくて論理型言語だけどねw
Prologだとretract/assertみたいな副作用が必須だったけど、並列論理型言語では副作用無しに状態を保持し、
ストリームを応用してクラス間の継承(インヘリタンス)すら記述できます。

というか、Haskellでの参戦者はいないの？ (自分は、このスレじゃHaskellに批判的な立場だから書かないぜ)
ストリーム(無限リスト)を使えば、>>968相当の処理は、もっとエレガントに記述できるんだけど。
これは関数型的思考プロセス段位であれば「中級」に相当するレベルだよ。>>909
誰も皆、モナド・モナド・モナド・モナド・モナド・モナド・モナド・モナド.... ばかり考えているから、
昔の純粋関数型言語におけるストリーム指向プログラミング技法なんて忘れ去られてしまったのかな？

>>993
(>>844が言うところの)プロセス指向を間違って理解しちゃってますヨ

995 ：デフォルトの名無しさん：2010/10/11(月) 18:19:37

出発点がおかしいんだわ。

ソフトウェアを状態を持たないで作ることは不可能なんだよね。
それが関数型言語で言えばモナドになる。
オブジェクト指向で言えば、インスタンスのこと。
（インスタンスではないクラスはメソッドの集まりなんで状態を持ってないよ。基本的に。）

実体を持たないメソッドを抽象メソッドと呼ぶように、
状態を変更しないメソッドを、関数とかプロセス指向（？）とか
言っているだけではないか？

結局は特殊な性質を持ったメソッドに、さもえらそうな名前をつけているだけ。

996 ：デフォルトの名無しさん：2010/10/11(月) 18:21:51

> 状態を変更しないメソッド

あぁ、C++でいうconstメソッドのことねｗ

997 ：デフォルトの名無しさん：2010/10/11(月) 18:40:54

語尾に指向をつければ、なんでもすごく感じるメソッド指向

998 ：デフォルトの名無しさん：2010/10/11(月) 18:44:19

俺えんてっど

999 ：デフォルトの名無しさん：2010/10/11(月) 18:47:21

>>995
メソッドって特殊な性質を持った手続きのことでしょ

1000 ：デフォルトの名無しさん：2010/10/11(月) 18:47:36

1000なら関数型言語は普及しない。

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。