関数型言語は何故普及しないのかを考える
レス数が1000を超えています。これ以上書き込みはできません。
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俺たちはそのゴミを使用して生活してるんだし
0102デフォルトの名無しさん
2010/10/12(火) 23:12:41とゴミの一人が言ってるかもしれんが, おまえハード組める?
OO じゃ組めないけど， 関数だと組めるんだ。
# 困ったもんだ
0103デフォルトの名無しさん
2010/10/12(火) 23:15:350104デフォルトの名無しさん
2010/10/12(火) 23:19:350105デフォルトの名無しさん
2010/10/12(火) 23:22:05お前らのいうめちゃくちゃ頭のいい奴ってせいぜいFランク私大の情報系学科首席レベルだろ？
0106デフォルトの名無しさん
2010/10/12(火) 23:23:13現場じゃ神扱いだよ。
0107デフォルトの名無しさん
2010/10/12(火) 23:24:22つ LISP
0108デフォルトの名無しさん
2010/10/12(火) 23:24:410109デフォルトの名無しさん
2010/10/12(火) 23:25:31なんだ、金じゃないんだ。
0110デフォルトの名無しさん
2010/10/12(火) 23:27:46別人だがフォローしておくと、
LISP マシンをターゲットにした場合の LISP な。
（ただし、LISP を関数型と仮定する）
0111デフォルトの名無しさん
2010/10/12(火) 23:29:370112デフォルトの名無しさん
2010/10/12(火) 23:30:06ゴミかどうかではなく、人をゴミ扱いする神経が問題だと気づけよ
0113デフォルトの名無しさん
2010/10/12(火) 23:32:13>>110
>>111
へー、知らんかった。
0114デフォルトの名無しさん
2010/10/12(火) 23:32:34関数型は普及しないってことなのかねぇ。
道案内するとき、
手続き型で説明したほうが
分かりやすいし。
0115デフォルトの名無しさん
2010/10/12(火) 23:33:31ロケット飛ばしてたりとか加速機扱ってる連中はおおむねそんなもんだ
一応国大の院出てるんじゃね？
0116デフォルトの名無しさん
2010/10/12(火) 23:33:35でもLISPは高機能なマクロが利用できるから、Cと違って汚い部分をマクロでカバーすることで
速度を低下させずに汚い部分を隠すことができるよ。
0117デフォルトの名無しさん
2010/10/12(火) 23:35:43Lispで他の言語と同じように書いてるからなおさら
状態を持たないって何がすごいの？
0118デフォルトの名無しさん
2010/10/12(火) 23:37:48状態を持たないんじゃないよ。
状態がローカル変数にあるからグローバルよりも安全なだけ。
そもそも状態はできてしまうもの。
これはどうしようもない。
0119デフォルトの名無しさん
2010/10/12(火) 23:42:34ああマクロね、なんか聞いたことある。
暇があったらLisp本よんでみよう。
0120デフォルトの名無しさん
2010/10/12(火) 23:44:14状態が関数名とかあり得るよな
# OO ってぶっちゃけ class の名前でグローバル変数かこっただけやん
0121デフォルトの名無しさん
2010/10/12(火) 23:45:39Haskell/OCamlではマクロはほとんど使われないな
型があるからだろうか
0122デフォルトの名無しさん
2010/10/12(火) 23:47:23一応、 補足
みんながみんなそんなことをやってるとは思ってない
けど， class の名前の元にグローバル変数かこっただけの奴が多いのも現実
0123デフォルトの名無しさん
2010/10/12(火) 23:50:51まじめなんだと思う
3 行以上似たようなことを書いたら関数かマクロに出来ないかと考えるのは
C プログラマでも健全な考え方ちゃうん?
0124デフォルトの名無しさん
2010/10/13(水) 00:04:39開発するのがやりやすい。
0125デフォルトの名無しさん
2010/10/13(水) 00:08:58型がきっちりと定義されていたほうが
リファクタリングブラウザがうまく働く。
大規模開発では、コンパイラが、コードの意味を適切に
理解し開発をサポートするためにがっちりと定義されるようになるだろう。
0126デフォルトの名無しさん
2010/10/13(水) 16:41:40でも、
「右曲がって、まっすぐ行って、それから、左に折れて・・」 この辺でもうわからなくなる。
0127デフォルトの名無しさん
2010/10/13(水) 18:54:050128デフォルトの名無しさん
2010/10/13(水) 23:57:00関数型言語なんてそれを逆向きにして
「・・・する前に左に折れて、その前にまっすぐ行って、その前に右曲がる」
って書くだけじゃん。何が違う？
0129デフォルトの名無しさん
2010/10/13(水) 23:59:41この場合、副作用ってどういうことになるんだろう？
0130デフォルトの名無しさん
2010/10/14(木) 00:29:37全然違う。
関数型は数学の関数を主軸に置いた言語。
引数と戻り値との間の「関係」を表現する事が特徴だ。
>>128 では関数型の性質を全く喩えていない。
>>128 はおそらく遅延評価と勘違いしていると思われる。
0131デフォルトの名無しさん
2010/10/14(木) 02:18:35内部状態：現在位置(緯度と経度)や方向(東西南北)
手続き：右へ曲がって --> 方向 := 方向 + 90
0132デフォルトの名無しさん
2010/10/14(木) 04:12:42使い手がひねくれて一般人に敬遠されてるからに決まってんだろ
0133デフォルトの名無しさん
2010/10/14(木) 04:42:30幸運にも、「16番街の一番高い白い建物」という風に表現できればずばり行くことができる。
こういう人類が育て上げてきたシンボル表現と手続き型は疎遠だ。論理型の得意とする領域かな。
0134デフォルトの名無しさん
2010/10/14(木) 21:25:28まあ、実際はこんな感じなんだがな。
0135デフォルトの名無しさん
2010/10/15(金) 20:34:29簡単なこと。
開発規模とステップ数が一致しないからだ。
マネージャーは開発規模を測る物差しにステップ数を使うから、
ステップ数がアテにならない関数型言語でどうやって開発規模を測ればいいのかわからないんだよ。
0136デフォルトの名無しさん
2010/10/15(金) 20:42:560137デフォルトの名無しさん
2010/10/15(金) 20:43:580138デフォルトの名無しさん
2010/10/15(金) 20:44:440139デフォルトの名無しさん
2010/10/15(金) 20:47:010140デフォルトの名無しさん
2010/10/15(金) 20:58:18ステップで金払えとか何処のヤクザだよｗ
てかまだそんな勘定してんのかよ。
プリントアウトした紙の枚数で金額きめてんのかよｗｗｗ
0141デフォルトの名無しさん
2010/10/15(金) 21:08:53お前、関数型言語でステップ数と一致しないほどの規模の開発をしたこと無いだろ
0142デフォルトの名無しさん
2010/10/15(金) 21:12:23ステップ数という言葉を使う奴にぜひ聞きたいといつも思うことなんだけど。
0143デフォルトの名無しさん
2010/10/15(金) 21:31:510144デフォルトの名無しさん
2010/10/15(金) 21:41:18行数
0145デフォルトの名無しさん
2010/10/15(金) 22:15:100146デフォルトの名無しさん
2010/10/15(金) 22:19:28行数が極端に少ない人と手続き型言語と同じぐらいの行数を使って書くヒトがいる。
0147デフォルトの名無しさん
2010/10/15(金) 22:34:01行数が「極端」に少ない人のコードは、たいていは読み難い
0148デフォルトの名無しさん
2010/10/15(金) 22:34:180149デフォルトの名無しさん
2010/10/15(金) 22:42:06行数多い人ってやたら頭の悪いアルゴリズムを書いちゃう人がおおい気がするんだよね。
0150デフォルトの名無しさん
2010/10/15(金) 22:48:120151デフォルトの名無しさん
2010/10/15(金) 22:52:17ステップ数は行数のことだって言ってるじゃんｗ
マネージャーが知りたいのは開発規模であって、C言語では行数を指標にするが、
関数型言語ではどうやって開発規模を測るかってことが問題なの。
0152デフォルトの名無しさん
2010/10/15(金) 22:54:34関数型言語では行数ではダメな理由を説明してください。
0153デフォルトの名無しさん
2010/10/15(金) 22:59:54おぉそうだった、言い直すわ
関数型の開発規模を測るための指標の一つとして、
コールしてる関数の数ってのはどうだ？
0154デフォルトの名無しさん
2010/10/15(金) 23:02:12一般論だが、関数型言語では記述行数が極めて少ないということをウリにしている事が多いから。
現実的には、>>146のとおり、プログラマの質によって行数の幅が広い。
C言語などの手続き型言語では、同じアルゴリズムなら一般的に同じような行数になるから、
行数を開発規模の指標に使われることが多い。
0155デフォルトの名無しさん
2010/10/15(金) 23:04:28一般的なマネージャーってファンクションポイント法は使わないのか？
0156デフォルトの名無しさん
2010/10/15(金) 23:09:53実に教科書的な回答だが、実際にはFP法は経験的な面が大きいし、
マネージャーに熟練が求められるのでメインで使われることはほとんどない。
行数を数えるだけなら誰でも簡単にできるでしょ？
まぁ、プログラミングの腕も高いマネージャの場合はその仕事が難しいか簡単か分かるから、
そのへんを考慮することも多いね。
0157デフォルトの名無しさん
2010/10/15(金) 23:10:31ならない
0158デフォルトの名無しさん
2010/10/15(金) 23:11:50そりゃ無理に短く書こうとすれば短くなるかもしれんが、
普通に書いている分には同じような行数になるよ。
経験的にそうだとしか言えないけどな。
統計データとかあるなら教えて欲しいぐらいだ。
0159デフォルトの名無しさん
2010/10/15(金) 23:14:470160デフォルトの名無しさん
2010/10/15(金) 23:21:02プログラミングは本質的に単純労働じゃないんだよ。強いて言えば小説家が得る収入と同じ意味がある。
売れるコードを書く奴が高収入になるべきなんだ。
0161デフォルトの名無しさん
2010/10/15(金) 23:21:24KLという単位は抽象的比喩的なものにすぎないのだが
0162デフォルトの名無しさん
2010/10/15(金) 23:22:430163デフォルトの名無しさん
2010/10/15(金) 23:31:241万行のプログラムと100万行のプログラムは、
たぶん後者のほうが複雑なのだろう
もっとも、行数以上にまともな指標が無いだけでもあるのだがｗ
ソフトウェアメトリクス屋がんばれ〜
0164デフォルトの名無しさん
2010/10/15(金) 23:31:42定量的でないものなのですか？
定量的に評価できないから関数型言語はダメで、定量的に評価できる手続き型言語がいいんだ、
という話だとばかり思っていたのですが、抽象的比喩的な単位で評価できるから手続き型言語が良くて、
抽象的比喩的な評価もできないのが関数型言語だ、ということなのですか？
0165デフォルトの名無しさん
2010/10/15(金) 23:39:24資産あるいは費用の根拠にするというだけの事であって
それが実際に作成されたプログラムの行数と同じかどうかなど誰も知らない
クライアントが気にするなら編集してつじつまの合うように行数を増減させるだけの話
0166デフォルトの名無しさん
2010/10/15(金) 23:40:18何かそういうの気持ち悪い
0167デフォルトの名無しさん
2010/10/15(金) 23:43:05鏡をなくせば不細工な自分は存在しなくなるか?
0168デフォルトの名無しさん
2010/10/15(金) 23:45:10そもそもなんだが・・・
開発言語として関数型も挙がったが開発規模を測れないという理由で却下された
という話は実際にあるものなのか
それ以前に、議題にすら挙がらず無視されるような気がするんだが
0169デフォルトの名無しさん
2010/10/15(金) 23:49:31どうやって運用したらいいものやらわからないから
議論に上がる前にみんな引っ込むんだよ。
誰も新しい試みをして責任とりたくないからね。
0170デフォルトの名無しさん
2010/10/15(金) 23:54:12言いだしっぺの法則という厄介な法則があるので、新しい事ができない。
基本的にマインドストーミングとか無くて、上司から部下への一方通行。
0171デフォルトの名無しさん
2010/10/16(土) 00:55:012chでそういわれる奴の殆どが、口だけの外野ばっかりだからなぁ
0172デフォルトの名無しさん
2010/10/16(土) 01:32:03スタンドプレーから生じるチームワークというのがあってだな
0173デフォルトの名無しさん
2010/10/16(土) 05:51:250174デフォルトの名無しさん
2010/10/16(土) 07:18:37バカな質問なんだろうけど、この際。 <- 積年の疑問
COBOLのステップ数っていうのは
PROCEDURE DIVISION だけを勘定するんですか？
0175デフォルトの名無しさん
2010/10/16(土) 13:33:59使われている言語は何故使われるようになったかを考える方が有用
0176デフォルトの名無しさん
2010/10/16(土) 15:33:58シンプルな事実だけど、逆に考えれば
関数型言語の情報が他に比べて少ないってことでもあると思う
0177デフォルトの名無しさん
2010/10/16(土) 18:07:29そうだと思う
>>176
それは普及してるから情報が多いんであって
情報が少ないから普及しないとは限らない。
0178デフォルトの名無しさん
2010/10/17(日) 10:34:05頭がいい奴がどんなに素晴らしいと思っても、
初心者がどこがどういいのかわからなかったら誰も寄り付かない。
「関数型の魅力」みたいなのを語る時点ですでに失格なのかもしれない。
0179デフォルトの名無しさん
2010/10/17(日) 10:40:370180デフォルトの名無しさん
2010/10/17(日) 10:55:43そんな馬鹿のことを気にしても仕方がない
0181デフォルトの名無しさん
2010/10/17(日) 11:08:57残念だけど、2:8の原則に従い、どうやったって8割はそんなに賢くはならないんだ。
「賢くないと使いこなせない」ものはどうやったって普及しない。
で、「今日インストールしたら、あなたが今やりたいことができます。
でも、後で色々苦労するかもしれません。」
というのと
「最初はちょっと勉強しないといけませんが、
いつかあなたのやりたいことがとても素早くできるようになります。」
というのとで、どちらを選ぶかというと、ふつうは前者だよね。
Ruby はキラーアプリとして Rails があった。
確かにまずは30分で何かDBアプリっぽいものを作ることができた。
このインパクトがなかったらここまで普及していないだろう。
流行れば、ライブラリ、情報が増える。
増えるとやりたいことがすぐできるようになるのでとっつきやすくなる。
プログラマ人口が増えると、安心して組織で採用しやすくなる。
(LISP がどんなに素晴らしくても、誰が LISP プログラムをずっと保守してくれるんだ?)
あと、そもそもやりたいことをするには事実上それしか選択肢がないというのもある。
Perl は、嫌でもこれしか選択肢がないから流行った。
JavaScript もそれ。
言語としての筋の良さは残念だけど二の次なんだよね…
例外的だなと感じているのは Python かなぁ。
これはじわじわ普及する感じがしている。
0182デフォルトの名無しさん
2010/10/17(日) 12:03:090183デフォルトの名無しさん
2010/10/17(日) 12:05:50「CGIはどの言語でも書ける」ということを教えるよりも
Perlを教えるほうが楽だと思ったからPerlが流行った。
Pythonでも「言語なんてどれでも同じ」と言えない空気があることには変わりない。
何も変わってない。
馬鹿でもわかるようにしたいなら
「クラスは構造体のようなものだ」とか
「クロージャはクラスのようなものだ」とか
「モナドはイテレータのようなものだ」と説明すればいいが
それを言ったらおしまいだという空気がある。
0184デフォルトの名無しさん
2010/10/17(日) 12:16:58C言語は何故普及したのかというと
「CPUなんてどれでも同じ」って言っちゃったからです
0185デフォルトの名無しさん
2010/10/17(日) 12:26:43クロージャとクラスならクロージャのほうが簡単じゃない？
0186デフォルトの名無しさん
2010/10/17(日) 12:40:11それは、ノーテーションが簡単ってことでしょ
モデルは共通だということをふまえた上でノーテーションにこだわるなら良いんじゃね
0187デフォルトの名無しさん
2010/10/17(日) 12:44:260188デフォルトの名無しさん
2010/10/17(日) 12:48:02クラス、構造体、クロージャ、モナド、イテレータ
どれも初心者にはわからない。
君の話は、手続き型言語を使い込んでる
人を対象にしている。すでに。
0189デフォルトの名無しさん
2010/10/17(日) 12:59:27今はそうでもないが、Web の黎明期(1995年頃)は Perl しか事実上選択肢がなかったんだ。
少なくともほとんどのレンタルサーバで Perl CGI しか選ばせてくれなかった。
(C言語は危険と言われて使わせてもらえなかったし、ほかの言語はインストールさえされていない。)
サーバーもレンタルくらいしか方法がなかった。
言語の選択の余地があったという認識はおかしいんじゃない?
ttp://plusd.itmedia.co.jp/products/hyperbox/special/031215.html
Unix 互換環境ならデフォルトでインストールされているだろう
sh とか awk とかでも確かに書こうと思えば書けるのかもしれないが、
Perl が使える状況でそんなことやろうという奴はいないだろう。
0190デフォルトの名無しさん
2010/10/17(日) 13:09:29単純なモデルは学者にとってメリットがあるが、プログラマにメリットないよね
学者が「利息つけて借りを返します」って書いてハンコ押してくれるなら話は別だが
0191デフォルトの名無しさん
2010/10/17(日) 13:25:46でもまあ理系なら口約束じゃなくて形式にこだわるような気もする
0192デフォルトの名無しさん
2010/10/17(日) 13:29:24> サーバー
をレンタル出来ない時代があった
0193デフォルトの名無しさん
2010/10/17(日) 13:32:46手続き型言語を教えるノウハウがあるのに、なんで使わないの
わざわざノウハウを再発明してどうすんの
0194デフォルトの名無しさん
2010/10/17(日) 13:43:42モデルが単純ってのは、プログラマから見れば「一つのことしかしない道具」ってことだろ
理解しやすく使いやすく組み合せやすい、メリットはたくさんある
0195デフォルトの名無しさん
2010/10/17(日) 14:01:11もっと絡繰り人形レベルで説明、理解できないものかな。
0196デフォルトの名無しさん
2010/10/17(日) 14:50:10モデルが単純でも、それが汎用の言語であるならプログラムは簡単にならない。
正規表現は単純で便利だが、汎用ではないから
他の複雑な言語と組み合わせないとプログラムは書けない。
0197デフォルトの名無しさん
2010/10/17(日) 15:16:35もちろんクロージャだけではプログラムは書けない
0198デフォルトの名無しさん
2010/10/17(日) 17:21:27やりたいことによってはそうじゃない気もする。
変更が可能な変数を扱う場合に
オブジェクトの中にオブジェクトを生成するのはやりやすいが
クロージャの中でクロージャを生成するのはバグりやすい
(内側のクロージャを複数生成すると、最初のクロージャの環境が内側クロージャで共有されてしまう)
外側のクロージャの環境は、全てクラス変数/静的フィールドみたいな感じ
クロージャで変更可能な変数を扱わなければ問題はないけど
0199185
2010/10/17(日) 17:56:40>>185で簡単と書いたのは、クラスとは何か理解するよりも、クロージャとは何
か理解することのほうが簡単じゃないか、てこと。使い方はそれぞれ向き不向
きがあると思う。
クロージャ＋色々でオブジェクトシステムを実装できるイメージがある。
0200デフォルトの名無しさん
2010/10/17(日) 19:14:33quoteの概念て関数型言語として見るとどうなの？
0201デフォルトの名無しさん
2010/10/17(日) 19:29:23LISPでリスト処理を書く時って、無意識的に参照透過性を
維持しながら書くと思うけど、あれが関数型言語のルーツ？
なんじゃないかって思う。
まあ手続き的に書いちゃう人もいるだろうけど。
0202デフォルトの名無しさん
2010/10/17(日) 20:17:11参照透過でなくなる最大の原因だな >(古典的マクロ + backquote)
# gensym の使い方を覚えるまでだけど…
0203デフォルトの名無しさん
2010/10/17(日) 20:28:32文字列と正規表現の最大のライバル
0204デフォルトの名無しさん
2010/10/17(日) 20:39:330205デフォルトの名無しさん
2010/10/19(火) 03:54:05普及とかどうでもいいんだけど
0206デフォルトの名無しさん
2010/10/19(火) 04:12:52ここが受け皿になっている感はあるが、
スレタイを変えて繁盛するかは分からん
0207デフォルトの名無しさん
2010/10/19(火) 04:15:39関数型言語Part5
http://hibari.2ch.net/test/read.cgi/tech/1252470706/
関数型と手続き型
http://hibari.2ch.net/test/read.cgi/tech/1145115971/
0208デフォルトの名無しさん
2010/10/19(火) 07:42:13Part5になってからもう・・・
0209デフォルトの名無しさん
2010/10/19(火) 21:36:40> オブジェクトの中にオブジェクトを生成するのはやりやすいが
> クロージャの中でクロージャを生成するのはバグりやすい
つまり、クロージャの中でクロージャを生成するのは、苦労するんじゃぁ。
0210デフォルトの名無しさん
2010/10/21(木) 00:20:55Armstrong博士は、アドバイザの議論によって完全に納得させられたのではないと述べたが、Erlangは「唯一のオブジェクト指向言語かもしれない」と考えているようだ。
0211デフォルトの名無しさん
2010/10/21(木) 01:37:010212デフォルトの名無しさん
2010/10/23(土) 10:53:13そのErlangの部分も含めて、なぜそうなのかの説明不足の
箇所が多く、翻訳が日本語と思えないこともあり、かなり
意味不明だなぁ。私にとっては。
0213デフォルトの名無しさん
2010/10/23(土) 11:52:25って当たり前のように語られるけど、これは本当は物凄く異常なことじゃないか？
普通はモデルの方を現実に合わせるべきだろ？
0214デフォルトの名無しさん
2010/10/23(土) 12:07:000215デフォルトの名無しさん
2010/10/23(土) 12:19:52抽象化ってのは現実を別の考え方で捉えることをいうのにｗ
要するに、どっちかに合わせろってことじゃなくて、
現実を抽象化しやすい抽象化法を用いて、
現実を抽象的に捉えるって事をしなきゃいけないんだから、
どっちかがどっちかに合わせなきゃいけないってことはないんだよｗ
0216デフォルトの名無しさん
2010/10/23(土) 12:42:01「別」ということは、少なくとも単一のモデルではありえない。
複数のモデルがある方が良い。そうすると、なんかカオスになって現実っぽくなる。
0217デフォルトの名無しさん
2010/10/23(土) 13:30:26そうは思いません
0218デフォルトの名無しさん
2010/10/24(日) 20:07:35そもそも, 何で日本語に訳されてないといけない？
原文を読むには, 中学/高校の英語で十分なんだが…
0219デフォルトの名無しさん
2010/10/24(日) 21:37:50無理です。
0220デフォルトの名無しさん
2010/10/24(日) 22:04:520221デフォルトの名無しさん
2010/10/24(日) 22:58:06原文で読んだけど大田さん日本語の方がましでした。
0222デフォルトの名無しさん
2010/10/24(日) 22:59:35大田さんの日本語
0223デフォルトの名無しさん
2010/10/27(水) 00:55:48これこそ、オブジェクト指向とプロセス指向との論争を終結させる
まさに魔法のような言葉。
すべてのもやもやが晴れた。
いままでのオブジェクト指向のオブジェクトとは本当のオブジェクトではなかった。
あー、今夜はなんかよく眠れそう。
0224デフォルトの名無しさん
2010/10/27(水) 18:15:12考えればいいのかも。
メッセージループ指向。
オブジェクトの前にメッセージループありき。
プログラミングもメッセージループから
入る。
システムにメッセージループが
どれだけ必要か、また、その
メッセージループの処理から考えはじめる。
0225デフォルトの名無しさん
2010/10/27(水) 21:58:320226デフォルトの名無しさん
2010/10/27(水) 22:05:04Functional Reactive Programmingの考え方がそれっぽいな
小さい回路を関数的に組み合わせて大きい回路を作り、まとめて実行
完成した回路一個がメッセージループ一個に相当する
0227デフォルトの名無しさん
2010/10/27(水) 22:08:07自然数の１０とは、メッセージループに１０回メッセージが送られた状態の異名である
0228デフォルトの名無しさん
2010/10/27(水) 22:16:210229デフォルトの名無しさん
2010/10/27(水) 22:31:24なっている
0230デフォルトの名無しさん
2010/10/27(水) 22:38:22もしもその関数が状態(ステート)を持っているのであれば、なっている
0231デフォルトの名無しさん
2010/10/27(水) 23:10:54どうみてもBeですね。
0232デフォルトの名無しさん
2010/10/28(木) 12:52:57FRP は「実行する」という概念をできるだけ排除して、
システムとメッセージとの間にある応答を伴った「性質や関係」を宣言的に記述しよう
というのが目論見のような気がする
0233デフォルトの名無しさん
2010/10/28(木) 17:49:420234デフォルトの名無しさん
2010/10/28(木) 22:34:05メッセージループまで必ず教えよう。
作ることができるシステムの
違いが多いことに気付く。
0235デフォルトの名無しさん
2010/10/29(金) 21:27:29メッセージループを選択しクリックする
画面上にメッセージループを表す
小さな丸いアイコンが出現する
そのアイコンを右クリックすると、
メッセージ作成、状態遷移表作成
などのメニューがあらわれる。
メニュー作成は、どうやら
このメッセージループが解釈できる
メッセージを定義するものらしい。
状態遷移表作成は、
このメッセージループの挙動を実装する
ためのエディタみたなものだ。
一昔前まえに、スモールトークという
開発環境に初めてあった時の感動を
覚えた。
0236デフォルトの名無しさん
2010/10/31(日) 05:48:280237デフォルトの名無しさん
2010/10/31(日) 09:07:44現在、一般的に利用できる関数型言語処理系で最速なのはML系言語の SML/NJ と言われており、
このコンパイラは直接ネイティブコード(機械語)を生成する。
ベンチマークの課題にもよるが、gccと比較して最速でも数倍は処理時間が必要。
ただし、見方を変えれば、gccの数倍から数十倍程度の遅さなら、
大半の処理で実用レベルの最適化が図られているとも言える。
他の関数型言語、たとえば Haskell 処理系である GHC は、SML/NJ と比較しても圧倒的に遅い。
0238デフォルトの名無しさん
2010/10/31(日) 09:09:200239デフォルトの名無しさん
2010/10/31(日) 09:19:350240デフォルトの名無しさん
2010/10/31(日) 09:25:250241デフォルトの名無しさん
2010/10/31(日) 09:39:58なんとなく手続きじゃないから最適化しやすいのではないかと考えて質問した次第です。
0242デフォルトの名無しさん
2010/10/31(日) 09:44:08関数型なら動的解析とかないし、ある意味最初から静的単一代入形式だったりするわけだけどさ。
0243デフォルトの名無しさん
2010/10/31(日) 09:48:360244デフォルトの名無しさん
2010/10/31(日) 10:17:38ソースコードを解析して最適化できるヶ所を見つけるということなら、
一般的には関数型の方が最適化しやすいと思う。
参照透過性がルールとしてあるのは大きい。
理論上、副作用が影響するぎりぎりの所まで関数をコンパイル時に評価できる。
機能毎のモジュール性が高いから fusion（deforestation）しやすい。
それでも実際に吐き出された実行ファイルは一般的にC言語の方が速い。
たぶんC言語はプログラマがチューニングし易いからだと思う。
メモリの確保・解放のタイミングをプログラマが制御できるから、
余計なオブジェクトの生成を省ける。
関数型は喩えるなら英文を機械翻訳するようなものだと思う。
0245デフォルトの名無しさん
2010/10/31(日) 10:37:45最終的に速くはならないだろうということですね。賢くなってほしいなぁ。
0246デフォルトの名無しさん
2010/10/31(日) 10:38:450247デフォルトの名無しさん
2010/10/31(日) 10:44:380248デフォルトの名無しさん
2010/10/31(日) 11:40:070249デフォルトの名無しさん
2010/10/31(日) 15:53:03広い意味での外部DSL
0250デフォルトの名無しさん
2010/10/31(日) 16:07:40意味が分からん
もう少し詳細に語ってくれ
0251デフォルトの名無しさん
2010/11/03(水) 07:58:09いや、Erlangなんかは1991年マイク ウィリアムズが
C言語で仮想マシンを書いたんだけど、
要は関数型言語を使うためにC言語でまずつくってるっていう
ビルディングブロックになってるというか階層構造になってるので
言語VS言語みたいな議論はその辺をちゃんと押さえないとってこと。
ある目的のために、低レベルな言語でスクリプトかいてそのスクリプトで効率的に
開発するっていう手法もある。
で、つまり究極的にはその関数型言語やスクリプトで書いたシステムは
C言語でかけるわけで。。。（Cでつくった仮想マシンでうごいてるんだから。）
最後はマシン語におちるから。
つまり、関数型言語っていうのは、フレームワークとか外部DSLにすぎないっていう
視点があって、それは言語論争をする際には記憶の片隅においておかないといけないことなんだよね。
0252デフォルトの名無しさん
2010/11/03(水) 08:11:06なんかいいことあるわけ？
0253デフォルトの名無しさん
2010/11/03(水) 08:32:56それを前提とした論理展開はおおいにバイアスがかかっているから鵜呑みにするな
ということだと思う。
所詮は構文と意味論が他のものと異なっているというところにアイデンティティを
持っているものに過ぎないわけで、その二つを生かしきれていない活用は
単なる個人の思い入れの産物に過ぎないとみなされても仕方ないよね、と言いたいんだろう。
0254デフォルトの名無しさん
2010/11/03(水) 08:45:43その関数型言語用集で表現されるC言語も、そのなかにおけるひとつの宇宙に
過ぎないとかいいたいのだと思う。
0255デフォルトの名無しさん
2010/11/03(水) 08:46:380256デフォルトの名無しさん
2010/11/03(水) 08:58:330257デフォルトの名無しさん
2010/11/03(水) 09:01:350258デフォルトの名無しさん
2010/11/03(水) 09:46:330259デフォルトの名無しさん
2010/11/03(水) 09:47:07ら、理論的には>>251の用な認識は無意味じゃない？ 実用的には、Cで書かない
と何で書くの？ となるから、Cで書くのがナンセンスという意味ではないよ。
関数型言語で自分自身をコンパイルできるようなコンパイラを作れるんだし。
0260デフォルトの名無しさん
2010/11/03(水) 11:34:16言語自身のことしか考えていないのが誤り。
重要なのは、他言語でも再利用されるライブラリを書くこと。
これは敵に塩を送るようなもので「なんかいいことあるわけ？」という気もする。
でも、言語が普及するということはまさにそういうことなんだ。
0261デフォルトの名無しさん
2010/11/03(水) 12:51:58他言語からも利用される＝普及する、
というのには言われてみれば一理あると思う。
ただ、
> 重要なのは、他言語でも再利用されるライブラリを書くこと。
それは、他言語からロードできるライブラリを書くこと、なのか、
他言語にも移植されるライブラリを書くこと、なのか。
それとも、もっと別のことなの？
その辺、ちょっと曖昧
0262デフォルトの名無しさん
2010/11/03(水) 13:21:14利用方法は自由。
自由は曖昧で嫌いだという奴は初心者。
自由の良さを啓蒙する必要がある。
0263デフォルトの名無しさん
2010/11/03(水) 13:47:08曖昧の意味を誤解されてしまった
> 他言語でも再利用されるライブラリを書く
というのが他言語からロードできるライブラリを書くことであるなら、意味は分かる。
既に普及している言語Ａが作ったライブラリを別の言語Ｂがロードして利用するは至極当然で、
それをもって言語Ａが普及していると見なすのは納得できる。
しかし、他言語にも移植されるライブラリを書くことであるなら、
それはほとんどアルゴリズムと実装の問題で、
ある言語Ａでの実装が別の言語Ｂに移植されたからと言って、
言語Ａが普及していると言えるかというと、それはほとんど関係ないと思う。
そもそも、移植可能ライブラリで実装されているアルゴリズムや考え方は、
たいていはまず最初に言語非依存で考えてから実装される。
どちらの意味なのかによって同意できるかできないかが変わってくるから、
それを >>260 に訊いてみたのだが、>>262 はどちらもあり得ると言うの？
それなら、後者の意味ではさっきも言ったように、それは違うのではと思うのだが、
>>262 はどう考えてるの？
> 自由は曖昧で嫌いだという奴は初心者。
何に対する「初心者」なのか意味が分からない
0264デフォルトの名無しさん
2010/11/03(水) 13:57:070265デフォルトの名無しさん
2010/11/03(水) 15:14:41そういうレスをよく見かけるけど、
こちらは言われるようにあなたから見れば初心者なんだから、
何がどう脱線しているのかを説明してくれないと分からないです
こちらは脱線してないと自分では思って会話をしているつもりなんだし
分かる人に分かればいいという流れだったのであれば、
初心者が割り込んで申し訳なかった、構わず続けてほしい
0266デフォルトの名無しさん
2010/11/03(水) 15:33:34どれでもよいとする回答に噛みついているから。このレスも無駄レス。
0267デフォルトの名無しさん
2010/11/03(水) 16:08:31という二つの結果があって、なぜ差がついたのかという問題がある。
ユーザーから見るとどうでもいい問題だが、そういう話題があっても悪くはないと思う。
0268デフォルトの名無しさん
2010/11/09(火) 02:28:24例えば、WikipediaにPerl6の開発を短縮できたみたいに書いてあるけど
言語処理なら開発の早さより、速さが大切で明らかにズレてる
ハード寄りなら、モナドばかりになるだろうし、
逆にGUI的なものも、OOPLの方が直感的
Webみたいな用途で使ったとして、PHPやRubyのような早さはない
思いつくのは、CUIのツール類とかサーバーだけど、
やはり、速さが欲しくなるだろうからCに勝てるのか疑問
要するに用途やメリットが解らないから、使わない
関数型言語を使ったこともない素人が、イメージだけで語ってみた
0269268
2010/11/09(火) 02:45:25例えば、音声ファイルのエンコーダは速さも大切だけど
音質とかどのプレイヤーでも正しく再生できるとかいうのを求めると思う
IOが少なく、速さと正しさのバランスが求められる分野が
関数型言語のポテンシャルを引き出せるんじゃないかな
0270デフォルトの名無しさん
2010/11/09(火) 08:39:250271268
2010/11/09(火) 12:18:14じゃあ、逆に訊きますけど、評価を遅らせることで速さを稼ぐのは、
Haskellの良さではないのですか？
リアルタイムを要求される場面で、評価が遅れないように意識して作るのと
ほとんど意識しないで作るのは、どっちが楽ですか？
それと、得意分野の例については、スルーですかそうですか
0272デフォルトの名無しさん
2010/11/09(火) 12:29:15コーデックなんて全然ダメだろう
その手の信号圧縮処理では大概離散コサイン変換のようなものを使ってるが
Cですら浮動小数点ベクトル演算が十分に高速ではないので、しばしば
アセンブラが使われてる世界だろ
0273デフォルトの名無しさん
2010/11/09(火) 12:51:48>言語処理なら開発の早さより、速さが大切で明らかにズレてる
速さも大切なのは十分認めるけど、要求された機能やバグ取り、
シェイプアップなどに素早く応える（開発する）ことも重要な要素の一つだよ。
関数型を使うことで開発（正式リリース）が早くなったというのは、
それだけ開発しやすかった、コードの見通しが良かったということだし、
当然メンテナンスもやりやすかったと思う。
で >>268 に訊くが、実際のところ
「関数型によるPerl6の開発が原因と思われる実行時の問題点」はある？
例えばそれが原因で実行速度が前のバージョンより遅くなったとか。
特にそれが原因の問題がなければ、メリットしか無いと思うがどうだろう。
0274デフォルトの名無しさん
2010/11/09(火) 13:26:370275デフォルトの名無しさん
2010/11/09(火) 13:35:30遅延評価はHaskellの特徴の一つに過ぎない
便利なこともあるが邪魔なことも多い
Haskellの良いところは別のところにあると思う(型クラスとか)
>リアルタイムを要求される場面で、評価が遅れないように意識して作るのと
Haskellでパフォーマンスを意識したコーディングをするなら、
どこが遅延するのか考えながら書くのは避けて通れない
別にリアルタイムアプリ(あるいはIOモナドを多用したコード)に限ったことじゃないよ
0276デフォルトの名無しさん
2010/11/09(火) 18:13:38>リアルタイムを要求される場面で、評価が遅れないように意識して作るのと
この言葉に違和感を感じる、ちょっと勘違いをしているかも。
遅延評価は「必要になるまで評価を遅らせる」仕組みだよ。
リアルタイムを要求される場面で評価が必要になれば、
その時にちゃんと（必要な分だけ）評価されるよ。
ただ、その仕組みを作るのに余分な処理がいるから、
そのオーバーヘッドで結果的に処理が遅くなる。
評価するのが必要になるまで遅延されるだけで、
遅延評価自体が処理を遅くする原因ではないからね。
あくまで現時点での、遅延評価という仕組みの実装方法が原因。
0277デフォルトの名無しさん
2010/11/09(火) 18:20:30遅延の非同期性は並列性と相性いい感じだね
でもリアルタイムシステムに使うのは無理なんじゃない
0278デフォルトの名無しさん
2010/11/09(火) 21:29:34>逆にGUI的なものも、OOPLの方が直感的
これよく耳にするんで聞いてみたいんだが、「直感的な GUI 設計」とは何だ？
OOPL の「何が」GUI 設計を直感的にしているんだ（要因）？
それが関数型でもできれば、あなたも直感的だと感じるのか？
0279268
2010/11/09(火) 22:55:32レス書いてますので、しばしお待ちを
0280268
2010/11/10(水) 01:54:25そういうものですか
試しにlameとlibogg覗いてみたんですが、FFT部分にアセンブラは無さそうでした
静止画、音声程度ならどうにかなるんじゃないでしょうか
動画はいくら速くても足りないかもしれませんね
>>273
実装方法が全然違うから、速さ比較は意味無いと思います
だから、早いというのも眉唾かもしれないと思ったわけです
コンパイルでしたら、まさにエンコードですから向いていると思います
でも、インタープリタは向かないと思います
>>274
ちょっとネタふって、逃げるつもりだったんですがサーセンｗ
>>275
そうなんですか
だとすると、「〜ソリューション！」みたいな感じで
良いところを生かせる場面を例示していけば
私みたいな一見さんを呼び込める気がします
0281268
2010/11/10(水) 01:56:51はい、「必要になるまで」は理解してます
例えば、ネットに接続してデータを送るとき
実際に接続してみないと状態がわからないわけなので
すぐに接続してしまうのではないですか？
送るデータが必要になるのは、接続の手続きの後なので、
必要になったデータを生成していると、
送るのに間に合わないといった事態は起きないのでしょうか？
>>277
そうですね、自然言語に近いとか
図でイメージしやすいとか、
関数型言語でそういうのがあるなら、
私みたいなのでも直感的に扱えるかもしれません
0282デフォルトの名無しさん
2010/11/10(水) 07:35:03>実装方法が全然違うから、速さ比較は意味無いと思います
>だから、早いというのも眉唾かもしれないと思ったわけです
速さ比較は単なる例で、何でもいいんだよ（例えばって言ったでしょ）。
質問は以下の２点。
1) 実際に君が使ってみて、あるいは周りで使ってる人達の実感を聞いて、
Perl6 を関数型で作ったことに関する弊害は何かあったのか？
要するに、実用に耐えられなかったのかと訊いている。
2) で、弊害がなければ、少なくとも perl6 に関しては、
関数型で作ったことにメリットしかないのではないか？
「言語処理なら開発の早さより、速さが大切で明らかにズレてる」は
プログラミング言語のひとつの側面を強調しすぎていると思うのだがなぁ
0283デフォルトの名無しさん
2010/11/10(水) 07:54:22> 実際に接続してみないと状態がわからないわけなので
> ...
> 送るのに間に合わないといった事態は起きないのでしょうか？
あぁ、接続してから必要なデータを計算していると、
ネット接続のタイムアウトを喰らうのではと懸念しているわけね。
それが心配なら、接続前に計算を済ませておけばいい。
ネット接続関数の引数の設定を正格評価にしておけば、
引数にその関数を適用した時点で引数が評価される。
もっと前の段階で計算を済ませておくことも当然できる。
C 言語でも、接続後にデータを計算するか、
接続前にデータを計算するか、プログラマが自分で選択できるでしょ。
というか、自動では処理されないから、どちらかを選ばなくてはならない。
Haskell も選択できる、いっしょだよ。
> そうですね、自然言語に近いとか
> 図でイメージしやすいとか
OOPL のどこにそのような要素があるのか解説してくれないか？
0284デフォルトの名無しさん
2010/11/10(水) 09:24:470285デフォルトの名無しさん
2010/11/10(水) 12:44:11如何様にも書ける。
直感的にグラフを直接構築してもいいし、
関数を要素とした配列変数を作ってもいいし、
関数に次の状態への関数を渡す方法でもいいし。
色々やり方はある。
参照透過性を保ちたいのなら、例えば前回の状態も一緒に運んで、
関数内で現在の状態へと再構築して、次の関数へ渡せばいい。
0286268
2010/11/10(水) 16:47:381)速さを訊きたいのはこっちなんですが・・・
早いというからには、検証可能であるデータを出さなければいけないのは
言った側であって、私じゃありません
2)「Perl6が使い物になる=Haskellが早い」では、ありません
Cで書かれている部分で高速化が図られていて、
トータルの開発に時間がかかっているかもしれません
Haskellの遅さが表面化していないだけかもしれません
0287268
2010/11/10(水) 16:49:07普通、何時評価されるかなんて気にしません
わざわざ気にしなければならない時点で、
プログラマに負担を強いることになってませんか？
選択できるかどうかではなく、
意識して遅延させるか、意識して遅延させないか
無意識がどっちにあるかという問題なんです
＞OOPL
例えば、野球を考えます
ボールを投げるとき、キャッチャーをめがけて投げます
直接的にはボールに速度を与えるだけですが、
間接的には、バッターが打つ準備をし、キャッチャーに捕る体勢をとらせます
OOPLであれば、
ball.throw(batter, catcher)
みたいな感じで、一連の事象に関わる目的語を沢山書けます
この辺りが自然言語に近く図でイメージしやすい理由です
0288デフォルトの名無しさん
2010/11/10(水) 17:32:28throw(ball,pitcher,catcher)
でも書けているのではないかな。
0289デフォルトの名無しさん
2010/11/10(水) 18:34:25実際、そういう書き方のOOPの実装もあるよね。
0290デフォルトの名無しさん
2010/11/10(水) 19:06:10＞OOPL のどこにそのような要素があるのか解説してくれないか？
クラス図やオブジェクト図を描けば、
全体的な構成が伝わりやすい。
目に見えるモノ単位なので、自然と
わかりやすい（気がする）。
>>285
関数型言語特有の言葉、常識、流れが
わからなければ、意味がほとんど
わからない。
スレタイのことは、要するにそういうこと。
何故？ではない。
理由が本気でわからないなら、すなわち、
普及させることができるはずがない。
個人的には、それでいんじゃね、と
思ってるけどね。ｗ
0291デフォルトの名無しさん
2010/11/10(水) 19:10:05> 早いというからには、検証可能であるデータを出さなければいけないのは
> 言った側であって、私じゃありません
え？ だって、あなたが自分で次のように言ったんだよ。
> 例えば、WikipediaにPerl6の開発を短縮できたみたいに書いてあるけど
> 言語処理なら開発の早さより、速さが大切で明らかにズレてる
この言い方って、Perl6の開発が処理速度よりも開発の早さを優先させた、
この考え方（作る姿勢）はおかしいと言っているように聞こえたんだけど。
実際に処理速度的に問題が起きてなければ、その姿勢でもいいじゃんと私は思ってる。
ハードルをクリアした上で、開発時間を短縮したんだから。
そこまであなたが、開発の早さを優先させた姿勢がズレてると言うのなら、
実際にその姿勢のせいで（関数型を使ったせいで）何か問題が起きてるのかなと訊いたんだよ。
厳密なデータとか比較可能なデータとか、そんな厳しく訊いてないよ。
厳しく聞こえたのならゴメン。
単に Perl6 を使って何か問題に気づいたのか、実体験を訊きたかった。
あるいは、周りで使ってる人の話でもいいよ。
> Haskellの遅さが表面化していないだけかもしれません
表面化してないなら十分でしょ。
0292デフォルトの名無しさん
2010/11/10(水) 19:25:31> 例えば、野球を考えます
Haskell ならこういう書き方をして、
ピッチャーとバッターとキャッチャーのボールを通しての関係性を
静的に表現すること「も」できる（もっと別の表現方法もできる）。
result <== catcher <== batter <== pitcher
ピッチャーが投げたボールがバットに当たったのか、
バットにかすったがキャッチャーが取ったのか、
ストライクゾーンを外れたのか、バッターが打ったのか、
キャッチャーが取りこぼしたのか、取ったのか、
といった情報が result を評価することで全て分かる仕組みを作れる。
正確には result を評価することが、一球投げることを意味する。
正直、恥ずかしながら野球をよく知らないので、
適切な用語を関数名などにつければ、もっと分かりやすくなると思うが。
0293デフォルトの名無しさん
2010/11/10(水) 19:28:29むしろいつ評価されるかきにしないための遅延評価。
正格評価はすべてを評価してるんだからそれもある意味"いつ"を気にしてないでいがリソースの無駄。
遅延評価にすることで必要なものだけ適切なタイミングで評価される。
評価の順序が気になるならモナドればおけー。
接続のタイミングに評価したら時間がかかる?
接続のタイミングの意味がわからんが(いやいわんとすることはわかるがｗ）時間のかかる処理ならそもそも時間のかかる処理の評価と接続のタイミングには特別な関係があるんだからそれもモナドればオケー。
特別なものだけ気にしてほかは一切Howを指定しないでWhatを指定すればいいという思想。
0294デフォルトの名無しさん
2010/11/10(水) 19:36:08正格評価の言語だと、有限のリストと無限のリストじゃ扱い方が変わっちゃうやね
0295デフォルトの名無しさん
2010/11/10(水) 19:52:31正格評価がデフォの言語は、関数をコールした時が関数を評価する時だから、
当然いつ評価されるかは気にしない。
でもパフォーマンスを求めてる時は、いつ関数をコールするかは気にするでしょ。
同じデータを構築するのにも順番によって効率が変わってくるしね。
そういう時は、プログラマは普段よりも負担を強いられてるけど、
負担を強いられてでもパフォーマンスを求めたいわけだよ。
非正格評価（遅延評価）がデフォの言語でいつ評価されるかを気にするのも、
そういったパフォーマンスを求めている時なんだよ。
初心者はともかく、普通の Haskell プログラマは、
普段はいつ評価されるかなんてほとんど気にしない。
必要な時に必要なだけ評価されるようコンパイラが良きに計らってくれるからね。
それに遅延されてても評価する順番は変わらないから安心してプログラムできるよ。
0296デフォルトの名無しさん
2010/11/10(水) 19:59:15って言われてたのを思い出すな
今でも解決したワケじゃないんだが、以前に比べると
欠点より利点が目立つようになった
遅延評価もいつかはそうなるんかな
0297デフォルトの名無しさん
2010/11/10(水) 20:02:13関数型言語を使ったこともないのにイメージだけで語っちゃう人だと、
もしかしたら誤解されるかも知れないから言っておくと、
> それに遅延されてても評価する順番は変わらないから
というのは、B の評価（処理のある部分）で A の評価結果が必要ならば、
必ず（その処理の後の部分より） A が先に評価されるという意味ね。
0298268
2010/11/12(金) 00:26:38引数を複数取れるんですか！？
だとしたら、私は完全に誤解していたようです
>>289
直接目的語が判り難いですが、自然言語には近いですね
>>290
多分、私に同調して下さったんだと思いますが、
アンカーとの関係が解りませんでした＞＜
>>291
開発で早さを重んじるスタンスがおかしいのではなく、
言語そのものを評価するスタンスが、おかしいと言いました
私は、言語処理系の開発において
早さより速さが大切だと思うので、そういう発言になりました
あなたが、十分と考えるのは勝手ですが、
少なくともそう考えない人には、普及しませんよね
ところで、あなたの意見は、どこかに書いてありましたか？
>>292
その例だと、他の流れが見え難くなる気がします
バッターが打てば、キャッチャーに届くことは少ないですし
打たなければ、バッターは、直接関わりません
さらに意地悪を言えば、キャッチャーが後逸しても
ボールは、別のところに飛んでいきます
ballという単語が見えないだけでなく、述語もありません
自然言語に近いと言うには、厳しいんじゃないでしょうか
0299268
2010/11/12(金) 00:28:32その特別の場面が、IO絡みということはないですか？
関数型でなければ、モナドるかどうか考える必要も無いんじゃないですか？
>>294
無限リストは、スマートですよね
無限を無限のまま扱ってる・・・って宇宙コピペみたいですねｗ
>>295
人に会わないかもしれないといって、
服を着ないで持ち歩いたりしませんよね？
前もって準備するのは、プログラミングやパフォーマンス云々以前に
そういう無意識に近いレベルで行われることです
パフォーマンスを求めることになっても、
海外旅行の準備になるだけの話で、思考パターンは変わりません
ところが、服を着ない人は、
人に会わないかいつも心配していなければなりません
海外旅行の準備では、服のことから悩むことになります
でも、無人島に住んでいれば、人に会う心配は要りません
海外旅行に行くことも無いでしょう
つまり、関数型にとっての無人島が何かわかれば、
それが得意分野として宣伝できるんじゃないでしょうか
>>296
たぶん、言い方だと思うんです
「金槌はどんなことでもできます」って言ってしまうと
「そこらの石の方が漬物の重石にもなるじゃん」とか言われてしまうけど
「金槌は釘を打てます」って言えば、
石の方が使いやすいとは、言われません
そう言ったからって、料理に使っちゃいけないわけでもありません
0300268
2010/11/12(金) 00:38:25(ここ数日他の事が手に付かないｗｗｗ)
言いっ放しになってしまいますが、この辺で名無しに戻らせてもらいます
有り難う御座いました
0301デフォルトの名無しさん
2010/11/12(金) 07:49:51> その例だと、他の流れが見え難くなる気がします
そのように要求すれば、それを可能な限り満たすように記述できる仕組みを作ればいい。
Haskell はそれができる（完璧とは言い難いが、記述方法に関してはかなり柔軟だ）。
あの例は、ピッチャーとバッターとキャッチャーのボールを通した「関係」を
プログラムで示した。
さらに、バッターが撃ったボールと野手との関係を示したかったら、それらを追加して、
先の関係の結果と今回の関係の結果を合成すればいい。
（ここではインデントが正しく表示できないかもしれん）
result <== field ( (catcher <== batter <== pitcher)
<+> (batter ==> [fielder1, fielder2, ・・・]))
<+> 演算子で２つの関係の結果を合成する。
べつに一気に一つの式にしなくても、分けて記述してもいい。
更にイニングの関係を被せればゲームそのものも表現できる。
（それにはもう少し洗練させる必要があるが）
ボールが見えないのは、「ボールを通した関係」を表してるんだ。
このプログラムを書いてる者や見る者に取っては、コメントにでも書いておけば
ボールを通した関係であることが明らかだから、記述する必要がない。
記述したければ記述するように書き換えできるけど、冗長だ。
あくまで、短時間で思いついた書き方を示しただけだ。
もっと直感的に書ける方法も当然あるだろうな。
Haskell ならそれが「考えやすい」し「設計しやすい」。
0302デフォルトの名無しさん
2010/11/12(金) 07:54:40おっと、忘れてた。
述語が無いのが不満なのか？
それは仕方がない。
「静的な関係を式で表す」のが関数型の一般的なスタイルだからだ。
これが馴染めないのはよく分かる。
ただ、慣れだ。
このスタイルが直感的だと感じるタイプの人間も少なくないよ。
0303デフォルトの名無しさん
2010/11/12(金) 10:41:34論理型言語のPrologだと「関係」の表現は以下のような簡潔なコードになる。
:- op(800, xfx, '==>'). % ボールの移動を表現する演算子 '==>' を宣言
pitcher ==> catcher. % 命題「ピッチャーからキャッチャーへボールが移動する」を定義。以下同様。
pitcher ==> batter.
batter ==> catcher.
batter ==> fielder1.
batter ==> fielder2.
batter ==> fielder3.
move_ball(X, Y) :- X ==> Y. % 述語「ボールはAからBへ移動する」を定義。以下も同じ。
move_ball(X, Z) :- X ==> Y, Y ==> Z.
＊＊＊＊ 実行してみよう。＊＊＊＊
?- move_ball(pitcher, fielder2). % ピッチャーから外野手２へボールは移動するか？
true . % 移動する
?- setof(Y, move_ball(pitcher, Y), L). % ピッチャーからどこへボールは送られるのか？
L = [batter, catcher, fielder1, fielder2, fielder3].
?- setof(X, move_ball(X, fielder2), L). % 外野手２はどこからボールを受け取るのか？
L = [batter, pitcher].
?- setof(X, X^move_ball(X, Y), L). 全てのボールの移動を列挙しなさい
Y = batter,
L = [pitcher] ;
Y = catcher,
L = [batter, pitcher] ;
：(以下略)
Haskellで同じ問題を解くコードを書いて下さいまし。「論よりコード」です。何ステップで書けますか？
0304デフォルトの名無しさん
2010/11/12(金) 12:18:22instance Show Player where
show P = "P"
show C = "C"
show B = "B"
show F1 = "F1"
show F2 = "F2"
show F3 = "F3"
instance Eq Player where
x==y = (show x)==(show y)
moves = [(P,C), (P,B), (B,C), (B,F1), (B,F2), (B,F3)]
move_ball p =
moves >>= \(x,y)->
(if p(x,y) then [(x,y)] else []) ++
(moves >>= \(y',z)-> if y==y' && p(x,z) then [(x,z)] else [])
0305デフォルトの名無しさん
2010/11/12(金) 13:14:55Q1. XからYへボールは移動するか？(真偽の判定)
Q2. Xからどこへボールは送られるのか？(自由変数を伴う演繹)
Q3. Xはどこからボールを受け取るのか？(同上)
Q4. すべての関係を列挙(関係に関する関係の演繹(高階演繹))
関連とは、その数学的定義からいって集合間の双方向な対応付けです。
従って「関係の表現」とは、上記のすべての質問に返答できる必要があります。
残念ながら、>>304では１個の対応しか定義できていないように見受けられます。
また、そのたった一個の定義である関数 move_ball にしても、
記号だらけで、あまりに冗長で、おまけに難解すぎますね。素人にはお勧めできない。
Prologなら
move_ball(X, Y) :- X ==> Y.
move_ball(X, Z) :- X ==> Y, X ==> Z.
という、たった２行で、簡潔かつ誰にも分かり易く「すべての関係を定義」できます。
これは、以下の事実を雄弁に物語っています。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
＊＊＊＊ あまりにも冗長で難解なＨａｓｋｅｌｌが現実世界で普及する事は有り得ない ＊＊＊＊
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
代弁、ありがとうございました。
0306305
2010/11/12(金) 13:16:43誤: move_ball(X, Z) :- X ==> Y, X ==> Z.
正: move_ball(X, Z) :- X ==> Y, Y ==> Z.
0307デフォルトの名無しさん
2010/11/12(金) 13:25:030308デフォルトの名無しさん
2010/11/12(金) 13:50:02Q2 = move_ball (\(x,y)-> x==P)
Q3 = move_ball (\(x,y)-> y==F2)
Q4 = move_ball (\_-> True)
0309デフォルトの名無しさん
2010/11/12(金) 14:23:07書いたことないから、動かないかもしれないけど、やはりこんな感じかな。一文字毎のrawmode receive 出力後
のflushout が必要なのかも知れない。
echo_server(Port) :-
socket(internet,stream,Socket),
socket_bind(Socket,Port),
一文字の受信・送信を繰り返す(Socket),
socket_shutdown(Socket).
一文字の受信・送信を繰り返す(Socket) :-
socket_listen(Socket),
socket_accept(Socket,Host : Port,NewSocket),
open(NewSocket,read,Input,[type(binary)]),
open(NewSocket,write,Output,[type(binary)]),
get_byte(Input,Code),
一文字の受信・送信を繰り返す(NewSocket,Input,Output,Code),
close(Output),
close(Input),
close(NewSocket),
一文字の受信・送信を繰り返す(Socket).
一文字の送信・受信を繰り返す(_,_,-1) :- !.
一文字の送信・受信を繰り返す(Input,Output,Code) :-
put_byte(Output,Code),
get_byte(Input,Code2),
一文字の送信・受信を繰り返す(Input,Output,Code2).
0310デフォルトの名無しさん
2010/11/12(金) 14:25:34(==)を定義すれば (F2==) のような述語を簡潔に書けるが、
定義できない場合は \x->case x of{F2->True;_->False} のようになる。
0311デフォルトの名無しさん
2010/11/12(金) 14:35:200312デフォルトの名無しさん
2010/11/12(金) 14:56:09すくなくとも以下は間違っているw
colose(NewSocket)
ここは
socket_shutdown(NewSocket).
0313デフォルトの名無しさん
2010/11/12(金) 14:59:370314305
2010/11/12(金) 15:37:49結局、Haskellでは、個々の質問ごとにいちいち関数を定義しないとならないんですね。
なんて面倒なんでしょう。元の move_ball 定義が４行だから、合計すると８行ですか。
>>380から始まった野球を関係として表現するという話題ですが、
Prologだとほんの初心者クラスの課題ですよ。だって、たった２行で済むのだから。
>>292,301を何も知らない素人が読めば、さぞやHaskellなら簡潔に記述できるんだと騙されますね（w
相手が素人だから、それをいいことに難解な言葉をまくしたてるのは、押し売りや詐欺師の手口ですよ。
>>305を繰り返します。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
＊＊＊＊ あまりにも冗長で難解なＨａｓｋｅｌｌが現実世界で普及する事は有り得ない ＊＊＊＊
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
0315デフォルトの名無しさん
2010/11/12(金) 15:41:120316デフォルトの名無しさん
2010/11/12(金) 15:59:20じつは論理でも集合でもなく、リスト処理だろ
詐欺じゃん
0317305
2010/11/12(金) 16:06:22Prologだと、>>307の質問には、以下のように対話環境に入力するだけですよ。
Q1. ?- move_ball(pitcher, fielder2).
Q2. ?- setof(Y, move_ball(pitcher, Y), L).
Q3. ?- setof(X, move_ball(X, fielder2), L).
Q4. ?- setof(X, X^move_ball(X, Y), L).
とても簡潔で意味も明解です。それに対して、Haskellだと
Q1. move_ball (¥(x,y)-> x==P && y==F2)
Q2. move_ball (¥(x,y)-> x==P)
Q3. move_ball (¥(x,y)-> y==F2)
Q4. move_ball (¥_-> True)
みたいに、(move_ballの定義内容を参照しながら<--ココ重要!!)、いちいち複雑な式を組まないとならない。
素人目にも「Haskellの冗長さ汚さ」が良く分かる具体例ですね。
0318305
2010/11/12(金) 16:08:56これのどこがリスト処理なんでしょうか？（Haskellなんかと一緒にしないでください！！）
move_ball(X, Y) :- X ==> Y.
move_ball(X, Z) :- X ==> Y, Y ==> Z.
0319デフォルトの名無しさん
2010/11/12(金) 16:09:58基地外を構うな
あれはPrologも貶めている
0320デフォルトの名無しさん
2010/11/12(金) 16:20:30なかなか本質を突いていらっしゃるw
0321デフォルトの名無しさん
2010/11/12(金) 16:30:16非決定性チューリングマシンさえあれば・・・・
0322デフォルトの名無しさん
2010/11/12(金) 17:58:43今気が付いたけど、受信・送信の順序が途中でひっくり返っているな。
0323デフォルトの名無しさん
2010/11/12(金) 18:50:49http://lab.klab.org/young/2009/10/haskell%E3%81%A7%E3%82%A8%E3%82%B3%E3%83%BC%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC/
はい、Haskellの勝ち
0324301
2010/11/12(金) 19:03:50> Haskellで同じ問題を解くコードを書いて下さいまし。
嫌です。
> 何ステップで書けますか？
あなたの prolog のコードより遙かに長いです。
>>305
> Haskellで定義した関数 move_ball p ですが、これは以下の質問に返答できますか？
できません。
> 関連とは、その数学的定義からいって集合間の双方向な対応付けです。
数学的定義など気にしてレスしていません。
日常会話レベルの曖昧さを含んで「関連」と言いました。
それが悪いことだったのでしたら、すいません。
以後気をつけます。
0326デフォルトの名無しさん
2010/11/12(金) 22:12:54関係はオブジェクトの数の階乗だけある
それを全部把握しようとするのは至難の業
人は一度示された関係を簡単に忘れることができない
麻雀で牌を昇順で整理してしまうと別の手が見え難くなる
推理小説のトリックでも先入観を利用する
したがって余計な先入観を持たせない言語がより直感的と言える
OOPLは関係を扱おうとしない(「扱わない」ではない)
だからバッターがピッチャーを殺す(hit)ことも容易に想像できる
ballが見えないということはballが飛び交うこともわからない
(野球ならサインや応援や野次が飛び交うこともある)
>>302
慣れが必要だから普及しないのかもしれない
0327デフォルトの名無しさん
2010/11/13(土) 01:43:55曖昧な点があるので質問させてほしい。
> だからバッターがピッチャーを殺す(hit)ことも容易に想像できる
この「想像できる」というのは、そのように発想できる思考の柔軟さがあるという意味なのか、
それとも何かプログラミングコードを見て動作をそのように認識できるという意味なのか。
もし前者であれば、それは OOPL に属するプログラミング言語に備わった性質なのか？
もし後者であれば、どのようなプログラミングコードを見て
バッターがピッチャーを殺す(hit)ことを認識するのか？
0328デフォルトの名無しさん
2010/11/13(土) 12:10:18「容易に想像できる」は確率と可能性を指す言葉
関数型が「できない」のではなく確率を低くする要素があると言っている
見たから認識できるのではない
見ないから認識できる(言語使用者の能力に委ねられる)
関係を明確にできるという意味ではOOPLに備わっていない
関係を曖昧にできるという意味ではOOPLに備わっている
result<==catcher<==batter<==pitcher
このコードは順序や方向が明確に"解ってしまう"
なまじ間違っていないだけにこういうのは無意識に刷り込まれる
だが現実にはこの流れは稀なケース
バッターが打った球がキャッチャーに飛んでいった場合だけだ
現実はキャッチャーに"直接"届いたり届かないケースが圧倒的
OOPLはバッターがキャッチャーにボールを飛ばすか知ることができない
知ったら言語の存在意義を失うからだ
ball.throw(batter, catcher)
これはボールの行き先を曖昧なままにしている
ピッチャーの前で地面に落ちたりバックネットに直撃する可能性も残している
だからデッドボールに怒って殺しにくることも先入観無く想像できる
既に登場しているオブジェクト同士の関係であることに注目して欲しい
想像できなかったとすればプログラミング以前に先入観があるからだ
あとは言語者の想像力欠如
それは言語の知ったことではない
関数型が得意とするのはよく解らないものより既知のものだ
数式になっている物理法則などを"直感的に"そのまま取り込める
それは新しい物理法則を"直感的に"見付けることを妨げる
GUIに関して言えばオブジェクトが無数にあり関係がよく解らない世界だ
関係を先入観無しに発想できた方が良いことは解るだろう
0329デフォルトの名無しさん
2010/11/13(土) 13:27:52見えているものや先入観にとらわれず、とにかく上手く動く抽象を考え出せと
0330デフォルトの名無しさん
2010/11/13(土) 13:55:340331デフォルトの名無しさん
2010/11/13(土) 14:02:04> ピッチャーの前で地面に落ちたりバックネットに直撃する可能性も残している
> だからデッドボールに怒って殺しにくることも先入観無く想像できる
なんで result <== catcher <== batter <== pitcher としか書けない前提なの？
他の表し方もできることは知らないのか？ それともわざと無視してる？
result<== field (catcher <== batter <== pitcher ==> fielders)
こうすれば、ピッチャーの前で地面に落ちたりバックネットに直撃する可能性も表現できる。
牽制球も表現できるし、バッターが打った球がホームランになったり、
フライを捕られたり、送りバント失敗したりする結果も得られる。
この式から、それらの事ができることを想像する人間側の能力と、
ball.throw(batter, catcher) というコールからそれらの事ができることを想像する人間側の能力とに、
どのような違いがある？
ちなみに、Haskell は次のように書いて処理させることも問題なくできる。
問題なくというのは、Haskell の長所（遅延評価や参照透過性など）を保ったままという意味だ。
ball # throw(batter, catcher)
たまたまドット演算子が関数結合演算に使われてるから別の記号を使った。
このように書けば、当然あなたは「ボールの行き先を曖昧なままにしている」と感じるよな。
それなら、あなたが言う OOPL の特徴は、本当に OOPL 特有の特徴なのか？
言語特有の特徴ではなく、書き方に備わる特徴なのではないのか？
0332デフォルトの名無しさん
2010/11/13(土) 14:57:09そんなんOOPLだからとか関係ないやん。
0333デフォルトの名無しさん
2010/11/13(土) 20:31:05>>328にはそれは本質的でないように見えたんだろう
俺はわからんｗ
0334デフォルトの名無しさん
2010/11/13(土) 20:47:210335デフォルトの名無しさん
2010/11/13(土) 23:17:210336デフォルトの名無しさん
2010/11/13(土) 23:39:14って言うか、普及の度合いを量る指標のひとつが、使ってる会社の多さなんじゃないの？
0337デフォルトの名無しさん
2010/11/14(日) 00:20:57いろいろ言ってるけど、多分使ってみたら普通に使えるんじゃないかと思う。
研修やらドキュメントの作成やらはもちろんしないといけないけど。
0338デフォルトの名無しさん
2010/11/15(月) 04:07:38せいぜい業務ツールとして内輪で使うだけ
しまいには業務そっちのけでｔｒｙ
0339デフォルトの名無しさん
2010/11/15(月) 12:33:46階乗・・・orz
>>331
神の俯瞰でならOOPLもこのような書き方ができる
umpire<=(catcher<=(batter<=(pitcher<=(ball))))
ball.pitcher.batter.catcher.umpire
この書き方は結果からバグを見付けるのを困難にする
ピッチャーがキャッチャーに直接渡すこともある
同名のメソッドを持つインスタンスが返ってくることもある
文が長くなることを想像してみて欲しい
従ってOOPLではやってはいけない書き方なのだ
そしてOOPLならメソッドとして定義しなければ書けない
関係を簡単に表せない代わりに知らなくて済む仕組みになっている
逆に関数型では準備無しに<==を使って表せる
当然知らなくても良い関係も知ってしまう
OOPLは関係を曖昧にすることで自由な発想を手に入れた
関数型は関係を明確にすることで簡潔な表現を手に入れた
それだけの違い
0340デフォルトの名無しさん
2010/11/15(月) 15:26:19自由は曖昧ではない
曖昧な感じがするのは最初だけ
0341デフォルトの名無しさん
2010/11/15(月) 18:13:32> 逆に関数型では準備無しに<==を使って表せる
> 当然知らなくても良い関係も知ってしまう
意味が分からない。
どういう関係を知ってほしくてどういうプログラムを書いた時、
知らなくてもよいどのような関係を知られてしまうのか、
具体的に説明してくれ。
> 逆に関数型では準備無しに<==を使って表せる
お前、関数型でプログラミングをしたこと全くないだろ。
準備無しに <== 演算子を使えるわけない。
<== 演算子がどのような意味なのかを正しく定義しなければ使えない。
0342デフォルトの名無しさん
2010/11/15(月) 19:06:14って言うか、そもそもお前の言う「準備」って何のことだ？
0343デフォルトの名無しさん
2010/11/15(月) 20:04:570344デフォルトの名無しさん
2010/11/15(月) 20:47:510345デフォルトの名無しさん
2010/11/15(月) 21:01:08理由を聞かせてもらおうか
0346デフォルトの名無しさん
2010/11/15(月) 21:02:36未だかつて一度も無いからだ
0347デフォルトの名無しさん
2010/11/15(月) 21:08:510348デフォルトの名無しさん
2010/11/15(月) 21:24:05そもそも今まで「漫画でわかる言語解説書」の類が出版されたことあったっけ？
ベーマガのつぐみちゃんくらいしか知らんぞ
いくつか出たが話題にならなかった、て言うなら分かるがな
0349デフォルトの名無しさん
2010/11/15(月) 21:51:110350デフォルトの名無しさん
2010/11/15(月) 21:51:420351デフォルトの名無しさん
2010/11/15(月) 21:55:490352デフォルトの名無しさん
2010/11/15(月) 21:56:55調べてみた
http://www.m-sugaya.com/arashi/pc-index.html
この付録は欲しいな
>>346
おい、嘘つくなよ
しっかり話題になってたんじゃねぇか
0353デフォルトの名無しさん
2010/11/15(月) 22:00:51関数型言語の「心」を漫画で描いてほしい
0354デフォルトの名無しさん
2010/11/15(月) 22:05:030355デフォルトの名無しさん
2010/11/15(月) 22:20:530356デフォルトの名無しさん
2010/11/15(月) 23:23:21http://hibari.2ch.net/test/read.cgi/unix/1268282846/272-273
272 名無しさん＠お腹いっぱい。 [sage] 2010/11/15(月) 11:42:30 ID: Be:
マウントオプションとは別に、CRLFをLFに変換するツールはないでしょうか？
美乳セーラー女子高生とSEX顔射フィニッシュ
というコマンドやnkfでも一応可能なのですが
専用のツールはなかったかと思いまして
273 名無しさん＠お腹いっぱい。 [sage] 2010/11/15(月) 11:43:21 ID: Be:
>>272
コピペミスった、、、、、
見なかったことにしてください
コマンドは、
cat crlf.txt | tr -d '\r' > lf.txt
です。
0357デフォルトの名無しさん
2010/11/16(火) 23:38:460358デフォルトの名無しさん
2010/11/17(水) 05:47:40そんなクズみたいな言語は使いたくありません．
http://shootout.alioth.debian.org/
0359デフォルトの名無しさん
2010/11/17(水) 11:06:27rm -rf /
0360デフォルトの名無しさん
2010/11/17(水) 11:29:20ラムダ計算の概念が数学的素養の欠けた一般的プログラマ候補者にとって、
理解し難いから。この話の出てくるタイミングが大変微妙。
0361デフォルトの名無しさん
2010/11/17(水) 11:42:480362デフォルトの名無しさん
2010/11/17(水) 12:33:59まずは、ラムダ計算とは何なのか、
それが関数型言語のプログラミングにおいて
何故＆どくらい重要か、お前自身の言葉で説明してくれ
万が一にも説明できなければ、
数学的素養の欠けた一般的プログラマ候補者には理解が難しいことも、
この話の出てくるタイミングが大変微妙なのも、共に根拠のない戯言だ
0363デフォルトの名無しさん
2010/11/17(水) 12:47:57一般的にはべつに数学の話ではなくて
スコープの話の出てくるタイミング
1. 関数とローカル変数
2. ポインタと関数ポインタとOOP
3. C#のdelegateとか、Pythonのnonlocalとか
のような流れになる
数学的素養が必要になるのは
ポインタやOOPの話を省略していきなり理解させようとする場合だけだ
0364デフォルトの名無しさん
2010/11/17(水) 13:13:580365デフォルトの名無しさん
2010/11/17(水) 13:31:480366デフォルトの名無しさん
2010/11/17(水) 13:42:38Emacsのlambdaよりも
OOPのほうが本物のlambdaに近い
0367デフォルトの名無しさん
2010/11/17(水) 13:49:18OOPとlambdaの関係性についてもっと詳しく解説を要しますね。
0368デフォルトの名無しさん
2010/11/17(水) 13:51:00その考え方は一般的でないと考えられるので、
是非ご教授願いたく思います。
0369デフォルトの名無しさん
2010/11/17(水) 13:57:15習得時間は多分変わらないような
0370デフォルトの名無しさん
2010/11/17(水) 14:08:33その程度の問題だと、言語は関係ない。
グローバル変数またはインスタンス変数またはnonlocal変数を使わないと書けない処理が
出てきた頃になってやっと言語の違いが出てくる。
0371デフォルトの名無しさん
2010/11/17(水) 14:16:18そんな初級レベルの話なら大差なし
0372デフォルトの名無しさん
2010/11/17(水) 14:31:17動的スコープとレキシカルスコープは全く違うが
インスタンス変数とレキシカルスコープは大差なし
0373デフォルトの名無しさん
2010/11/17(水) 15:15:43手続き型、それもOOPが普及した理由は何となくわかる。
OOPって仕様書に書いてあることを上から文章のように記述するだけだもの。
OOP+メソッドのオーバーロードで自然言語にかなり近くなる。
0374デフォルトの名無しさん
2010/11/17(水) 15:31:020375デフォルトの名無しさん
2010/11/17(水) 15:34:00上からなぞればプログラムが出来上がる関数型言語向きの仕様書の書き方を考えれば？
0376デフォルトの名無しさん
2010/11/17(水) 15:40:200377デフォルトの名無しさん
2010/11/17(水) 15:42:25関数型言語向きに仕様書を書けば関数型言語で書きやすくなるに違いないよ。
0378デフォルトの名無しさん
2010/11/17(水) 15:43:390379デフォルトの名無しさん
2010/11/17(水) 18:10:46常識的に考えて、今から30年前の仕様書が残ってる訳がない
任天堂ですら、初代スーマリの仕様書はスーファミの時代には消えていたというのに
0380デフォルトの名無しさん
2010/11/17(水) 18:18:44俺のところは有史以来の全文書を5年前に電子化したから、
鯖探せば見つかるぞ。
だいたい、見つからないってことは大切な情報をちゃんと管理してない証拠。
ずさんな会社って事だ。
0381デフォルトの名無しさん
2010/11/17(水) 18:22:080382デフォルトの名無しさん
2010/11/17(水) 21:23:52関数型言語が普及しないのは、副作用をなくす必要がなかったから。
何かをなくす必要がないなら、既存の言語に機能を加えるだけで良い。
0383デフォルトの名無しさん
2010/11/18(木) 19:52:12黒歴史に意味はないからね
過去を文書化できる自信がある会社なんてどれだけあるか
0384デフォルトの名無しさん
2010/11/18(木) 22:16:21＞任天堂ですら
といっても、あくまでゲーム企業だぞ？
0385デフォルトの名無しさん
2010/11/19(金) 00:50:52いや、任天堂はゲーム企業ですら無い、実質的にそう呼ばれるようになっただけで
そもそもは玩具メーカーだし、今もそういうスタンスみたい
やたらハードウェアが頑丈なのも、基準が精密機械じゃなくてオモチャだからだしな
0386デフォルトの名無しさん
2010/11/19(金) 05:39:320387デフォルトの名無しさん
2010/11/21(日) 14:09:550388デフォルトの名無しさん
2010/11/21(日) 14:20:340389デフォルトの名無しさん
2010/11/21(日) 22:08:420390デフォルトの名無しさん
2010/11/21(日) 22:16:180391デフォルトの名無しさん
2010/11/21(日) 23:02:240392デフォルトの名無しさん
2010/11/22(月) 00:26:49歴史的には Robin Milner が発案/実証した --- 型推論 --- が、現在の普及に大きな好影響を与えたのだろね。
0393デフォルトの名無しさん
2010/11/22(月) 00:31:570394デフォルトの名無しさん
2010/11/22(月) 08:28:22破壊的リスト操作はあるし。
>>389 みたいな FUD が一番有害。
0395デフォルトの名無しさん
2010/11/22(月) 10:38:32手続き型である根拠にそれを出すのは不適切。
それにLispと一口で言ってもCLとSchemeとClojureじゃ全然違うし
0396デフォルトの名無しさん
2010/11/22(月) 11:08:360397デフォルトの名無しさん
2010/11/22(月) 11:08:42>Haskellにだって破壊的リスト操作があるから、
Haskellのmutableなリストは(nativeじゃなく)ライブラリとして実装されている。
だからアプリからは破壊的操作に見えても、参照透明性が保証されている。
ただし、その代償として破壊的リストを使ってもメモリ効率や実行速度は向上しない。
LISPの破壊的リスト(あるいはMLの参照型)とは意味あい(= 導入目的)が全く違うから、
Haskellを引き合いに出す事そのものが不適切だと思う。
0398デフォルトの名無しさん
2010/11/22(月) 12:02:00パクりパクられは世の常。それを言い訳にしている内は、普及なんて夢のまた夢。
関数型言語マニアはリスト等のパターンマッチ機能を自慢するけど、あれは論理型言語(Prolog)のパクリ。
かつて記号処理(狭義の人工知能)の分野で関数型言語と論理型言語が激しく競っていた時代があった。(LISP vs. PROLOGの時代)
結局、PROLOGにパターンマッチ機能はあったけど、当時の(LISPを含む)関数型言語には無かったこともあって、
リスト処理に関しても論理型言語の評価が高かった。時代は進み、最近設計された関数型言語の大半は、
その反省を活かしてパターンマッチ機能を取り込み、少なくともリスト処理に限れば論理型言語の優位性は消え失せた。
振り返って、元々は関数型言語から生まれた継続(continuation)、閉包(closure)、結合子(combinator)といった概念は、
いくつかのOOPでは言語機能に取り込まれ、そうでない言語でもプログラミング技法として活用されている。
そういった状況については、平然かつ生暖かくニヤニヤしながら上から見下ろしていればいいのではないかと。
今のところ(今しばらくは)、たとえば>>392の型推論のような関数型言語の独壇場にある概念は、まだまだ存在している。
その絶対的な優位性の存在に、まだ多くの人が気付いていないだけだと思う。
0399デフォルトの名無しさん
2010/11/22(月) 12:11:120400デフォルトの名無しさん
2010/11/22(月) 12:16:52パターンマッチは、まるで動的型のように見えるので
静的型の絶対的優位性に気付いている人ほど、戸惑いが大きいのだと思います
0401デフォルトの名無しさん
2010/11/22(月) 12:17:24関数型言語のパターンマッチがユニフィケーションと同じなんて、どこにも書いてないよ。(curryのような例外を除く....)
言語の表層(構文)として、関数型言語がパターンマッチ機能をパクったとは書いたけどね。
0402デフォルトの名無しさん
2010/11/22(月) 13:39:53Haskellの標準のリストはimmutableで、破壊的操作はまったく定義されてない
破壊的に更新できるリストは別に用意する必要があるけど、それを使っても実行速度が向上しないなんてことはもちろんなくて、
通常のリストでは遅い演算(連結とか)を効率的に実行できる
0403デフォルトの名無しさん
2010/11/25(木) 23:18:30むしろ、要素の定数性を利用して効率よく連結できそうだが。
0404デフォルトの名無しさん
2010/11/26(金) 07:22:30少なくともインターフェイスはconsセルのチェーンに見える
内部実装は知らん
>>402 の言ってる連結演算は恐らく ++ 関数の事だ
リスト同士の連結をする
通常のリストだと第１引数のリストの要素数に関して O(n) の時間がかかる
0405デフォルトの名無しさん
2010/11/27(土) 16:02:38> 通常のリストだと第１引数のリストの要素数に関して O(n) の時間がかかる
なるほど。tailを保持する実装になっていて、かつ、x ++ yに際して、
xを破壊して良ければ、O(1)にできますね。
0406デフォルトの名無しさん
2010/11/27(土) 16:06:40ML+yaccとかHaskell+BNFCとかがそれなりに使われていると想像して
いるが、その方面の人に補足願いたい)、HPCでない数値計算にも
もっと使われてもよいと思う。もっとも、RとMathematicaを数える
ならば、十分普及しているとは云えるが。
0407デフォルトの名無しさん
2010/11/27(土) 16:15:13ところだろう。
・大学でデータ構造の演習になにを使うだろうか。Cが多いのではないか、
どこかのWebページで、ある助手がデータ構造の教育に関数型言語を使う
ことを教授Aに提案したが、横で聞いていた教授Bで鼻で嗤われたという
記事を読んだことがある。
・Unix系を使っていて、C/C++/Fortran/Perlがインストールされてないこ
とを心配する必要はないだろう。だが、SML/Ocaml/Haskellは、期待できな
いだろう。インストーラが良くできているので、DLしてmakeするだけなのだ
が、「そこまでしないと使えないようなマニアックな言語を使うな」とはい
は云われる。
0408デフォルトの名無しさん
2010/11/27(土) 16:18:20まあ大学にもよるんだろうけどさ
0409デフォルトの名無しさん
2010/11/27(土) 16:25:090410デフォルトの名無しさん
2010/11/27(土) 17:26:460411デフォルトの名無しさん
2010/11/27(土) 22:56:30ってのも教育目的としては一理ある主張。
ただ単にその教授がものを知らないだけって可能性もあるが。
0412デフォルトの名無しさん
2010/11/27(土) 23:06:010413デフォルトの名無しさん
2010/11/28(日) 00:34:480414デフォルトの名無しさん
2010/11/28(日) 09:05:01中途半端だな
C、Lisp、Smalltalkでいいんじゃね
あ、でも関数型言語と論理型言語が足りないか……HaskellとPrologも追加で
0415デフォルトの名無しさん
2010/11/28(日) 09:15:21Smalltalk持ち出してくるとか、お前ただの学生だろ
0416デフォルトの名無しさん
2010/11/28(日) 10:02:36確かにそうだけど、でも大学でやるんならそれでよくね
職業訓練所ならJavaだろうけど
それともSmalltalkよりEiffelの方が契約による設計を学べていいとか
Simulaを差し置いてSmalltalkを挙げるなとかそういうこと？
0417デフォルトの名無しさん
2010/11/28(日) 10:25:31馬鹿か。
オブジェクト指向なんて別に原点がどこにあるかなんて気にするほど
ご大層なものでもないし、学術的な意義があるものでもないし、
そもそも何が"純粋"なのか気になるほど数学的厳密性もないし、
オブジェクト指向の明確な機能の定義もない。
言語機能としてオブジェクト指向のサポートを謳っているかどうかすら関係ない。
だからSmalltalkだろうとJavaだろうとPerlだろうとオブジェクト指向的には関係ない。
関係ないなら仕事で使えるJavaを選ぶほうが幾分マシだろう。
0418デフォルトの名無しさん
2010/11/28(日) 10:46:37俺は原点を気にしてはいないし、純粋さも重視してない（そんなことを書いたつもりもない）
ただ、逆に「仕事で使うことになるんならわざわざ教えなくても自分で学ぶ」とは思う
0419デフォルトの名無しさん
2010/11/28(日) 10:47:34じゃあSmalltalkをわざわざ覚えるメリットはなんだ？
0420デフォルトの名無しさん
2010/11/28(日) 10:54:01別に言語をすぐ覚えられることをこんなところでアピールしなくてもいいよｗ
このスレの住人にとってそれぐらいのことは当たり前だからｗ
0421デフォルトの名無しさん
2010/11/28(日) 10:59:22大学は就職活動をするところですよね
0422デフォルトの名無しさん
2010/11/28(日) 11:04:26Smalltalkの考え方を学べること
CにはCの、JavaにはJavaの、LispにはLispの、HaskellにはHaskellの、EiffelにはEiffelの、PrologにはPrologの考え方がある
そして問題解決に別の言語の考え方を生かせる場面はあると思う
商業プロジェクトに関わったことがないから断言はできないけど
そして特定の言語の考え方に縛られすぎて遠回りするのも防げる
自分で言語を設計するのにも役立つ（これは今のところ仕事になることは少ないから些細な利点だけど）
こっちも訊くけど、仕事で使う言語が変化していくかもしれない（今までの流れからすれば多少は変わらない方がおかしい）のに
そこまで「今仕事で使われていること」を大学で教える言語に強く求めるのはなぜ？
0423デフォルトの名無しさん
2010/11/28(日) 11:06:36いや、俺はむしろ覚えるの遅い
0424デフォルトの名無しさん
2010/11/28(日) 11:32:24言いたいことも分かるんだけど、発想が言語オタク的のような気がするなー
SICPとか、Schemeひとつでやってることは随分多岐に渡るけど
別にSchemeを教えているわけでもなければSchemeの考え方を教えてるわけでもなくて
そこでのSchemeは計算機科学の基本を教えるための、ただの道具でしょ
俺としては大学で計算機科学を学ぶ人に言語「ごとき」（あえて言うが）に
拘泥してほしくはないねえ
0425デフォルトの名無しさん
2010/11/28(日) 11:35:56大学は就職活動をするところだとトップが思い込んでる大学では、
「今仕事に使えること」が最重要だからな
0426デフォルトの名無しさん
2010/11/28(日) 11:41:50会社も4月採用で学校も4月開始だから余裕がなくなるだろう
9月採用とかするだけでだいぶ違うと思うんだけど
3年から就職活動とかあるし関係ないか・・・
0427デフォルトの名無しさん
2010/11/28(日) 11:44:32確かに言語の学習に大きく時間を割くんじゃ考え方を学ぶも何もないか
>>425
俺が大切じゃないかなと思うことは大学や世間からしたら
実際は大したことじゃないってことか
よく考えたら、本当に大切なら実際に大切にされるはずだもんな
俺が世間知らずなだけだった
0428デフォルトの名無しさん
2010/11/28(日) 13:14:470429デフォルトの名無しさん
2010/11/28(日) 13:22:150430デフォルトの名無しさん
2010/11/28(日) 13:58:35それはない
0431デフォルトの名無しさん
2010/11/28(日) 14:18:04仮に悪貨が良貨を駆逐しても、悪貨は悪貨なりの良貨をしのぐ利点があるのだよ。
0432デフォルトの名無しさん
2010/11/28(日) 14:43:460433デフォルトの名無しさん
2010/11/28(日) 14:52:44必ずしも進化とは思えないみずぼらしさを感じるよ
2000年もたてば美形ぞろいになってもおかしくなかったのになｗ
0434デフォルトの名無しさん
2010/11/28(日) 15:00:28それは人間なりの戦略で、
わざと改悪も許すことで多様性を維持していると解釈できる
何が良いかなんて環境によって変わる
0435デフォルトの名無しさん
2010/11/28(日) 17:06:16> そこまで「今仕事で使われていること」を大学で教える言語に強く求めるのはなぜ？
・大学卒業後就職する人が多いから。
・今後10年以上は使われることが予想できる言語だから。
・SmalltalkだろうがJavaだろうがパラダイムや原理にさほど違いがないから。
0436デフォルトの名無しさん
2010/11/28(日) 17:07:33京産大生乙
黒田元気？ｗ
0437デフォルトの名無しさん
2010/11/28(日) 17:34:190438デフォルトの名無しさん
2010/11/28(日) 17:36:020439デフォルトの名無しさん
2010/11/28(日) 19:08:110440デフォルトの名無しさん
2010/11/28(日) 19:12:57それは当たり前だろ。
自分が使いたくない言語が糞だと思わないわけがない。
0441デフォルトの名無しさん
2010/11/28(日) 20:53:26自分の使いたくない言語と使うべきではないと判断できるくらい熟知した言語も等価とは限らない
そもそもその存在を知らない言語とか
名前は聞いたことあるけど良い言語かどうか判断できない言語とか
悪評をよく聞くから手を出す気になれない言語とかあるでしょ？
もしないなら過小評価してごめん
0442デフォルトの名無しさん
2010/11/28(日) 21:13:05最も良い物以外は多少なり劣っているから糞。
0443デフォルトの名無しさん
2010/11/29(月) 12:09:32単に色々必修にするほどコマ数無くて、開発スキルの向上は
大学的にはさほど重要じゃないだけ。
0444デフォルトの名無しさん
2010/11/30(火) 07:20:33Lispとくみあわされる鉄板は何になるの？
やっぱりYacc?
0445デフォルトの名無しさん
2010/11/30(火) 15:51:43LispならYaccよりCL-Yaccの方がずっと使いやすいと思います。
CL-Yacc ― a LALR(1) parser generator for Common Lisp
http://www.pps.jussieu.fr/~jch/software/cl-yacc/
The CL-Yacc Manual 翻訳
http://lispuser.net/commonlisp/cl-yacc.html
最高にキモい Lisp コードを書いてみよう with 100 行リーダーマクロ
http://lispuser.net/memo/lisp/2006-03-30-23-58.html
0446デフォルトの名無しさん
2010/12/01(水) 22:39:030447デフォルトの名無しさん
2010/12/08(水) 16:02:50何かを「返す」という事が実はたいして大事ではない。
日常的には。
0448デフォルトの名無しさん
2010/12/08(水) 20:24:390449デフォルトの名無しさん
2010/12/09(木) 17:50:14lazy-MLがあるように、eager-Haskellが登場したら、考えなくもない。
0450デフォルトの名無しさん
2010/12/09(木) 18:04:31言う前に検索してみれば良かったのに
0451デフォルトの名無しさん
2010/12/09(木) 19:15:59そういうのは揚げ足取りという。検索すると'研究'は出てくるが、実用になる'実装'は出てこない。
0452デフォルトの名無しさん
2010/12/09(木) 19:44:27そういうのを言い訳という。
0453デフォルトの名無しさん
2010/12/09(木) 19:55:280454デフォルトの名無しさん
2010/12/09(木) 20:04:15そもそも、なんで eager-Haskell が登場したら
Haskell ひとつで済ませようと考えなくもないのか、理由を聞きたいな
君にとって Haskell ひとつで済ませるには不足だった何が、
eager-Haskell によって改善されるだろうと考えているのか
0455デフォルトの名無しさん
2010/12/09(木) 22:04:24lazinessはHaskellをHaskellたらしめている部分だから、まさか、あるとは
思わなかった。これは面白そうだ。じっくり、読むことにしよう。
>>454
破壊的代入がただで使えること。むろん、lazinessで支えられている美しい
記述のいくつかは失われるだろうが、型クラスとか、functional record
updationとかは、残るだろう。
0456デフォルトの名無しさん
2010/12/09(木) 23:13:55Eager Haskell だとなんで破壊的代入がただで使えるの？
遅延評価と参照透過性は別物なんじゃないの？
0457デフォルトの名無しさん
2010/12/09(木) 23:40:54関数型言語を使って何かを作るスレはないよな。
もっと現実的な○○を実現するには
どういうライブラリを使えばいいかとか。
そういうの。
誰も関数型言語でなにかをつくろうなんて
考えてないのかな？
0458デフォルトの名無しさん
2010/12/09(木) 23:50:03> どういうライブラリを使えばいいかとか
そこまでいってしまうと、個々の言語スレで訊いた方がいいと思う。
参照透過性はどの関数型でもたいていはデフォで備えてるから、
それを考慮した関数型らしいアルゴリズム表現くらいまでだろうね、
共通の話題で盛り上がれるのは。
> 誰も関数型言語でなにかをつくろうなんて
> 考えてないのかな？
今、reyes アルゴリズムを使った RenderMan 互換レンダラーを Haskell で作ってる。
パイプラインを逆向きに作ってて、画像ファイル出力から初めて、
今はサブピクセルのフィルタリングまで作れた。
次は、サンプルからサブピクセルのカラー値を計算するところを作る。
今のところ他人に訊くことも特に無いから、独りで黙々と作ってるよ。
0459デフォルトの名無しさん
2010/12/10(金) 00:27:190460デフォルトの名無しさん
2010/12/10(金) 00:44:40GC必要な言語では本気出せないじゃん？
0461デフォルトの名無しさん
2010/12/10(金) 00:47:410462458
2010/12/10(金) 07:22:37完全に趣味でやってるから、作りやすいかどうかなんて考えてない。
ガンプラ好きな人が作りやすいかなんて考えないのと、たぶん同じ心境だ。
（おそらく、一般的には作りにくいのではと思われてるんだろうな）
少なくとも俺は手続き型より関数型の方が楽に考えられるし、
考えたことを素直にプログラムできるから、楽しんでやってるよ。
まぁ分かってはいたが処理速度は出ないな。
ただ、最適化はまだ何も施していないから、
最後にその辺りを追求するのも楽しみの一つ。
0463デフォルトの名無しさん
2010/12/10(金) 07:24:56本気の意味が分からん
0464デフォルトの名無しさん
2010/12/10(金) 09:27:37使ってる言語のARM非対応やらAndroid非対応やらのデメリットを無視できなくなってきたから
最近は簡単なツールにしか使わなくなった
0465デフォルトの名無しさん
2010/12/10(金) 17:01:57OCamlの良さはわかるけど
0466デフォルトの名無しさん
2010/12/10(金) 17:18:29ストリームを感じるのだ
0467デフォルトの名無しさん
2010/12/10(金) 21:25:08それが問題だ
実装が見えてこないと出力がよくわからない
出力されるコードがすべてだ
速さこそ正義だ
効率こそ正義だ
0468デフォルトの名無しさん
2010/12/10(金) 21:35:11>効率こそ正義だ
関数型言語死亡
0469デフォルトの名無しさん
2010/12/10(金) 21:35:440470デフォルトの名無しさん
2010/12/10(金) 21:39:25実装が見えなくても、Cほどの速くなく非効率でも、
普通に商業利用もされてる。
たんに君個人の好みに合わないだけだよ。
0471デフォルトの名無しさん
2010/12/10(金) 22:58:18わけのわからんものを勉強して、
遅かったら時間の無駄だろうが。
バカですか？
Rubyとか糞遅い言語は、
「判り易いから」という条件付きで存在が許されてんの。
「判りにくくて遅い」なんて、
言語の存在価値を問うのに、
もはや好みも糞もねーんですよ
判りませんかねえ？
そんな単純なことが
0472デフォルトの名無しさん
2010/12/10(金) 23:01:07解りにくいのはお前の頭が悪いから、という可能性はありませんか？
0473デフォルトの名無しさん
2010/12/10(金) 23:02:06分かる 解る 判る
それぞれの違いは分かりますか？
0474デフォルトの名無しさん
2010/12/10(金) 23:03:240475デフォルトの名無しさん
2010/12/10(金) 23:34:14きみの組むプログラムはきっとＣ言語でも遅いだろうな。
なんかこう、効率的なアルゴリズムはとても考えられずに、
ごり押しでプログラムしそうな感じがするよ。
あるいは、どうでもいいところでループを展開して最適化しましたとか、
変数使わないスワップ関数を作って最適化しましたとか言いそう。
で、一週間前の自分のコードすら解読不能になって、飽きて投げ出す。
0476デフォルトの名無しさん
2010/12/11(土) 00:39:120477デフォルトの名無しさん
2010/12/11(土) 02:05:38JavaScriptからJSON形式でデータを受け取るのですが、
どうやって処理すればいいのでしょうか？
0478デフォルトの名無しさん
2010/12/11(土) 07:20:500479デフォルトの名無しさん
2010/12/11(土) 10:09:370480デフォルトの名無しさん
2010/12/11(土) 11:48:06haskellのライブラリだとこの辺：
http://www.haskell.org/hoogle/?hoogle=json
0481デフォルトの名無しさん
2010/12/11(土) 11:49:00haskell分かりやすいよ？
0482デフォルトの名無しさん
2010/12/13(月) 02:59:49だからどうしてもライブラリの多いPythonに軍配があがる。
0483デフォルトの名無しさん
2010/12/13(月) 03:13:15プログラミングにある程度首を突っ込むなら
どうしてもメジャーな言語を数個習得する事になる。
しかし今のところメジャーな言語といえば殆どが手続き型だから
そこに関数型を加えるのは一手間かかることになる。
0484デフォルトの名無しさん
2010/12/13(月) 05:08:360485デフォルトの名無しさん
2010/12/13(月) 06:13:11CreateFile成功したらReadFileで適当に読んで
CloseHandleするまでちょっと書いてみてよ。
0486デフォルトの名無しさん
2010/12/13(月) 12:19:16import System.Win32.File して
openFile, win32_ReadFile, closeHandleを使う
0487デフォルトの名無しさん
2010/12/13(月) 12:21:260488デフォルトの名無しさん
2010/12/13(月) 12:28:33それならPrologがもっと普及したはず
0489デフォルトの名無しさん
2010/12/13(月) 12:29:18メインストリームにパラダイムなんて
言えるもの、あるか？
0490デフォルトの名無しさん
2010/12/13(月) 12:32:30何が「それなら」なのかわからんｗ
0491デフォルトの名無しさん
2010/12/13(月) 12:39:531980年代には関数型と比較にならないくらい、
勢いがあったろう。
0492デフォルトの名無しさん
2010/12/13(月) 12:43:02ひと昔と比べてマルチパラダイムになってきたが、
少なくとも関数型がメインでは無いのは確か
0493デフォルトの名無しさん
2010/12/13(月) 12:50:07インテルが心を改めて、関数型言語に最適化した、
CPUの設計・製造に腐心するようになったら、
関数型は普及するものですか？
0494デフォルトの名無しさん
2010/12/13(月) 12:53:16http://d.hatena.ne.jp/camlspotter/20101212/1292165692
おまいら的にこのエントリーはどうよ
0495デフォルトの名無しさん
2010/12/13(月) 12:58:11ちょっとやそっと頑張ったところで、量産効果でやっすくなってる現行チップと、
現行チップで性能を出すために基本設計のレベルからチューニングされてる
GHCの組み合わせにはC/P的にかないません。
0496デフォルトの名無しさん
2010/12/13(月) 13:12:21その時代、俺はまだ生まれてないしｗ
それにいくら探しても過去にPrologに勢いがあった痕跡なんて皆無なんだが。
0497デフォルトの名無しさん
2010/12/13(月) 13:19:24かつて国家プロジェクトでprolog使った時代があったのよ
0498デフォルトの名無しさん
2010/12/13(月) 13:23:44第五でしょ、それは知ってる。
国鉄の情報システム設計にZ言語をつかって、Prologでプログラミングしたりなどの成果はあったけど
コスト的にあまり良くなかったでしょ。
流行っていたというより実験的プロジェクトだったと思う。
0499デフォルトの名無しさん
2010/12/13(月) 13:26:30書いてみた。
普段、Win APIを直接叩いたりしないので、外部ポインタの開放とかでミスってるかもしれん。
module Main where
import Data.ByteString
import Data.ByteString.Internal
import Data.ByteString.UTF8
import Foreign.ForeignPtr
import Foreign.Marshal.Alloc
import System.Win32.File
main = do
fptr <- mallocByteString 128
len <- withForeignPtr fptr $ \ptr -> do
handle <- createFile "test.txt" gENERIC_READ fILE_SHARE_NONE Nothing
oPEN_EXISTING fILE_ATTRIBUTE_NORMAL Nothing
len <- win32_ReadFile handle ptr 128 Nothing
closeHandle handle
return $ fromIntegral len
print $ toString $ fromForeignPtr fptr 0 len
finalizeForeignPtr fptr
0500499
2010/12/13(月) 13:28:27「fILE_SHARE_NONE Nothing」と「oPEN_EXISTING」の間は半角空白だと考えてね。
0501デフォルトの名無しさん
2010/12/13(月) 13:29:22常識的に考えてwin32apiはhaskellで使うもんじゃないよなぁ。
普通はhaskellに親和性の高い関数をCで書いてffiで呼び出すもんだよなぁ。
0502デフォルトの名無しさん
2010/12/13(月) 13:29:52Prologの本は50冊以上出版されているが、49冊は
1999年以前にそのうち30冊以上が1980年代に
出版されている。1980年代に出版されたLISPを
含む関数型言語の本は十数冊のはず。
0503デフォルトの名無しさん
2010/12/13(月) 13:37:23なるほど、結構本が出ているんだね。
Haskellの日本語本なんて数えるほどしかでてないもんね。
だとしても1980年代と現代ではインターネットの存在や選択肢の多さや並列処理の必要性やCPUの処理速度や
どんな力を持った何者が推進しているのかなどいろんな点で違うから、単純比較は難しいよね。
0504デフォルトの名無しさん
2010/12/13(月) 13:38:050505デフォルトの名無しさん
2010/12/13(月) 13:40:170506デフォルトの名無しさん
2010/12/13(月) 13:42:11もともと、パラダイムシフトだけで押せるのものなら、
そういう立場の代表格だったPrologが萎むことは
なかったんじゃないか、という話だろ。
0507デフォルトの名無しさん
2010/12/13(月) 13:43:20なに因縁つけてんのwww
そんなこと言い出したら、JavaもPerlもいずれは「単純比較は難しいよね」といわれるようになって、all time standardは回路図だけになるじゃん。
0508デフォルトの名無しさん
2010/12/13(月) 13:46:510509デフォルトの名無しさん
2010/12/13(月) 13:48:08パラダイムシフトしなかったから廃れたんじゃないの。
0510デフォルトの名無しさん
2010/12/13(月) 13:49:101980年代はCOBOL,FOTRAN,PL/Iなどが勢いを失って、
Pascal,Ada,Smalltalkは不振、C,BASICの独壇場で、90年
近くになってようやく、C++が漸くでてくるという特殊な年代。
30数冊はかなり突出した数字だね。
0511デフォルトの名無しさん
2010/12/13(月) 13:50:18過去にPrologが流行らなかったからHaskellも流行らない、とは言えないよね？
歴史から学ぶことは大切なことだけど、周りの環境も違うのだから
単純にPrologと同じ運命をたどって廃れると予言するのは難しいよね？
0512デフォルトの名無しさん
2010/12/13(月) 13:52:13Basicには数えないとして。
0514デフォルトの名無しさん
2010/12/13(月) 13:55:35いや、もとはと言えば>>487がパラダイムが離れているから
関数型をやるというレスでPrologの話が出てきた。
その理屈ならPrologがもっと流行ってもいいんじゃないかと
0515デフォルトの名無しさん
2010/12/13(月) 13:59:22問題はHaskellのあまりの助走の長さ。20数年w
0516デフォルトの名無しさん
2010/12/13(月) 14:04:22haskellに限るわけじゃないけど、
このスレは飽くまで関数型言語がなぜ普及しないのかを考えるスレだぜ
0517デフォルトの名無しさん
2010/12/13(月) 14:08:05結局お金に結びつきやすいかどうかですよ
0518デフォルトの名無しさん
2010/12/13(月) 14:08:56LazyBadAssだったら普及した
0519デフォルトの名無しさん
2010/12/13(月) 14:10:50庶民レベルの「儲かった」なら中には儲けた人もいたかもしれん。
0520デフォルトの名無しさん
2010/12/13(月) 14:13:280521デフォルトの名無しさん
2010/12/13(月) 14:18:33GUIだけで作れるソフトなんて小物アプリしかないだろ。
0522デフォルトの名無しさん
2010/12/13(月) 15:56:32「Offside rule は何もいいこと無い」には賛成できないなぁ。
オレはOffside ruleがあることはすばらしいと思う。
また、そう思わないとしても、この記事の筆者も分かっているように、これはHaskellの欠点ではない。
Offside ruleは使用しなくても良いオプションだから。
「Laziness」で書かれていることは、ちょっと違うと思う。
遅延評価より正格評価のほうが高速であると確信できるなら、正格データ型を作れば回避できる問題。
遅延評価がどうしてもいやなのならば、自分が書き下すデータ型はすべて正格にすればよろしい。
ただし、心理的傾向として、Haskellプログラマは計算量に鈍感になりがちかもしれない。
一般的傾向として、そういうのはあると思う。
「Purity」で書かれている、参照透明なコードをモナディックに書きなおすっていうことは起きることがあって、それが面倒っていうのは、たしかにそのとおり。
ただ、そこでの例示は良く分からない。
「あるデータファイル群が何度も何度もロードされるのを気づいたので」って、それは始からモナディックなコードになっていたのでは？
0523デフォルトの名無しさん
2010/12/13(月) 16:03:50萎んではいるけど、廃れてはいない。
0524デフォルトの名無しさん
2010/12/13(月) 16:06:150525デフォルトの名無しさん
2010/12/13(月) 16:19:30http://hibari.2ch.net/test/read.cgi/tech/1289016056/107
0526デフォルトの名無しさん
2010/12/13(月) 16:20:33誘導してくれとは言っとらん。
ウリを教えてくれと言ってるんだよ。
0527デフォルトの名無しさん
2010/12/13(月) 16:28:37仕様記述言語のZのことが、>>498に出てきたが、
これはプログラマにとって最も難解な言語のひとつ。
一方、ほぼ同じ目的に使用した場合、Prologは
現在存在するプログラム言語の中で、最も易しい
言語。
0528デフォルトの名無しさん
2010/12/13(月) 16:32:22そのスレの107番のレスを見ろってことじゃないの？
0529デフォルトの名無しさん
2010/12/13(月) 16:37:45ちょっとまって、Z言語はプログラマの為の言語じゃないよ。
顧客と意思疎通するための言語だよ。
0530デフォルトの名無しさん
2010/12/13(月) 16:45:23そこをプログラマが簡単に兼ねられるのがProlog環境と
いうこと。たとえば、電話を受けながら。
0531デフォルトの名無しさん
2010/12/13(月) 16:46:59このスレ的な切り口でいうなら、数学的知識(論理学を含めて)が
まったく必要ない、ということじゃないかな。
数学的どころか、1985年以降に発明された概念、ほとんどすべてを
必要としないことではないか。たとえば、このスレ、
http://hibari.2ch.net/test/read.cgi/tech/1289397085/
で議論するのに必要となる知識はPrologにとってはすべて無意味。
0532デフォルトの名無しさん
2010/12/13(月) 16:51:51>遅延評価より正格評価のほうが高速であると確信できるなら、正格データ型を作れば回避できる問題。
GHCは「評価済みだと分かっている値をもう評価しない」という最適化をしないから、完全に正格なコードを書いても
正格な言語の性能には及ばない
>遅延評価がどうしてもいやなのならば、自分が書き下すデータ型はすべて正格にすればよろしい。
リスト、Maybe、タプルを全部自分で書き直して、さらにそれらを扱う標準関数も全部書き直して
…ってやってたら時間がいくらあっても足りないぞ
0533デフォルトの名無しさん
2010/12/13(月) 18:53:21ZとUMLを比較してください。
0534デフォルトの名無しさん
2010/12/13(月) 23:32:57それにくらべてhaskelときたら
0535デフォルトの名無しさん
2010/12/14(火) 00:51:27結局はシステムなんて入力を処理して出力するだけなんだから
コアの部分はCOBOLで十分ってことなんだよ。
0536デフォルトの名無しさん
2010/12/14(火) 00:52:28haskellごときじゃ日本の国費投入されたら跡形も残らず忘れ去られる
0537デフォルトの名無しさん
2010/12/14(火) 00:53:220538デフォルトの名無しさん
2010/12/14(火) 00:54:57prologでtwitterクローン作ったらどうなるの？
どれだけ便利な言語なのか推し量るには実際のプログラムを見ないことには判断できない
0539デフォルトの名無しさん
2010/12/14(火) 00:55:400540デフォルトの名無しさん
2010/12/14(火) 01:00:37> 結局はシステムなんて入力を処理して出力するだけなんだから
本当にそれだけなら、コアの部分は BrainFuck でも十分じゃないのか？
もし十分ではないのなら、COBOL には有って BrainFuck には無い何かが、
そのシステムを君が構築するのに必要な要素なのだろう（例えば分りやすさとか）
0541デフォルトの名無しさん
2010/12/14(火) 01:50:26> GHCは「評価済みだと分かっている値をもう評価しない」という最適化をしないから、完全に正格なコードを書いても
> 正格な言語の性能には及ばない
正格な『データ型』を使えば、それを二度評価したりしないと思うが。
そうじゃないと、RWHの最適化の章に書いてあることの意味が分からなくなる。
また、「完全に正格なコードを書いても正格な言語の性能には及ばない」というのは、もし一般論としていっているのなら、間違いでしょ。
単純なBASICインタプリタやLISPインタプリタよりは速かろう。
> リスト、Maybe、タプルを全部自分で書き直して、さらにそれらを扱う標準関数も全部書き直して
> …ってやってたら時間がいくらあっても足りないぞ
すべての標準関数を書き直す必要はなくって、自分が使う関数だけ書き直せば良いのだから、そんな深刻な問題ではないと思うが。
実際、いまでも、Cプログラマなら、リストや辞書などのデータ構造を自分で書くのは普通のことじゃない？
もっとも、もともとは、「遅延評価によって計算コストの見積もりができなくなる」という趣旨の話についてのコメントだから、C並の速度がでるとかそういう話はしていないんだけど。
0542デフォルトの名無しさん
2010/12/14(火) 02:47:540543デフォルトの名無しさん
2010/12/14(火) 14:43:38これ買った。
高かった。
気持ち良い。
0544デフォルトの名無しさん
2010/12/14(火) 15:31:410545デフォルトの名無しさん
2010/12/14(火) 16:55:17Ｃ言語でいうなら基本的な構造たとえば配列やポインタがサポートされてない状態に相当する。
配列がないなら当然文字列もないのでハローワールドしたかったら
コンパイラを全面的に書き直してからprintfを自作しないといけない。絶対無理。
0546デフォルトの名無しさん
2010/12/14(火) 19:07:54ある変数（関数）がいつ評価されるかといえば、
それは必要な時に初めて評価されるんであって、
タイミングは完全に分ってるはずだろ。
あと、正格評価で計算量 O(nlogn) の計算は、
遅延評価でも同じ O(nlogn) の計算量だよな。
違うのか？
0547デフォルトの名無しさん
2010/12/14(火) 19:29:16その通りであるが、そこでの「計算コスト」は空間コストも含まれているのではなかろうか。
実際に体感される(測定される)計算時間には空間コストも当然反映されるでしょう。
まえに紹介された、eager haskell ttp://csg.csail.mit.edu/pubs/haskell.html
には、「なんで末尾再帰で書いたのにスタックオーバーフローが起こるんだばかやろう」
というメイルが毎月Haskellメーリングリストに送られてくる」と書かれている。
#これで遊びたいのだが、personal communicationでしか手に入らんのかな。
0548デフォルトの名無しさん
2010/12/14(火) 19:29:36>タイミングは完全に分ってるはずだろ。
それはそうだが、直感が働きにくい
>あと、正格評価で計算量 O(nlogn) の計算は、
時間計算量についてはその通り
空間計算量は正格評価より悪くなることがある
0549デフォルトの名無しさん
2010/12/14(火) 19:57:41>>あと、正格評価で計算量 O(nlogn) の計算は、
>時間計算量についてはその通り
>空間計算量は正格評価より悪くなることがある
例えばどんな計算で？
0550デフォルトの名無しさん
2010/12/14(火) 20:00:08変数がモジュール間で共有され、モジュール内部の情報は隠蔽されている場合
タイミングが分からなくなる。
代入のタイミングと同じ。
ある変数がいつ代入されるか
必要な時に代入される
タイミングは完全に分ってる
0551デフォルトの名無しさん
2010/12/14(火) 21:40:12評価順序（遅延か正格か）は時間計算量には影響を与えない（見積もり簡単）。
しかし、遅延評価をさせるための仕組みが空間計算量を複雑にする＆多くする（見積もり難しい）。
という認識でいいの？
もしそうなら、たとえば C 言語に比べて C# や Java などは、
メモリ領域の確保や解放をランタイムが引き受けてくれる仕組みを作るために GC が働き、
いつメモリが解放されるか分らないから、空間計算量は C 言語に比べて見積もり難い、
という言い方も正しい？
0552デフォルトの名無しさん
2010/12/14(火) 21:59:06かわいいね
誰？
0553デフォルトの名無しさん
2010/12/14(火) 22:21:320554デフォルトの名無しさん
2010/12/14(火) 23:41:21>>554 時計でないほうのオリエントね。
こっちの人生も魅惑的であるんだよね。
>>545に戻るが、
ところで、リストの場合は正格版が
ダッシュがついた名前であるのでは。
0555デフォルトの名無しさん
2010/12/14(火) 23:44:10サユリ１号
0556デフォルトの名無しさん
2010/12/14(火) 23:51:17ダッチワイフについて自己レスしている男の人って…
0557デフォルトの名無しさん
2010/12/15(水) 00:15:18http://blog-imgs-38-origin.fc2.com/m/u/d/mudainodqnment3/5872462_500.jpg
0558デフォルトの名無しさん
2010/12/15(水) 00:16:070559デフォルトの名無しさん
2010/12/15(水) 00:43:260560デフォルトの名無しさん
2010/12/15(水) 00:54:17どっかでレンタルしてたぞ
0561デフォルトの名無しさん
2010/12/15(水) 01:49:360562デフォルトの名無しさん
2010/12/15(水) 01:53:520563デフォルトの名無しさん
2010/12/15(水) 02:58:220564デフォルトの名無しさん
2010/12/15(水) 03:03:340565デフォルトの名無しさん
2010/12/15(水) 10:47:48Yaccみたいなラブラリーで他言語への変換を簡単に書けるのがいいな
0566デフォルトの名無しさん
2010/12/15(水) 11:24:38みんな自分の頭のレベルや得意な思考スタイルに応じて
VBやったりHTML書いたりマシン語やったりしてるだけだと思ってた
0567デフォルトの名無しさん
2010/12/15(水) 12:10:100568デフォルトの名無しさん
2010/12/15(水) 12:12:23その代わりコンピュータそのものを理解している割合が極端に少ない世代だぞ。
0569デフォルトの名無しさん
2010/12/15(水) 12:15:39まじですか！？
マシン語を触っていればハードを意識するというもんでもないのか
0570デフォルトの名無しさん
2010/12/15(水) 12:23:340571デフォルトの名無しさん
2010/12/15(水) 12:31:09関数型ですか？ 全然だめでしょう。
0572デフォルトの名無しさん
2010/12/15(水) 12:31:35いや、そういう意味じゃなくて、
年配の一部のオタクはプログラミングもできるしマシン語も分かるけど、
一方でオタク以外は全くコンピュータやインターネットの知識をほとんど持っていない。
若者のほとんどは広くコンピュータリテラシを学んでいるから、どんな底辺でもそれなりにコンピュータの知識がある。
街中のド底辺DQNでも普通に携帯でネット使ってるだろ？
0573デフォルトの名無しさん
2010/12/15(水) 12:36:16なるほどすいません誤解しました。
0574デフォルトの名無しさん
2010/12/15(水) 12:40:580575デフォルトの名無しさん
2010/12/15(水) 12:47:590576デフォルトの名無しさん
2010/12/15(水) 12:51:01私が初めて読んだプログラムは学芸会ので、
完全に手続き型だったな。
0577デフォルトの名無しさん
2010/12/15(水) 12:52:280578デフォルトの名無しさん
2010/12/15(水) 12:54:02そういえば、高校数学とかでも何で BASIC なんだろうな
関数型を使うとまずい問題でもあるんかな
0579デフォルトの名無しさん
2010/12/15(水) 12:55:17いや、あれは読み手が手続き的解釈をしているだけだよ。僕の番はいつくるかとね。
0580デフォルトの名無しさん
2010/12/15(水) 16:30:580581デフォルトの名無しさん
2010/12/15(水) 16:32:11いや、手続き型ね orz
0582デフォルトの名無しさん
2010/12/15(水) 17:36:45関数型言語は何フェチの人がやるの？
0583デフォルトの名無しさん
2010/12/15(水) 17:40:100584デフォルトの名無しさん
2010/12/15(水) 19:22:54関数型は内向的
0585デフォルトの名無しさん
2010/12/15(水) 20:04:33ところが、２００５年になって青少年治安対策本部というのができたんですよ。
そこに警察庁からキャリア官僚が都庁に出向で来て、その青少年治安対策本部というのを作って、そこの本部長になるわけですよ。
それ以降、さっき言った青少年の保護育成というのは、生活文化局という、つまり生活文化のカテゴリーではなくて、
治安対策になっちゃったわけですよ。
今回のこの条文の改正というのも、この青少年対策本部の本部長とその下についている女性のキャリア官僚がいるんですけど、
この２人が主にというか、この２人が主導してやろうとしているわけですよ。
なぜそれをやろうとしているかということを、さらに都庁関係者に取材したところ、今本部長についている警察庁から出向してた方というのは、
実はあの志布志事件ってご存知ですか。あの選挙違反の世紀の冤罪事件と呼ばれている志布志事件の時の鹿児島の県警本部長なんですよ。
つまり、何かって言うと、そこで彼は汚点を作ってしまったわけですよ。キャリアとしての傷を負ってしまったが故に、出世が今遅れているんですよ。その汚名挽回と名誉回復のために、この条例を通して警察庁に帰りたいと。
さらに彼の今下についている、これはけっこう若手の女性のキャリア官僚なんですけれども、これは非常に優秀な方らしくて、
警察庁としても一押しで、日本初の県警本部長にしたいというふうに思ってらっしゃる方がいらっしゃって、その人にも手柄を与えたい。
そのためにこの条例をどうしても今回通したいということでですね。
0586デフォルトの名無しさん
2010/12/16(木) 00:01:31まじか!?
Lazy-Ocamlだいじょうぶかなぁ。
0587デフォルトの名無しさん
2010/12/16(木) 01:34:14第一段落は手続き的だな。
0588デフォルトの名無しさん
2010/12/16(木) 02:31:41手続き脳が完成した後に覚える第二言語(英語)が関数型
0589デフォルトの名無しさん
2010/12/16(木) 05:56:04これは何型ですか
0590デフォルトの名無しさん
2010/12/16(木) 06:50:230591デフォルトの名無しさん
2010/12/16(木) 07:25:23DQNが携帯でネット見てるのを見ると
まず料金が気になってこなイカ？
月いくら払ってんの？って聞きたくならなイカ？
0592デフォルトの名無しさん
2010/12/16(木) 13:06:20命文法（英米） 関数型
0593デフォルトの名無しさん
2010/12/16(木) 13:35:37？？？ 「命文法」って初めて聞いた。
「成文法」と「判例法」って言いたいのか？
0594デフォルトの名無しさん
2010/12/16(木) 19:49:060595デフォルトの名無しさん
2010/12/17(金) 15:54:52命文法 法律が作られた時の意味を解釈
0596デフォルトの名無しさん
2010/12/17(金) 17:05:03誰が使っている用語法？
0597デフォルトの名無しさん
2010/12/20(月) 00:57:39逆にいえば大学や専門学校で純粋関数型言語を１年生に強制すれば関数型が普及するかもしれない
0598デフォルトの名無しさん
2010/12/20(月) 01:07:110599デフォルトの名無しさん
2010/12/20(月) 02:27:13言語心理学のプログラミング言語版みたいな研究はないのか
0600デフォルトの名無しさん
2010/12/20(月) 07:14:33まずサンプルを探すのが大変そうだ
0601デフォルトの名無しさん
2010/12/21(火) 00:53:48まずないのと同じように、プログラミング言語で
初めて学ぶ言語が関数型言語になることはまずないな。
なぜなら、日本語以外も、関数型言語も
まわりで普及してないから
0602デフォルトの名無しさん
2010/12/21(火) 02:12:28レベル高い人が集まるコミュニティ見つけたからそっちに移住するわ。
0603デフォルトの名無しさん
2010/12/21(火) 02:28:220604デフォルトの名無しさん
2010/12/21(火) 02:57:07恐ろしい場所です。
0605デフォルトの名無しさん
2010/12/21(火) 12:32:440606デフォルトの名無しさん
2010/12/22(水) 00:21:34俺は Haskell 大好き人間だが、
初めて学ぶ言語が関数型言語というのは、
まず無いどころか、絶対に避けていただきたい。
初めてが Haskell なんて以ての外。
語句と、その語句の並びから、
動作（操作的意味論）を頭の中で容易に変換できる言語を使って、
プログラミングの本質をよ〜く感じ取ってほしい。
理解はしなくてもいいから、感覚でいい。
そういう意味では BASIC は今のところ最も優れた言語だ。
これを越える教育用言語は他にないな。
関数型を学ぶのは手続き型言語にどっぷりとつかってからでいい。
むしろ、手続き型言語のハッカーほど関数型を簡単に学べる。
だから、関数型を普及させるには、
その前に手続き型言語を計算機科学としてしっかりと学ばせる必要がある。
0607デフォルトの名無しさん
2010/12/22(水) 00:33:14普及しないのはとろいコンパイラしか作れないから
PerlやPythonのようなインタプリタが最適化の部分で大した苦労せずに普及したからって
自分らも同じようにいくなんてかんがえちゃだめ〜
0608デフォルトの名無しさん
2010/12/22(水) 00:36:58型推論バンザイだな
0609デフォルトの名無しさん
2010/12/22(水) 00:45:160610デフォルトの名無しさん
2010/12/22(水) 00:47:00> むしろ、手続き型言語のハッカーほど関数型を簡単に学べる。
うーんその根拠は？
単にそいつがハッカーだから
どんな言語でも楽勝なだけでは？
0611デフォルトの名無しさん
2010/12/22(水) 01:08:420612デフォルトの名無しさん
2010/12/22(水) 02:47:57サイテーでもC++でヒープとかスタックとかVTableとかわかってからでいいと思ふ
0613デフォルトの名無しさん
2010/12/22(水) 03:05:320614デフォルトの名無しさん
2010/12/22(水) 03:26:290615デフォルトの名無しさん
2010/12/22(水) 07:32:36おまえ馬鹿か？
俺みたいなのが日本に数万人いたって、
普及するかどうかにはほとんど影響ないよ
俺は単にここで持論を発してるだけで、
普及を妨げる活動は一切していない。
>>610
> 単にそいつがハッカーだから
> どんな言語でも楽勝なだけでは？
そうだよ
手続き型に慣れまくってると関数型を学ぶ時にハードル高いよね
という根拠のほとんど無い馬鹿げた意見を時々見るが、
そんなことはない、むしろハードルを低くしていると言いたかった
0616デフォルトの名無しさん
2010/12/22(水) 08:23:05中学受験で算数の難問を解いておけば、
中学で方程式も楽勝、的な議論だなぁ。
0617デフォルトの名無しさん
2010/12/22(水) 08:31:250618デフォルトの名無しさん
2010/12/22(水) 08:42:180619デフォルトの名無しさん
2010/12/22(水) 08:47:540620デフォルトの名無しさん
2010/12/22(水) 09:26:50パソコンを制御するのが目的なら手続き型だし
数式を解くのが関数型の役割だろう
学生は関数型に触れる機会がわりとあるかもしれないが
社会に出てからは関数型が必要になるような問題を表現する機会はない
このスレの対立構図は学生対社会人であるに違いない
0621デフォルトの名無しさん
2010/12/22(水) 09:48:26どんだけ狭い社会だ。
おまえの住む社会には論理回路も金融デリバティブも存在しないのか。
0622デフォルトの名無しさん
2010/12/22(水) 09:52:23おまえの住む社会には論理回路や金融デリバティブやってる人間がそんなにいるのか。
0623デフォルトの名無しさん
2010/12/22(水) 10:06:080624デフォルトの名無しさん
2010/12/22(水) 10:26:05結局頭の中で手続きを考えていたら手続きを書いているんだよ
0625デフォルトの名無しさん
2010/12/22(水) 11:02:02↑言葉の問題にすりかえても意味はない
0626デフォルトの名無しさん
2010/12/22(水) 11:02:490627デフォルトの名無しさん
2010/12/22(水) 12:58:23> 手続き型に慣れまくってると関数型を学ぶ時にハードル高いよね
> という根拠のほとんど無い馬鹿げた意見を時々見るが、
馬鹿と一蹴するくらいだから
> そんなことはない、むしろハードルを低くしていると言いたかった
というのはよっぽど根拠があるんだろうな？
0628デフォルトの名無しさん
2010/12/22(水) 13:00:22M$は本気で流行らす気ないからなぁ
0629デフォルトの名無しさん
2010/12/22(水) 13:29:11その壁はただ壊すだけで良い
創造性とか才能とかマーケティングとか必要ない
0630デフォルトの名無しさん
2010/12/22(水) 13:35:16俺はExcelがいいと思うよ
スプレッドシートは手続き的でなくて宣言的・関数的な世界なので
もともと相性がいいと思う
今だってワークシート関数のifとか全部関数だし
ワークシート関数をもうちょっときれいにして
ラムダ式を使えるようにして
VBAとかいうロクでもないものの代わりに関数型言語でユーザ定義関数を
記述できるようにすればいいと思うんだ
0631デフォルトの名無しさん
2010/12/22(水) 14:50:310632デフォルトの名無しさん
2010/12/22(水) 15:47:47意見としては分かるけど、いまさらBASICはどうかと思う。
現行のコンピュータの何たるかを学ぶということでは、アセンブリ言語のほうが良いし、次点でC言語。
逆に、たんに手続き的なフローチャートの思考法を学ぶということでは、perlとかPHPで良いんでは。
Webページを動的に生成できたら楽しいし。
0633デフォルトの名無しさん
2010/12/22(水) 16:09:52もしグローバル変数しかない古典的な BASIC がベストとか思ってるなら見識を疑う。
0634デフォルトの名無しさん
2010/12/22(水) 19:11:400635デフォルトの名無しさん
2010/12/22(水) 19:13:36関数型言語は漫才言語じゃねーぞ
0636デフォルトの名無しさん
2010/12/22(水) 19:14:00> 数式を解くのが関数型の役割だろう
関数型プログラミング言語の役割は数式を解くことではないよ。
役割というと語弊があるが、手続き型も関数型も、
ともに目的はコンピュータを制御することだ。
>>627
> というのはよっぽど根拠があるんだろうな？
どうせ俺が何を言っても君は信じないだろう。
そこで百聞は一見にしかずだ。
その辺の（自他共に認める）ハッカーに関数型を学ばせてみろ。
初めは大いに戸惑うだろうが、すぐに理解し、使いこなすようなる。
0637デフォルトの名無しさん
2010/12/22(水) 19:43:25現行のコンピュータの何たるかを学ぶのが目的なら、アセンブラもいいと思うよ。
でも、プログラミングというものに初めて触れ、
「コンピュータを制御するためにうまく文を構成する」ことを学ぶのなら、
やはり俺は BASIC を奨めるな。
アセンブラではプリミティブ過ぎて「文を構成する」というのが理解しにくい。
それに BASIC は意味を理解させるのが容易だ。
あくまで、初めてプログラミングを学ぶ者を対象とした話ね（>>606 はそういう話）。
学問として学ぶのは、おそらく小学校の授業が最初だろうと思われる。
およそコンピュータを制御するためのプログラミング言語全てに共通する、
根底にある考え方や、仕組み、なんたるかなどを学ばせる必要がある。
その目的なら BASIC でなくともビジュアルプログラミング言語でもいいとは思うが、
そうすると今度は教師の方が「教え方」を改めて学ぶ必要があるからね。
枯れているというのも BASIC の強み。
0638デフォルトの名無しさん
2010/12/22(水) 20:02:02操作的意味論については、IOをやるときに嫌というほど考えることになるだろう
そんなことより初心者向け言語で重要なのは、
・本質的でない面倒臭さがない
・型安全(動的型含む)
だと思う
0639デフォルトの名無しさん
2010/12/22(水) 20:21:08> 別にいきなりHaskellでも良いと思うけどな
だれが教えるんだね
0640デフォルトの名無しさん
2010/12/22(水) 20:24:01>>606に反論しただけ
0641デフォルトの名無しさん
2010/12/22(水) 20:27:45天才ハッカー君が関数型を容易に覚えても
「むしろハードルを低くしている」根拠にはなってないで。
まあ俺も関数型の普及しない第一の原因は
最初に習わないからというよりも
ゲームが作りにくい、金になりにくいからだと思うが
0642デフォルトの名無しさん
2010/12/22(水) 20:34:42型安全(動的型含む)
ここのところを解説を。
0643642
2010/12/22(水) 20:36:080644デフォルトの名無しさん
2010/12/22(水) 20:37:12言っているのでは
0645デフォルトの名無しさん
2010/12/22(水) 20:39:46Prologのように事実上型がない(型概念がない)言語は
どういう扱いになるのだろうか。
0646デフォルトの名無しさん
2010/12/22(水) 20:40:03変なコードを書いたときにすぐ未定義動作が起こって、
・アクセス違反で強制終了
・メモリが黙って書き換えられて誤動作
・まったく問題なく動作
という現象が一貫性なく起こる言語は、
・初心者にとってデバッグが異様に難しいことがある
・間違ったコードが間違っていることが分かりにくい
という点で教育向きではないと思う
0647デフォルトの名無しさん
2010/12/22(水) 20:40:520648デフォルトの名無しさん
2010/12/22(水) 20:47:25ことが保証されているという意味だと思っていたが、コンパイル時という
のは狭すぎ? たとえば、JAVAは中身と違う型にダウンキャストしようとする
と、例外が出るよるが、これも型安全の範疇にはいるのか?
0649デフォルトの名無しさん
2010/12/22(水) 21:12:25定義された動作をしてるわけだから、立派に型安全なのでは
一方Cでprintf()やscanf()に書式指定と違う型の引数渡しても
Cの仕様の範疇では誰もチェックしないし、挙動も未定義
（gccは拡張仕様でprintf()の引数の型をチェックするけど）
0650デフォルトの名無しさん
2010/12/22(水) 21:47:52いたしかたないとは思うが、こういう基本的な関数がやくざな関数
で提供されているところが(初心者向けとしては)よくない言語だな。
Cのような言語でもう少し安全な言語としてはFortran(90以降)がよい
のではないか。
・組み込みの強力なI/O (read/write「文」)
・強い静的な型付け
・モジュールの概念
・配列の境界検査が可能 (コンパイルオプションで指定)
0651デフォルトの名無しさん
2010/12/22(水) 22:11:40printf()は端的な例だから挙げたけど、
例えばCのポインタはvoid*とキャストも何も無しで
相互に変換可能なので、いずれにせよ型付けは弱いと思う
まあ俺は>>638ではないので、>>638がどういうつもりでのレスだかは知らないけどｗ
0652デフォルトの名無しさん
2010/12/22(水) 22:14:41あーそうなん？
悪貨が良貨を駆逐した例ってことなんかな？ｗ
0653デフォルトの名無しさん
2010/12/22(水) 22:30:03Cできないんじゃお話にならない
0654デフォルトの名無しさん
2010/12/22(水) 22:34:410655デフォルトの名無しさん
2010/12/22(水) 22:41:58誰もCをやるなとは書いてないじゃん
Cから始める人、Haskellから、VBからと多様性があるのは悪い事でもあるまい
0656デフォルトの名無しさん
2010/12/22(水) 22:42:17最低限実行ファイルが作れる言語な
0657デフォルトの名無しさん
2010/12/22(水) 22:43:22なぜ
0658デフォルトの名無しさん
2010/12/22(水) 22:43:36その次はLisp、その後にC
0659デフォルトの名無しさん
2010/12/22(水) 22:52:34haskellのunsafeCoerceはどうよ？
その論理だと、haskellもC同様型付けは弱い言語になるのでは
0660デフォルトの名無しさん
2010/12/22(水) 22:59:45Cだとキャストとかcoerceのために何の呪文も唱えず
ごく普通にこういう風に代入できるし、勿論誰もチェックしないし、
ポインタを使ったunsafeなコードを隔離するのも困難なので
さすがに一緒にはできないのでは
void *p = "Don't do this" + 1;
int *np = p;
*np++ = 12345;
0661デフォルトの名無しさん
2010/12/22(水) 23:22:25作ったプログラムを配布しやすいからじゃないか?
初心者が自習するのには、関係ない話ではあるが。
>>659
void*、union、...(さらに、マクロも入れるべきか)は、一種の「呪文」だと思う。安上がりで、
genericityを手に入れるための。
0662デフォルトの名無しさん
2010/12/22(水) 23:27:45Cの問題は、ごく普通のプログラムでもしばしばその種の呪文に触れる
必要があるってことかな
0663デフォルトの名無しさん
2010/12/22(水) 23:49:01なのに、静的な型付けのおかげで安全だ、とミスリードする
こういう呪術的なものは本当にごく普通にある
0664デフォルトの名無しさん
2010/12/22(水) 23:57:31デバッグモードで詳細が取れれば言語仕様を安全にする必要はないんだが
0665デフォルトの名無しさん
2010/12/23(木) 00:10:500666デフォルトの名無しさん
2010/12/23(木) 00:14:36お前の言う「正常に出来上がって動き出したら無駄な負荷でしかないコンパイルチェック」
って何の事だ？
0667デフォルトの名無しさん
2010/12/23(木) 00:16:400668デフォルトの名無しさん
2010/12/23(木) 02:21:280669デフォルトの名無しさん
2010/12/23(木) 02:36:51マシン語アセンブリ語やれば自動的にCもできるじゃん
Cなんて汎用アセンブラ以外の何者でもないだろうに
0670デフォルトの名無しさん
2010/12/23(木) 02:38:120671デフォルトの名無しさん
2010/12/23(木) 02:44:050672デフォルトの名無しさん
2010/12/23(木) 08:58:290673デフォルトの名無しさん
2010/12/23(木) 13:11:160674デフォルトの名無しさん
2010/12/23(木) 13:20:30頭が良くなる
0675デフォルトの名無しさん
2010/12/23(木) 13:23:500676デフォルトの名無しさん
2010/12/23(木) 13:34:31たとえば10進数を2進数に変換するときに
順番に2で割っていって最後に逆順に表示
ってことをやるんだけどこれを再帰的に
プログラムに書くとどうなりますうか？
0677デフォルトの名無しさん
2010/12/23(木) 14:11:14Haskellだと、例えばこんな感じかな：
num2binlist n = let{ f 0 [] = [0]; f 0 l = l; f n l = f (n `div` 2) (n `mod` 2 : l) } in f n []
0678デフォルトの名無しさん
2010/12/23(木) 14:15:49大雑把に言えば、関数型言語は
全ての計算を（写像とほぼ同義な）関数の評価によって行う言語だよ。
一方Ｃ言語なんかの手続き型言語は、
状態を変化させる命令によって全ての計算を行うんだよ。
> それ極めると、C言語で再帰関数が簡単に書けるようになるの？
「再帰」というものの考え方はどの言語でも同じだよ。
だから、例えば Java を極めればＣでの再帰関数が簡単に書けるようになる、
とも言えてしまう。
Ｃ言語で再帰が理解できない人は関数型でも他言語でも理解できないよ。
どれでも理解するのに同じくらいの努力が必要になるね。
ちなみに関数型では、現実的には再帰計算を明示的に記述することはあまりないよ。
ふつうは再帰計算を暗黙的に行う高階関数（関数を引数に取ったり返したりする関数）が
すでにライブラリで用意されているから、可能な限りそれを駆使するよう努める。
その方がプログラムソースの見通しが良くなるし、
おまけとしてコンパイラの最適化機能を働かせるのが簡単になるからね。
（これについては私が知ってるのは Haskell だけだが、他の言語でも似たようなものでしょ）
0679デフォルトの名無しさん
2010/12/23(木) 15:11:51(labels ((f (i binlist)
(if (zerop i)
(or binlist 0)
(f (truncate (/ i 2)) (cons (mod i 2) binlist)))))
(f n nil)))
0680デフォルトの名無しさん
2010/12/23(木) 15:25:46(define (f x)
(if (= x 0) '()
(begin (f (quotient x 2)) (display (logand x 1)))))
0681デフォルトの名無しさん
2010/12/23(木) 15:41:06void printbin(unsigned n)
{
if (n > 1) printbin(n >> 1);
printf("%u", n & 1);
}
ってとこだろ
これだけだとCでも十分短くて大して変わらんけど、
これでは印字する以外の使い道が無いので汎用性が低い
リストのような形で数の列を簡単に扱える言語なら、印字するのではなく
リストを返す関数にすれば汎用性を高められる
この例だと生成される数の列が有限にしかならないが、
そうとは限らない問題の場合は、無限リスト的な物を扱える言語なら、そう作ることで
より汎用性を高められる
0682デフォルトの名無しさん
2010/12/23(木) 15:51:26とりあえずprintしといて後でreverseできるよって例を書こうとして
ググってもビット演算子が出てこんから挫折した＼(＾o＾)／
0683デフォルトの名無しさん
2010/12/23(木) 16:36:10順番にｎで割っていって最後に逆順に表示
ってことをやるんだけどこれを再帰的に
プログラムに書くとどうなりますうか？
0684デフォルトの名無しさん
2010/12/23(木) 16:44:51あるよー。超あるよー bit演算子:
http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Data-Bits.html
0685デフォルトの名無しさん
2010/12/23(木) 16:46:21http://hibari.2ch.net/test/read.cgi/tech/1289292155/477
関数型言語でどうやるかはしらない。
0686デフォルトの名無しさん
2010/12/23(木) 17:18:242進数はn進数の一種だからbit演算子より整数の割り算と余りの方が良いのでは？
http://haskell.org/ghc/docs/7.0-latest/html/libraries/haskell2010-1.0.0.0/Prelude.html
>div :: a -> a -> a
> integer division truncated toward negative infinity
>mod :: a -> a -> a
> integer modulus, satisfying
> (x `div` y)*y + (x `mod` y) == x
>divMod :: a -> a -> (a, a)
> simultaneous div and mod
0687デフォルトの名無しさん
2010/12/23(木) 19:20:00超ありがとう。満足♪
f :: Int -> IO ()
f n = if n==0 then return () else f (Data.Bits.shiftR n 1) >> (printf "%d" (n .&. 1))
g n k = if n==0 then return () else g (div n k) k >> (printf "%d" (mod n k))
reverseを使ってみた版
当初IO [a]をliftMでreverseみたいなのが頭の中にあったものの
printとかじゃIO[a]は作れなかったので
結局リストに入れただけ
思ったより複雑になってしまったし
あまり利点が感じられなかった
h:: Int -> Int -> [IO ()]
h n k = if n==0 then [] else (printf "%d" (mod n k)) : (h (div n k) k)
i n k = List.reverse $ ((putStrLn ""):(h n k))
j k n = List.foldl (\a b -> a >> b) (return ()) (i n k)
tester k = mapM_ (j k) [1..10]
--2進数と3進数で10まで出力
main = tester 2 >> tester 3
0688339
2010/12/23(木) 19:36:49規制で書けなかった
おまえは一行で言語の仕様を全て把握できるんだな？
定義しようが同じ関数には違いないんだろ？
a <== b <== c <== d
<==は関数であり文の外で定義されているものとする
<==はxクラスを受け取ってyクラスを渡す
ab間bc間cd間が同じ関数だと知ることができる
関数は関係そのものである
従って同じ関係であると"知ることができる"
e<==(f<==(g<==(h)))
g<==メソッドはmクラスを受け取りnクラスを渡す
f<==メソッドはnクラスを受け取りmクラスを受け取っていない
同じ関係となるためには渡すクラスもmクラスにする必要がある
ところがそれを一箇所で定義できないため確信できない
定義が誤って一致したとしても文中でそれを知る術が無い
コピペを変更し忘れた場面を想像して欲しい
したがって同じ関係かどうか"知ることができない"
OOPLも演算子オーバーライドを使えば書くことはできる
だがそれはOOPLに不要な機能とされている
現にJAVAはC++との差別化を図りそれを削っている
C++もCの思想を優先したに過ぎない
「プログラマーのできることを制限しない」という思想だ
すなわち高級言語とは真逆の思想だ
0689339
2010/12/23(木) 19:38:22a(b)
aとbが関数でありxクラスを受け取ってxクラスを返すものとする
するとaとbを入れ替えて書くこともできる
入力に関わらず同じ値を返す関数を想像してくれ
全体の関係は変わるがaとbの定義は変わらない
述語と目的語が場面によって換わるので自然言語的とは言えない
e.f
OOPLで入れ換えるにはf.eを別に定義することになる
同じ名前であってもオブジェクトとメソッドという定義が変わる
したがって入れ換えることができず自然言語的と言える
人は理由も無く面倒なことはしたがらない
ましてそれが良くないと判っていればなおさら
つまり面倒であることが抑止力になるということ
関数型は自然言語的でないしそれっぽく書くのも面倒
上の例で判るように一文に関数を詰め込んだ方が書き易いから
思想が反映された書き方の違いこそ言語の違い
高級言語は何をできるかより何をできないかに存在意義がある
関数型はOOPLより少しできてしまうから低級なだけ
低級な言語を理由無く使おうとしないのが人間の心理
普及させたければ使う理由を作ってやれば良い
0690339
2010/12/23(木) 19:40:57じゃあ自分と何かとの関係を考えてみてくれ
├──関係─→┤＿＿何か＿＿│
関数型であればこうなる
├──関数─→┨＿＿何か＿＿┃
何かが関数であればこうなる
├──関数─→┨＿＿関数＿＿┃
関数は直接扱える
扱えないと既に関係を扱っていることと矛盾するため
関数を直接扱えるということは関数を知ることができる
関数は関係そのものだから関係も"知ることができる"
どこからどの関数なのか境界が曖昧になるところに注目
それこそが参照透過性や遅延評価の有無になる
OOPLであればこうなる
┃＿＿＿オブジェクト＿＿＿＿┃
├─メソッド→┨＿＿何か＿＿┃
何かがオブジェクトであればこうなる
┃＿＿＿＿＿＿＿オブジェクト＿＿＿＿＿＿＿┃
├─メソッド→┨＿＿＿オブジェクト＿＿＿＿┃
├─メソッド→┼─メソッド→┨＿＿何か＿＿┃
オブジェクト以外の何かは直接扱えない
直接何かを扱うことがオブジェクトの定義に反するため
従ってメソッドは直接扱えず知ることができない
メソッドは関係そのものだから関係も"知ることができない"
関数型はミクロの関係を扱おうとする
OOPLはマクロの関係を扱おうとする
相反する概念なのだから良いとこ取りはできない
関数型言語を知らなくても本質は語れる
関数とオブジェクト指向を理解してればな
これでも解らないならもう知らん
0691デフォルトの名無しさん
2010/12/23(木) 20:33:55そうだな、俺が悪かった、もう許せ
0692デフォルトの名無しさん
2010/12/23(木) 21:25:59>>622は論理回路、金融デリバティブと書いてるが他にもある？
0693デフォルトの名無しさん
2010/12/23(木) 21:31:32科学技術計算ではFORTRANに勝てず
低水準の仕事ではCやアセンブラに勝てず
事務計算ではCOBOLに勝てず
WebではJavaやLLに勝てないから
きんゆうでりばてぃぶとかになるのか？
0694デフォルトの名無しさん
2010/12/23(木) 21:39:230695デフォルトの名無しさん
2010/12/23(木) 22:00:50おもちゃとして遊びに使われるに決まってる
おれは Haskell で遊んでるぞ
0696デフォルトの名無しさん
2010/12/23(木) 22:09:140697デフォルトの名無しさん
2010/12/23(木) 22:15:050698デフォルトの名無しさん
2010/12/23(木) 22:25:29parseん：じいさん、manyはさっき(コンパイラが)食ったばかりですよ
0699デフォルトの名無しさん
2010/12/23(木) 22:44:52状況とか価値の判断がおかしくなるんだよ
幼児よりもキチガイに近い
もともと頭の悪かったやつにプログラミングなんてやらせても意味ない
0700デフォルトの名無しさん
2010/12/23(木) 22:49:11さすがにCOBOLには勝ってるのでは…
それと、低水準の処理でアセンブラに「勝てる」言語など、永遠に登場しないだろう。
コンピュータ・アーキテクチャが変わりでもしない限り。
0701デフォルトの名無しさん
2010/12/23(木) 23:21:24いやマジでつっこまれてもｗ
COBOLって任意桁数のBCD演算やらISAMやらを組み込みで持ってて
メインフレームの固定長データセットに非常に相性が良いようだし
COBOLが使われてる分野では未だに圧倒的なシェアを誇る言語だと
思っていたけど、何しろ全然詳しくないので…
事務処理の世界はもう関数型の独壇場だったのか？
0702デフォルトの名無しさん
2010/12/23(木) 23:30:170703デフォルトの名無しさん
2010/12/23(木) 23:33:430704デフォルトの名無しさん
2010/12/23(木) 23:36:57例えば給与明細の紙を出力するためにデータベースからデータを取ってきて
それを整形表示して印刷とかそんなの？
0705デフォルトの名無しさん
2010/12/23(木) 23:38:50相当範囲は広い。
0706デフォルトの名無しさん
2010/12/23(木) 23:44:160707デフォルトの名無しさん
2010/12/23(木) 23:46:38勝てないのに普及させるのは相当難しくないか？
0708デフォルトの名無しさん
2010/12/23(木) 23:48:49うん俺もそんなんをイメージしていた
汎用機にもツリー型とかリレーショナルなデータベースはあるはずだけど
固定長のISAMファイルって要するに簡易的なデータベースだから
ただのISAMでやってるケースも多いのではと思われ
バッチだけでなくオンライン的な処理が必要な場合は
資源管理のためにトランザクションモニタとかジョブキューとか使うんだろう
Javaは特別にその種の仕事に特化した言語じゃないから、
J2EEあたりのブクブクに太ってた頃のJavaでリプレースしようとして
泣いた会社は結構あるのでは
全然詳しく無いし、ただの想像だけど
0709デフォルトの名無しさん
2010/12/23(木) 23:50:110710デフォルトの名無しさん
2010/12/23(木) 23:51:080711デフォルトの名無しさん
2010/12/23(木) 23:53:350712デフォルトの名無しさん
2010/12/23(木) 23:57:45C++, Java, C#, Flash/ActionScript, Luaといったあたり？
0713デフォルトの名無しさん
2010/12/24(金) 00:06:06アダルトに特化するしかない
0714デフォルトの名無しさん
2010/12/24(金) 00:06:32メーカによりけりだろ？
メーカー固有のゲーム製作言語とかあったりするし…
0715デフォルトの名無しさん
2010/12/24(金) 00:09:36つまり「大人のおもちゃ」か！
0716デフォルトの名無しさん
2010/12/24(金) 00:22:33Real World Haskell を成人図書コーナーに置けば
中高生が隠れて読み耽るだろう
0717デフォルトの名無しさん
2010/12/24(金) 05:45:44http://www.indeed.com/jobtrends?q=Perl,PHP,Python,Ruby,COBOL,Fortran,Lisp,SML,Haskell
COBOLの求人はLLに抜かれましたが、関数型言語の数十倍あります。
http://www.indeed.com/jobtrends?q=Lisp,SML,Haskell,Scala,Clojure
古参をごぼう抜きしたScalaは普及が続くかも知れません。
0718デフォルトの名無しさん
2010/12/24(金) 07:46:13プログラムしてて楽しければ、役に立たなくてもいいじゃん
（応用じゃない）純粋な数学と同じだよ
0719デフォルトの名無しさん
2010/12/24(金) 07:48:44なんで考えるかというとそういう趣旨のスレだから
0720デフォルトの名無しさん
2010/12/24(金) 07:49:13Webアプリを簡単に組めないプログラム言語を
探す方が難しい。
0721デフォルトの名無しさん
2010/12/24(金) 07:52:41数学的思考が出来ないドカタは理解出来なくて当然！
こういう上から目線が多いから、いつまでたっても普及しない。
0722デフォルトの名無しさん
2010/12/24(金) 07:53:07あると、将来その分野に進出するケースも
想定して忌避することはある。関数型言語の
場合ここら辺はあるのかな。
0723デフォルトの名無しさん
2010/12/24(金) 07:54:35それは、はっきりいって、あると思う。
0724デフォルトの名無しさん
2010/12/24(金) 09:33:09まあ、プログラム言語としての利用じゃないわけだけどね。
0725デフォルトの名無しさん
2010/12/24(金) 10:14:050726デフォルトの名無しさん
2010/12/24(金) 10:33:39数値計算とか数式処理って専用のソフト使わないの？
matlabとかmathematicaとか
0727デフォルトの名無しさん
2010/12/24(金) 10:58:42そもそも関数型を本当に普及させたいのかと疑問に思う
自分はポルシェを乗り回せるぜ、というひとは、ポルシェがカローラになるより
ポルシェのままのほうがうれしいのでは？
0728デフォルトの名無しさん
2010/12/24(金) 12:36:18それもあるし、関数型が普及する必要があるとみんな思ってるのかも疑問
普及する必要あるのか？
無ければ普及しないぞ
0729デフォルトの名無しさん
2010/12/24(金) 13:23:24Haskellは、IOモナドが分かりにくいのが一番の理由じゃないかな。
副作用を分かりやすく形式化したもののはずなのに、これが分かりにくくて普及しないって、にんともかんとも。
0730デフォルトの名無しさん
2010/12/24(金) 15:37:43部分評価とか非正格評価は分散サーバとかに使える。
純粋ナンタラで美しいｨｨ！とか
モナドはストリームより表現力が上ｪｪｪ！
とかはどうでもいい。
0731デフォルトの名無しさん
2010/12/24(金) 15:56:03普及した方が、給料は上がる。
0732デフォルトの名無しさん
2010/12/24(金) 16:29:50一般に、普及すると仕事は増えるけど給料は下がるのでは
需要「だけ」が増えれば給料も上がるかもしれないが
そういう都合のいい普及の仕方ってあるのだろうか
0733デフォルトの名無しさん
2010/12/24(金) 16:49:37普及の程度にもよるけど。10年後に世の中の主流が
Haskellになると周知されたら、今、ソフトウェアハウス
で月給40万のHaskellプログラマの月給は転職前提で
100万を超える。そういう意味で。それを夢見て。
0734デフォルトの名無しさん
2010/12/24(金) 17:01:220735デフォルトの名無しさん
2010/12/24(金) 17:43:361番でなくては。
0736デフォルトの名無しさん
2010/12/24(金) 19:11:45その給料を出す方から見た関数型の必要性は？
0737デフォルトの名無しさん
2010/12/24(金) 21:20:09最近の数値計算はMatlabとC、C++が主流っぽい
0738デフォルトの名無しさん
2010/12/24(金) 21:22:460739デフォルトの名無しさん
2010/12/24(金) 21:29:580740デフォルトの名無しさん
2010/12/25(土) 00:21:59やはり、Webかクラウドに最適だと言えなきゃね。
0741デフォルトの名無しさん
2010/12/25(土) 00:53:530742デフォルトの名無しさん
2010/12/25(土) 01:04:590743デフォルトの名無しさん
2010/12/25(土) 01:15:03マルチコアCPU時代のプログラム言語は関数型言語でウッドボールって
説はどうなったの？
最近、あんまり聞かないから、フカシだったの?
0744デフォルトの名無しさん
2010/12/25(土) 01:57:05「ねぁ、はやく。はやく、あなたを感じたいの！」
「ふふ… ここかい？ ここが君のメールボックスなのかい？」
「そうそうよ。はやく、あなたの… あなたのメッセージを私にいれて」
「いいね？ 一緒に動くんだよ」
「いいから、はやくあなたのメッセージをいれてったら！」
>>743
「あら？ 早漏？」
0745デフォルトの名無しさん
2010/12/25(土) 02:34:54ItaniumのEPIC向けの最適化にも関数型言語が適してるなんて話もあったなｗ
0746デフォルトの名無しさん
2010/12/25(土) 02:52:54って、以下の考え方でおｋ？
(L1 L2 L3 ... Ln)
で、L(k+1)はLkの結果とは関係がない
Lｋは互いに無関係だから別々のスレッドで処理できる
さらにLkは
(M1 M2 ... Mn)
で、M(k+1)は以下略
どんどんスレッド増えていくからうまくいってないのかな
0747デフォルトの名無しさん
2010/12/25(土) 03:00:50条件が厳しすぎると思う。状態の概念は導入しないと。
0748デフォルトの名無しさん
2010/12/25(土) 05:50:090749デフォルトの名無しさん
2010/12/25(土) 09:12:080750デフォルトの名無しさん
2010/12/25(土) 11:18:390751デフォルトの名無しさん
2010/12/25(土) 13:20:41関数型って難解なのか？
何年もかけて習得した手続き型でのテクが使えないから
最初は手も足も出ないが
0752デフォルトの名無しさん
2010/12/25(土) 13:40:500753デフォルトの名無しさん
2010/12/25(土) 13:56:00結城浩とかえぴすてーめーとかやねうらおｗとか
0754デフォルトの名無しさん
2010/12/25(土) 13:56:51俺選 ザ・手続き型コード
while(*p++=*c++){}
0755デフォルトの名無しさん
2010/12/25(土) 13:56:56ただ鉄痔木型のノウハウがあまり通用しなかったりするのもたしか
0756デフォルトの名無しさん
2010/12/25(土) 13:59:12例えばJavaを書いてる人がRubyを習得するのは「比較的」楽だろう。
その習得を容易にさせた何かの総称。
Rubyを触った時は方言が聞き取りにくいが日本のどっかって感じだが
Hakellを触るのは外国に来た気分だった。
0757デフォルトの名無しさん
2010/12/25(土) 14:03:160758デフォルトの名無しさん
2010/12/25(土) 14:15:54ワードカウントといったら辞書にワードを挿入、カウントをインクリメント
するんだろ、とかまず発想するし
深さ優先探索といったらスタックの出し入れだの枝のマーキングだのを考える
そもそも「深さ優先」とかいう時点で計算の順序を思いっきり想定している
0759デフォルトの名無しさん
2010/12/25(土) 14:22:42ループと外部イテレータ。
ループが外部に晒され、副作用も晒される。
外部イテレータがあれば内部イテレータも簡単に書けるが、逆は難しい。
つまり、副作用ありの言語で副作用を隠蔽するのは簡単だが、逆は難しい。
0760デフォルトの名無しさん
2010/12/25(土) 14:51:30それとおすすめの関数型言語の本があったら教えて欲しい
来年はとりあえずその言語の習得から始めようかと思ってるんで
0761デフォルトの名無しさん
2010/12/25(土) 15:04:320762デフォルトの名無しさん
2010/12/25(土) 16:07:37もう「関数型の」利点なんて大して無いんじゃね
俺にとって使い易い言語がたまたま関数型だっただけだと思ってる
「プログラミングHaskell」おすすめ
0763デフォルトの名無しさん
2010/12/25(土) 16:13:27それを読んだら、「関数プログラミング」もおすすめ
0764デフォルトの名無しさん
2010/12/25(土) 17:30:300765デフォルトの名無しさん
2010/12/25(土) 17:36:03スタックを浪費するだけのアホ再帰は有害。
半端に関数型かじった生半可な奴がよく書く糞コードの典型例。
0766デフォルトの名無しさん
2010/12/25(土) 17:38:530767デフォルトの名無しさん
2010/12/25(土) 17:41:41再帰が見えない連中の典型的なコメント。
ここで、「見える」とは棋士が「読む」のでは
なく、一瞥で決める。そういう意味。
0768デフォルトの名無しさん
2010/12/25(土) 17:45:06世知辛い世の中だな。
0769デフォルトの名無しさん
2010/12/25(土) 18:06:51わかりやすいという奴がいたらお目にかかりたいものだよなw
0770デフォルトの名無しさん
2010/12/25(土) 18:22:19自分の知っている事を事前条件にしようとしてるって意味で
プログラム言語だというくくりで学習しようとするから成長曲線が鈍るんだよね
パラダイムシフトって単語使うのはいやだけど考え方が違う物なのだから、
一度自分は何も知らないって地点に立ってくれるだけで楽に学習可能なハズなんだけど
そういう事をするには既存言語で得た地位が高いプライドになって邪魔してる感じ
0771デフォルトの名無しさん
2010/12/25(土) 18:32:25「早すぎる最適化は諸悪の根源である」という格言を知らない人なのかも
知れないけど、たんに再帰を苦手な人が「パフォーマンスが悪いから書くな」と
言っているだけのことが多いんだろうな
0772デフォルトの名無しさん
2010/12/25(土) 18:36:05なんつーか手続き型でいきなり書くとしっくりこないw
0773デフォルトの名無しさん
2010/12/25(土) 18:37:21> 一度自分は何も知らないって地点に立ってくれるだけで
簡単にいうけど、そう簡単なことではないのでは
多くの人にとってプログラミング言語は単に目的を達成するための手段で、
慣れた言語なら簡単に達成できることのために一度全てを捨てるほどの
多大な努力を必要とするなら、よほどの動機付けやメリットが必要になる
0774デフォルトの名無しさん
2010/12/25(土) 18:37:50一番の利点はプログラミングに対する学習コストが下がることだと思う
駆け出しの頃、iとかjとか色々な変数の意味の解析からしなきゃならなくて
クイックソートのコードってなんて難しいんだって思ったものだけど
あれがHaskellであったなら、すっきり理解できただろうと思う。
短い上、リスト内包表記と再帰理解すればいいだけだし
0775デフォルトの名無しさん
2010/12/25(土) 18:40:48それぐらいの話なら関数型言語である必要は無い気がする
要は高級言語であればいいんだよね、Pythonみたいな
リスト内包も再帰も使えるよ
0776デフォルトの名無しさん
2010/12/25(土) 18:42:05クイックソートは末尾再帰じゃないから、手続き型でもループは使わないよ
その思い出話は捏造くさい
0777デフォルトの名無しさん
2010/12/25(土) 18:42:33高階関数の使用に原因がある、という意見はあまり聞かないが。
人間の問題の解く際の理解力、構成力の個人差を考えると、凡庸
な頭脳の持ち主にとって、障壁になりそうなのは、ここら辺り。
頭がオーバーヒートして、思考停止に陥る危険があるのかも知れ
ない。 この問題が原因だとすれば深刻。
0778デフォルトの名無しさん
2010/12/25(土) 18:44:56higher order functionを難しい人は確かにいるだろうけど、
そういう人はCでqsort()やsignal()、コールバックを使うにも困るはずなので、
別にぜんぜん関数型に限った話じゃない
そうした人はたんにプログラマに全く向いていない人であるというだけのこと
0779デフォルトの名無しさん
2010/12/25(土) 18:51:52多くのプログラマが現に使えないし、多分、プログラマと
して向いていない。それにもかかわらず、プログラマとして
何十万人(多分もっとずっと多い)も存在している。
0780デフォルトの名無しさん
2010/12/25(土) 18:52:39なんというかPythonはわりと関数型言語に近いと思うんだよね
何故関数型言語が普及しないのかってスレだけどさ
普通の言語にどんどん関数型の機能が取り入れられてるから
関数型の考え方はどんどん普及してるってのが個人的な思い
少し言えば、理解コストについては、
型がある言語のほうが低いと思う
引数の型を調べるコストが減るからね
>>776
手続き型でも再帰の理解が必要ってのは省いたよ
0781デフォルトの名無しさん
2010/12/25(土) 18:59:54うん、現に今のメジャーな手続き型言語の多くが何らかの形で
ファーストクラスの関数的なものを扱えて、LISPのリスト処理能力をある程度
パクってる
手続き型をベースとしているけど、関数型の便利なところをどんどんパクっている
C#、JavaScript、Ruby、Pythonのような言語で特に困っていない人たちに
アピールできるようなメリットがなければ、なかなか普及は難しいんじゃないの
0782デフォルトの名無しさん
2010/12/25(土) 19:01:26だから、コード量が多いと、些細な事でもこれはどういう意味だろうって考えて
アルゴリズムの重要な部分とは違う所で止まってしまう
関数型は手続き型に比べてそういうのが少ない
Win32APIとかでコードを書こうとしてた頃にやっと
「全部理解しようとすると結局挫折する」ってことを学んだけど
最初はそういうのわからなかったから結構勉強は時間かかった
あと、クイックソートは非再帰版も良く見るよ。スタック使うやつ
まぁスタック使えばどんな再帰もループに展開出来るわけだが
0783デフォルトの名無しさん
2010/12/25(土) 19:06:04無限ループしてない限りは、オーバーフローしないよね。
0784デフォルトの名無しさん
2010/12/25(土) 19:09:33個人的には代数的データ型が欲しい
オブジェクト指向でinstanceofで派生クラスチェックとか、
全く型システムの恩恵を受けてる気がしない
0785デフォルトの名無しさん
2010/12/25(土) 19:13:28長大なログファイルの1文字ずつ統計を取るような操作をしたらハングした
0786デフォルトの名無しさん
2010/12/25(土) 19:18:29OOの人はそうした場合には継承とポリモーフィズムを使うのが染み付いていると思う
instanceofなんて使わないんじゃないの
0787デフォルトの名無しさん
2010/12/25(土) 19:24:100788デフォルトの名無しさん
2010/12/25(土) 19:27:20CLOS の総称関数なんかはそうだけど。
0789デフォルトの名無しさん
2010/12/25(土) 19:31:04だから本来文法にinstanceofみたいなものを含むべきじゃない。
まあやっぱりgotoみたいなもので必要じゃないけど特定操作を簡潔に書くのに使えるような場面があれば別だけど。
0790デフォルトの名無しさん
2010/12/25(土) 19:35:25List<Object>的なものを返すAPIとかどうしようもないよ
代数的データ型なら、パターンマッチだから
全てにマッチするパターンをわざと書かない手法(おすすめ)で
マッチ漏れは検出出来るし
新しく増やしてもコードを直すべき箇所はコンパイラが教えてくれる
0791デフォルトの名無しさん
2010/12/25(土) 21:35:52Haskell布教を10年続けているnobsunこと山下伸夫さんと
Haskell連載を4年続けているshelarcyあたりでしょう。
継続性という点でこの二人が突出しています。
WWW.SAMPOU.ORG
http://www.sampou.org/
本物のプログラマはHaskellを使う
http://itpro.nikkeibp.co.jp/article/COLUMN/20060915/248215/
0792デフォルトの名無しさん
2010/12/25(土) 22:21:13目次リストに reverse 関数が適用されて見難くなった
0793デフォルトの名無しさん
2010/12/26(日) 06:36:46それで16M行あるCSVファイルを末尾再帰になってないアホ再帰で処理したらどうなる？
0794デフォルトの名無しさん
2010/12/26(日) 07:36:470795デフォルトの名無しさん
2010/12/26(日) 08:45:33と思ったけど、もしかしてこういう考えはもう古いのか？
0796デフォルトの名無しさん
2010/12/26(日) 10:43:50クイックソートあたりだと空間計算量がO(log n)だから再帰でも問題に
なりにくいけど、空間計算量がO(n)以上なら、わりと簡単に
スタックオーバーフローするでしょう
上で出てたpythonとか、デフォルトの再帰リミットは高々1000ですよ
1000回なんてループで回すならなんてことのない数字だけど
0797デフォルトの名無しさん
2010/12/26(日) 10:52:50保証されているけどそうでない言語も多いし
最近の賢いCコンパイラのように、末尾再帰として書かれていなくとも
（単純な例では）ループに最適化するものもある
要はケースバイケースかと
再帰＝悪、と単純に決め付けるのも良くないし、再帰で問題ないよ、と
言い切ってしまうのも良くない
0798デフォルトの名無しさん
2010/12/26(日) 11:56:13ことが多いな。
関数型を学び始めた頃、Javaコードがfinalだらけになったけど可読性を下げただけだった。
再帰だと木構造やグラフ構造の操作くらいにとどめておくのがいいと思う。
0799デフォルトの名無しさん
2010/12/26(日) 12:04:23コンビネーションのほうが分かりやすく安全。
0800デフォルトの名無しさん
2010/12/26(日) 12:08:020801デフォルトの名無しさん
2010/12/26(日) 12:39:22関数型はべつにIORefを使うなとかfinalを使えとか言ってない。
実際、IORefを使うことが許されている。
関数型の考えを持ち込んだというのは嘘なんだよ。
本当は、誰が言ったか不明の匿名の意見を持ち込んだ結果うまくいかなかったんだ。
0802デフォルトの名無しさん
2010/12/26(日) 12:47:50スタックに積むのが1回当たりint 4つぐらいだとすると、16M回で256MBでしょ？
あらかじめulimitしとけば、実用上別に問題無いんじゃない？
0803デフォルトの名無しさん
2010/12/26(日) 13:15:220804デフォルトの名無しさん
2010/12/26(日) 13:16:17>>796
0805デフォルトの名無しさん
2010/12/26(日) 13:29:58再帰で書いてあったコードをコンビネーションで
書き直した例を示してください。お願い。
0806デフォルトの名無しさん
2010/12/26(日) 13:59:31コンビネーション？組み合わせ？コンビネータの間違い？ｗ
0807デフォルトの名無しさん
2010/12/26(日) 14:13:32むかし書いたときは小さなプログラムだけで、大きなシステムは書ける気がしなかったのだが。
最近は違うのか?
0808デフォルトの名無しさん
2010/12/26(日) 14:15:32Cで10万行ならhaskellで1000行だな
0809デフォルトの名無しさん
2010/12/26(日) 14:16:520810デフォルトの名無しさん
2010/12/26(日) 14:17:18簡単な問題を標準ライブラリ以外使わずに書いてみて比べてみればわかるんじゃない。
0811デフォルトの名無しさん
2010/12/26(日) 14:19:33小さなプログラムなら。その様になるのは知ってる。
しかしだ、基本的によく使う処理は小さな関数群に集約する。
数十万行ともなると、ほとんどが目的のロジックだけになるんだが。いかが。
0812デフォルトの名無しさん
2010/12/26(日) 14:24:02>>811
ロジックそのものが短く記述できるってことだろ
1/100は明らかに誇張だけど1/2くらいにはなるはず
0813デフォルトの名無しさん
2010/12/26(日) 14:31:26GHCてなんですか？GHCの説明ページを教えて貰えませんか。
1/2ぐらいなら、妥当な気がする。でも1/2ぐらいだと、説得力が薄い気がする。
1/100なら広まらない理由が見あたらないので、嘘と確信できる。
0814デフォルトの名無しさん
2010/12/26(日) 14:32:18http://www.haskell.org/ghc/
0815デフォルトの名無しさん
2010/12/26(日) 14:38:26>>とか>>=なら改行減らしてもごまかせる
0816デフォルトの名無しさん
2010/12/26(日) 14:39:36数えるのが面倒だけど
0817デフォルトの名無しさん
2010/12/26(日) 14:40:02機械学習とかであるような、100万 * 100万 の行列同士の乗算をするような処理を
full lazyな関数型言語で書くことを想像するだけで気が遠くなる。
0818デフォルトの名無しさん
2010/12/26(日) 14:40:45せめてサイクロマティック数とかで比較しようぜ。
0819デフォルトの名無しさん
2010/12/26(日) 14:41:09Cの100分の1のプログラムを10倍の時間掛けて作るのがhaskell
0820デフォルトの名無しさん
2010/12/26(日) 14:47:41言いたい事は分かるが。ここで、そこまでする必要性は感じなかったな。
そうやって、細かくする事で、一般的な簡単な理解を阻む事が。
関数型言語の広がりを阻害する例だね。
0821デフォルトの名無しさん
2010/12/26(日) 14:49:33関数型は久しぶりだけど、ちょっとhaskellやってみるかな。
0822デフォルトの名無しさん
2010/12/26(日) 14:49:361年間どっぷり浸かれば良さも見えてるわな。
だいたい言語の良さなんて定量化できるもんでもないだろ。
ゴミみたいな数字なんか捨てろ。
いいか、プログラムってのは工業生産品じゃなくて工芸品なんだよ、カス
覚えとけ
0823デフォルトの名無しさん
2010/12/26(日) 15:01:13工芸品だと言っている間は、普及は無理との結論だ。
0824デフォルトの名無しさん
2010/12/26(日) 15:08:38作業量保存の法則だなｗ
0825デフォルトの名無しさん
2010/12/26(日) 16:02:51保存していないように見えるのは俺だけか
0826デフォルトの名無しさん
2010/12/26(日) 17:06:34俺も思ったｗ
時間10倍かかるんなら、作業量／コストも10倍
何文字／何行タイプしたかどうかははっきり言ってどうでもいい話
まあ普通はメンテやデバッグのコストも考えなければならないので
プロファイラ、デバッガ、リーク解析なんかのツールがどれぐらい使いやすいかとか
そういうのも響いてくるのでは
0827デフォルトの名無しさん
2010/12/26(日) 17:13:021/100作るのに10倍かかったら、効率はCの1/1000
0828デフォルトの名無しさん
2010/12/26(日) 17:23:120829デフォルトの名無しさん
2010/12/26(日) 17:27:43Jなんかだと、本当に100分の1だけどね。
0830デフォルトの名無しさん
2010/12/26(日) 17:29:29話を聞いたが実際はどうなんだろう。
0831デフォルトの名無しさん
2010/12/26(日) 17:32:070832デフォルトの名無しさん
2010/12/26(日) 17:34:48ソフトウェアってのは一度作ったらコピーは自由なのだから、
本質的に創造の力が必要になる。
工場で大量生産するような類のものじゃない。
ソフトウェアの大量生産は簡単に一瞬でできるコピーでしかない。
0833デフォルトの名無しさん
2010/12/26(日) 17:36:58そう。
日本人ではないけど、INTERLISPに関わってた人から聞いた。
0834デフォルトの名無しさん
2010/12/26(日) 17:41:20例えばマテマティカの言語は別にソフト開発するために便利なわけじゃなくて
数式取り扱うのに便利でそれなりに普及している。
統計処理のR言語もよく知らないけど、統計処理するために便利なので
普及している、と思われる。
こういう文脈でムリヤリ考えると、C++やJavaはそもそもソフトウェアを
開発するのに便利な言語として普及している、と限りなくそのままだけど、
考えることができる。
何が言いたいのかというと、関数型言語としての特徴をフルに発揮できる
分野自体を見つけるほうが筋がいいんじゃないか、ということ。
0835デフォルトの名無しさん
2010/12/26(日) 17:41:48それがある面真実なのであれば
immutableなデータによりコピーが多発する関数型は
速度的に不利なんじゃないかと思う
OSの記述は楽だとしても
0836デフォルトの名無しさん
2010/12/26(日) 17:42:51日本のソフトウェア産業は世界に遅れをとっているんだよ。
いわゆる詳細設計＝プログラミング
生産＝コピー
だと考えればもうちょっとマシになる。
0837デフォルトの名無しさん
2010/12/26(日) 17:43:23それは凄い
LISPマシンなんて実物を見たことも無いよ…
>>834
面白い考え方だ
0838デフォルトの名無しさん
2010/12/26(日) 17:45:19LISPがシステム記述に向いているのは、関数型だからじゃなくて、メタ機能が柔軟で強力だからだろ。
つうか、関数型言語の長所としてLISPの例を出されるとは思わなかった。
0839デフォルトの名無しさん
2010/12/26(日) 17:46:390840デフォルトの名無しさん
2010/12/26(日) 17:52:30むしろ関数型言語によって定量的だか定性的だかわからんが
一般的に低コストで取り扱いが可能になるような領域を明らかにする方向で
考えたほうが発展性があるよ。全然具体性がないけれど。
0841デフォルトの名無しさん
2010/12/26(日) 17:58:31> OSの記述には関数型が優れているという
> 話を聞いたが実際はどうなんだろう。
実際にモノを作って証明するまでは
全部マユツバだと思えばいいよ。
0842デフォルトの名無しさん
2010/12/26(日) 18:00:06ハードウェアを動かすためのもので、
そのハードウェアが関数型言語で作られてない以上
関数型言語でハードウェアを効率良く動かすことはできない。
なんらかの変換が絶対に必要になる。
0843デフォルトの名無しさん
2010/12/26(日) 18:01:59であれば、
1. 関数型言語としての特徴とは何か？
2. それがソフトウェアを開発するのに何故・どう妨げになっているか？
（C や Java ほどソフトウェア開発分野で普及しないのは
その特徴が妨げになってるからという前提の話）
と考えて、初めて「3. ではその特徴が活かせる分野は？」と
段階を踏んで考えないとまとまらないと思う。
まぁ、当たり前だが。
>>842
バーチャルマシンという考え方もある
0844デフォルトの名無しさん
2010/12/26(日) 18:03:300845デフォルトの名無しさん
2010/12/26(日) 18:04:19> そのハードウェアが関数型言語で作られてない以上
逆に「ハードウェアが関数型ではない言語で作られている」というのは、
どういうこと？
0846デフォルトの名無しさん
2010/12/26(日) 18:11:29言語の特徴が妨げになっている訳じゃないだろ
宣伝が足りない、実績が足りない、扱える人間が足りない、ライブラリが足りない、ツールが足りない
0847デフォルトの名無しさん
2010/12/26(日) 18:17:01手続き的な記述のしかたもできるが。
0848デフォルトの名無しさん
2010/12/26(日) 18:18:08たとえばC言語が忠実に対応しているとも思えない
0849デフォルトの名無しさん
2010/12/26(日) 18:18:44・ 階層キャッシュが効きにくい
・ ヒープ消費の予測が立てにくい
・ チューニングがむずかしい(特に非正格)
・ I/Oのオーバーヘッドが大きい
・ トイプログラムと実用のギャップが大きい
0850デフォルトの名無しさん
2010/12/26(日) 18:25:39>・ 階層キャッシュが効きにくい
これはオブジェクト指向言語も一緒だと思っていい？
>・ ヒープ消費の予測が立てにくい
非正格だけじゃね
>・ I/Oのオーバーヘッドが大きい
>・ トイプログラムと実用のギャップが大きい
そんなことないと思うが。何か例ある？
0851デフォルトの名無しさん
2010/12/26(日) 18:35:04OOの場合は世代コンパクションで同世代オブジェクトが集められて若干マシじゃなかろうか。
関数型の場合はヒープ上での生成/消滅のタイミングがバラバラ。
0852デフォルトの名無しさん
2010/12/26(日) 18:39:56OOPLのC++の場合基本的に自己管理。だから、階層キャッシュ自由自在。
LL言語の場合>>815
0853デフォルトの名無しさん
2010/12/26(日) 18:42:23言語だけでなく、言語周りのいろいろな環境やサポート含め、とても大きいと思っている。
これが一番のネックじゃないかな?
0854デフォルトの名無しさん
2010/12/26(日) 18:42:36>>851のタイポだろうか…
Bind演算子でなにかインチキをやるとかやらないとかいう
いけない話が目に入ったけど
0855デフォルトの名無しさん
2010/12/26(日) 18:49:02それなら分かるけど、そもそもデフォルトで非正格という言語設計が糞なのであって、
関数型言語の問題というのとは違う気がする
0856デフォルトの名無しさん
2010/12/26(日) 18:54:41別にトイ向けでもいいんじゃないかなー
ただ、エロ画像を高速にダウンロードしたり
エロ画像を高速に仕分けしたりするような
俺の俺のための俺だけのトイプログラミングをするときって
LLしか使わないな俺は
楽だし！
0857デフォルトの名無しさん
2010/12/26(日) 18:57:01糞は言い過ぎじゃない？
非正格のおかげで考えやすくなった経験を持つ人は少なからずいるし。
言うなら、＊＊というケースには非正格という言語設計は合わない、くらいでしょ。
その ＊＊ が多いから、じゃあ合っているケースは何なの？ に繋がる話ならわかるが
0858デフォルトの名無しさん
2010/12/26(日) 19:01:14書き捨ての実用コードは含めないよね、普通
0859デフォルトの名無しさん
2010/12/26(日) 19:04:34理解できない。
0860デフォルトの名無しさん
2010/12/26(日) 19:04:350861デフォルトの名無しさん
2010/12/26(日) 19:04:47でも、非正格性による考え易さの恩恵が、
非正格性によるチューニングの面倒臭さのデメリットを上回る分野ってそんなにあるかな
0862デフォルトの名無しさん
2010/12/26(日) 19:07:590863デフォルトの名無しさん
2010/12/26(日) 19:09:03一回haskell製のソフトのソースコードでも読んでこい。
読んでから発言しろ。
0864デフォルトの名無しさん
2010/12/26(日) 19:09:440865デフォルトの名無しさん
2010/12/26(日) 19:50:44Haskellなら日常的に使ってるが
0866デフォルトの名無しさん
2010/12/26(日) 19:53:02お前のゴミコードじゃなくて人が書いたコードだよ
0867デフォルトの名無しさん
2010/12/26(日) 19:55:11アプリを丸ごと読んだことはないような気がするけど、ライブラリの実装は良く読むよ
0868デフォルトの名無しさん
2010/12/26(日) 20:21:03> 非正格性によるチューニングの面倒臭さ
どの程度を面倒臭いと言ってるの？
何か例を示してほしい
0869デフォルトの名無しさん
2010/12/26(日) 20:48:51うっかりspace leakを入れてしまったときに特定するのが面倒
ループをチューニングするのにGHCのcoreを見ながらやるのが面倒
Stringが遅すぎるのでByteStringを使おうと思えば、
Stringほど手厚いサポートがない(たとえばshowの結果はString)ので面倒
それに遅延評価のオーバーヘッドが広く浅くかかるからトータルで性能が出にくいし
0870デフォルトの名無しさん
2010/12/26(日) 20:58:48開発効率は置いといて、究極的には
機械語にするのが一番効率がいいんだよ。
で、機械語は手続き型で動作する。
0871デフォルトの名無しさん
2010/12/26(日) 21:11:58なにを今さら
0872デフォルトの名無しさん
2010/12/26(日) 21:20:560873デフォルトの名無しさん
2010/12/26(日) 21:24:08なるほど
> うっかりspace leakを入れてしまったときに特定するのが面倒
これは分る、同感。
> Stringが遅すぎるのでByteStringを使おうと思えば、
> Stringほど手厚いサポートがない(たとえばshowの結果はString)ので面倒
Stringほど手厚いサポートがない例が「showの結果はString」って何だ？
show の結果が String では困るケースがあるのか？
> ループをチューニングするのにGHCのcoreを見ながらやるのが面倒
ループのチューニングとやらが具体的にどのようなものを指しているのか分らん。
それほどまでのチューニングが必要なケースには
今の Haskell は不向きであることはよーく分る。
べつの分野を開拓した方が良さそうだよね。
0874デフォルトの名無しさん
2010/12/26(日) 21:30:25> で、機械語は手続き型で動作する。
CPU に入力する機械語や解釈の構造が関数型というのは、
机上の空論だとしても理論的には可能なのかな？
そもそも、どういうのか想像もできんが
0875デフォルトの名無しさん
2010/12/26(日) 21:34:59RISCとかVLIW系のCPUだとおまえの書いた機械語より
コンパイラの吐き出したコードの方が早いと思われる
0876デフォルトの名無しさん
2010/12/26(日) 21:46:19そもそも「関数型」という理論はない
あるのは、一見関係ありそうで関係ない理論や
イデオロギーや風説などの社会現象だ
0877デフォルトの名無しさん
2010/12/26(日) 21:53:55Lispマシンも手続き型の機械語ということ？
0878デフォルトの名無しさん
2010/12/26(日) 21:55:44Lispマシンが手続き型なのか関数型なのかを判定する理論的な基準はないということ
0879デフォルトの名無しさん
2010/12/26(日) 22:21:30それは、そもそも手続き型とは何か？ 関数型とは何か？
が論理的に定義されていないからなの？
それとも、そのレベルのものは論理的に定義されているが、
CPU に入力する機械語とは何か？ Lispマシンとは何か？
の方が論理的に定義されていないからなの？
前者なら、このスレ自体議論できないよ
0880デフォルトの名無しさん
2010/12/26(日) 22:54:06主記憶がタグサポートしてるだけでCPU自体はスタックマシンだよ
0881デフォルトの名無しさん
2010/12/26(日) 23:04:56スタック使うようになってからだろプログラマがバカになったのは
0882デフォルトの名無しさん
2010/12/26(日) 23:49:100883デフォルトの名無しさん
2010/12/26(日) 23:55:30マシン語でもスタックって使うよね？
0884デフォルトの名無しさん
2010/12/26(日) 23:56:170885デフォルトの名無しさん
2010/12/26(日) 23:58:410886デフォルトの名無しさん
2010/12/27(月) 00:00:09それにしたってスタック的な何かを自前で実装して概念自体は存在した可能性はあるが
0887デフォルトの名無しさん
2010/12/27(月) 00:08:17MN1617はなかった
あとIBMのメインフレームにも無いのあったきがする
iTMS9900シリーズも無かったかも（コレはレジスタがCWPしか無いのだったかも)
0888デフォルトの名無しさん
2010/12/27(月) 00:12:02>関数型とは何か？
内包表記のような定義はできないが、ごく一部を具体的に列挙することはできる
いかにもありがちなシチュエーション
0889デフォルトの名無しさん
2010/12/27(月) 00:17:53MN1617ちょっと調べたけど、命令表や内部構造は見つからなかった。
がしかし、関数コールが出来る以上。戻り先保存のスタックはあるはず。
無ければどうやって関数コールのネストするんだ? それがスタックだろ。
0890デフォルトの名無しさん
2010/12/27(月) 00:27:01私も MN1617 はしらないが、そのスタックは関数コールの戻り位置を記録する意外には使えないシステムスタックではないだろうか？
他にも、6809 や 68000 ではシステムスタックとユーザースタックが区別されている。
0891デフォルトの名無しさん
2010/12/27(月) 00:33:17脱線しすぎる気がするけど、8080はSP（スタックポインタ）レジスターがあって、
それを書き換える事で、スタックデータの処理をしていた。
もし、MN1617がそのレジスターが書換え不可なら（あり得ないと思いますが、
最初にメモリーアドレス決めないといけないので）
理解します。が、たぶん書き換える事が出来るでしょう。それすなわちスタックですよ。
0892デフォルトの名無しさん
2010/12/27(月) 00:45:42でもそのスタックにユーザがデータを載せることができるかどうかは？できないシステムスタックなら、応用は限定されてしまう。
0893デフォルトの名無しさん
2010/12/27(月) 00:48:34ユーザがデータを載せるのは関係なくないか
0894デフォルトの名無しさん
2010/12/27(月) 00:49:08当時のCPUにメモリーガードなど有りませんので何処でも書き換えられます。
SPレジスターが書換え計算可能なら＋２して、2バイトのスタックデータデータエリアにします。
何の問題もありません。ちなみにMN1617が関数コールが出来るとの仕様は見てます。
0895デフォルトの名無しさん
2010/12/27(月) 01:20:070896デフォルトの名無しさん
2010/12/27(月) 02:05:03Emacs関係を除いて、ここ数年のを挙げると、Darcsぐらい？
0897デフォルトの名無しさん
2010/12/27(月) 02:12:420898デフォルトの名無しさん
2010/12/27(月) 02:13:28でも再利用できない書き捨てなんてプログラムとして書く価値もないと思う。
場当たり的な問題はUIで手作業すればいいのだから。
精密で複雑で慎重に取り組まざるを得ないのにそれでも書くのは、何度でも使えるからだ。
0899デフォルトの名無しさん
2010/12/27(月) 02:16:280900デフォルトの名無しさん
2010/12/27(月) 03:13:36R3000とかと一緒
戻りアドレスが記録されたレジスタが１つある
プログラマが戻りアドレスをどのように保護するか決める(listでもstackでもarrayでも)
0901デフォルトの名無しさん
2010/12/27(月) 06:11:37そういう作業は何度も起こったりしないよ。
0902デフォルトの名無しさん
2010/12/27(月) 06:35:08while(*p++=*c++);
0903デフォルトの名無しさん
2010/12/27(月) 07:19:05Yi や Snap はどう？
0904デフォルトの名無しさん
2010/12/27(月) 07:21:49MN1610がSP持ってるから、発展型の1617もSPもってるんじゃねぇの？
0905デフォルトの名無しさん
2010/12/27(月) 09:32:41行列計算が処理系ごとに独自行列構造体を導入してて
他の処理系から移植できない
0906デフォルトの名無しさん
2010/12/27(月) 10:32:55クロージャが普通の関数と同様に扱えるかどうか、という基準はあるんじゃないの？
0907デフォルトの名無しさん
2010/12/27(月) 10:35:21ええ！ 書き捨てコードこそ、プログラマの本懐だと思うが。
0908デフォルトの名無しさん
2010/12/27(月) 10:49:35元々その言語を使ってたプログラマの為のWebフレームワークを含めてもいいのなら、
ScalaのLiftが一番実際に商用に使われてるだろう。でも、あんまり挙げる意味が無いと思う。
やっぱ、その言語を使ってなかったプログラマが使い始めるようなrailsみたいなのや、
その言語のプログラマでない人も広く使うようなツールとかじゃないとね。
その意味で、darcsを挙げた。
0909デフォルトの名無しさん
2010/12/27(月) 11:04:57そういう基準ならバージョン管理システムのdarcsより
タイル型ウィンドウマネージャのxmonadの方が
広く使われているのでは？
0910デフォルトの名無しさん
2011/01/05(水) 00:27:14ポジティブな言い方をすると、プロトタイピングに向いている、って事か。
0911デフォルトの名無しさん
2011/01/05(水) 00:48:250912デフォルトの名無しさん
2011/01/05(水) 01:56:28公開されているという条件が無ければ、
次のサイトで「決してサンプル作成専用ではない」と反論はできる。
http://cufp.org/conference
ただ、広く当たり前のように活用されているとは言えないだろうね。
まだまだだからこそ、こんなカンファレンスが毎年開かれるわけで。
0913デフォルトの名無しさん
2011/01/05(水) 10:40:25手続き型で本格実装するなら参考にもならないんじゃないか
原理が違いすぎる
0914デフォルトの名無しさん
2011/01/05(水) 11:15:20なんでそう思ったの？
プロトタイピングにはぜんぜん向いてないように見えるけど…
その手の用途なら言語的にはLLのほうが向いてるだろうし
さっさと何かをデッチあげたいときには
RADのような開発環境やライブラリが整備されてるかどうかも重要だと思うな
0915デフォルトの名無しさん
2011/01/05(水) 12:42:190916デフォルトの名無しさん
2011/01/05(水) 21:41:30Excelでプロットをたくさんつくると手がしびれてくるじゃないか。
0917デフォルトの名無しさん
2011/01/05(水) 21:46:46数値シミュレーションのプロトタイプはときどきMLでやったりするが。
同じ関数型のRでやってもよいのだが、型がないのでやりにくい。
0918デフォルトの名無しさん
2011/01/05(水) 22:47:17純粋じゃなくてマルチパラダイムだが
0919デフォルトの名無しさん
2011/01/06(木) 01:41:25問題なく追加できて手続き的プログラミングとが共存できる。
ところがHaskellのようなcall-by-need (lazy evaluation) の関数型言語はそうはいかない。
lazｙな関数型言語に破壊的代入なんて追加しようものなら整合性のあるすっきりした意味論が構築できない。
だから手続き的なスタイルの方が自然なケースでも強引に関数型プログラミングのスタイルで書かなければならなくなって不自然。
ところが関数型プログラミングの信徒はlazyな言語こそが関数型プログラミング言語の正統派だと主張するから、ますます現実とかけ離れてしまう。
関数型プログラミングが世の中に広まらないのはこういう宗教的とさえ言えるファナティックな原理主義が原因の大きな部分なのは確か。
0920デフォルトの名無しさん
2011/01/06(木) 10:26:25それで足らないというのなら分かるけど
0921デフォルトの名無しさん
2011/01/06(木) 10:28:08> だから手続き的なスタイルの方が自然なケースでも強引に関数型プログラミングのスタイルで書かなければならなくなって不自然。
モナド使えばいいじゃん。
あと、Lazyであることには、関数型プログラミングの正統云々じゃなくて、実際上利点があるよ。
だからこそ、LISPやJavascriptで引数なしのクロージャを使うことがあるんじゃない。
そうすることによって、ロジックとデータ構造が分離せず、書きやすくなる。
ロジックとデータ『構造』を分離させたいときは、クラス使えばいいしね。
0922デフォルトの名無しさん
2011/01/06(木) 11:51:23使うことがあるが、使わないこともある。
使わないケースで不自然になると言ってるのに、使うことがあると言うのは
論点がずれている。
0923デフォルトの名無しさん
2011/01/06(木) 12:35:35え？ いや、それに対する応答は「モナド使えばいいじゃん」で終了している。
たしかに、lazyな言語で手続き的に書くためにはトリックが必要。
そういうトリックがないと仮定すれば、lazyな言語であることは、手続き的に書けない/書きにくいということに直結する。
だけど、実際には、そのトリックは使いやすい形ですでに用意されているのだから、手続き的に書けるかどうかとlazyかどうかは別の問題になる。
手続き的に書くためにはモナドを使えばよい。以上。
そこで、別の問題としてlazyであることに利点があるか？
関数型として純粋であるという宗教的情熱以外に？
ということに対する答えが、「LISPやJavascriptで引数なしのクロージャを使うことがある」から利点があることははっきりしている、と言っている。
Haskellerは、その利点がたまにではなく広範に活用できると思っている、ということ。
0924デフォルトの名無しさん
2011/01/06(木) 13:17:51広範に活用すると、モナドを使う範囲が狭くなるよな。
仮にモナドを使えば不自然にならないとしても、
実際はモナドを使う範囲を狭くするのなら、結局不自然じゃないか。
0925デフォルトの名無しさん
2011/01/06(木) 13:53:38え？ それはプログラマがやりやすいスタイルでやれば良いじゃん。
手続き型の書き方が自然なアルゴリズムや処理、あるいはプログラマが個人的にそうしたいときはモナドで書けばよい。
遅延評価で、ロジックをカプセル化(?)したいときはそう書けばよい。
手続き的である必要はないけど、あるいは純粋な関数だけど、なんらかの理由で遅延評価をしたくないときは、正格型をつかえばよい。
あなたがしたいようにすればよい。
オレが言っているのは、遅延評価には利点がある、広範に使えるということであって、つねに使えということではない。
0926デフォルトの名無しさん
2011/01/07(金) 02:35:58再帰呼び出しで延々と同じパラメタ（例えばコンパイラを関数型で書こうとしたらシンボルテーブルがそういうパラメタ）を
引きずりまわすのを省略したような書き方ができるだけ。
Haskellのモナドは単なるシンタックスシュガー同然のものでモナドを使わない純関数型スタイルに機械的に書き直せるレベル。
それにプログラム全体で使うグローバルな手続き的変数に相当するものをモナドのスタイルで書こうとしたら
プログラム全体を覆う巨大なモナドが必要になって後での機能追加とか削除の変更がやりにくくなる。
それからcall-by-needの場合だと関数の計算量という概念が意味を持たなくなる。
つまり関数が返す値が最終的にどう使われるかで実際にどこまで評価が行われるかが変わるからね。
だから今まで手続き的プログラミング向けに整備されて来たアルゴリズムやプログラムの性能評価の理論やテクニックが使えない。
その点、ML/Lisp系のcall-by-value意味論ベースの言語だとそれらの理論やテクニックがそのまま使える。
（高階関数に関する評価は今までも未整備な部分が多いからそれは新たに整備しないといけないけど
通常のリスト処理とかだと手続き的言語向けの理論やテクニックがほぼそのまま使える）
更にcall-by-need言語では外部割り込み（例えばUNIX系OSでのBREAKキーの信号を拾うとか）の例外は
ゼロ除算や空リストの先頭要素を取り出そうとするような類の内部エラーと違ってモナドでは扱えない。
call-by-need言語の意味論にズルをして汚いものというかゴマカシを持ちこまないと扱えない。
call-by-value言語は手続き的言語と同じで何の問題もなく扱える。
call-by-needは確かに無限データ構造を簡単に扱えるとか便利な点もあるけれど、その為に犠牲にしてる部分の方が
実用的な観点からは大きいと思うなあ。
無限リスト（ストリーム）とか無限木なんて、それらのデモ用のトイプログラムならばともかく、実用プログラムを書く上で
そんなに必要になるものじゃないもの。
0927デフォルトの名無しさん
2011/01/07(金) 04:17:17プログラマの意図をどれだけ正確に記述できるとかにあると思うし、
その辺りしか興味がないんだけど、遅延評価する言語とはいえ、
処理系が作り出す評価順序というものは事実としてあるわけで、
性能を第一とするなら、プログラマはそこを熟知して意識しながら
書く事をやっぱり求められるはず。
haskellはそこがぼやけてはっきりしない。
本来なら一番把握してないといけない部分のなはずなのに。
そこの言及を避けて通っていたら使われないに決まってる。
0928デフォルトの名無しさん
2011/01/07(金) 05:45:40> haskellはそこがぼやけてはっきりしない。
ハア？それはあんたが不勉強なだけでしょ・・・
0929デフォルトの名無しさん
2011/01/07(金) 07:32:15今までとは考え方を変えて勉強しなければならない時点で
普及はできないよと言いたいんじゃないかな。
俺は Haskell 大好きだし、
Haskell の表示的意味論の美しさには感動すら覚えるが、
痛いところ突かれて反論でなくとても悔しい。
でも、>>926 や >>927 は正論だと思うよ。
実用的じゃなければ、コンピュータの制御が簡単にできなければ、
流行るはずもない。
>>296
> モナドは手続き風の書き方ができるだけで
その後の書き方で君が分っているのは承知しているが、
見てる方が勘違いするともどかしいので一応言っておくと、
それは Haskell の do 記法のことね。
あと、その後の話はモナドの中でも IO モナドの話ね。
モナドスタイルなんて言葉はあまり適切じゃないな。
モナドがいかにも何か特別なプログラミング テクニックみたいじゃないか。
0930デフォルトの名無しさん
2011/01/07(金) 08:35:12だったら、Haskellの言語としての特徴を「モナド」という言葉を使わずに説明してみろよ。
そこにはMirandaが残るだけだぞ？それでいいのか？
0931デフォルトの名無しさん
2011/01/07(金) 09:30:30意味論的なゴマカシって？
imprecise exceptionが黒魔術っぽいというのなら分かるけど、その話じゃないよね
>>927
性能を考えるときに評価順序が重要なのはみんな知ってるし、Haskellの入門書でも取り上げられてるだろ
0932デフォルトの名無しさん
2011/01/07(金) 09:32:580933デフォルトの名無しさん
2011/01/07(金) 09:35:440934デフォルトの名無しさん
2011/01/07(金) 09:56:23もちろんHaskellすげーと思うし、OCamlでサンプル書いたりすることもあるけど
関数型言語メインでってのは考えられない
0935デフォルトの名無しさん
2011/01/07(金) 10:04:25OCamlの評価順が分からんというのはJavaの評価順が分からんと言うようなものじゃないか
0936デフォルトの名無しさん
2011/01/07(金) 12:03:09仕様ではシンタクティックシュガー的な言語機能について、Core と呼ばれてる基本的な機能への
変換は形式的に示されてるけど、Core そのものの形式的な定義や意味論は無かったと思うんだが。
>>930
Type Class は？
0937デフォルトの名無しさん
2011/01/07(金) 20:01:31こんなのはどう？
http://en.wikibooks.org/wiki/Haskell/Denotational_semantics
べつに公式仕様として公開されてなくても、
意味領域への変換関数がちゃんと示せるという事はわかると思う。
ただ、「言語設計者たちが考えること」でも触れられてるけど、
Haskell の表示的意味論は 100% 完全には定義されていないようだね。
100% にするのは労力に見合わないとかで。
それでも多くの機能についてまず意味論から考えて設計したそうだ。
まぁ脱線だが、この辺りでも興味深いことが語られてる。
http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/
0938デフォルトの名無しさん
2011/01/07(金) 20:19:37> それにプログラム全体で使うグローバルな手続き的変数に相当するものをモナドのスタイルで書こうとしたら
> プログラム全体を覆う巨大なモナドが必要になって後での機能追加とか削除の変更がやりにくくなる。
プログラム全体で使うグローバルな手続き的変数って何だ？
何に使うんだよ、そんなもの
0939デフォルトの名無しさん
2011/01/07(金) 23:10:52プログラミング言語なんて、誰にとっても平明
なものでなくては。
0940デフォルトの名無しさん
2011/01/07(金) 23:16:45誰得だよ？
0941デフォルトの名無しさん
2011/01/07(金) 23:17:51だから普及はしないんだろ。
0942デフォルトの名無しさん
2011/01/07(金) 23:46:110943デフォルトの名無しさん
2011/01/07(金) 23:56:03むしろ Haskell の方が平明に感じる
0944デフォルトの名無しさん
2011/01/08(土) 00:13:22どっちの視点かの問題かと。
0945デフォルトの名無しさん
2011/01/08(土) 00:26:30>Haskellのほうが思考に近い。
どちらも奇妙な考えにしか思えない。
0946デフォルトの名無しさん
2011/01/08(土) 00:30:07必要なさそうな部分はわかりたくない人は、色々見えないのが平明に感じる
0947デフォルトの名無しさん
2011/01/08(土) 00:33:060948デフォルトの名無しさん
2011/01/08(土) 00:35:30いまさらこれにケチ付けるやつが居るのが信じられん。
0949デフォルトの名無しさん
2011/01/08(土) 06:26:58ライブラリとそのドキュメントを探して機能を解釈して使うのがややこしくて困る
公理のように明快でない人工的で文系的な機能が頭に入らない
やはりネットの情報だけじゃ無理か
0950デフォルトの名無しさん
2011/01/08(土) 10:46:56Haskell の何と C の何を比べて、どの程度難しいというのだ？
0951デフォルトの名無しさん
2011/01/08(土) 10:55:41配列や文字列ごときで領域外アクセスしないように気を使うとかは本気であり得んと思う。
0952デフォルトの名無しさん
2011/01/08(土) 11:10:330953デフォルトの名無しさん
2011/01/08(土) 11:23:35領域内でも間違った場所を指すことはあるから、領域の内か外かに気を使うことはない
内なら正しいと意識するとむしろ偏見になる
0954デフォルトの名無しさん
2011/01/08(土) 11:29:59ますます難しいや…
0955デフォルトの名無しさん
2011/01/08(土) 12:07:440956デフォルトの名無しさん
2011/01/08(土) 12:10:570957デフォルトの名無しさん
2011/01/08(土) 12:15:590958デフォルトの名無しさん
2011/01/08(土) 12:18:45人間は状態機械を把握できる。問題は以下に構造化して把握するか。
その視点が致命的にない。
0959デフォルトの名無しさん
2011/01/08(土) 12:19:380960デフォルトの名無しさん
2011/01/08(土) 12:31:540961デフォルトの名無しさん
2011/01/08(土) 12:32:150962デフォルトの名無しさん
2011/01/08(土) 13:03:57> その視点が致命的にない。
ステートモナドないしIOモナドが構造化されていない、という証明を。
0963デフォルトの名無しさん
2011/01/08(土) 13:07:41比べてるだけだろ。
0964デフォルトの名無しさん
2011/01/08(土) 13:08:53お前の中の「構造化」って何なのか説明してほしいな
そして、それが関数型言語の「副作用の有るものと無いものをしっかり分ける機能」
とどう関係しているのか説明してほしい
0965デフォルトの名無しさん
2011/01/08(土) 13:11:020966デフォルトの名無しさん
2011/01/08(土) 13:18:010967デフォルトの名無しさん
2011/01/08(土) 13:52:18つまり
Lispを除くオブジェクト指向ではない動的言語
が最適である
0968デフォルトの名無しさん
2011/01/08(土) 13:58:090969デフォルトの名無しさん
2011/01/08(土) 14:00:210970デフォルトの名無しさん
2011/01/08(土) 15:00:35古典力学も量子力学も電磁気学も方程式で記述されてるけど、なんで？
0971デフォルトの名無しさん
2011/01/08(土) 15:42:37具体的に何よ
0972デフォルトの名無しさん
2011/01/08(土) 15:56:37方程式だけを記述するということは、まともに解く気がない。
0973デフォルトの名無しさん
2011/01/08(土) 17:11:230974デフォルトの名無しさん
2011/01/08(土) 17:26:120975デフォルトの名無しさん
2011/01/08(土) 17:45:41方程式自体をデータとして扱うようなコード(定理を使って簡約とか)が書きたい
項書き換え系を理論的背景とする言語だと楽かと思い
以前elanだとか他にも何個か落としてみたが、情報がなさ過ぎて。
現状一番マシなのはMaxima(Mathematicaは買えないんで)
0976デフォルトの名無しさん
2011/01/08(土) 19:14:040977デフォルトの名無しさん
2011/01/08(土) 19:30:33ttp://www.uni-koeln.de/REDUCE/
未チェックだったので今度調べてみようかな
0978デフォルトの名無しさん
2011/01/08(土) 20:36:59つ >>968
0979デフォルトの名無しさん
2011/01/09(日) 00:36:420980デフォルトの名無しさん
2011/01/09(日) 00:44:370981デフォルトの名無しさん
2011/01/09(日) 00:47:10関数型言語のHaskellが
モナドの特殊なバージョンを言語の機能としてサポートしているというだけ
それとは別に哲学にもモナドという語があります
0982デフォルトの名無しさん
2011/01/09(日) 13:58:110983デフォルトの名無しさん
2011/01/09(日) 16:42:370984デフォルトの名無しさん
2011/01/09(日) 18:37:540985デフォルトの名無しさん
2011/01/09(日) 19:34:360986デフォルトの名無しさん
2011/01/09(日) 19:43:020987デフォルトの名無しさん
2011/01/09(日) 19:48:58プログラムしてて一番面白いのは Haskell
0988デフォルトの名無しさん
2011/01/09(日) 20:09:350989デフォルトの名無しさん
2011/01/09(日) 20:34:38当然だ
仕事の悩みなんて一切考えずに、数学や計算機科学に没頭できる至福の時だよ
おもちゃとして最高のプログラミング言語だと思う
Haskell に勝るおもちゃんなんて、そうそう無いよ
0990デフォルトの名無しさん
2011/01/09(日) 22:34:170991デフォルトの名無しさん
2011/01/09(日) 23:35:040992デフォルトの名無しさん
2011/01/10(月) 00:32:20本気でそんな頓珍漢な質問をするのなら、真面目に勉強してみてくれ
そのレベルのヤツにここで説明するのは骨が折れる
どうせ説明できないんだろと言われるだろが、説明を拒む理由も分るはず
0993デフォルトの名無しさん
2011/01/10(月) 00:59:040994デフォルトの名無しさん
2011/01/10(月) 01:01:26>>987
ただし、そこまでたどり着くには何度もゲームオーバーにならなければいけないという。
もっとも今では組み込みインタプリタやCトランスレータなり資料あるから、
うまく使えばゲームオーバーの回数も減るが。
>>990
多くのマイナー言語に共通することだが、普及させたかったら良いライブラリ、
良いテキスト、豊富なサンプル、あと目標にできる人といったものが必要になる。
あとは、所詮一般人の度肝を抜くようなデモも必要。ギークのおもちゃでは普及しないよ。
HSPの言語仕様は色々負けているが、ライトユーザーを取り込めているという点では
では上手い戦略太都重う。
0995デフォルトの名無しさん
2011/01/10(月) 06:35:15度肝抜くデモも作れないと
0996デフォルトの名無しさん
2011/01/10(月) 09:32:39何かコード晒して下さい
0997デフォルトの名無しさん
2011/01/10(月) 11:25:020998デフォルトの名無しさん
2011/01/10(月) 11:28:510999デフォルトの名無しさん
2011/01/10(月) 11:36:441000デフォルトの名無しさん
2011/01/10(月) 13:09:57どんな企画でも今まで使ってて手慣れている言語、
つまり C や Java などの有名な手続き型言語のひとつを使うに決まってる。
関数型なんて頭の片隅にも入っていない。
1001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。