関数型言語は何故普及しないのかを考える
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/10/11(月) 19:07:49このテーマの存在をどうかお忘れなきよう願います。
前スレ
関数型言語は何故普及しないのかを考える
http://hibari.2ch.net/test/read.cgi/tech/1277215506/l50
0002デフォルトの名無しさん
2010/10/11(月) 19:12:390003デフォルトの名無しさん
2010/10/11(月) 19:14:04一分野でしかないから。
0004デフォルトの名無しさん
2010/10/11(月) 19:18:33Haskellすげー
関数型言語でUMLみたいな図にできる設計技法はあるのか
Haskellでオブジェクト指向？
型推論いる？いらない？そもそも型推論ってなに？
関数型言語でGUIとかやりにくい？→いやFudgetとか関数型言語向きのGUIライブラリがある
SIerはゴミ糞
プロセス指向があればオブジェクト指向いらない
関数型言語はプロセス指向に適している
0005デフォルトの名無しさん
2010/10/11(月) 19:19:34せっかくお給料アップのために無理してやっと覚えたオブジェクト指向を否定されたくないんですよね。
0006デフォルトの名無しさん
2010/10/11(月) 19:21:490007デフォルトの名無しさん
2010/10/11(月) 19:27:28あなたコード読んでないでしょ。
それ以前にひょっとしてperlわからないの？
よく読めばnamaeコマンドを受信したら$namae変数を変更する処理がちゃんと入ってるでしょうが。
↓の順番で呼んでみればわかるよ。
$q->enqueue({command=>'namae', namae=>'タマ'});
$q->enqueue({command=>'nero'});
$q->enqueue({command=>'namae', namae=>'クロ'});
$q->enqueue({command=>'nero'});
$q->enqueue({command=>'sine'});
0008前スレ ◆st4kIyCS7.
2010/10/11(月) 19:27:30(前スレ #989 の続き。)
で、構造不一致の問題は関数指向設計技法でも同様に発生する。これに対する挑戦(研究)はいくつか
あるらしいが、たとえば自分が知っている文献を以下に紹介。(どちらも同じ著者陣による報告)
・関数スキーマベースを用いたソフトウェア設計自動化(1985) -- 情報処理学会論文誌
http://ci.nii.ac.jp/naid/110002724012
・ソフトウェア設計自動化のための仕様記述言語 F(1986) -- 情報処理学会論文誌
http://ci.nii.ac.jp/naid/110002724187
注目は後者の「仕様記述言語 F」。詳細は論文を読んでもらうとして、
入力集合(定義域)から出力集合(値域)の対応として単純な関数ではなく、
関数を関数に写像する「関数結合子(function combinator)」を用いている。
さらに関数結合子と定義域/値域との正当な対応(組合せ)について考察している。
なにしろ1986年という古い研究で、その後の継続報告は見つけられないけど、
今なら、このきれいに形式化された課題をカテゴリ(圏論)の視点で、
言い換えると、机上の理論で終わらせずにHaskellプログラミング技法の一つとして
再検討できるんじゃないかと妄想している。(あまりにもったいない研究成果に思える。)
(更に続く。次で終わり。)
0009デフォルトの名無しさん
2010/10/11(月) 19:27:310010前スレ 475
2010/10/11(月) 19:29:44また、この研究では、(入出力がファイルではなく)メモリ上のデータ構造を暗黙的に仮定している。
もしもすべてのデータ(直積/直和/列)がメモリ上にあることを前提とできるならば、豊富な関数群を
いかに適用すればいいか、それだけを検討すればいいけど、現実のバッチ処理というのは
数万件のレコードを含む複数のファイルを処理の対象としている。これは単純に言えばI/Oモナドなのだろうけど、
I/Oモナドと他の結合子(コンビネータ)との正当に一致する組合せについても検討が必要になってくるだろう。
言い換えると、関数間の結合を床下配線として隠すのが関数結合子であるのなら、それら関数結合子同士の
結合を床下配線として隠すことができる、高階関数結合子の型体系を検討しなければならない気がしている。
なお、何度も書いているけど、モナドやアローを含む圏論については勉強中の身。
誤解や勘違いもあるはずで、モヤモヤした「妄想」を吐き出しただけの文章だけど、それを承知でコメントを請う。
(これで終わり。PS. 用事で外出するので、もしレスするとしたら深夜になると思う。)
0011デフォルトの名無しさん
2010/10/11(月) 19:34:36形を変えただけにしか見えないよな。
どうみても、ネットワーク通信の
コードと同じように見えるんだがｗ
データ受け取って、値を返す。コレ↓
http://x68000.q-e-d.net/~68user/net/echo-2.html
0012デフォルトの名無しさん
2010/10/11(月) 19:35:35スレッドプログラミング ＝ プロセス指向・関数型言語
0013デフォルトの名無しさん
2010/10/11(月) 19:37:290014デフォルトの名無しさん
2010/10/11(月) 19:38:270015デフォルトの名無しさん
2010/10/11(月) 19:41:51http://venus.is.s.u-tokyo.ac.jp/kobalab/kadai99/picalc.html
これを読んでからもう一度質問してください
0016デフォルトの名無しさん
2010/10/11(月) 19:46:50sub 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";
} elsif ($$message{command} eq 'nero') {
print "$namaeが寝ます。\n";
sleep(3);
print "$namaeが起きました。\n"
} elsif ($$message{command} eq 'sine') {
print "$namaeが死んでしまいました\n";
last;
}
}
});
}
↓オブジェクト指向風に書き直すと
0017デフォルトの名無しさん
2010/10/11(月) 19:47:32sub neko {
my $q = shift or die $!;
return threads->new(class {
private $namae = '';
function namae() {
$namae = $$message{namae};
print "命名：$namae\n";
}
function nake() {
print "にゃーにゃー\n";
}
function nake() {
print "$namaeが寝ます。\n";
sleep(3);
print "$namaeが起きました。\n"
}
function sine() {
print "$namaeが死んでしまいました\n";
last;
}
});
}
0018デフォルトの名無しさん
2010/10/11(月) 19:55:300019デフォルトの名無しさん
2010/10/11(月) 19:58:18パターンの一つにしか見えんのだよな。
0020デフォルトの名無しさん
2010/10/11(月) 20:03:37それ動かないぞ。
0021デフォルトの名無しさん
2010/10/11(月) 20:05:280022デフォルトの名無しさん
2010/10/11(月) 20:09:06わかる言語で書くようにするから。
0023デフォルトの名無しさん
2010/10/11(月) 20:09:53こういう感じという例だよ。何が足りないかぐらい分かるだろ？
0024デフォルトの名無しさん
2010/10/11(月) 20:11:02じゃあ、オブジェクト指向言語のJavaでお願いｗ
そうすれば、パターンの一つに過ぎないとはっきりするからね。
0025デフォルトの名無しさん
2010/10/11(月) 20:15:32デザインパターンの最終兵器
0026デフォルトの名無しさん
2010/10/11(月) 20:42:030027デフォルトの名無しさん
2010/10/11(月) 21:16:18>>15 と http://en.wikipedia.org/wiki/Process-oriented_programming 読ん
でみたけど、 同じプログラミングパラダイムについて書いてあるのか分からな
い。
0028デフォルトの名無しさん
2010/10/11(月) 21:20:200029デフォルトの名無しさん
2010/10/11(月) 21:23:19普段マルチパラダイムプログラミング言語を使っているから、
その言語の一機能にしか見えないんだ。
あぁ、そういうことか。
http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%83%91%E3%83%A9%E3%83%80%E3%82%A4%E3%83%A0
> マルチパラダイムプログラミング言語が登場してから、プログラミングパラダイムとプログラミング言語との
> 関連は複雑になっている。たとえば、C++は手続き型プログラミング、ジェネリックプログラミング、
> オブジェクト指向プログラミングに対応するよう設計されているが、設計時には個々の部分毎に
> どのパラダイムを使うか選ぶ必要に迫られる。あるプログラムは全て手続き型プログラミングで作り、
> またあるプログラムは全てオブジェクト指向で作り、また別のプログラムは両方を混在して作るという具合である。
0030デフォルトの名無しさん
2010/10/11(月) 22:51:53手続き型プログラミング、ジェネリック（テンプレート）プログラミング、 オブジェクト指向プログラミング
この三つは全く別のクラスの概念だから混在はなにも障害ないはず。
0031デフォルトの名無しさん
2010/10/11(月) 22:58:580032デフォルトの名無しさん
2010/10/11(月) 23:08:51あなたの説明では、帳票印刷パッケージで
代数や圏論の概念の正確な理解が必要な理由になっていない。
単に関数指向設計技法の提案でしかない（それも曖昧だが）。
Gtk2Hs には ListStore というウィジェットがあり、
それを使えば所謂グリッドビューを表示できる。
HackageDB にはデータベースへ SQL でアクセスするライブラリもある。
都合の良いデータ構造（コンテナ）もライブラリとしてある。
たいていの Haskell プログラマは、それらの使い方を理解すれば、
帳票を扱うプログラムは組める。
その時にあなたの言う関数指向設計技法が大いに役立つかも知れんが、
無くてもプログラムできる。
少なくとも、グレープシティのようなライブラリを作る側ではなく、
ライブラリを利用する側である大多数のプログラマにとっては
それで十分アプリは作れる。
あなたのように「数学やソフトウェア工学などの理解がないとアプリが作れない」
と思い込んでいる人たちがそう触れ回っているために、
関数型は難しいんだ、アプリは作れないんだと萎縮してしまう人が多いんだよ。
0033デフォルトの名無しさん
2010/10/11(月) 23:17:01素人でも簡単に目的に見合ったモナドを作るためにモナド変換子ライブラリがある
0034デフォルトの名無しさん
2010/10/11(月) 23:21:02モナド則だけ知ってればHaskellのモナドは完璧だｗ
0035デフォルトの名無しさん
2010/10/11(月) 23:22:350036デフォルトの名無しさん
2010/10/12(火) 00:57:10間違っちゃいないが九割九分はハッタリにすぎん
0037デフォルトの名無しさん
2010/10/12(火) 02:27:04ただ、別に操作的意味論とかを知らなくてもC言語は使えるし教育もできるのと同様、
圏論を使わなくても「モナドはモナド」として説明できるべきだと思う
0038前スレ 475
2010/10/12(火) 02:42:26>単に関数指向設計技法の提案でしかない（それも曖昧だが）。
>>8,10で書いたのは、関数合成の自動生成法に関する妄想であって、関数指向設計技法ではないよ。
関数指向設計技法は(前スレ>>989で書いた)以下のように曖昧なもの。
>（２）副関数群への分解手順(アルゴリズム)について、JSP法の考え方に沿って(JSP法を模倣して、あるいは
> JSP法の用語を使って)、指導者が普通のプログラマへ説明する
だから技法(テクニック)でしかない。構造不一致問題に対しては、今まで通り、プログラマの持つ
プログラミング知識を前提にした、経験と勘による手法で対応するしかない。
ただ、それだけであっても「静的関数型言語の持つ(型推論のような)優れた特性があれば、
上流設計工程における品質の向上というソフトウェア工学上の利点は十分に得られる」はずだよね、というのが
前スレで書いた関数指向設計技法の要旨。
で、そんな静的関数型言語の持つ優れた特性は、(Haskellのように実行順序が定まらずモナドに頼らなければ
入出力すらまともに書けない非正格な関数型言語でなくても、)F#やSMLのような正格な言語にも備わっている。
事務系処理で本質的に無限リストが必要になるケースなんてほとんど無いんだから、正格な言語で十分。
しかもF#やSMLなどであれば、明示的な可変宣言をすれば副作用を許容しているのだから、初学者には、
（１）まず手続き型言語で学んだ普通の(副作用だらけの)アルゴリズムで設計し、
（２） 関数型言語の学習を進めていく課程でmap/filter/遅延ストリームのような技法を習得することで
（１）のアルゴリズムを徐々に改善していく
といった指導法を採ることができる。これなら業務用パッケージ/コンポーネントが整備されすれば、
今すぐにでも「関数型言語を普及させる(=従来の手続き型言語を置き換える)」提案を進められる。
(だから、Windowsでは特に、F#は急速に普及していく潜在的可能性があるだろうし、今すぐにでもお勧めしたい)
(長いので続く)
0039デフォルトの名無しさん
2010/10/12(火) 03:16:300040デフォルトの名無しさん
2010/10/12(火) 07:34:35質問に答える気はないのですか。
あなたが最初に例として挙げた帳票印刷パッケージという具体例では、
圏論などの難しい概念を正確に理解しないと作れない理由を
説明できないのですね。
もしかして帳票印刷パッケージを関数型で「作ろうとしてみた」経験もなく、
妄想だけで、圏論を理解しないと作れないと適当に言ってみただけですか。
最後にもう一度訊きます。
あなた自身が最初に例として挙げた帳票印刷パッケージで、
圏論などの難しい概念を正確に理解しないと作れない理由を
説明してください。
説明する気がないのなら、もういいです。
0041デフォルトの名無しさん
2010/10/12(火) 09:26:280042前スレ 475
2010/10/12(火) 09:53:29>>32
>たいていの Haskell プログラマは、それらの使い方を理解すれば、
>帳票を扱うプログラムは組める。
これに関しては、前スレの>>935で書いたけど、(サードパーティ等の他社が提供する)
帳票印刷用のライブラリが存在していれば、もちろんHaskellでも「帳票を扱うプログラムは組める」から、
同意します。
(続く)
0043前スレ 475
2010/10/12(火) 09:55:55>>40
帳票印刷パッケージは単なる例だけど、こういった業務用パッケージ/コンポーネントというのは、
過去からの膨大なコード資産があって、一から新規作成するケースは少ない。
たとえばC++で書かれた帳票印刷パッケージ、C#で書かれたバーコード表示コンポーネント、...etc、
これら一つ一つについて、関数型言語向けにカプセル化する必要があります。
（この話は帳票を扱う業務アプリ開発(プログラミング)ではなく、帳票印刷パッケージそのものの
開発に関する話だから、誤解/混同しないで下さいね。念の為。）
このカプセル化を設計する時に、単にIOモナドを使うだけで済ますのか、あるいは
その上にもう一皮被せた独自のモナドで実装するのかは、case-by-caseだと思います。
ただし、一般に帳票というのは、そのデザイン(定義)が面倒なもので、それに加えて業務単位に類似性のある
複数の帳票を定義するといった事柄が要求されます。だから、帳票印刷パッケージには、
その手間(ユーザの負担)を減らすために、使い易いUI、定義の差分記述やモジュール化といった
多くの機能要素から構成されます。他にもエラー回復(紙づまり/用紙切れ)や印刷スプール管理といった
帳票定義以外の機能も一緒に提供されます。ただ単に「帳票を定義して印刷する」だけじゃ済まんのですよ。
そして、それら機能設計の優劣が他社製品との差別化(セールスポイント)に直結するわけですから、
各社とも必死に設計/開発するわけで、低レベルな印刷APIを単純なIOモナドで操作するだけでは済まず、
おそらく個々の機能要素(関数)を柔軟かつ正確に結合できる独自のモナドを設計しようとすると思うんです。
で、その時に、前スレの>>971で書いてくれたような「IOモナドを使えばIOとの入出力ができる。
印刷ライブラリも呼べる。」といったモナドの知識、あるいはいわゆる一般的な「モナド則」だけを
知っていさえすれば設計できるものなのか？という疑問です。とうてい可能とは想像がつかないんですけど。
(まだ続く)
0044前スレ 475
2010/10/12(火) 09:57:03>もしかして帳票印刷パッケージを関数型で「作ろうとしてみた」経験もなく、
ええ、Haskellを業務開発に適用するなんて想定していませんから、そんな経験はありませんよ。
ただし、C++で書かれたある軽量でマイナーなGUIライブラリをGoferで使えるようにしたくて、
TkGoferのソースやペーパーを読みあさりました。その結果、TkGoferがどう動いているかは
イメージを持てたのですけど、いざGUIライブラリ向けのGUIモナドを設計しようとした段階で
挫折した経験ならあります。単なる自分のプログラミング能力不足が主な原因なんですけどね。
で、基本に立ち返って、代数の勉強からやり直している、というのが現状です。
(これで終わり)
0045デフォルトの名無しさん
2010/10/12(火) 10:03:50わかりやすい説明だね。
0046前スレ 475
2010/10/12(火) 10:32:18これがHaskellであれば、今まで培ってきた手続き型言語の知識を捨て去って、一から関数型言語の
プログラミング技法を習得する必要がある。勘違いしやすいのは、
・Haskellプログラマ --> 「モナドを使えば副作用が実現できる(= be can)」なのに対して、
・普通のプログラマ --> 入出力やステートマシンなんて手続き型言語や正格関数型言語であれば、
ごく自然に(直感的に)記述できるけれど、Haskellでは
「同じ事をしたいだけなのに、モナドを使わなければならない(= be must)」
という認識が、現実であるということ。
モナドは負の要素であり「本来は不要だけれども、しかたなく使わざるをえない」仕掛けである事を忘れてはならない。
これが「Haskellが(現時点で)普及していない」し、「Haskellが数年のうちに普及することは有り得ない」という主張の理由。
この「モナドは負の要素でしかない」という切り口(視点)を「モナドは正の要素である(=モナドでなければ実現できない)」
という世界へと逆転させる潜在的可能性の曖昧な模索が、>>8,10で書いた妄想。妄想は妄想であって、今はまだ現実じゃない。
ただ、こういった高度に抽象化された対象、言い換えると、時間の経過や状態の変化が存在しない数学の世界を扱うには、
(「評価順序が定まらない」のではなく)評価順序を考慮せずにアルゴリズムを定義(記述)できる
Haskellのような非正格関数型言語に絶対的な優位性があるはず。また、>>10ではI/Oモナドについて書いたけど、
処理対象がメモリであってもファイルであっても統一したインターフェイスを提供できるのが、
非正格関数型ならではの(=非正格関数型でなければ実現できない)利点ではなかったのか？と思う。
（Haskellや圏論については勉強中だから、間違った推測かもしれないけど....。）
0047デフォルトの名無しさん
2010/10/12(火) 10:39:530049前スレ 475
2010/10/12(火) 10:44:20手続き型言語や正格関数型言語なら入出力や変数値を何の迷いも無く素直に書けるのに、
なんでHaskellだとわざわざモナドとやらを使わないと表現できねえんだYo!!
ただ単に面倒なだけじゃん。F#やSMLで十分でそ。Haskellの出番なんてネーヨ。
0050デフォルトの名無しさん
2010/10/12(火) 10:57:54なんで面倒な非純粋言語を使わなきゃならないんだYo!!
0052デフォルトの名無しさん
2010/10/12(火) 11:28:260053前スレ 475
2010/10/12(火) 11:50:030054デフォルトの名無しさん
2010/10/12(火) 12:00:08ただ手続き型でもちょっと捻れば書けちゃうのが残念。
「これは関数型じゃないと書きにくいぞ」ってのが欲しいなあ。
0055デフォルトの名無しさん
2010/10/12(火) 12:03:51例えばトリップ検索するという例では、
トリップの無限リストを作ってから順次比較していくとか、そういう使い方をする。
0056デフォルトの名無しさん
2010/10/12(火) 12:11:03手続き型でも「ゼロから初めて1加えつつ順次比較していく」と置き換えると
大概の用途は間に合ってしまうんよ。
それは手続き型では割と書きやすい部類の処理だ。
若干直感的ではない書き方だとは思うのだが
慣れてる人間にとっては目から鱗になるほどのインパクトは無いんよね。
0057デフォルトの名無しさん
2010/10/12(火) 12:14:55そんなモッサイやり方はクールな俺にはできないね。
0058デフォルトの名無しさん
2010/10/12(火) 12:43:15手続き型でもC#やPythonのようにyieldある言語なら特に問題なく容易に使えるし
実際使われていると思う
yieldない言語だと、湯水のように使われることはなさげ
0059デフォルトの名無しさん
2010/10/12(火) 12:53:39では、ライブラリがあれば普及できるのではないか。
VB が普及できた大きな理由の一つでもある。
圏論などはライブラリ作成者や、フレームワーク作成者が考えることであって、
普及の担い手である一般プログラマには「普及のためには」不要だ。
>>43
> この話は帳票を扱う業務アプリ開発(プログラミング)ではなく、帳票印刷パッケージそのものの
> 開発に関する話だから、誤解/混同しないで下さいね。念の為。
あなたは、バーコード印刷と帳票印刷パッケージを同列に扱っていたように見えたが。
>>44
> ええ、Haskellを業務開発に適用するなんて想定していませんから、そんな経験はありませんよ。
一度で良いから、途中までで良いから、仮想の帳票パッケージなり
バーコード印刷なりを Haskell で組んでみる事を勧める。
モナドが負の要素と言っている事が如何に的外れかが分かる。
帳票パッケージを作るのにあなたが恐れるほどモナドで苦労することはないと分かる。
そして机上の理論だけではなく、自分で組んでみて「実感した」問題点を挙げ、
関数型の普及の話と絡めてくれ。
0060デフォルトの名無しさん
2010/10/12(火) 13:31:50yieldがないならThread::Queueを使うと昨日からさんざん言われてるのに
少しは学習しろよ
0061デフォルトの名無しさん
2010/10/12(火) 13:39:06ごめん、スレに書き込むのはじめてなので……昨日のレスとか全然読んでなかった
Thread::QueueってPerlの話？
それは「可能なだけ」で、言語組み込みのyieldと違って、その言語のユーザが
普通に水や空気のように使うことはないのでは
それにThread::Queueとか言わなくとも、ファーストクラスの関数があれば
unfoldがとても簡単に簡単に書けると思う
Javaなどの場合はファーストクラスの関数はないので、Function2<S, T, R>とかいう
クラスを捏造するんだろうけど
0062デフォルトの名無しさん
2010/10/12(火) 13:43:25シーケンスでやれば正確でも楽にできるyo
0063デフォルトの名無しさん
2010/10/12(火) 13:55:15ステートマシンの良いテスト方法はないものか。
0064デフォルトの名無しさん
2010/10/12(火) 15:31:23別にそんなもん使わなくてもfor文で十分だよｗ
0065デフォルトの名無しさん
2010/10/12(火) 15:50:470066前スレ 475
2010/10/12(火) 18:41:22>では、ライブラリがあれば普及できるのではないか。
話がループしています。繰返しになりますが、業務用の部品(ライブラリ/パッケージ/フレームワーク)が
豊富に流通していたからこそ、VBやC#が業務アプリ開発分野市場で成功を納めている訳ですが、
その「業務用部品の開発にはHaskellは適さない」という理由を、長々と説明してきたつもりなんですが。
>圏論などはライブラリ作成者や、フレームワーク作成者が考えることであって、
ライブラリ/フレームワーク作成者のようなシステムプログラマには、
圏論の正確な理解が必須であることを理解して頂けたようで、嬉しく思います。
>普及の担い手である一般プログラマには「普及のためには」不要だ。
業務用部品が整備されれば、VBやCOBOLのような業務アプリ開発言語をHaskellで置き換えが可能でしょう。
そして、それら部品(COMサーバ)の多くはC/C++で開発されているわけですが、
その部品開発には、手続き型言語や(F#/SMLといった)正格関数型言語を使えば良いという理屈と解釈できます。
言い換えると、普及の担い手である(圏論を正確に理解できもしない)一般のプログラマにとって、
・Haskell --> VBやCOBOLと同様に、「アプリ開発にしか(= only)」適用(普及)できない言語であり、それに対して
・F#やSML --> CやC++と同様に、「ライブラリ/フレームワーク開発にも(= all-round)」即対応(普及)可能な言語である
と結論付けられます。このような解釈でよろしいでしょうか？
(続く)・
0067前スレ 475
2010/10/12(火) 18:46:00>帳票パッケージを作るのにあなたが恐れるほどモナドで苦労することはないと分かる。
>そして机上の理論だけではなく、自分で組んでみて「実感した」問題点を挙げ、関数型の普及の話と絡めてくれ。
>>44で書いたように、自分でGUIモナド設計を試みた(そして挫折した)経験はあります。
その課程で「実感した問題点」とは、
・ウィジェット(GUI部品)の正当な組合せ(組み立て)方法を厳密に定義し、
・それらを圏論の枠組みの中で再構築する
能力がプログラマには求められる事です。(モナドでなければ、ある程度のルーズさは許容されるんですけどね...)
例えると、言語処理系(インタプリタやコンパイラ)の設計者には形式言語の正確な理解が必須であり、
対象となる言語の文法を厳密に定義したうえでＢＮＦとして表現する能力が求められるのと同じです。
そして、出した結論が、(何度も繰り返しになりますけど、自分を含む)数理や情報工学の専門家ではない
【＊＊＊ 一般のプログラマに普及するのはF#やSMLといった正格関数型言語である ＊＊＊】
というものです。(>>38,46,49)
・
ただ単純に「現実世界の開発現場でもHaskellは普及できる、やってみれば分かるハズだ」という主張を
繰り返すだけでは、似非キリスト教神父の語る陳腐な台詞と、何ら変わりはありませんよ。
「アナタハ神ヲ信ジマスカ？ 信ジル者ハ救ワレマス。スベテハ神ヲ信ジル事カラ始マリマス。」
あなたの実体験を元に、Haskell信者ではない一般のプログラマが理解できる言葉/表現方法で、
いかに「モナドが正の要素であるか」について、具体例挙げて説明してください。お願いします。
0068デフォルトの名無しさん
2010/10/12(火) 19:16:350069デフォルトの名無しさん
2010/10/12(火) 19:25:210070デフォルトの名無しさん
2010/10/12(火) 19:26:58業務用「部品」の開発に無理して Haskell を使う必要はないだろ。
俺もさっきから「ライブラリを使う」と言ってる。
>>32 でもライブラリを組み合わせる例を挙げた。
GUI でも別の言語で作ったライブラリを Haskell でラッピングしたものを使って、
問題なく組み立てることが出来る。
GUIモナド設計を試みる必要はないんだよ、既にあるんだから。
試みるべきは、既存のライブラリによる帳票パッケージの作成だ。
ライブラリを組み合わせるのに必要なモナドなどの知識は、
あなたが恐れるほどのものではない。
Haskell が普及しないのは、そういった個々のライブラリの使い方と、
ライブラリ同士の組み合わせ方、つまりテクニックを教えないからだよ。
これを理解すれば、規模にもよるが色んなアプリが意外にサクツク作れる。
たぶん、普及の兆しは業務よりも趣味から始まる。
趣味プログラマに広まれば、業務ライブラリも整備される。
0071デフォルトの名無しさん
2010/10/12(火) 19:29:43低収益率のチープ産業に何かを求めるのは間違い。
0072デフォルトの名無しさん
2010/10/12(火) 19:45:11その思い込みの強さと、不適切な言葉遣いは前スレと変わらんな。
0073デフォルトの名無しさん
2010/10/12(火) 19:52:38Haskellのライブラリを書くのに圏論の知識が必要なんてことはない(もちろん圏論用のライブラリを除いて)
GUIみたいな「実際的」な分野ならなおさら
モナドを作りたいときは既存のモナド変換子の組み合わせで事足りるし、それも自信がなければ生のIOモナドを使って何も問題ない
モナドの形で提供するのは利便性のために過ぎないんだから
>>66が挫折したのは、モナドで表現すべきでないものを無理矢理モナドにしようとしているからに見える
そもそも、Haskellライブラリだからって関数的でかっこいい設計じゃないといけないなんて決まりはない
難しいなら妥協して「まるで手続き型言語のような」ライブラリを書けばいいし、Haskellはそれができるように設計されてる
0074デフォルトの名無しさん
2010/10/12(火) 20:00:23> ただ単純に「現実世界の開発現場でもHaskellは普及できる、やってみれば分かるハズだ」という主張を
> 繰り返すだけでは、似非キリスト教神父の語る陳腐な台詞と、何ら変わりはありませんよ。
そうか？
前スレでモナドうざいとか言ってた人は、
Fudgets という「ライブラリ」の存在を教えたら
「自分で調べて」モナドうざいを取り消してくれた。
調べれば分かるはずだと直接言ってはいないが、
似たようなモンだと思う。
今回も、ライブラリを組み合わせればできると言えば、
あなたほどの方なら自分で調べて可能性を検証してくれると思ったが、
思い過ごしか。
> あなたの実体験を元に、Haskell信者ではない一般のプログラマが理解できる言葉/表現方法で、
> いかに「モナドが正の要素であるか」について、具体例挙げて説明してください。お願いします。
モナドが負なのか正なのかと考える、それが的外れだと言っている。
>>73
そうだな、よく考えればライブラリやフレームワーク自体を作るのにも、
圏論などは必要ないかもしれん。
0075デフォルトの名無しさん
2010/10/12(火) 20:11:39ROMしてましたがちょっと突っ込ませてください。
Haskell以外で帳票パッケージが書けるのは当たり前の話で、議論しているのは
Haskellで帳票パッケージを書くには代数や圏論の概念の正確な理解が必要か、でしょう。
>>43のHaskellで書くにはモナドの知識だけでは不十分という説明に異論はないのでしょうか？
0076デフォルトの名無しさん
2010/10/12(火) 20:19:22> Haskellで帳票パッケージを書くには代数や圏論の概念の正確な理解が必要か、でしょう。
違う。
Haskell が普及しないのは帳票パッケージを作るのに圏論が必要だからか？ だよ。
で俺は、必要ない、なぜならライブラリがあるから、と言った。
0077前スレ 475
2010/10/12(火) 20:21:29>Haskell が普及しないのは、そういった個々のライブラリの使い方と、
>ライブラリ同士の組み合わせ方、つまりテクニックを教えないからだよ。
>これを理解すれば、規模にもよるが色んなアプリが意外にサクツク作れる。
その通りだと思います。そんなアプリケーション開発テクニック(技法)が確立して、
それが一般に広まって常識化すれば、おそらく大規模開発プロジェクトにもHaskellは普及するでしょう。
問題は、そのテクニック(技法)の確立/常識化がいつになるのか？いつまで待てばいいのか？という事です。
OOPの場合を振り返れば、日本でSmalltalk-80が登場したのが1980年代の前半で、
その当時は、オブジェクトって何？ クラスはどうやって設計すればいいの？という否定的な反応が一般的でした。
それが変化したのが、ランボーのOMT本(オブジェクト指向設計技法)が出版(1992年)と、それに続く
GoF本(デザインパターン)の出版(1995年)です。そして、ようやく今ではOOPはプログラマの常識となりました。
Haskellの普及も、同じような時間的スケールで進展していくのではないかと思います。
0078デフォルトの名無しさん
2010/10/12(火) 20:23:08ことさら圏論とのかかわりを小難しく論じていい気になってる人がいるよね
returnと>>=だけ理解すりゃいい極めて単純な原理を、
何でわざわざ偉そうに解説してみせる必要があるんだろう
0079デフォルトの名無しさん
2010/10/12(火) 20:32:15特殊性を内包した時点で完結してしまってる
無から有を生む力がなくて、現実に目を向ける力を奪うだけ
で、関数型言語が普及しないのは、実行ファイル作れないからじゃないかな
Vectorに登録したって、誰も使う環境もってないだろうし、そのためにだけ入れる気にもならないだろう
0080デフォルトの名無しさん
2010/10/12(火) 20:37:14>で、関数型言語が普及しないのは、実行ファイル作れないからじゃないかな
この誤解が酷すぎて前半の意見まで説得力を失うぞ
調べればocamlcやGHCがすぐ見つかるだろうに
0081前スレ 475
2010/10/12(火) 20:37:18>モナドを作りたいときは既存のモナド変換子の組み合わせで事足りるし、それも自信がなければ....(snip)
ズバリな指摘です。「既存のモナド変換子の組み合わせ」が(当時の自分では)上手くできなかったのが、挫折の原因でした。
>そもそも、Haskellライブラリだからって関数的でかっこいい設計じゃないといけないなんて決まりはない
>難しいなら妥協して「まるで手続き型言語のような」ライブラリを書けばいいし、Haskellはそれができるように設計されてる
そうであれば、最初から副作用を許容する正格関数型言語(F#やSML)を使えばいい、という話になりますよ。
どうせHaskellでライブラリを設計するんなら、宣言的で視覚的なイメージ(床下配線？)が湧き易い、言い換えると、
利用者にモナド・モナド・モナド...を強いらせない関数的なGUIライブラリ設計をしたくなるのが技術者心情ってもんです。
0082デフォルトの名無しさん
2010/10/12(火) 20:39:03あんた釣りだろｗｗｗ
0083デフォルトの名無しさん
2010/10/12(火) 20:41:03Haskellは関数型言語研究のための土台として作られたのだから
理論面について話題にする人が多いのは当たり前でしょう。
あなたが自分には関係ないと無視すればすむ話です。
0084デフォルトの名無しさん
2010/10/12(火) 20:42:40いやexeむりだろそれ
0085デフォルトの名無しさん
2010/10/12(火) 20:45:250086デフォルトの名無しさん
2010/10/12(火) 20:46:570087デフォルトの名無しさん
2010/10/12(火) 20:52:20> 問題は、そのテクニック(技法)の確立/常識化がいつになるのか？いつまで待てばいいのか？
確立/常識化するまで何で待ってるの？
今でもライブラリを組み合わせてアプリを普通に作れるよ。
あなたが調べようとしないだけ。
後の世から見れば、たいそう拙い組み合わせ方かも知れんが、
少なくとも今、趣味レベルのゲームを作ったり、帳票を扱ったり、
何かを印刷したり、チャートを表示したり、ソースエディタを作ったり、
そういった事をするために、みんなライブラリを組み合わせてるよ。
問題は、方法はソースを見れば分かる、という段階で止まってる事だよ。
作者がそのテクニックを発信する事がほとんどない。
だから、入門書なんかで教える必要がある。
＊＊法とか言って名前を付けて確立しなくても、
入門書で色々な小粒テクニックを紹介して、
そのテクニックでこういうアプリが作れるよと教えれば、利用者は増えるよ。
逆に、今それが無いから普及しないと思う。
少なくとも、圏論なんかを理解させるよりも余程いい。
圏論理解させてもアプリが作れるわけじゃないから、
圏論を理解しないことが普及しない理由だとはとうてい思えない。
圏論の理解より、アプリを作るためのライブラリの組み合わせ方の方が、
多くのプログラマ入門者（この人経ちも大きな普及の担い手）には魅力的だよ。
いい加減自分の発言も自分でウザく思えてきたから、もうこの議論から逃げる。
0088前スレ 475
2010/10/12(火) 21:00:41>前スレでモナドうざいとか言ってた人は、
>Fudgets という「ライブラリ」の存在を教えたら
>「自分で調べて」モナドうざいを取り消してくれた。
あ、それは自分です。Haskellにはモナドを使ったGUIライブラリしか存在しないもんだと思い込んでいましたので、
(モナドを使わずに関数結合子をストリーム指向で実装した)Fudgetsの存在は以外であり喜びでした。
だから「Haskellにはモナドを使ったGUIライブラリしか存在しない」という発言は、自分で取り下げました。
でも「モナドそのものが負の要素」という立場には、何の変化もありません。
そのレスで書いたように、(モナドを使わずに)ストリーム指向で関数を結合したFudgetsは(自分でも)理解しやすかったのに、
Fudgetsの開発が中断したままになっているのは、残念でなりません。(機会があれば自分で挑戦してみたいんですけどね....。)
>モナドが負なのか正なのかと考える、それが的外れだと言っている。
それは>>49(>>38,46)の指摘に対するレスになっていませんよ。
(モナドを「使う」レベルにはHaskellを知ってる)自分が、他人にHaskellを勧めようとして(= Haskellの普及を考えて)、
>>49のような反応をされたら、自分じゃ上手く説明できそうにありません。もし可能であれば、具体的な説明を願います。
0089デフォルトの名無しさん
2010/10/12(火) 21:10:44>そうであれば、最初から副作用を許容する正格関数型言語(F#やSML)を使えばいい、という話になりますよ。
なんでそうなる？
遅延評価や「関数型っぽい格好良さ」を抜きにしても、Haskellには魅力的な点がたくさんある
一番目立つのは型クラス
>>84
ごめんocamlcじゃなくてocamlopt
0090前スレ 475
2010/10/12(火) 21:28:12>遅延評価や「関数型っぽい格好良さ」を抜きにしても、Haskellには魅力的な点がたくさんある
おっしゃる通り、
「何が嫌いかより何が好きかで自分を語れよ!!!」(AA略)
という事ですね。
自分も長文カキコがウザクなってきたので(<<今頃気付いたのかヨ)、この話から降ります。
0091デフォルトの名無しさん
2010/10/12(火) 21:32:45「モナド変換子を使えばいい」みたいなのをネタでなく素で言ってるのだとしたら大分タチが悪い
「do記法を使えば手続き型の人も理解しやすい」みたいな嘘くささ
これらに共通するのは、内部に対するある程度の理解が無ければ実際は応用して使えないこと
前者は既にモナドをある程度マスターしてることが前提、後者はdoの変換ルール(+モナド関連の型の知識)
求められる前提が高いなら、一般に普及するわけがない
0092デフォルトの名無しさん
2010/10/12(火) 21:46:49ライブラリ製作者は言語に関して一歩踏み込んだ理解が求められる、普通のことだろ
do記法については弁護しようと思わない
0093デフォルトの名無しさん
2010/10/12(火) 21:48:29おい、Java版まだか？
0094デフォルトの名無しさん
2010/10/12(火) 21:52:36批判目的の要求はスルーに決まってる。
本当に知りたいかどうかは文面を見ればわかるし、俺がそうでないと判断すればスルーだ。
0095デフォルトの名無しさん
2010/10/12(火) 21:56:50理解していれば取捨選択もできるけど、多くの挫折した入門者はHaskell界隈のそういう空気
が障壁となって、STモナドやunsafe関数群の提供する自由を享受する前にアンチになるんじゃないのかね
アンチHakslellの人たちって、驚くほどHaksellについて誤解してる場合が多いよ
0096デフォルトの名無しさん
2010/10/12(火) 22:00:28普及すると言語がおかしな方向に拡張されるからね。
理想を保ったまま緩やかに進化するのが望ましいと思う。
0097デフォルトの名無しさん
2010/10/12(火) 22:08:40片言で話すのも、専門用語で小難しく話すのも、平等に自由だみたいな
0098デフォルトの名無しさん
2010/10/12(火) 22:20:14じゃあ、こんな所にレスするなよ
0099デフォルトの名無しさん
2010/10/12(火) 22:35:19元ハード屋から見てもこのスレの論点はおかしいと思う
信号処理とらやってるとオブジェクト指向なんてのは， 滅茶苦茶頭のいい奴が
書いたものしか信用できない
# ゴミがソフトを書くなと言いたいが， 今の現場は大半がゴミだったりするな
0100デフォルトの名無しさん
2010/10/12(火) 22:47:240101デフォルトの名無しさん
2010/10/12(火) 23:10:40俺たちはそのゴミを使用して生活してるんだし
■ このスレッドは過去ログ倉庫に格納されています