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

1 ：デフォルトの名無しさん：2010/10/11(月) 19:07:49

あくまで、関数型言語は何故普及しないのかをメインに考えるスレです。
このテーマの存在をどうかお忘れなきよう願います。

前スレ
　関数型言語は何故普及しないのかを考える
　http://hibari.2ch.net/test/read.cgi/tech/1277215506/l50

2 ：デフォルトの名無しさん：2010/10/11(月) 19:12:39

2ゲット

3 ：デフォルトの名無しさん：2010/10/11(月) 19:14:04

要するにオブジェクト指向の
一分野でしかないから。

4 ：デフォルトの名無しさん：2010/10/11(月) 19:18:33

前回までのあらすじ：
Haskellすげー
関数型言語でUMLみたいな図にできる設計技法はあるのか
Haskellでオブジェクト指向？
型推論いる？いらない？そもそも型推論ってなに？
関数型言語でGUIとかやりにくい？→いやFudgetとか関数型言語向きのGUIライブラリがある
SIerはゴミ糞
プロセス指向があればオブジェクト指向いらない
関数型言語はプロセス指向に適している

5 ：デフォルトの名無しさん：2010/10/11(月) 19:19:34

>>3
せっかくお給料アップのために無理してやっと覚えたオブジェクト指向を否定されたくないんですよね。

6 ：デフォルトの名無しさん：2010/10/11(月) 19:21:49

ああ、オブジェクト指向すらなかなか覚えられない下流プログラマかｗ

7 ：デフォルトの名無しさん：2010/10/11(月) 19:27:28

前スレ>>990
あなたコード読んでないでしょ。
それ以前にひょっとして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'});

8 ：前スレ ◆st4kIyCS7. ：2010/10/11(月) 19:27:30

>>1乙

(前スレ #989 の続き。)

で、構造不一致の問題は関数指向設計技法でも同様に発生する。これに対する挑戦(研究)はいくつか
あるらしいが、たとえば自分が知っている文献を以下に紹介。(どちらも同じ著者陣による報告)

・関数スキーマベースを用いたソフトウェア設計自動化(1985) -- 情報処理学会論文誌
　　http://ci.nii.ac.jp/naid/110002724012
・ソフトウェア設計自動化のための仕様記述言語 F(1986) -- 情報処理学会論文誌
　　http://ci.nii.ac.jp/naid/110002724187

注目は後者の「仕様記述言語 F」。詳細は論文を読んでもらうとして、
入力集合(定義域)から出力集合(値域)の対応として単純な関数ではなく、
関数を関数に写像する「関数結合子(function combinator)」を用いている。
さらに関数結合子と定義域/値域との正当な対応(組合せ)について考察している。
なにしろ1986年という古い研究で、その後の継続報告は見つけられないけど、
今なら、このきれいに形式化された課題をカテゴリ(圏論)の視点で、
言い換えると、机上の理論で終わらせずにHaskellプログラミング技法の一つとして
再検討できるんじゃないかと妄想している。(あまりにもったいない研究成果に思える。)

(更に続く。次で終わり。)

9 ：デフォルトの名無しさん：2010/10/11(月) 19:27:31

手続き型＝関数型

10 ：前スレ 475：2010/10/11(月) 19:29:44

(>>8の続き。)

また、この研究では、(入出力がファイルではなく)メモリ上のデータ構造を暗黙的に仮定している。
もしもすべてのデータ(直積/直和/列)がメモリ上にあることを前提とできるならば、豊富な関数群を
いかに適用すればいいか、それだけを検討すればいいけど、現実のバッチ処理というのは
数万件のレコードを含む複数のファイルを処理の対象としている。これは単純に言えばI/Oモナドなのだろうけど、
I/Oモナドと他の結合子(コンビネータ)との正当に一致する組合せについても検討が必要になってくるだろう。
言い換えると、関数間の結合を床下配線として隠すのが関数結合子であるのなら、それら関数結合子同士の
結合を床下配線として隠すことができる、高階関数結合子の型体系を検討しなければならない気がしている。

なお、何度も書いているけど、モナドやアローを含む圏論については勉強中の身。
誤解や勘違いもあるはずで、モヤモヤした「妄想」を吐き出しただけの文章だけど、それを承知でコメントを請う。

(これで終わり。PS. 用事で外出するので、もしレスするとしたら深夜になると思う。)

11 ：デフォルトの名無しさん：2010/10/11(月) 19:34:36

プロセス指向って、オブジェクト指向のオブジェクトの
形を変えただけにしか見えないよな。

どうみても、ネットワーク通信の
コードと同じように見えるんだがｗ

データ受け取って、値を返す。コレ↓
http://x68000.q-e-d.net/~68user/net/echo-2.html

12 ：デフォルトの名無しさん：2010/10/11(月) 19:35:35

新たな説が登場しました！

スレッドプログラミング＝プロセス指向・関数型言語

13 ：デフォルトの名無しさん：2010/10/11(月) 19:37:29

ただのスレッドプログラミングとプロセス指向の違いが理解出来ないとはなぁｗ

14 ：デフォルトの名無しさん：2010/10/11(月) 19:38:27

名前が違うだけだろ？ｗ

15 ：デフォルトの名無しさん：2010/10/11(月) 19:41:51

>>14
http://venus.is.s.u-tokyo.ac.jp/kobalab/kadai99/picalc.html
これを読んでからもう一度質問してください

16 ：デフォルトの名無しさん：2010/10/11(月) 19:46:50

これがプロセス指向らしい・・・
sub neko {
　my $q = shift or die $!;

　return threads->new(sub {
　　my $namae = '';

　　while (1) {
　　　my $message = $q->dequeue();

　　　if ($$message{command} eq 'namae') {
　　　　$namae = $$message{namae};
　　　　print "命名：$namae\n";
　　　} elsif ($$message{command} eq 'nake') {
　　　　print "にゃーにゃー\n";
　　　} elsif ($$message{command} eq 'nero') {
　　　　print "$namaeが寝ます。\n";
　　　　sleep(3);
　　　　print "$namaeが起きました。\n"
　　　} elsif ($$message{command} eq 'sine') {
　　　　print "$namaeが死んでしまいました\n";
　　　　last;
　　　}
　　}
　});
}

↓オブジェクト指向風に書き直すと

17 ：デフォルトの名無しさん：2010/10/11(月) 19:47:32

↓オブジェクト指向風に書き直すと

sub 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;
　　}
　});
}

18 ：デフォルトの名無しさん：2010/10/11(月) 19:55:30

プロセス指向ってJavaScriptかぁ！

19 ：デフォルトの名無しさん：2010/10/11(月) 19:58:18

やっぱり、言語としてはオブジェクト指向で、
パターンの一つにしか見えんのだよな。

20 ：デフォルトの名無しさん：2010/10/11(月) 20:03:37

>>17
それ動かないぞ。

21 ：デフォルトの名無しさん：2010/10/11(月) 20:05:28

高卒プログラマーの怨念

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

perlわからないなら分からないでいいから、本当の事をいってほしい。
わかる言語で書くようにするから。

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

>>20
こういう感じという例だよ。何が足りないかぐらい分かるだろ？

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

>>22
じゃあ、オブジェクト指向言語のJavaでお願いｗ
そうすれば、パターンの一つに過ぎないとはっきりするからね。

25 ：デフォルトの名無しさん：2010/10/11(月) 20:15:32

「There's more than one パターン」
デザインパターンの最終兵器

26 ：デフォルトの名無しさん：2010/10/11(月) 20:42:03

>>15読んでくれた？

27 ：デフォルトの名無しさん：2010/10/11(月) 21:16:18

>>26

>>15 と http://en.wikipedia.org/wiki/Process-oriented_programming 読ん
でみたけど、同じプログラミングパラダイムについて書いてあるのか分からな
い。

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

プロセス指向パターンのJava実装まだ？

29 ：デフォルトの名無しさん：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++は手続き型プログラミング、ジェネリックプログラミング、
> オブジェクト指向プログラミングに対応するよう設計されているが、設計時には個々の部分毎に
> どのパラダイムを使うか選ぶ必要に迫られる。あるプログラムは全て手続き型プログラミングで作り、
> またあるプログラムは全てオブジェクト指向で作り、また別のプログラムは両方を混在して作るという具合である。

30 ：デフォルトの名無しさん：2010/10/11(月) 22:51:53

>>29
手続き型プログラミング、ジェネリック（テンプレート）プログラミング、オブジェクト指向プログラミング
この三つは全く別のクラスの概念だから混在はなにも障害ないはず。

31 ：デフォルトの名無しさん：2010/10/11(月) 22:58:58

へ？なにとなにが同じクラスだというの？

32 ：デフォルトの名無しさん：2010/10/11(月) 23:08:51

>>10
あなたの説明では、帳票印刷パッケージで
代数や圏論の概念の正確な理解が必要な理由になっていない。
単に関数指向設計技法の提案でしかない（それも曖昧だが）。

Gtk2Hs には ListStore というウィジェットがあり、
それを使えば所謂グリッドビューを表示できる。
HackageDB にはデータベースへ SQL でアクセスするライブラリもある。
都合の良いデータ構造（コンテナ）もライブラリとしてある。
たいていの Haskell プログラマは、それらの使い方を理解すれば、
帳票を扱うプログラムは組める。

その時にあなたの言う関数指向設計技法が大いに役立つかも知れんが、
無くてもプログラムできる。
少なくとも、グレープシティのようなライブラリを作る側ではなく、
ライブラリを利用する側である大多数のプログラマにとっては
それで十分アプリは作れる。

あなたのように「数学やソフトウェア工学などの理解がないとアプリが作れない」
と思い込んでいる人たちがそう触れ回っているために、
関数型は難しいんだ、アプリは作れないんだと萎縮してしまう人が多いんだよ。

33 ：デフォルトの名無しさん：2010/10/11(月) 23:17:01

前スレで、圏論の知識がないと自分でモナドを設計できないという話があったけど、
素人でも簡単に目的に見合ったモナドを作るためにモナド変換子ライブラリがある

34 ：デフォルトの名無しさん：2010/10/11(月) 23:21:02

圏論の知識なんかいらねーｗ
モナド則だけ知ってればHaskellのモナドは完璧だｗ

35 ：デフォルトの名無しさん：2010/10/11(月) 23:22:35

vipでやれ

36 ：デフォルトの名無しさん：2010/10/12(火) 00:57:10

ルービックキューブの解法を説明するのに群論云々言うのと同じで、
間違っちゃいないが九割九分はハッタリにすぎん

37 ：デフォルトの名無しさん：2010/10/12(火) 02:27:04

理論的な裏付けがあるのは良いことでしょ
ただ、別に操作的意味論とかを知らなくてもC言語は使えるし教育もできるのと同様、
圏論を使わなくても「モナドはモナド」として説明できるべきだと思う

38 ：前スレ 475：2010/10/12(火) 02:42:26

>>32
>単に関数指向設計技法の提案でしかない（それも曖昧だが）。

>>8,10で書いたのは、関数合成の自動生成法に関する妄想であって、関数指向設計技法ではないよ。
関数指向設計技法は(前スレ>>989で書いた)以下のように曖昧なもの。

>（２）副関数群への分解手順(アルゴリズム)について、JSP法の考え方に沿って(JSP法を模倣して、あるいは
>　　　JSP法の用語を使って)、指導者が普通のプログラマへ説明する

だから技法(テクニック)でしかない。構造不一致問題に対しては、今まで通り、プログラマの持つ
プログラミング知識を前提にした、経験と勘による手法で対応するしかない。
ただ、それだけであっても「静的関数型言語の持つ(型推論のような)優れた特性があれば、
上流設計工程における品質の向上というソフトウェア工学上の利点は十分に得られる」はずだよね、というのが
前スレで書いた関数指向設計技法の要旨。

で、そんな静的関数型言語の持つ優れた特性は、(Haskellのように実行順序が定まらずモナドに頼らなければ
入出力すらまともに書けない非正格な関数型言語でなくても、)F#やSMLのような正格な言語にも備わっている。
事務系処理で本質的に無限リストが必要になるケースなんてほとんど無いんだから、正格な言語で十分。
しかもF#やSMLなどであれば、明示的な可変宣言をすれば副作用を許容しているのだから、初学者には、
（１）まず手続き型言語で学んだ普通の(副作用だらけの)アルゴリズムで設計し、
（２）関数型言語の学習を進めていく課程でmap/filter/遅延ストリームのような技法を習得することで
　　　（１）のアルゴリズムを徐々に改善していく
といった指導法を採ることができる。これなら業務用パッケージ/コンポーネントが整備されすれば、
今すぐにでも「関数型言語を普及させる(=従来の手続き型言語を置き換える)」提案を進められる。
(だから、Windowsでは特に、F#は急速に普及していく潜在的可能性があるだろうし、今すぐにでもお勧めしたい)

(長いので続く)

39 ：デフォルトの名無しさん：2010/10/12(火) 03:16:30

(と思ったが、ニートと思われるのがイヤだから続きは明日にする)

40 ：デフォルトの名無しさん：2010/10/12(火) 07:34:35

>>38
質問に答える気はないのですか。

あなたが最初に例として挙げた帳票印刷パッケージという具体例では、
圏論などの難しい概念を正確に理解しないと作れない理由を
説明できないのですね。

もしかして帳票印刷パッケージを関数型で「作ろうとしてみた」経験もなく、
妄想だけで、圏論を理解しないと作れないと適当に言ってみただけですか。

最後にもう一度訊きます。
あなた自身が最初に例として挙げた帳票印刷パッケージで、
圏論などの難しい概念を正確に理解しないと作れない理由を
説明してください。

説明する気がないのなら、もういいです。

41 ：デフォルトの名無しさん：2010/10/12(火) 09:26:28

いいからだれか圏論をつかわずにモナドとアローの説明とそれを使えばこんなナイスなことが出来るってのを教えてたもれ(´・ω・｀)

42 ：前スレ 475：2010/10/12(火) 09:53:29

>>38の続きを書こうとしましたが、レスがあったので、そちらについて先にカキコします。

>>32
>たいていの Haskell プログラマは、それらの使い方を理解すれば、
>帳票を扱うプログラムは組める。

これに関しては、前スレの>>935で書いたけど、(サードパーティ等の他社が提供する)
帳票印刷用のライブラリが存在していれば、もちろんHaskellでも「帳票を扱うプログラムは組める」から、
同意します。

(続く)

43 ：前スレ 475：2010/10/12(火) 09:55:55

(>>42の続き)

>>40
帳票印刷パッケージは単なる例だけど、こういった業務用パッケージ/コンポーネントというのは、
過去からの膨大なコード資産があって、一から新規作成するケースは少ない。
たとえばC++で書かれた帳票印刷パッケージ、C#で書かれたバーコード表示コンポーネント、...etc、
これら一つ一つについて、関数型言語向けにカプセル化する必要があります。
（この話は帳票を扱う業務アプリ開発(プログラミング)ではなく、帳票印刷パッケージそのものの
　開発に関する話だから、誤解/混同しないで下さいね。念の為。）

このカプセル化を設計する時に、単にIOモナドを使うだけで済ますのか、あるいは
その上にもう一皮被せた独自のモナドで実装するのかは、case-by-caseだと思います。
ただし、一般に帳票というのは、そのデザイン(定義)が面倒なもので、それに加えて業務単位に類似性のある
複数の帳票を定義するといった事柄が要求されます。だから、帳票印刷パッケージには、
その手間(ユーザの負担)を減らすために、使い易いUI、定義の差分記述やモジュール化といった
多くの機能要素から構成されます。他にもエラー回復(紙づまり/用紙切れ)や印刷スプール管理といった
帳票定義以外の機能も一緒に提供されます。ただ単に「帳票を定義して印刷する」だけじゃ済まんのですよ。

そして、それら機能設計の優劣が他社製品との差別化(セールスポイント)に直結するわけですから、
各社とも必死に設計/開発するわけで、低レベルな印刷APIを単純なIOモナドで操作するだけでは済まず、
おそらく個々の機能要素(関数)を柔軟かつ正確に結合できる独自のモナドを設計しようとすると思うんです。
で、その時に、前スレの>>971で書いてくれたような「IOモナドを使えばIOとの入出力ができる。
印刷ライブラリも呼べる。」といったモナドの知識、あるいはいわゆる一般的な「モナド則」だけを
知っていさえすれば設計できるものなのか？という疑問です。とうてい可能とは想像がつかないんですけど。

(まだ続く)

44 ：前スレ 475：2010/10/12(火) 09:57:03

(>>43の続き)

>もしかして帳票印刷パッケージを関数型で「作ろうとしてみた」経験もなく、

ええ、Haskellを業務開発に適用するなんて想定していませんから、そんな経験はありませんよ。
ただし、C++で書かれたある軽量でマイナーなGUIライブラリをGoferで使えるようにしたくて、
TkGoferのソースやペーパーを読みあさりました。その結果、TkGoferがどう動いているかは
イメージを持てたのですけど、いざGUIライブラリ向けのGUIモナドを設計しようとした段階で
挫折した経験ならあります。単なる自分のプログラミング能力不足が主な原因なんですけどね。
で、基本に立ち返って、代数の勉強からやり直している、というのが現状です。

(これで終わり)

45 ：デフォルトの名無しさん：2010/10/12(火) 10:03:50

>>43
わかりやすい説明だね。

46 ：前スレ 475：2010/10/12(火) 10:32:18

(中断していた>>18の続き)

これがHaskellであれば、今まで培ってきた手続き型言語の知識を捨て去って、一から関数型言語の
プログラミング技法を習得する必要がある。勘違いしやすいのは、
・Haskellプログラマ --> 「モナドを使えば副作用が実現できる(= be can)」なのに対して、
・普通のプログラマ --> 　入出力やステートマシンなんて手続き型言語や正格関数型言語であれば、
　　　　　　　　　　　　ごく自然に(直感的に)記述できるけれど、Haskellでは
　　　　　　　　　　　　「同じ事をしたいだけなのに、モナドを使わなければならない(= be must)」
という認識が、現実であるということ。
モナドは負の要素であり「本来は不要だけれども、しかたなく使わざるをえない」仕掛けである事を忘れてはならない。
これが「Haskellが(現時点で)普及していない」し、「Haskellが数年のうちに普及することは有り得ない」という主張の理由。

この「モナドは負の要素でしかない」という切り口(視点)を「モナドは正の要素である(=モナドでなければ実現できない)」
という世界へと逆転させる潜在的可能性の曖昧な模索が、>>8,10で書いた妄想。妄想は妄想であって、今はまだ現実じゃない。
ただ、こういった高度に抽象化された対象、言い換えると、時間の経過や状態の変化が存在しない数学の世界を扱うには、
(「評価順序が定まらない」のではなく)評価順序を考慮せずにアルゴリズムを定義(記述)できる
Haskellのような非正格関数型言語に絶対的な優位性があるはず。また、>>10ではI/Oモナドについて書いたけど、
処理対象がメモリであってもファイルであっても統一したインターフェイスを提供できるのが、
非正格関数型ならではの(=非正格関数型でなければ実現できない)利点ではなかったのか？と思う。
（Haskellや圏論については勉強中だから、間違った推測かもしれないけど....。）

47 ：デフォルトの名無しさん：2010/10/12(火) 10:39:53

3行で

48 ：前スレ 475：2010/10/12(火) 10:39:58

自己レスで>>46を訂正。先頭行(継続元レス)のアンカ>>18は間違いで、>>38が正しい。

49 ：前スレ 475：2010/10/12(火) 10:44:20

>>47
手続き型言語や正格関数型言語なら入出力や変数値を何の迷いも無く素直に書けるのに、
なんでHaskellだとわざわざモナドとやらを使わないと表現できねえんだYo!!
ただ単に面倒なだけじゃん。F#やSMLで十分でそ。Haskellの出番なんてネーヨ。

50 ：デフォルトの名無しさん：2010/10/12(火) 10:57:54

Haskellなら無限リストを何の迷いも無く素直に書けるのに、
なんで面倒な非純粋言語を使わなきゃならないんだYo!!

51 ：前スレ 475：2010/10/12(火) 11:18:26

>>50
>事務系処理で本質的に無限リストが必要になるケースなんてほとんど無いんだから、正格な言語で十分。(>>38)

52 ：デフォルトの名無しさん：2010/10/12(火) 11:28:26

何の迷いもなくirrefutableパターンとかlazyパターンとかを使う方法を教えてください

53 ：前スレ 475：2010/10/12(火) 11:50:03

そのパターンというのは、(たとえばJavaのような)手続き型言語であれば、誰でも何の迷いもなく書けるものなのか？

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

基本手続き型な俺でも無限リストは便利だなと思う。
ただ手続き型でもちょっと捻れば書けちゃうのが残念。
「これは関数型じゃないと書きにくいぞ」ってのが欲しいなあ。

55 ：デフォルトの名無しさん：2010/10/12(火) 12:03:51

無限リストって普段から使うけどなぁｗ
例えばトリップ検索するという例では、
トリップの無限リストを作ってから順次比較していくとか、そういう使い方をする。

56 ：デフォルトの名無しさん：2010/10/12(火) 12:11:03

いや関数型的には確かに普段使いなんだけどね。

手続き型でも「ゼロから初めて1加えつつ順次比較していく」と置き換えると
大概の用途は間に合ってしまうんよ。
それは手続き型では割と書きやすい部類の処理だ。

若干直感的ではない書き方だとは思うのだが
慣れてる人間にとっては目から鱗になるほどのインパクトは無いんよね。

57 ：デフォルトの名無しさん：2010/10/12(火) 12:14:55

>>56
そんなモッサイやり方はクールな俺にはできないね。

58 ：デフォルトの名無しさん：2010/10/12(火) 12:43:15

無限リストって手続き型だとiterator/generatorじゃないの？
手続き型でもC#やPythonのようにyieldある言語なら特に問題なく容易に使えるし
実際使われていると思う

yieldない言語だと、湯水のように使われることはなさげ

59 ：デフォルトの名無しさん：2010/10/12(火) 12:53:39

>>42
では、ライブラリがあれば普及できるのではないか。
VB が普及できた大きな理由の一つでもある。
圏論などはライブラリ作成者や、フレームワーク作成者が考えることであって、
普及の担い手である一般プログラマには「普及のためには」不要だ。

>>43
> この話は帳票を扱う業務アプリ開発(プログラミング)ではなく、帳票印刷パッケージそのものの
>　開発に関する話だから、誤解/混同しないで下さいね。念の為。

あなたは、バーコード印刷と帳票印刷パッケージを同列に扱っていたように見えたが。

>>44
> ええ、Haskellを業務開発に適用するなんて想定していませんから、そんな経験はありませんよ。

一度で良いから、途中までで良いから、仮想の帳票パッケージなり
バーコード印刷なりを Haskell で組んでみる事を勧める。
モナドが負の要素と言っている事が如何に的外れかが分かる。
帳票パッケージを作るのにあなたが恐れるほどモナドで苦労することはないと分かる。

そして机上の理論だけではなく、自分で組んでみて「実感した」問題点を挙げ、
関数型の普及の話と絡めてくれ。

60 ：デフォルトの名無しさん：2010/10/12(火) 13:31:50

>>58
yieldがないならThread::Queueを使うと昨日からさんざん言われてるのに
少しは学習しろよ

61 ：デフォルトの名無しさん：2010/10/12(火) 13:39:06

>>60
ごめん、スレに書き込むのはじめてなので……昨日のレスとか全然読んでなかった
Thread::QueueってPerlの話？
それは「可能なだけ」で、言語組み込みのyieldと違って、その言語のユーザが
普通に水や空気のように使うことはないのでは

それにThread::Queueとか言わなくとも、ファーストクラスの関数があれば
unfoldがとても簡単に簡単に書けると思う
Javaなどの場合はファーストクラスの関数はないので、Function2<S, T, R>とかいう
クラスを捏造するんだろうけど

62 ：デフォルトの名無しさん：2010/10/12(火) 13:43:25

>50
シーケンスでやれば正確でも楽にできるyo

63 ：デフォルトの名無しさん：2010/10/12(火) 13:55:15

関数型言語のテストって副作用を考えなければずいぶんらくだよな～。
ステートマシンの良いテスト方法はないものか。

64 ：デフォルトの名無しさん：2010/10/12(火) 15:31:23

>>58
別にそんなもん使わなくてもfor文で十分だよｗ

65 ：デフォルトの名無しさん：2010/10/12(火) 15:50:47

>64　アホすぐるｗｗｗ

66 ：前スレ 475：2010/10/12(火) 18:41:22

>>59
>では、ライブラリがあれば普及できるのではないか。

話がループしています。繰返しになりますが、業務用の部品(ライブラリ/パッケージ/フレームワーク)が
豊富に流通していたからこそ、VBやC#が業務アプリ開発分野市場で成功を納めている訳ですが、
その「業務用部品の開発にはHaskellは適さない」という理由を、長々と説明してきたつもりなんですが。

>圏論などはライブラリ作成者や、フレームワーク作成者が考えることであって、

ライブラリ/フレームワーク作成者のようなシステムプログラマには、
圏論の正確な理解が必須であることを理解して頂けたようで、嬉しく思います。

>普及の担い手である一般プログラマには「普及のためには」不要だ。

業務用部品が整備されれば、VBやCOBOLのような業務アプリ開発言語をHaskellで置き換えが可能でしょう。
そして、それら部品(COMサーバ)の多くはC/C++で開発されているわけですが、
その部品開発には、手続き型言語や(F#/SMLといった)正格関数型言語を使えば良いという理屈と解釈できます。

言い換えると、普及の担い手である(圏論を正確に理解できもしない)一般のプログラマにとって、
・Haskell --> VBやCOBOLと同様に、「アプリ開発にしか(= only)」適用(普及)できない言語であり、それに対して
・F#やSML --> CやC++と同様に、「ライブラリ/フレームワーク開発にも(= all-round)」即対応(普及)可能な言語である
と結論付けられます。このような解釈でよろしいでしょうか？

(続く)・

67 ：前スレ 475：2010/10/12(火) 18:46:00

(>>66の続き)

>帳票パッケージを作るのにあなたが恐れるほどモナドで苦労することはないと分かる。
>そして机上の理論だけではなく、自分で組んでみて「実感した」問題点を挙げ、関数型の普及の話と絡めてくれ。

>>44で書いたように、自分でGUIモナド設計を試みた(そして挫折した)経験はあります。
その課程で「実感した問題点」とは、
・ウィジェット(GUI部品)の正当な組合せ(組み立て)方法を厳密に定義し、
・それらを圏論の枠組みの中で再構築する
能力がプログラマには求められる事です。(モナドでなければ、ある程度のルーズさは許容されるんですけどね...)
例えると、言語処理系(インタプリタやコンパイラ)の設計者には形式言語の正確な理解が必須であり、
対象となる言語の文法を厳密に定義したうえでＢＮＦとして表現する能力が求められるのと同じです。

そして、出した結論が、(何度も繰り返しになりますけど、自分を含む)数理や情報工学の専門家ではない
　　【＊＊＊一般のプログラマに普及するのはF#やSMLといった正格関数型言語である＊＊＊】
というものです。(>>38,46,49)
・
ただ単純に「現実世界の開発現場でもHaskellは普及できる、やってみれば分かるハズだ」という主張を
繰り返すだけでは、似非キリスト教神父の語る陳腐な台詞と、何ら変わりはありませんよ。

　　「アナタハ神ヲ信ジマスカ？信ジル者ハ救ワレマス。スベテハ神ヲ信ジル事カラ始マリマス。」

あなたの実体験を元に、Haskell信者ではない一般のプログラマが理解できる言葉/表現方法で、
いかに「モナドが正の要素であるか」について、具体例挙げて説明してください。お願いします。

68 ：デフォルトの名無しさん：2010/10/12(火) 19:16:35

blogでやれよー

69 ：デフォルトの名無しさん：2010/10/12(火) 19:25:21

なんか長くて読む気なくす

70 ：デフォルトの名無しさん：2010/10/12(火) 19:26:58

>>66
業務用「部品」の開発に無理して Haskell を使う必要はないだろ。
俺もさっきから「ライブラリを使う」と言ってる。
>>32 でもライブラリを組み合わせる例を挙げた。

GUI でも別の言語で作ったライブラリを Haskell でラッピングしたものを使って、
問題なく組み立てることが出来る。

GUIモナド設計を試みる必要はないんだよ、既にあるんだから。
試みるべきは、既存のライブラリによる帳票パッケージの作成だ。

ライブラリを組み合わせるのに必要なモナドなどの知識は、
あなたが恐れるほどのものではない。

Haskell が普及しないのは、そういった個々のライブラリの使い方と、
ライブラリ同士の組み合わせ方、つまりテクニックを教えないからだよ。
これを理解すれば、規模にもよるが色んなアプリが意外にサクツク作れる。

たぶん、普及の兆しは業務よりも趣味から始まる。
趣味プログラマに広まれば、業務ライブラリも整備される。

71 ：デフォルトの名無しさん：2010/10/12(火) 19:29:43

業務アプリとか、常に技術を後追いしている業界でイノベーションなんかありえないだろｗ
低収益率のチープ産業に何かを求めるのは間違い。

72 ：デフォルトの名無しさん：2010/10/12(火) 19:45:11

>>67
その思い込みの強さと、不適切な言葉遣いは前スレと変わらんな。

73 ：デフォルトの名無しさん：2010/10/12(火) 19:52:38

>>66も>>70も前提がおかしいよ
Haskellのライブラリを書くのに圏論の知識が必要なんてことはない(もちろん圏論用のライブラリを除いて)
GUIみたいな「実際的」な分野ならなおさら
モナドを作りたいときは既存のモナド変換子の組み合わせで事足りるし、それも自信がなければ生のIOモナドを使って何も問題ない
モナドの形で提供するのは利便性のために過ぎないんだから

>>66が挫折したのは、モナドで表現すべきでないものを無理矢理モナドにしようとしているからに見える
そもそも、Haskellライブラリだからって関数的でかっこいい設計じゃないといけないなんて決まりはない
難しいなら妥協して「まるで手続き型言語のような」ライブラリを書けばいいし、Haskellはそれができるように設計されてる

74 ：デフォルトの名無しさん：2010/10/12(火) 20:00:23

>>67
> ただ単純に「現実世界の開発現場でもHaskellは普及できる、やってみれば分かるハズだ」という主張を
> 繰り返すだけでは、似非キリスト教神父の語る陳腐な台詞と、何ら変わりはありませんよ。

そうか？
前スレでモナドうざいとか言ってた人は、
Fudgets という「ライブラリ」の存在を教えたら
「自分で調べて」モナドうざいを取り消してくれた。
調べれば分かるはずだと直接言ってはいないが、
似たようなモンだと思う。

今回も、ライブラリを組み合わせればできると言えば、
あなたほどの方なら自分で調べて可能性を検証してくれると思ったが、
思い過ごしか。

> あなたの実体験を元に、Haskell信者ではない一般のプログラマが理解できる言葉/表現方法で、
> いかに「モナドが正の要素であるか」について、具体例挙げて説明してください。お願いします。

モナドが負なのか正なのかと考える、それが的外れだと言っている。

>>73
そうだな、よく考えればライブラリやフレームワーク自体を作るのにも、
圏論などは必要ないかもしれん。

75 ：デフォルトの名無しさん：2010/10/12(火) 20:11:39

>>70
ROMしてましたがちょっと突っ込ませてください。
Haskell以外で帳票パッケージが書けるのは当たり前の話で、議論しているのは
Haskellで帳票パッケージを書くには代数や圏論の概念の正確な理解が必要か、でしょう。
>>43のHaskellで書くにはモナドの知識だけでは不十分という説明に異論はないのでしょうか？

76 ：デフォルトの名無しさん：2010/10/12(火) 20:19:22

>>75
> Haskellで帳票パッケージを書くには代数や圏論の概念の正確な理解が必要か、でしょう。

違う。
Haskell が普及しないのは帳票パッケージを作るのに圏論が必要だからか？だよ。

で俺は、必要ない、なぜならライブラリがあるから、と言った。

77 ：前スレ 475：2010/10/12(火) 20:21:29

>>70
>Haskell が普及しないのは、そういった個々のライブラリの使い方と、
>ライブラリ同士の組み合わせ方、つまりテクニックを教えないからだよ。
>これを理解すれば、規模にもよるが色んなアプリが意外にサクツク作れる。

その通りだと思います。そんなアプリケーション開発テクニック(技法)が確立して、
それが一般に広まって常識化すれば、おそらく大規模開発プロジェクトにもHaskellは普及するでしょう。
問題は、そのテクニック(技法)の確立/常識化がいつになるのか？いつまで待てばいいのか？という事です。

OOPの場合を振り返れば、日本でSmalltalk-80が登場したのが1980年代の前半で、
その当時は、オブジェクトって何？クラスはどうやって設計すればいいの？という否定的な反応が一般的でした。
それが変化したのが、ランボーのOMT本(オブジェクト指向設計技法)が出版(1992年)と、それに続く
GoF本(デザインパターン)の出版(1995年)です。そして、ようやく今ではOOPはプログラマの常識となりました。
Haskellの普及も、同じような時間的スケールで進展していくのではないかと思います。

78 ：デフォルトの名無しさん：2010/10/12(火) 20:23:08

Haskellのモナドを理解するのに圏論の予備知識など全く必要ないのに、
ことさら圏論とのかかわりを小難しく論じていい気になってる人がいるよね
returnと>>=だけ理解すりゃいい極めて単純な原理を、
何でわざわざ偉そうに解説してみせる必要があるんだろう

79 ：デフォルトの名無しさん：2010/10/12(火) 20:32:15

圏論は期待してたんだけど全然使えない
特殊性を内包した時点で完結してしまってる
無から有を生む力がなくて、現実に目を向ける力を奪うだけ

で、関数型言語が普及しないのは、実行ファイル作れないからじゃないかな
Vectorに登録したって、誰も使う環境もってないだろうし、そのためにだけ入れる気にもならないだろう

80 ：デフォルトの名無しさん：2010/10/12(火) 20:37:14

>>79
>で、関数型言語が普及しないのは、実行ファイル作れないからじゃないかな
この誤解が酷すぎて前半の意見まで説得力を失うぞ
調べればocamlcやGHCがすぐ見つかるだろうに

81 ：前スレ 475：2010/10/12(火) 20:37:18

>>73
>モナドを作りたいときは既存のモナド変換子の組み合わせで事足りるし、それも自信がなければ....(snip)

ズバリな指摘です。「既存のモナド変換子の組み合わせ」が(当時の自分では)上手くできなかったのが、挫折の原因でした。

>そもそも、Haskellライブラリだからって関数的でかっこいい設計じゃないといけないなんて決まりはない
>難しいなら妥協して「まるで手続き型言語のような」ライブラリを書けばいいし、Haskellはそれができるように設計されてる

そうであれば、最初から副作用を許容する正格関数型言語(F#やSML)を使えばいい、という話になりますよ。

どうせHaskellでライブラリを設計するんなら、宣言的で視覚的なイメージ(床下配線？)が湧き易い、言い換えると、
利用者にモナド・モナド・モナド...を強いらせない関数的なGUIライブラリ設計をしたくなるのが技術者心情ってもんです。

82 ：デフォルトの名無しさん：2010/10/12(火) 20:39:03

>>79
あんた釣りだろｗｗｗ

83 ：デフォルトの名無しさん：2010/10/12(火) 20:41:03

>>78
Haskellは関数型言語研究のための土台として作られたのだから
理論面について話題にする人が多いのは当たり前でしょう。
あなたが自分には関係ないと無視すればすむ話です。

84 ：デフォルトの名無しさん：2010/10/12(火) 20:42:40

>>80
いやexeむりだろそれ

85 ：デフォルトの名無しさん：2010/10/12(火) 20:45:25

ＧＨＣはいけるのか

86 ：デフォルトの名無しさん：2010/10/12(火) 20:46:57

てかHaskell前提なのか

87 ：デフォルトの名無しさん：2010/10/12(火) 20:52:20

>>77
> 問題は、そのテクニック(技法)の確立/常識化がいつになるのか？いつまで待てばいいのか？

確立/常識化するまで何で待ってるの？
今でもライブラリを組み合わせてアプリを普通に作れるよ。
あなたが調べようとしないだけ。

後の世から見れば、たいそう拙い組み合わせ方かも知れんが、
少なくとも今、趣味レベルのゲームを作ったり、帳票を扱ったり、
何かを印刷したり、チャートを表示したり、ソースエディタを作ったり、
そういった事をするために、みんなライブラリを組み合わせてるよ。

問題は、方法はソースを見れば分かる、という段階で止まってる事だよ。
作者がそのテクニックを発信する事がほとんどない。
だから、入門書なんかで教える必要がある。

＊＊法とか言って名前を付けて確立しなくても、
入門書で色々な小粒テクニックを紹介して、
そのテクニックでこういうアプリが作れるよと教えれば、利用者は増えるよ。
逆に、今それが無いから普及しないと思う。

少なくとも、圏論なんかを理解させるよりも余程いい。
圏論理解させてもアプリが作れるわけじゃないから、
圏論を理解しないことが普及しない理由だとはとうてい思えない。
圏論の理解より、アプリを作るためのライブラリの組み合わせ方の方が、
多くのプログラマ入門者（この人経ちも大きな普及の担い手）には魅力的だよ。

いい加減自分の発言も自分でウザく思えてきたから、もうこの議論から逃げる。

88 ：前スレ 475：2010/10/12(火) 21:00:41

>>74
>前スレでモナドうざいとか言ってた人は、
>Fudgets という「ライブラリ」の存在を教えたら
>「自分で調べて」モナドうざいを取り消してくれた。

あ、それは自分です。Haskellにはモナドを使ったGUIライブラリしか存在しないもんだと思い込んでいましたので、
(モナドを使わずに関数結合子をストリーム指向で実装した)Fudgetsの存在は以外であり喜びでした。
だから「Haskellにはモナドを使ったGUIライブラリしか存在しない」という発言は、自分で取り下げました。
でも「モナドそのものが負の要素」という立場には、何の変化もありません。
そのレスで書いたように、(モナドを使わずに)ストリーム指向で関数を結合したFudgetsは(自分でも)理解しやすかったのに、
Fudgetsの開発が中断したままになっているのは、残念でなりません。(機会があれば自分で挑戦してみたいんですけどね....。)

>モナドが負なのか正なのかと考える、それが的外れだと言っている。

それは>>49(>>38,46)の指摘に対するレスになっていませんよ。
(モナドを「使う」レベルにはHaskellを知ってる)自分が、他人にHaskellを勧めようとして(= Haskellの普及を考えて)、
>>49のような反応をされたら、自分じゃ上手く説明できそうにありません。もし可能であれば、具体的な説明を願います。

89 ：デフォルトの名無しさん：2010/10/12(火) 21:10:44

>>81
>そうであれば、最初から副作用を許容する正格関数型言語(F#やSML)を使えばいい、という話になりますよ。
なんでそうなる？
遅延評価や「関数型っぽい格好良さ」を抜きにしても、Haskellには魅力的な点がたくさんある
一番目立つのは型クラス

>>84
ごめんocamlcじゃなくてocamlopt

90 ：前スレ 475：2010/10/12(火) 21:28:12

>>89
>遅延評価や「関数型っぽい格好良さ」を抜きにしても、Haskellには魅力的な点がたくさんある

おっしゃる通り、

　「何が嫌いかより何が好きかで自分を語れよ!!!」(AA略)

という事ですね。

自分も長文カキコがウザクなってきたので(<<今頃気付いたのかヨ)、この話から降ります。

91 ：デフォルトの名無しさん：2010/10/12(火) 21:32:45

>>73 モナドの使用に圏論知識が不要、というのには同意するが
「モナド変換子を使えばいい」みたいなのをネタでなく素で言ってるのだとしたら大分タチが悪い
「do記法を使えば手続き型の人も理解しやすい」みたいな嘘くささ

これらに共通するのは、内部に対するある程度の理解が無ければ実際は応用して使えないこと
前者は既にモナドをある程度マスターしてることが前提、後者はdoの変換ルール(+モナド関連の型の知識)

求められる前提が高いなら、一般に普及するわけがない

92 ：デフォルトの名無しさん：2010/10/12(火) 21:46:49

>>91
ライブラリ製作者は言語に関して一歩踏み込んだ理解が求められる、普通のことだろ
do記法については弁護しようと思わない

93 ：デフォルトの名無しさん：2010/10/12(火) 21:48:29

>>22
おい、Java版まだか？

94 ：デフォルトの名無しさん：2010/10/12(火) 21:52:36

>>93
批判目的の要求はスルーに決まってる。
本当に知りたいかどうかは文面を見ればわかるし、俺がそうでないと判断すればスルーだ。

95 ：デフォルトの名無しさん：2010/10/12(火) 21:56:50

>>83
理解していれば取捨選択もできるけど、多くの挫折した入門者はHaskell界隈のそういう空気
が障壁となって、STモナドやunsafe関数群の提供する自由を享受する前にアンチになるんじゃないのかね
アンチHakslellの人たちって、驚くほどHaksellについて誤解してる場合が多いよ

96 ：デフォルトの名無しさん：2010/10/12(火) 22:00:28

Haskellerとして正直に言うと、普及してほしくない。
普及すると言語がおかしな方向に拡張されるからね。
理想を保ったまま緩やかに進化するのが望ましいと思う。

97 ：デフォルトの名無しさん：2010/10/12(火) 22:08:40

Perl界隈は雰囲気づくりがすごい上手いよな
片言で話すのも、専門用語で小難しく話すのも、平等に自由だみたいな

98 ：デフォルトの名無しさん：2010/10/12(火) 22:20:14

>>96
じゃあ、こんな所にレスするなよ

99 ：デフォルトの名無しさん：2010/10/12(火) 22:35:19

べつにHaskellにかぎったもんじゃないわな
元ハード屋から見てもこのスレの論点はおかしいと思う
信号処理とらやってるとオブジェクト指向なんてのは，滅茶苦茶頭のいい奴が
書いたものしか信用できない
# ゴミがソフトを書くなと言いたいが，今の現場は大半がゴミだったりするな

100 ：デフォルトの名無しさん：2010/10/12(火) 22:47:24

とゴミの一人が申しております

101 ：デフォルトの名無しさん：2010/10/12(火) 23:10:40

べつにゴミでいいと思うが、ゴミだと何かまずいのか

俺たちはそのゴミを使用して生活してるんだし

102 ：デフォルトの名無しさん：2010/10/12(火) 23:12:41

>>100
とゴミの一人が言ってるかもしれんが, おまえハード組める?
OO じゃ組めないけど，関数だと組めるんだ。
# 困ったもんだ

103 ：デフォルトの名無しさん：2010/10/12(火) 23:15:35

OOにも関数はあるよ。

104 ：デフォルトの名無しさん：2010/10/12(火) 23:19:35

そういえば関数型低級言語みたいなのってあるの？

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

>>99
お前らのいうめちゃくちゃ頭のいい奴ってせいぜいFランク私大の情報系学科首席レベルだろ？

106 ：デフォルトの名無しさん：2010/10/12(火) 23:23:13

俺はBランク私大の首席で記念の銀メダルもらってるんだけど、
現場じゃ神扱いだよ。

107 ：デフォルトの名無しさん：2010/10/12(火) 23:24:22

>>104

つ LISP

108 ：デフォルトの名無しさん：2010/10/12(火) 23:24:41

お前の現場の基準ではそうなんだろうなｗ

109 ：デフォルトの名無しさん：2010/10/12(火) 23:25:31

>>106
なんだ、金じゃないんだ。

110 ：デフォルトの名無しさん：2010/10/12(火) 23:27:46

>>107
別人だがフォローしておくと、
LISP マシンをターゲットにした場合の LISP な。
（ただし、LISP を関数型と仮定する）

111 ：デフォルトの名無しさん：2010/10/12(火) 23:29:37

LISPはめちゃくちゃ汚く書くことに我慢出来ればCと同等のコンパイル結果が出るよ。

112 ：デフォルトの名無しさん：2010/10/12(火) 23:30:06

>>102
ゴミかどうかではなく、人をゴミ扱いする神経が問題だと気づけよ

113 ：デフォルトの名無しさん：2010/10/12(火) 23:32:13

>>107
>>110
>>111
へー、知らんかった。

114 ：デフォルトの名無しさん：2010/10/12(火) 23:32:34

結局は、人間の考え方が手続き型だから
関数型は普及しないってことなのかねぇ。

道案内するとき、
手続き型で説明したほうが
分かりやすいし。

115 ：デフォルトの名無しさん：2010/10/12(火) 23:33:31

>>105
ロケット飛ばしてたりとか加速機扱ってる連中はおおむねそんなもんだ
一応国大の院出てるんじゃね？

116 ：デフォルトの名無しさん：2010/10/12(火) 23:33:35

>>113
でもLISPは高機能なマクロが利用できるから、Cと違って汚い部分をマクロでカバーすることで
速度を低下させずに汚い部分を隠すことができるよ。

117 ：デフォルトの名無しさん：2010/10/12(火) 23:35:43

手続き型との根本的な違いがわからん
Lispで他の言語と同じように書いてるからなおさら
状態を持たないって何がすごいの？

118 ：デフォルトの名無しさん：2010/10/12(火) 23:37:48

>>117
状態を持たないんじゃないよ。
状態がローカル変数にあるからグローバルよりも安全なだけ。

そもそも状態はできてしまうもの。
これはどうしようもない。

119 ：デフォルトの名無しさん：2010/10/12(火) 23:42:34

>>116
ああマクロね、なんか聞いたことある。
暇があったらLisp本よんでみよう。

120 ：デフォルトの名無しさん：2010/10/12(火) 23:44:14

>>118
状態が関数名とかあり得るよな
# OO ってぶっちゃけ class の名前でグローバル変数かこっただけやん

121 ：デフォルトの名無しさん：2010/10/12(火) 23:45:39

そういえば一応それらしい機能はあるにもかかわらず
Haskell/OCamlではマクロはほとんど使われないな
型があるからだろうか

122 ：デフォルトの名無しさん：2010/10/12(火) 23:47:23

>>120
一応、補足
みんながみんなそんなことをやってるとは思ってない
けど， class の名前の元にグローバル変数かこっただけの奴が多いのも現実

123 ：デフォルトの名無しさん：2010/10/12(火) 23:50:51

>>122
まじめなんだと思う
3 行以上似たようなことを書いたら関数かマクロに出来ないかと考えるのは
C プログラマでも健全な考え方ちゃうん?

124 ：デフォルトの名無しさん：2010/10/13(水) 00:04:39

クラスがあると、プログラムを分担して
開発するのがやりやすい。

125 ：デフォルトの名無しさん：2010/10/13(水) 00:08:58

あと、リファクタリングする場合
型がきっちりと定義されていたほうが
リファクタリングブラウザがうまく働く。

大規模開発では、コンパイラが、コードの意味を適切に
理解し開発をサポートするためにがっちりと定義されるようになるだろう。

126 ：デフォルトの名無しさん：2010/10/13(水) 16:41:40

>>114
でも、
「右曲がって、まっすぐ行って、それから、左に折れて・・」　この辺でもうわからなくなる。

127 ：デフォルトの名無しさん：2010/10/13(水) 18:54:05

LOGOとかのタートルグラフックス(亀の子幾何学)と同じだね

128 ：デフォルトの名無しさん：2010/10/13(水) 23:57:00

>>126
関数型言語なんてそれを逆向きにして
「・・・する前に左に折れて、その前にまっすぐ行って、その前に右曲がる」
って書くだけじゃん。何が違う？

129 ：デフォルトの名無しさん：2010/10/13(水) 23:59:41

>>126
この場合、副作用ってどういうことになるんだろう？

130 ：デフォルトの名無しさん：2010/10/14(木) 00:29:37

>>128
全然違う。

関数型は数学の関数を主軸に置いた言語。
引数と戻り値との間の「関係」を表現する事が特徴だ。
>>128 では関数型の性質を全く喩えていない。

>>128 はおそらく遅延評価と勘違いしていると思われる。

131 ：デフォルトの名無しさん：2010/10/14(木) 02:18:35

>>129
内部状態：現在位置(緯度と経度)や方向(東西南北)
手続き：右へ曲がって --> 方向 := 方向 + 90

132 ：デフォルトの名無しさん：2010/10/14(木) 04:12:42

関数型言語が普及しない理由？
使い手がひねくれて一般人に敬遠されてるからに決まってんだろ

133 ：デフォルトの名無しさん：2010/10/14(木) 04:42:30

>>128
幸運にも、「16番街の一番高い白い建物」という風に表現できればずばり行くことができる。
こういう人類が育て上げてきたシンボル表現と手続き型は疎遠だ。論理型の得意とする領域かな。

134 ：デフォルトの名無しさん：2010/10/14(木) 21:25:28

16番街の一番高い黒い建物の裏の５番目に低い白い建物

まあ、実際はこんな感じなんだがな。

135 ：デフォルトの名無しさん：2010/10/15(金) 20:34:29

なぜ関数型言語が普及しないか？
簡単なこと。
開発規模とステップ数が一致しないからだ。
マネージャーは開発規模を測る物差しにステップ数を使うから、
ステップ数がアテにならない関数型言語でどうやって開発規模を測ればいいのかわからないんだよ。

136 ：デフォルトの名無しさん：2010/10/15(金) 20:42:56

CやJAVAなら開発規模を測る事ができるとでも言うのか

137 ：デフォルトの名無しさん：2010/10/15(金) 20:43:58

手続き型言語なら測るのは簡単だし、実際に開発規模の指標にステップ数が使われているよ。

138 ：デフォルトの名無しさん：2010/10/15(金) 20:44:44

ステップ数は予算に合わせて逆算するものだ

139 ：デフォルトの名無しさん：2010/10/15(金) 20:47:01

どうでもいいような処理にはステップ数がお似合いかも？

140 ：デフォルトの名無しさん：2010/10/15(金) 20:58:18

>>135
ステップで金払えとか何処のヤクザだよｗ
てかまだそんな勘定してんのかよ。

プリントアウトした紙の枚数で金額きめてんのかよｗｗｗ

141 ：デフォルトの名無しさん：2010/10/15(金) 21:08:53

>>135
お前、関数型言語でステップ数と一致しないほどの規模の開発をしたこと無いだろ

142 ：デフォルトの名無しさん：2010/10/15(金) 21:12:23

C言語でもなんでもいいからさ、そのステップ数とやらのフォーマルな（形式的な）算出方法を教えてくれないかな。

ステップ数という言葉を使う奴にぜひ聞きたいといつも思うことなんだけど。

143 ：デフォルトの名無しさん：2010/10/15(金) 21:31:51

ttp://www.fpdock.net/webtools/cocomo.php3

144 ：デフォルトの名無しさん：2010/10/15(金) 21:41:18

>>142
行数

145 ：デフォルトの名無しさん：2010/10/15(金) 22:15:10

関数型の場合、簡約段数になるの？

146 ：デフォルトの名無しさん：2010/10/15(金) 22:19:28

関数型言語ではなぜか同じことをしようと思ったら、
行数が極端に少ない人と手続き型言語と同じぐらいの行数を使って書くヒトがいる。

147 ：デフォルトの名無しさん：2010/10/15(金) 22:34:01

>>146
行数が「極端」に少ない人のコードは、たいていは読み難い

148 ：デフォルトの名無しさん：2010/10/15(金) 22:34:18

同じことをしたのに、天才小学生と大人では評価が違う。

149 ：デフォルトの名無しさん：2010/10/15(金) 22:42:06

>>147
行数多い人ってやたら頭の悪いアルゴリズムを書いちゃう人がおおい気がするんだよね。

150 ：デフォルトの名無しさん：2010/10/15(金) 22:48:12

関数型の場合は、コード中に呼び出してる関数の数をステップ数にすればどうかな？

151 ：デフォルトの名無しさん：2010/10/15(金) 22:52:17

>>150
ステップ数は行数のことだって言ってるじゃんｗ

マネージャーが知りたいのは開発規模であって、C言語では行数を指標にするが、
関数型言語ではどうやって開発規模を測るかってことが問題なの。

152 ：デフォルトの名無しさん：2010/10/15(金) 22:54:34

C言語では行数でOKで、
関数型言語では行数ではダメな理由を説明してください。

153 ：デフォルトの名無しさん：2010/10/15(金) 22:59:54

>>151
おぉそうだった、言い直すわ

関数型の開発規模を測るための指標の一つとして、
コールしてる関数の数ってのはどうだ？

154 ：デフォルトの名無しさん：2010/10/15(金) 23:02:12

>>152
一般論だが、関数型言語では記述行数が極めて少ないということをウリにしている事が多いから。
現実的には、>>146のとおり、プログラマの質によって行数の幅が広い。
C言語などの手続き型言語では、同じアルゴリズムなら一般的に同じような行数になるから、
行数を開発規模の指標に使われることが多い。

155 ：デフォルトの名無しさん：2010/10/15(金) 23:04:28

>>135
一般的なマネージャーってファンクションポイント法は使わないのか？

156 ：デフォルトの名無しさん：2010/10/15(金) 23:09:53

>>155
実に教科書的な回答だが、実際にはFP法は経験的な面が大きいし、
マネージャーに熟練が求められるのでメインで使われることはほとんどない。
行数を数えるだけなら誰でも簡単にできるでしょ？
まぁ、プログラミングの腕も高いマネージャの場合はその仕事が難しいか簡単か分かるから、
そのへんを考慮することも多いね。

157 ：デフォルトの名無しさん：2010/10/15(金) 23:10:31

> C言語などの手続き型言語では、同じアルゴリズムなら一般的に同じような行数になるから、

ならない

158 ：デフォルトの名無しさん：2010/10/15(金) 23:11:50

>>157
そりゃ無理に短く書こうとすれば短くなるかもしれんが、
普通に書いている分には同じような行数になるよ。
経験的にそうだとしか言えないけどな。

統計データとかあるなら教えて欲しいぐらいだ。

159 ：デフォルトの名無しさん：2010/10/15(金) 23:14:47

そんなことよりお前ら明後日の試験勉強しろよｗ

160 ：デフォルトの名無しさん：2010/10/15(金) 23:21:02

１＋１を計算する関数と、未来を予測する関数が同じ価値でないのは誰でもわかることだが、どのくらい違うのかをだれも定量化できない。
プログラミングは本質的に単純労働じゃないんだよ。強いて言えば小説家が得る収入と同じ意味がある。
売れるコードを書く奴が高収入になるべきなんだ。

161 ：デフォルトの名無しさん：2010/10/15(金) 23:21:24

本当に行数を数えてるとでも思っているのかな
KLという単位は抽象的比喩的なものにすぎないのだが

162 ：デフォルトの名無しさん：2010/10/15(金) 23:22:43

前日の夜に写真を撮り忘れた事に気付く

163 ：デフォルトの名無しさん：2010/10/15(金) 23:31:24

漠然とした感覚であれば役に立つ
1万行のプログラムと100万行のプログラムは、
たぶん後者のほうが複雑なのだろう

もっとも、行数以上にまともな指標が無いだけでもあるのだがｗ
ソフトウェアメトリクス屋がんばれ～

164 ：デフォルトの名無しさん：2010/10/15(金) 23:31:42

>>161
定量的でないものなのですか？

定量的に評価できないから関数型言語はダメで、定量的に評価できる手続き型言語がいいんだ、
という話だとばかり思っていたのですが、抽象的比喩的な単位で評価できるから手続き型言語が良くて、
抽象的比喩的な評価もできないのが関数型言語だ、ということなのですか？

165 ：デフォルトの名無しさん：2010/10/15(金) 23:39:24

ソフトウェア規模とは人月であり、人月から行あたりいくらで行数を逆算して
資産あるいは費用の根拠にするというだけの事であって
それが実際に作成されたプログラムの行数と同じかどうかなど誰も知らない

クライアントが気にするなら編集してつじつまの合うように行数を増減させるだけの話

166 ：デフォルトの名無しさん：2010/10/15(金) 23:40:18

>>165
何かそういうの気持ち悪い

167 ：デフォルトの名無しさん：2010/10/15(金) 23:43:05

事実あるいは現実を気持ち悪いとしたところで何の解決にもならない
鏡をなくせば不細工な自分は存在しなくなるか?

168 ：デフォルトの名無しさん：2010/10/15(金) 23:45:10

>>135
そもそもなんだが・・・

開発言語として関数型も挙がったが開発規模を測れないという理由で却下された
という話は実際にあるものなのか

それ以前に、議題にすら挙がらず無視されるような気がするんだが

169 ：デフォルトの名無しさん：2010/10/15(金) 23:49:31

>>168
どうやって運用したらいいものやらわからないから
議論に上がる前にみんな引っ込むんだよ。
誰も新しい試みをして責任とりたくないからね。

170 ：デフォルトの名無しさん：2010/10/15(金) 23:54:12

日本のダメな所。
言いだしっぺの法則という厄介な法則があるので、新しい事ができない。
基本的にマインドストーミングとか無くて、上司から部下への一方通行。

171 ：デフォルトの名無しさん：2010/10/16(土) 00:55:01

本来は逆の意味なんだけど。
2chでそういわれる奴の殆どが、口だけの外野ばっかりだからなぁ

172 ：デフォルトの名無しさん：2010/10/16(土) 01:32:03

日本の良い所。
スタンドプレーから生じるチームワークというのがあってだな

173 ：デフォルトの名無しさん：2010/10/16(土) 05:51:25

ﾜｰﾜｰｻｯｶｰはつまらん

174 ：デフォルトの名無しさん：2010/10/16(土) 07:18:37

>>154
バカな質問なんだろうけど、この際。 <- 積年の疑問
COBOLのステップ数っていうのは
PROCEDURE DIVISION だけを勘定するんですか？

175 ：デフォルトの名無しさん：2010/10/16(土) 13:33:59

使われてない言語の方が圧倒的多数なのだから
使われている言語は何故使われるようになったかを考える方が有用

176 ：デフォルトの名無しさん：2010/10/16(土) 15:33:58

該当言語のWeb情報の多さと普及度には相関があるってのをどこかで見た
シンプルな事実だけど、逆に考えれば
関数型言語の情報が他に比べて少ないってことでもあると思う

177 ：デフォルトの名無しさん：2010/10/16(土) 18:07:29

>>175
そうだと思う

>>176
それは普及してるから情報が多いんであって
情報が少ないから普及しないとは限らない。

178 ：デフォルトの名無しさん：2010/10/17(日) 10:34:05

最初が馬鹿でもわかるのが重要

頭がいい奴がどんなに素晴らしいと思っても、
初心者がどこがどういいのかわからなかったら誰も寄り付かない。

「関数型の魅力」みたいなのを語る時点ですでに失格なのかもしれない。

179 ：デフォルトの名無しさん：2010/10/17(日) 10:40:37

初心者と馬鹿は全然違うだろ

180 ：デフォルトの名無しさん：2010/10/17(日) 10:55:43

馬鹿は馬鹿なりに知恵があって馬鹿でも判るのを使うよ
そんな馬鹿のことを気にしても仕方がない

181 ：デフォルトの名無しさん：2010/10/17(日) 11:08:57

「馬鹿」という言葉がダメなら「サルでもわかる」にしておくか。
残念だけど、2:8の原則に従い、どうやったって8割はそんなに賢くはならないんだ。
「賢くないと使いこなせない」ものはどうやったって普及しない。

で、「今日インストールしたら、あなたが今やりたいことができます。
でも、後で色々苦労するかもしれません。」
というのと
「最初はちょっと勉強しないといけませんが、
いつかあなたのやりたいことがとても素早くできるようになります。」
というのとで、どちらを選ぶかというと、ふつうは前者だよね。

Ruby はキラーアプリとして Rails があった。
確かにまずは30分で何かDBアプリっぽいものを作ることができた。
このインパクトがなかったらここまで普及していないだろう。

流行れば、ライブラリ、情報が増える。
増えるとやりたいことがすぐできるようになるのでとっつきやすくなる。
プログラマ人口が増えると、安心して組織で採用しやすくなる。
(LISP がどんなに素晴らしくても、誰が LISP プログラムをずっと保守してくれるんだ?)

あと、そもそもやりたいことをするには事実上それしか選択肢がないというのもある。
Perl は、嫌でもこれしか選択肢がないから流行った。
JavaScript もそれ。

言語としての筋の良さは残念だけど二の次なんだよね…

例外的だなと感じているのは Python かなぁ。
これはじわじわ普及する感じがしている。

182 ：デフォルトの名無しさん：2010/10/17(日) 12:03:09

賢いやつほど無駄に手間のかかるものを嫌うはずだけど

183 ：デフォルトの名無しさん：2010/10/17(日) 12:05:50

>>181
「CGIはどの言語でも書ける」ということを教えるよりも
Perlを教えるほうが楽だと思ったからPerlが流行った。

Pythonでも「言語なんてどれでも同じ」と言えない空気があることには変わりない。
何も変わってない。

馬鹿でもわかるようにしたいなら
「クラスは構造体のようなものだ」とか
「クロージャはクラスのようなものだ」とか
「モナドはイテレータのようなものだ」と説明すればいいが
それを言ったらおしまいだという空気がある。

184 ：デフォルトの名無しさん：2010/10/17(日) 12:16:58

>>175
C言語は何故普及したのかというと
「CPUなんてどれでも同じ」って言っちゃったからです

185 ：デフォルトの名無しさん：2010/10/17(日) 12:26:43

>>183
クロージャとクラスならクロージャのほうが簡単じゃない？

186 ：デフォルトの名無しさん：2010/10/17(日) 12:40:11

>>185
それは、ノーテーションが簡単ってことでしょ
モデルは共通だということをふまえた上でノーテーションにこだわるなら良いんじゃね

187 ：デフォルトの名無しさん：2010/10/17(日) 12:44:26

モデルからして比較にならないくらい簡単だろ

188 ：デフォルトの名無しさん：2010/10/17(日) 12:48:02

>>183
クラス、構造体、クロージャ、モナド、イテレータ
どれも初心者にはわからない。
君の話は、手続き型言語を使い込んでる
人を対象にしている。すでに。

189 ：デフォルトの名無しさん：2010/10/17(日) 12:59:27

>>183
今はそうでもないが、Web の黎明期(1995年頃)は Perl しか事実上選択肢がなかったんだ。
少なくともほとんどのレンタルサーバで Perl CGI しか選ばせてくれなかった。
(C言語は危険と言われて使わせてもらえなかったし、ほかの言語はインストールさえされていない。)
サーバーもレンタルくらいしか方法がなかった。
言語の選択の余地があったという認識はおかしいんじゃない?
ttp://plusd.itmedia.co.jp/products/hyperbox/special/031215.html

Unix 互換環境ならデフォルトでインストールされているだろう
sh とか awk とかでも確かに書こうと思えば書けるのかもしれないが、
Perl が使える状況でそんなことやろうという奴はいないだろう。

190 ：デフォルトの名無しさん：2010/10/17(日) 13:09:29

>>187
単純なモデルは学者にとってメリットがあるが、プログラマにメリットないよね
学者が「利息つけて借りを返します」って書いてハンコ押してくれるなら話は別だが

191 ：デフォルトの名無しさん：2010/10/17(日) 13:25:46

少し言い過ぎたか
でもまあ理系なら口約束じゃなくて形式にこだわるような気もする

192 ：デフォルトの名無しさん：2010/10/17(日) 13:29:24

>>189 単なる茶々だが
> サーバー
をレンタル出来ない時代があった

193 ：デフォルトの名無しさん：2010/10/17(日) 13:32:46

>>188
手続き型言語を教えるノウハウがあるのに、なんで使わないの
わざわざノウハウを再発明してどうすんの

194 ：デフォルトの名無しさん：2010/10/17(日) 13:43:42

>>190
モデルが単純ってのは、プログラマから見れば「一つのことしかしない道具」ってことだろ
理解しやすく使いやすく組み合せやすい、メリットはたくさんある

195 ：デフォルトの名無しさん：2010/10/17(日) 14:01:11

>>193
もっと絡繰り人形レベルで説明、理解できないものかな。

196 ：デフォルトの名無しさん：2010/10/17(日) 14:50:10

>>194
モデルが単純でも、それが汎用の言語であるならプログラムは簡単にならない。

正規表現は単純で便利だが、汎用ではないから
他の複雑な言語と組み合わせないとプログラムは書けない。

197 ：デフォルトの名無しさん：2010/10/17(日) 15:16:35

>>187は>>186に対するレスなんだが、分かってる？
もちろんクロージャだけではプログラムは書けない

198 ：デフォルトの名無しさん：2010/10/17(日) 17:21:27

>>185
やりたいことによってはそうじゃない気もする。
変更が可能な変数を扱う場合に
オブジェクトの中にオブジェクトを生成するのはやりやすいが
クロージャの中でクロージャを生成するのはバグりやすい
(内側のクロージャを複数生成すると、最初のクロージャの環境が内側クロージャで共有されてしまう)
外側のクロージャの環境は、全てクラス変数/静的フィールドみたいな感じ

クロージャで変更可能な変数を扱わなければ問題はないけど

199 ：185：2010/10/17(日) 17:56:40

>>198
>>185で簡単と書いたのは、クラスとは何か理解するよりも、クロージャとは何
か理解することのほうが簡単じゃないか、てこと。使い方はそれぞれ向き不向
きがあると思う。

クロージャ＋色々でオブジェクトシステムを実装できるイメージがある。

200 ：デフォルトの名無しさん：2010/10/17(日) 19:14:33

関数型言語で一番簡単なのはLISP系だろうけど、
quoteの概念て関数型言語として見るとどうなの？

201 ：デフォルトの名無しさん：2010/10/17(日) 19:29:23

backquote(quasiquote)って数学的基盤ってあるの？
LISPでリスト処理を書く時って、無意識的に参照透過性を
維持しながら書くと思うけど、あれが関数型言語のルーツ？
なんじゃないかって思う。
まあ手続き的に書いちゃう人もいるだろうけど。

202 ：デフォルトの名無しさん：2010/10/17(日) 20:17:11

>>201
参照透過でなくなる最大の原因だな >(古典的マクロ + backquote)
# gensym の使い方を覚えるまでだけど…

203 ：デフォルトの名無しさん：2010/10/17(日) 20:28:32

バリアントとパターンマッチのルーツ
文字列と正規表現の最大のライバル

204 ：デフォルトの名無しさん：2010/10/17(日) 20:39:33

仮想関数のライバルでもある

205 ：デフォルトの名無しさん：2010/10/19(火) 03:54:05

関数型言語スレって、やっぱいるかね？
普及とかどうでもいいんだけど

206 ：デフォルトの名無しさん：2010/10/19(火) 04:12:52

一般論としての関数型言語スレが無いせいで
ここが受け皿になっている感はあるが、
スレタイを変えて繁盛するかは分からん

207 ：デフォルトの名無しさん：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/

208 ：デフォルトの名無しさん：2010/10/19(火) 07:42:13

関数型言語Part4の最後辺りは興味深い議論をしてるのに
Part5になってからもう・・・

209 ：デフォルトの名無しさん：2010/10/19(火) 21:36:40

>>198
> オブジェクトの中にオブジェクトを生成するのはやりやすいが
> クロージャの中でクロージャを生成するのはバグりやすい

つまり、クロージャの中でクロージャを生成するのは、苦労するんじゃぁ。

210 ：デフォルトの名無しさん：2010/10/21(木) 00:20:55

http://www.infoq.com/jp/news/2010/07/objects-smalltalk-erlang

Armstrong博士は、アドバイザの議論によって完全に納得させられたのではないと述べたが、Erlangは「唯一のオブジェクト指向言語かもしれない」と考えているようだ。

211 ：デフォルトの名無しさん：2010/10/21(木) 01:37:01

お前ん中ではな

212 ：デフォルトの名無しさん：2010/10/23(土) 10:53:13

>>210
そのErlangの部分も含めて、なぜそうなのかの説明不足の
箇所が多く、翻訳が日本語と思えないこともあり、かなり
意味不明だなぁ。私にとっては。

213 ：デフォルトの名無しさん：2010/10/23(土) 11:52:25

実装をモデルに合わせるのが良くて、モデルに忠実でない実装はダメだ
って当たり前のように語られるけど、これは本当は物凄く異常なことじゃないか？
普通はモデルの方を現実に合わせるべきだろ？

214 ：デフォルトの名無しさん：2010/10/23(土) 12:07:00

それは設計の段階でやること

215 ：デフォルトの名無しさん：2010/10/23(土) 12:19:52

お前らアホだな－ｗ
抽象化ってのは現実を別の考え方で捉えることをいうのにｗ
要するに、どっちかに合わせろってことじゃなくて、
現実を抽象化しやすい抽象化法を用いて、
現実を抽象的に捉えるって事をしなきゃいけないんだから、
どっちかがどっちかに合わせなきゃいけないってことはないんだよｗ

216 ：デフォルトの名無しさん：2010/10/23(土) 12:42:01

>現実を別の考え方で捉える
「別」ということは、少なくとも単一のモデルではありえない。
複数のモデルがある方が良い。そうすると、なんかカオスになって現実っぽくなる。

217 ：デフォルトの名無しさん：2010/10/23(土) 13:30:26

>>216
そうは思いません

218 ：デフォルトの名無しさん：2010/10/24(日) 20:07:35

>>212
そもそも, 何で日本語に訳されてないといけない？
原文を読むには, 中学/高校の英語で十分なんだが…

219 ：デフォルトの名無しさん：2010/10/24(日) 21:37:50

>>218
無理です。

220 ：デフォルトの名無しさん：2010/10/24(日) 22:04:52

中学生からやり直せ

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

>>218
原文で読んだけど大田さん日本語の方がましでした。

222 ：デフォルトの名無しさん：2010/10/24(日) 22:59:35

>>221
大田さんの日本語

223 ：デフォルトの名無しさん：2010/10/27(水) 00:55:48

メッセージループをもったスレッドやプロセスこそオブジェクト。

これこそ、オブジェクト指向とプロセス指向との論争を終結させる
まさに魔法のような言葉。

すべてのもやもやが晴れた。

いままでのオブジェクト指向のオブジェクトとは本当のオブジェクトではなかった。

あー、今夜はなんかよく眠れそう。

224 ：デフォルトの名無しさん：2010/10/27(水) 18:15:12

メッセージループを中心に
考えればいいのかも。

メッセージループ指向。

オブジェクトの前にメッセージループありき。
プログラミングもメッセージループから
入る。
システムにメッセージループが
どれだけ必要か、また、その
メッセージループの処理から考えはじめる。

225 ：デフォルトの名無しさん：2010/10/27(水) 21:58:32

↑キチガイって一日中こんなこと考えてるのか

226 ：デフォルトの名無しさん：2010/10/27(水) 22:05:04

>>224
Functional Reactive Programmingの考え方がそれっぽいな
小さい回路を関数的に組み合わせて大きい回路を作り、まとめて実行
完成した回路一個がメッセージループ一個に相当する

227 ：デフォルトの名無しさん：2010/10/27(水) 22:08:07

全てのデータ構造とアルゴリズムは、メッセージループによって記述できる
自然数の１０とは、メッセージループに１０回メッセージが送られた状態の異名である

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

メッセージループを受け持つ関数はステートマシンにもなってんのかね？

229 ：デフォルトの名無しさん：2010/10/27(水) 22:31:24

>>228
なっている

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

>>228
もしもその関数が状態(ステート)を持っているのであれば、なっている

231 ：デフォルトの名無しさん：2010/10/27(水) 23:10:54

＞224
どうみてもBeですね。

232 ：デフォルトの名無しさん：2010/10/28(木) 12:52:57

>>226
FRP は「実行する」という概念をできるだけ排除して、
システムとメッセージとの間にある応答を伴った「性質や関係」を宣言的に記述しよう
というのが目論見のような気がする

233 ：デフォルトの名無しさん：2010/10/28(木) 17:49:42

何をやっても結局パフォーマンスの問題に突き当たる

234 ：デフォルトの名無しさん：2010/10/28(木) 22:34:05

プログラミングを教えるとき、
メッセージループまで必ず教えよう。

作ることができるシステムの
違いが多いことに気付く。

235 ：デフォルトの名無しさん：2010/10/29(金) 21:27:29

新規作成メニューから
メッセージループを選択しクリックする

画面上にメッセージループを表す
小さな丸いアイコンが出現する

そのアイコンを右クリックすると、
メッセージ作成、状態遷移表作成
などのメニューがあらわれる。

メニュー作成は、どうやら
このメッセージループが解釈できる
メッセージを定義するものらしい。

状態遷移表作成は、
このメッセージループの挙動を実装する
ためのエディタみたなものだ。

一昔前まえに、スモールトークという
開発環境に初めてあった時の感動を
覚えた。

236 ：デフォルトの名無しさん：2010/10/31(日) 05:48:28

関数型言語とCってどっちの方が最適化しやすいの？

237 ：デフォルトの名無しさん：2010/10/31(日) 09:07:44

C だよん。

現在、一般的に利用できる関数型言語処理系で最速なのはML系言語の SML/NJ と言われており、
このコンパイラは直接ネイティブコード(機械語)を生成する。
ベンチマークの課題にもよるが、gccと比較して最速でも数倍は処理時間が必要。
ただし、見方を変えれば、gccの数倍から数十倍程度の遅さなら、
大半の処理で実用レベルの最適化が図られているとも言える。

他の関数型言語、たとえば Haskell 処理系である GHC は、SML/NJ と比較しても圧倒的に遅い。

238 ：デフォルトの名無しさん：2010/10/31(日) 09:09:20

fortranが最速

239 ：デフォルトの名無しさん：2010/10/31(日) 09:19:35

最適化とは処理時間のことなのか。

240 ：デフォルトの名無しさん：2010/10/31(日) 09:25:25

定数倍なら同じだよな

241 ：デフォルトの名無しさん：2010/10/31(日) 09:39:58

コンパイラによる最適化を意図して聞きました。処理時間による評価です。
なんとなく手続きじゃないから最適化しやすいのではないかと考えて質問した次第です。

242 ：デフォルトの名無しさん：2010/10/31(日) 09:44:08

Cコンパイラのほうが圧倒的に投入されている労力が大きいから、比較にならない。
関数型なら動的解析とかないし、ある意味最初から静的単一代入形式だったりするわけだけどさ。

243 ：デフォルトの名無しさん：2010/10/31(日) 09:48:36

なるほど、どちらかといえば普及したら速くなるかもって感じなんですね。

244 ：デフォルトの名無しさん：2010/10/31(日) 10:17:38

「最適化しやすい」というのが、
ソースコードを解析して最適化できるヶ所を見つけるということなら、
一般的には関数型の方が最適化しやすいと思う。

参照透過性がルールとしてあるのは大きい。
理論上、副作用が影響するぎりぎりの所まで関数をコンパイル時に評価できる。
機能毎のモジュール性が高いから fusion（deforestation）しやすい。

それでも実際に吐き出された実行ファイルは一般的にC言語の方が速い。

たぶんC言語はプログラマがチューニングし易いからだと思う。
メモリの確保・解放のタイミングをプログラマが制御できるから、
余計なオブジェクトの生成を省ける。

関数型は喩えるなら英文を機械翻訳するようなものだと思う。

245 ：デフォルトの名無しさん：2010/10/31(日) 10:37:45

なるほど、熟練したプログラマ並のコスト評価と適応的なロジックの適用ができないと
最終的に速くはならないだろうということですね。賢くなってほしいなぁ。

246 ：デフォルトの名無しさん：2010/10/31(日) 10:38:45

GUESSじゃなくて、HOWを書けよ。

247 ：デフォルトの名無しさん：2010/10/31(日) 10:44:38

私に言ってるならGUESSでもなくHOPEですが

248 ：デフォルトの名無しさん：2010/10/31(日) 11:40:07

沈思黙考するよりもheuristicな実験をする方が賢いですよね

249 ：デフォルトの名無しさん：2010/10/31(日) 15:53:03

関数型言語葉、C言語でつくってる。
広い意味での外部DSL

250 ：デフォルトの名無しさん：2010/10/31(日) 16:07:40

>>249
意味が分からん
もう少し詳細に語ってくれ

251 ：デフォルトの名無しさん：2010/11/03(水) 07:58:09

>>250
いや、Erlangなんかは1991年マイク　ウィリアムズが
C言語で仮想マシンを書いたんだけど、
要は関数型言語を使うためにC言語でまずつくってるっていう
ビルディングブロックになってるというか階層構造になってるので
言語VS言語みたいな議論はその辺をちゃんと押さえないとってこと。
ある目的のために、低レベルな言語でスクリプトかいてそのスクリプトで効率的に
開発するっていう手法もある。
で、つまり究極的にはその関数型言語やスクリプトで書いたシステムは
C言語でかけるわけで。。。（Cでつくった仮想マシンでうごいてるんだから。）
最後はマシン語におちるから。
つまり、関数型言語っていうのは、フレームワークとか外部DSLにすぎないっていう
視点があって、それは言語論争をする際には記憶の片隅においておかないといけないことなんだよね。

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

片隅においておいて、
なんかいいことあるわけ？

253 ：デフォルトの名無しさん：2010/11/03(水) 08:32:56

251ではないけれど、関数型言語は唯一絶対の言語というような言説は誤りで、
それを前提とした論理展開はおおいにバイアスがかかっているから鵜呑みにするな
ということだと思う。
所詮は構文と意味論が他のものと異なっているというところにアイデンティティを
持っているものに過ぎないわけで、その二つを生かしきれていない活用は
単なる個人の思い入れの産物に過ぎないとみなされても仕方ないよね、と言いたいんだろう。

254 ：デフォルトの名無しさん：2010/11/03(水) 08:45:43

あとは、ある特定の関数型言語用集はC言語におけるひとつの宇宙に過ぎないし、
その関数型言語用集で表現されるC言語も、そのなかにおけるひとつの宇宙に
過ぎないとかいいたいのだと思う。

255 ：デフォルトの名無しさん：2010/11/03(水) 08:46:38

間違えた、関数型言語語用集ね。まとめてしまうと読めないわ。

256 ：デフォルトの名無しさん：2010/11/03(水) 08:58:33

"関数型言語語用集"との一致はありません。

257 ：デフォルトの名無しさん：2010/11/03(水) 09:01:35

確かに単純に関数型言語とすればいいや。訂正。

258 ：デフォルトの名無しさん：2010/11/03(水) 09:46:33

関数型言語って大部分その言語自身で書かれてると思うが

259 ：デフォルトの名無しさん：2010/11/03(水) 09:47:07

C言語もlambda計算などを基礎とする関数型言語もチューリング完全なはずだか
ら、理論的には>>251の用な認識は無意味じゃない？実用的には、Cで書かない
と何で書くの？となるから、Cで書くのがナンセンスという意味ではないよ。

関数型言語で自分自身をコンパイルできるようなコンパイラを作れるんだし。

260 ：デフォルトの名無しさん：2010/11/03(水) 11:34:16

>>258-259
言語自身のことしか考えていないのが誤り。

重要なのは、他言語でも再利用されるライブラリを書くこと。
これは敵に塩を送るようなもので「なんかいいことあるわけ？」という気もする。
でも、言語が普及するということはまさにそういうことなんだ。

261 ：デフォルトの名無しさん：2010/11/03(水) 12:51:58

>>260
他言語からも利用される＝普及する、
というのには言われてみれば一理あると思う。
ただ、

> 重要なのは、他言語でも再利用されるライブラリを書くこと。

それは、他言語からロードできるライブラリを書くこと、なのか、
他言語にも移植されるライブラリを書くこと、なのか。
それとも、もっと別のことなの？

その辺、ちょっと曖昧

262 ：デフォルトの名無しさん：2010/11/03(水) 13:21:14

>>261
利用方法は自由。
自由は曖昧で嫌いだという奴は初心者。
自由の良さを啓蒙する必要がある。

263 ：デフォルトの名無しさん：2010/11/03(水) 13:47:08

>>262
曖昧の意味を誤解されてしまった

> 他言語でも再利用されるライブラリを書く
というのが他言語からロードできるライブラリを書くことであるなら、意味は分かる。
既に普及している言語Ａが作ったライブラリを別の言語Ｂがロードして利用するは至極当然で、
それをもって言語Ａが普及していると見なすのは納得できる。

しかし、他言語にも移植されるライブラリを書くことであるなら、
それはほとんどアルゴリズムと実装の問題で、
ある言語Ａでの実装が別の言語Ｂに移植されたからと言って、
言語Ａが普及していると言えるかというと、それはほとんど関係ないと思う。
そもそも、移植可能ライブラリで実装されているアルゴリズムや考え方は、
たいていはまず最初に言語非依存で考えてから実装される。

どちらの意味なのかによって同意できるかできないかが変わってくるから、
それを >>260 に訊いてみたのだが、>>262 はどちらもあり得ると言うの？

それなら、後者の意味ではさっきも言ったように、それは違うのではと思うのだが、
>>262 はどう考えてるの？

> 自由は曖昧で嫌いだという奴は初心者。
何に対する「初心者」なのか意味が分からない

264 ：デフォルトの名無しさん：2010/11/03(水) 13:57:07

>>262じゃないけど>>263は脱線してるな。確かに初心者のようだ。

265 ：デフォルトの名無しさん：2010/11/03(水) 15:14:41

>>264
そういうレスをよく見かけるけど、
こちらは言われるようにあなたから見れば初心者なんだから、
何がどう脱線しているのかを説明してくれないと分からないです
こちらは脱線してないと自分では思って会話をしているつもりなんだし

分かる人に分かればいいという流れだったのであれば、
初心者が割り込んで申し訳なかった、構わず続けてほしい

266 ：デフォルトの名無しさん：2010/11/03(水) 15:33:34

>>265
どれでもよいとする回答に噛みついているから。このレスも無駄レス。

267 ：デフォルトの名無しさん：2010/11/03(水) 16:08:31

オリジナルがそのまま普及するか、普及したせいで色々改変されるか、
という二つの結果があって、なぜ差がついたのかという問題がある。

ユーザーから見るとどうでもいい問題だが、そういう話題があっても悪くはないと思う。

268 ：デフォルトの名無しさん：2010/11/09(火) 02:28:24

文句を言われても生き残ってる言語は、顧客のニーズを満たしていると思う
例えば、WikipediaにPerl6の開発を短縮できたみたいに書いてあるけど
言語処理なら開発の早さより、速さが大切で明らかにズレてる
ハード寄りなら、モナドばかりになるだろうし、
逆にGUI的なものも、OOPLの方が直感的
Webみたいな用途で使ったとして、PHPやRubyのような早さはない
思いつくのは、CUIのツール類とかサーバーだけど、
やはり、速さが欲しくなるだろうからCに勝てるのか疑問
要するに用途やメリットが解らないから、使わない
関数型言語を使ったこともない素人が、イメージだけで語ってみた

269 ：268：2010/11/09(火) 02:45:25

書きながら思い付いたけど、コーデックとか向いてるかも
例えば、音声ファイルのエンコーダは速さも大切だけど
音質とかどのプレイヤーでも正しく再生できるとかいうのを求めると思う
IOが少なく、速さと正しさのバランスが求められる分野が
関数型言語のポテンシャルを引き出せるんじゃないかな

270 ：デフォルトの名無しさん：2010/11/09(火) 08:39:25

IOモナドを使うとHaskellの良さが生かせないって誤解は相当根深いな

271 ：268：2010/11/09(火) 12:18:14

>>270
じゃあ、逆に訊きますけど、評価を遅らせることで速さを稼ぐのは、
Haskellの良さではないのですか？
リアルタイムを要求される場面で、評価が遅れないように意識して作るのと
ほとんど意識しないで作るのは、どっちが楽ですか？
それと、得意分野の例については、スルーですかそうですか

272 ：デフォルトの名無しさん：2010/11/09(火) 12:29:15

>>269
コーデックなんて全然ダメだろう
その手の信号圧縮処理では大概離散コサイン変換のようなものを使ってるが
Cですら浮動小数点ベクトル演算が十分に高速ではないので、しばしば
アセンブラが使われてる世界だろ

273 ：デフォルトの名無しさん：2010/11/09(火) 12:51:48

>>268
>言語処理なら開発の早さより、速さが大切で明らかにズレてる

速さも大切なのは十分認めるけど、要求された機能やバグ取り、
シェイプアップなどに素早く応える（開発する）ことも重要な要素の一つだよ。
関数型を使うことで開発（正式リリース）が早くなったというのは、
それだけ開発しやすかった、コードの見通しが良かったということだし、
当然メンテナンスもやりやすかったと思う。

で >>268 に訊くが、実際のところ
「関数型によるPerl6の開発が原因と思われる実行時の問題点」はある？
例えばそれが原因で実行速度が前のバージョンより遅くなったとか。

特にそれが原因の問題がなければ、メリットしか無いと思うがどうだろう。

274 ：デフォルトの名無しさん：2010/11/09(火) 13:26:37

使ったこともない奴がなぜこんな上から目線で物が言えるんだかｗぷげらっちょｗ

275 ：デフォルトの名無しさん：2010/11/09(火) 13:35:30

>>271
遅延評価はHaskellの特徴の一つに過ぎない
便利なこともあるが邪魔なことも多い
Haskellの良いところは別のところにあると思う(型クラスとか)

>リアルタイムを要求される場面で、評価が遅れないように意識して作るのと
Haskellでパフォーマンスを意識したコーディングをするなら、
どこが遅延するのか考えながら書くのは避けて通れない
別にリアルタイムアプリ(あるいはIOモナドを多用したコード)に限ったことじゃないよ

276 ：デフォルトの名無しさん：2010/11/09(火) 18:13:38

>>271
>リアルタイムを要求される場面で、評価が遅れないように意識して作るのと

この言葉に違和感を感じる、ちょっと勘違いをしているかも。

遅延評価は「必要になるまで評価を遅らせる」仕組みだよ。
リアルタイムを要求される場面で評価が必要になれば、
その時にちゃんと（必要な分だけ）評価されるよ。

ただ、その仕組みを作るのに余分な処理がいるから、
そのオーバーヘッドで結果的に処理が遅くなる。

評価するのが必要になるまで遅延されるだけで、
遅延評価自体が処理を遅くする原因ではないからね。
あくまで現時点での、遅延評価という仕組みの実装方法が原因。

277 ：デフォルトの名無しさん：2010/11/09(火) 18:20:30

そういう場合は、必要になる前に空いた時間に評価するのが妥当な気がする
遅延の非同期性は並列性と相性いい感じだね
でもリアルタイムシステムに使うのは無理なんじゃない

278 ：デフォルトの名無しさん：2010/11/09(火) 21:29:34

>>268
>逆にGUI的なものも、OOPLの方が直感的

これよく耳にするんで聞いてみたいんだが、「直感的な GUI 設計」とは何だ？
OOPL の「何が」GUI 設計を直感的にしているんだ（要因）？

それが関数型でもできれば、あなたも直感的だと感じるのか？

279 ：268：2010/11/09(火) 22:55:32

たくさんのレスありがとうございます
レス書いてますので、しばしお待ちを

280 ：268：2010/11/10(水) 01:54:25

>>272
そういうものですか
試しにlameとlibogg覗いてみたんですが、FFT部分にアセンブラは無さそうでした
静止画、音声程度ならどうにかなるんじゃないでしょうか
動画はいくら速くても足りないかもしれませんね
>>273
実装方法が全然違うから、速さ比較は意味無いと思います
だから、早いというのも眉唾かもしれないと思ったわけです
コンパイルでしたら、まさにエンコードですから向いていると思います
でも、インタープリタは向かないと思います
>>274
ちょっとネタふって、逃げるつもりだったんですがサーセンｗ
>>275
そうなんですか
だとすると、「～ソリューション！」みたいな感じで
良いところを生かせる場面を例示していけば
私みたいな一見さんを呼び込める気がします

281 ：268：2010/11/10(水) 01:56:51

>>276
はい、「必要になるまで」は理解してます
例えば、ネットに接続してデータを送るとき
実際に接続してみないと状態がわからないわけなので
すぐに接続してしまうのではないですか？
送るデータが必要になるのは、接続の手続きの後なので、
必要になったデータを生成していると、
送るのに間に合わないといった事態は起きないのでしょうか？
>>277
そうですね、自然言語に近いとか
図でイメージしやすいとか、
関数型言語でそういうのがあるなら、
私みたいなのでも直感的に扱えるかもしれません

282 ：デフォルトの名無しさん：2010/11/10(水) 07:35:03

>>280
>実装方法が全然違うから、速さ比較は意味無いと思います
>だから、早いというのも眉唾かもしれないと思ったわけです

速さ比較は単なる例で、何でもいいんだよ（例えばって言ったでしょ）。
質問は以下の２点。

1) 実際に君が使ってみて、あるいは周りで使ってる人達の実感を聞いて、
Perl6 を関数型で作ったことに関する弊害は何かあったのか？
要するに、実用に耐えられなかったのかと訊いている。

2) で、弊害がなければ、少なくとも perl6 に関しては、
関数型で作ったことにメリットしかないのではないか？

「言語処理なら開発の早さより、速さが大切で明らかにズレてる」は
プログラミング言語のひとつの側面を強調しすぎていると思うのだがなぁ

283 ：デフォルトの名無しさん：2010/11/10(水) 07:54:22

>>281
> 実際に接続してみないと状態がわからないわけなので
> ...
> 送るのに間に合わないといった事態は起きないのでしょうか？

あぁ、接続してから必要なデータを計算していると、
ネット接続のタイムアウトを喰らうのではと懸念しているわけね。

それが心配なら、接続前に計算を済ませておけばいい。
ネット接続関数の引数の設定を正格評価にしておけば、
引数にその関数を適用した時点で引数が評価される。
もっと前の段階で計算を済ませておくことも当然できる。

C 言語でも、接続後にデータを計算するか、
接続前にデータを計算するか、プログラマが自分で選択できるでしょ。
というか、自動では処理されないから、どちらかを選ばなくてはならない。
Haskell も選択できる、いっしょだよ。

> そうですね、自然言語に近いとか
> 図でイメージしやすいとか

OOPL のどこにそのような要素があるのか解説してくれないか？

284 ：デフォルトの名無しさん：2010/11/10(水) 09:24:47

関数型でFSMってどう書くの？

285 ：デフォルトの名無しさん：2010/11/10(水) 12:44:11

>>284
如何様にも書ける。

直感的にグラフを直接構築してもいいし、
関数を要素とした配列変数を作ってもいいし、
関数に次の状態への関数を渡す方法でもいいし。
色々やり方はある。

参照透過性を保ちたいのなら、例えば前回の状態も一緒に運んで、
関数内で現在の状態へと再構築して、次の関数へ渡せばいい。

286 ：268：2010/11/10(水) 16:47:38

>>282
1)速さを訊きたいのはこっちなんですが・・・
早いというからには、検証可能であるデータを出さなければいけないのは
言った側であって、私じゃありません
2)「Perl6が使い物になる=Haskellが早い」では、ありません
Cで書かれている部分で高速化が図られていて、
トータルの開発に時間がかかっているかもしれません
Haskellの遅さが表面化していないだけかもしれません

287 ：268：2010/11/10(水) 16:49:07

>>283
普通、何時評価されるかなんて気にしません
わざわざ気にしなければならない時点で、
プログラマに負担を強いることになってませんか？
選択できるかどうかではなく、
意識して遅延させるか、意識して遅延させないか
無意識がどっちにあるかという問題なんです
＞OOPL
例えば、野球を考えます
ボールを投げるとき、キャッチャーをめがけて投げます
直接的にはボールに速度を与えるだけですが、
間接的には、バッターが打つ準備をし、キャッチャーに捕る体勢をとらせます
OOPLであれば、
ball.throw(batter, catcher)
みたいな感じで、一連の事象に関わる目的語を沢山書けます
この辺りが自然言語に近く図でイメージしやすい理由です

288 ：デフォルトの名無しさん：2010/11/10(水) 17:32:28

>>287
throw(ball,pitcher,catcher)

でも書けているのではないかな。

289 ：デフォルトの名無しさん：2010/11/10(水) 18:34:25

>>288
実際、そういう書き方のOOPの実装もあるよね。

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

>>283
＞OOPL のどこにそのような要素があるのか解説してくれないか？
クラス図やオブジェクト図を描けば、
全体的な構成が伝わりやすい。
目に見えるモノ単位なので、自然と
わかりやすい（気がする）。

>>285
関数型言語特有の言葉、常識、流れが
わからなければ、意味がほとんど
わからない。

スレタイのことは、要するにそういうこと。
何故？ではない。
理由が本気でわからないなら、すなわち、
普及させることができるはずがない。

個人的には、それでいんじゃね、と
思ってるけどね。ｗ

291 ：デフォルトの名無しさん：2010/11/10(水) 19:10:05

>>286
> 早いというからには、検証可能であるデータを出さなければいけないのは
> 言った側であって、私じゃありません

え？だって、あなたが自分で次のように言ったんだよ。

> 例えば、WikipediaにPerl6の開発を短縮できたみたいに書いてあるけど
> 言語処理なら開発の早さより、速さが大切で明らかにズレてる

この言い方って、Perl6の開発が処理速度よりも開発の早さを優先させた、
この考え方（作る姿勢）はおかしいと言っているように聞こえたんだけど。

実際に処理速度的に問題が起きてなければ、その姿勢でもいいじゃんと私は思ってる。
ハードルをクリアした上で、開発時間を短縮したんだから。

そこまであなたが、開発の早さを優先させた姿勢がズレてると言うのなら、
実際にその姿勢のせいで（関数型を使ったせいで）何か問題が起きてるのかなと訊いたんだよ。

厳密なデータとか比較可能なデータとか、そんな厳しく訊いてないよ。
厳しく聞こえたのならゴメン。

単に Perl6 を使って何か問題に気づいたのか、実体験を訊きたかった。
あるいは、周りで使ってる人の話でもいいよ。

> Haskellの遅さが表面化していないだけかもしれません

表面化してないなら十分でしょ。

292 ：デフォルトの名無しさん：2010/11/10(水) 19:25:31

>>287
> 例えば、野球を考えます

Haskell ならこういう書き方をして、
ピッチャーとバッターとキャッチャーのボールを通しての関係性を
静的に表現すること「も」できる（もっと別の表現方法もできる）。

result <== catcher <== batter <== pitcher

ピッチャーが投げたボールがバットに当たったのか、
バットにかすったがキャッチャーが取ったのか、
ストライクゾーンを外れたのか、バッターが打ったのか、
キャッチャーが取りこぼしたのか、取ったのか、
といった情報が result を評価することで全て分かる仕組みを作れる。

正確には result を評価することが、一球投げることを意味する。
正直、恥ずかしながら野球をよく知らないので、
適切な用語を関数名などにつければ、もっと分かりやすくなると思うが。

293 ：デフォルトの名無しさん：2010/11/10(水) 19:28:29

>287
むしろいつ評価されるかきにしないための遅延評価。
正格評価はすべてを評価してるんだからそれもある意味"いつ"を気にしてないでいがリソースの無駄。
遅延評価にすることで必要なものだけ適切なタイミングで評価される。
評価の順序が気になるならモナドればおけー。
接続のタイミングに評価したら時間がかかる?
接続のタイミングの意味がわからんが(いやいわんとすることはわかるがｗ）時間のかかる処理ならそもそも時間のかかる処理の評価と接続のタイミングには特別な関係があるんだからそれもモナドればオケー。
特別なものだけ気にしてほかは一切Howを指定しないでWhatを指定すればいいという思想。

294 ：デフォルトの名無しさん：2010/11/10(水) 19:36:08

Haskellの無限リストを初めて使ったときは遅延評価の凄さにちびった
正格評価の言語だと、有限のリストと無限のリストじゃ扱い方が変わっちゃうやね

295 ：デフォルトの名無しさん：2010/11/10(水) 19:52:31

>>287
正格評価がデフォの言語は、関数をコールした時が関数を評価する時だから、
当然いつ評価されるかは気にしない。

でもパフォーマンスを求めてる時は、いつ関数をコールするかは気にするでしょ。
同じデータを構築するのにも順番によって効率が変わってくるしね。

そういう時は、プログラマは普段よりも負担を強いられてるけど、
負担を強いられてでもパフォーマンスを求めたいわけだよ。

非正格評価（遅延評価）がデフォの言語でいつ評価されるかを気にするのも、
そういったパフォーマンスを求めている時なんだよ。

初心者はともかく、普通の Haskell プログラマは、
普段はいつ評価されるかなんてほとんど気にしない。
必要な時に必要なだけ評価されるようコンパイラが良きに計らってくれるからね。
それに遅延されてても評価する順番は変わらないから安心してプログラムできるよ。

296 ：デフォルトの名無しさん：2010/11/10(水) 19:59:15

Javaが昔、GCのせいでメモリの解放タイミングが管理できなくて不便だ
って言われてたのを思い出すな
今でも解決したワケじゃないんだが、以前に比べると
欠点より利点が目立つようになった
遅延評価もいつかはそうなるんかな

297 ：デフォルトの名無しさん：2010/11/10(水) 20:02:13

>>295
関数型言語を使ったこともないのにイメージだけで語っちゃう人だと、
もしかしたら誤解されるかも知れないから言っておくと、

> それに遅延されてても評価する順番は変わらないから

というのは、B の評価（処理のある部分）で A の評価結果が必要ならば、
必ず（その処理の後の部分より） A が先に評価されるという意味ね。

298 ：268：2010/11/12(金) 00:26:38

>>288
引数を複数取れるんですか！？
だとしたら、私は完全に誤解していたようです
>>289
直接目的語が判り難いですが、自然言語には近いですね
>>290
多分、私に同調して下さったんだと思いますが、
アンカーとの関係が解りませんでした＞＜
>>291
開発で早さを重んじるスタンスがおかしいのではなく、
言語そのものを評価するスタンスが、おかしいと言いました
私は、言語処理系の開発において
早さより速さが大切だと思うので、そういう発言になりました
あなたが、十分と考えるのは勝手ですが、
少なくともそう考えない人には、普及しませんよね
ところで、あなたの意見は、どこかに書いてありましたか？
>>292
その例だと、他の流れが見え難くなる気がします
バッターが打てば、キャッチャーに届くことは少ないですし
打たなければ、バッターは、直接関わりません
さらに意地悪を言えば、キャッチャーが後逸しても
ボールは、別のところに飛んでいきます
ballという単語が見えないだけでなく、述語もありません
自然言語に近いと言うには、厳しいんじゃないでしょうか

299 ：268：2010/11/12(金) 00:28:32

>>293
その特別の場面が、IO絡みということはないですか？
関数型でなければ、モナドるかどうか考える必要も無いんじゃないですか？
>>294
無限リストは、スマートですよね
無限を無限のまま扱ってる・・・って宇宙コピペみたいですねｗ
>>295
人に会わないかもしれないといって、
服を着ないで持ち歩いたりしませんよね？
前もって準備するのは、プログラミングやパフォーマンス云々以前に
そういう無意識に近いレベルで行われることです
パフォーマンスを求めることになっても、
海外旅行の準備になるだけの話で、思考パターンは変わりません
ところが、服を着ない人は、
人に会わないかいつも心配していなければなりません
海外旅行の準備では、服のことから悩むことになります
でも、無人島に住んでいれば、人に会う心配は要りません
海外旅行に行くことも無いでしょう
つまり、関数型にとっての無人島が何かわかれば、
それが得意分野として宣伝できるんじゃないでしょうか
>>296
たぶん、言い方だと思うんです
「金槌はどんなことでもできます」って言ってしまうと
「そこらの石の方が漬物の重石にもなるじゃん」とか言われてしまうけど
「金槌は釘を打てます」って言えば、
石の方が使いやすいとは、言われません
そう言ったからって、料理に使っちゃいけないわけでもありません

300 ：268：2010/11/12(金) 00:38:25

レスにかなり時間をとられてしまっているので、
(ここ数日他の事が手に付かないｗｗｗ)
言いっ放しになってしまいますが、この辺で名無しに戻らせてもらいます
有り難う御座いました

301 ：デフォルトの名無しさん：2010/11/12(金) 07:49:51

>>298
> その例だと、他の流れが見え難くなる気がします
そのように要求すれば、それを可能な限り満たすように記述できる仕組みを作ればいい。
Haskell はそれができる（完璧とは言い難いが、記述方法に関してはかなり柔軟だ）。

あの例は、ピッチャーとバッターとキャッチャーのボールを通した「関係」を
プログラムで示した。

さらに、バッターが撃ったボールと野手との関係を示したかったら、それらを追加して、
先の関係の結果と今回の関係の結果を合成すればいい。
（ここではインデントが正しく表示できないかもしれん）

result <== field ( (catcher <== batter <== pitcher)
<+> (batter ==> [fielder1, fielder2, ・・・]))

<+> 演算子で２つの関係の結果を合成する。
べつに一気に一つの式にしなくても、分けて記述してもいい。
更にイニングの関係を被せればゲームそのものも表現できる。
（それにはもう少し洗練させる必要があるが）

ボールが見えないのは、「ボールを通した関係」を表してるんだ。
このプログラムを書いてる者や見る者に取っては、コメントにでも書いておけば
ボールを通した関係であることが明らかだから、記述する必要がない。
記述したければ記述するように書き換えできるけど、冗長だ。

あくまで、短時間で思いついた書き方を示しただけだ。
もっと直感的に書ける方法も当然あるだろうな。
Haskell ならそれが「考えやすい」し「設計しやすい」。

302 ：デフォルトの名無しさん：2010/11/12(金) 07:54:40

>>298
おっと、忘れてた。
述語が無いのが不満なのか？

それは仕方がない。
「静的な関係を式で表す」のが関数型の一般的なスタイルだからだ。
これが馴染めないのはよく分かる。
ただ、慣れだ。

このスタイルが直感的だと感じるタイプの人間も少なくないよ。

303 ：デフォルトの名無しさん：2010/11/12(金) 10:41:34

>>301,302
論理型言語の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で同じ問題を解くコードを書いて下さいまし。「論よりコード」です。何ステップで書けますか？

304 ：デフォルトの名無しさん：2010/11/12(金) 12:18:22

data Player = P | C | B | F1 | F2 | F3

instance 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 [])

305 ：デフォルトの名無しさん：2010/11/12(金) 13:14:55

Haskellで定義した関数 move_ball p ですが、これは以下の質問に返答できますか？

　Q1. 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.

という、たった２行で、簡潔かつ誰にも分かり易く「すべての関係を定義」できます。

これは、以下の事実を雄弁に物語っています。

　＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
　＊＊＊＊　あまりにも冗長で難解なＨａｓｋｅｌｌが現実世界で普及する事は有り得ない　＊＊＊＊
　＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

代弁、ありがとうございました。

306 ：305：2010/11/12(金) 13:16:43

>>305を訂正
誤: move_ball(X, Z) :- X ==> Y, X ==> Z.
正: move_ball(X, Z) :- X ==> Y, Y ==> Z.

307 ：デフォルトの名無しさん：2010/11/12(金) 13:25:03

prologで簡単なechoサーバ書いてみてよ。

308 ：デフォルトの名無しさん：2010/11/12(金) 13:50:02

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)

309 ：デフォルトの名無しさん：2010/11/12(金) 14:23:07

>>307
書いたことないから、動かないかもしれないけど、やはりこんな感じかな。一文字毎の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).

310 ：デフォルトの名無しさん：2010/11/12(金) 14:25:34

型クラスが冗長なのは問題だと思う。

(==)を定義すれば (F2==) のような述語を簡潔に書けるが、
定義できない場合は \x->case x of{F2->True;_->False} のようになる。

311 ：デフォルトの名無しさん：2010/11/12(金) 14:35:20

showを定義しないとデバッグできないし

312 ：デフォルトの名無しさん：2010/11/12(金) 14:56:09

>>308
すくなくとも以下は間違っているw
　　colose(NewSocket)
ここは
　　socket_shutdown(NewSocket).

313 ：デフォルトの名無しさん：2010/11/12(金) 14:59:37

いやderiving (Eq, Show)しろよ

314 ：305：2010/11/12(金) 15:37:49

>>308
結局、Haskellでは、個々の質問ごとにいちいち関数を定義しないとならないんですね。
なんて面倒なんでしょう。元の move_ball 定義が４行だから、合計すると８行ですか。

>>380から始まった野球を関係として表現するという話題ですが、
Prologだとほんの初心者クラスの課題ですよ。だって、たった２行で済むのだから。
>>292,301を何も知らない素人が読めば、さぞやHaskellなら簡潔に記述できるんだと騙されますね（w
相手が素人だから、それをいいことに難解な言葉をまくしたてるのは、押し売りや詐欺師の手口ですよ。

>>305を繰り返します。

　＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
　＊＊＊＊　あまりにも冗長で難解なＨａｓｋｅｌｌが現実世界で普及する事は有り得ない　＊＊＊＊
　＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

315 ：デフォルトの名無しさん：2010/11/12(金) 15:41:12

個々の質問は、いちいち定義しなくても右辺を対話環境に入力すればいいよ

316 ：デフォルトの名無しさん：2010/11/12(金) 15:59:20

たしかにPrologは簡潔ではあるけど
じつは論理でも集合でもなく、リスト処理だろ
詐欺じゃん

317 ：305：2010/11/12(金) 16:06:22

>>315
Prologだと、>>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の冗長さ汚さ」が良く分かる具体例ですね。

318 ：305：2010/11/12(金) 16:08:56

>>316
これのどこがリスト処理なんでしょうか？（Haskellなんかと一緒にしないでください！！）

　move_ball(X, Y) :- X ==> Y.
　move_ball(X, Z) :- X ==> Y, Y ==> Z.

319 ：デフォルトの名無しさん：2010/11/12(金) 16:09:58

>>316
基地外を構うな
あれはPrologも貶めている

320 ：デフォルトの名無しさん：2010/11/12(金) 16:20:30

>>316
なかなか本質を突いていらっしゃるw

321 ：デフォルトの名無しさん：2010/11/12(金) 16:30:16

>>316
非決定性チューリングマシンさえあれば・・・・

322 ：デフォルトの名無しさん：2010/11/12(金) 17:58:43

>>309
今気が付いたけど、受信・送信の順序が途中でひっくり返っているな。

323 ：デフォルトの名無しさん：2010/11/12(金) 18:50:49

Haskell版echoサーバ
http://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の勝ち

324 ：301：2010/11/12(金) 19:03:50

>>303
> Haskellで同じ問題を解くコードを書いて下さいまし。
嫌です。

> 何ステップで書けますか？
あなたの prolog のコードより遙かに長いです。

>>305
> Haskellで定義した関数 move_ball p ですが、これは以下の質問に返答できますか？
できません。

> 関連とは、その数学的定義からいって集合間の双方向な対応付けです。

数学的定義など気にしてレスしていません。
日常会話レベルの曖昧さを含んで「関連」と言いました。

それが悪いことだったのでしたら、すいません。
以後気をつけます。

325 ：301：2010/11/12(金) 19:05:27

>>324
あぁ、私が言ったのは関連ではなく「関係」でしたね。
>>303 さん、すいません。

326 ：デフォルトの名無しさん：2010/11/12(金) 22:12:54

>>301
関係はオブジェクトの数の階乗だけある
それを全部把握しようとするのは至難の業
人は一度示された関係を簡単に忘れることができない
麻雀で牌を昇順で整理してしまうと別の手が見え難くなる
推理小説のトリックでも先入観を利用する
したがって余計な先入観を持たせない言語がより直感的と言える
OOPLは関係を扱おうとしない(「扱わない」ではない)
だからバッターがピッチャーを殺す(hit)ことも容易に想像できる
ballが見えないということはballが飛び交うこともわからない
(野球ならサインや応援や野次が飛び交うこともある)
>>302
慣れが必要だから普及しないのかもしれない

327 ：デフォルトの名無しさん：2010/11/13(土) 01:43:55

>>326
曖昧な点があるので質問させてほしい。

> だからバッターがピッチャーを殺す(hit)ことも容易に想像できる

この「想像できる」というのは、そのように発想できる思考の柔軟さがあるという意味なのか、
それとも何かプログラミングコードを見て動作をそのように認識できるという意味なのか。

もし前者であれば、それは OOPL に属するプログラミング言語に備わった性質なのか？

もし後者であれば、どのようなプログラミングコードを見て
バッターがピッチャーを殺す(hit)ことを認識するのか？

328 ：デフォルトの名無しさん：2010/11/13(土) 12:10:18

>>327
「容易に想像できる」は確率と可能性を指す言葉
関数型が「できない」のではなく確率を低くする要素があると言っている
見たから認識できるのではない
見ないから認識できる(言語使用者の能力に委ねられる)
関係を明確にできるという意味ではOOPLに備わっていない
関係を曖昧にできるという意味ではOOPLに備わっている
result<==catcher<==batter<==pitcher
このコードは順序や方向が明確に"解ってしまう"
なまじ間違っていないだけにこういうのは無意識に刷り込まれる
だが現実にはこの流れは稀なケース
バッターが打った球がキャッチャーに飛んでいった場合だけだ
現実はキャッチャーに"直接"届いたり届かないケースが圧倒的
OOPLはバッターがキャッチャーにボールを飛ばすか知ることができない
知ったら言語の存在意義を失うからだ
ball.throw(batter, catcher)
これはボールの行き先を曖昧なままにしている
ピッチャーの前で地面に落ちたりバックネットに直撃する可能性も残している
だからデッドボールに怒って殺しにくることも先入観無く想像できる
既に登場しているオブジェクト同士の関係であることに注目して欲しい
想像できなかったとすればプログラミング以前に先入観があるからだ
あとは言語者の想像力欠如
それは言語の知ったことではない
関数型が得意とするのはよく解らないものより既知のものだ
数式になっている物理法則などを"直感的に"そのまま取り込める
それは新しい物理法則を"直感的に"見付けることを妨げる
GUIに関して言えばオブジェクトが無数にあり関係がよく解らない世界だ
関係を先入観無しに発想できた方が良いことは解るだろう

329 ：デフォルトの名無しさん：2010/11/13(土) 13:27:52

目に見えるものだけが全てじゃないと
見えているものや先入観にとらわれず、とにかく上手く動く抽象を考え出せと

330 ：デフォルトの名無しさん：2010/11/13(土) 13:55:34

僕は耳と目を閉じ口をつぐんだ人間になろうと考えた

331 ：デフォルトの名無しさん：2010/11/13(土) 14:02:04

>>328
> ピッチャーの前で地面に落ちたりバックネットに直撃する可能性も残している
> だからデッドボールに怒って殺しにくることも先入観無く想像できる

なんで result <== catcher <== batter <== pitcher としか書けない前提なの？
他の表し方もできることは知らないのか？それともわざと無視してる？

result<== field (catcher <== batter <== pitcher ==> fielders)

こうすれば、ピッチャーの前で地面に落ちたりバックネットに直撃する可能性も表現できる。
牽制球も表現できるし、バッターが打った球がホームランになったり、
フライを捕られたり、送りバント失敗したりする結果も得られる。

この式から、それらの事ができることを想像する人間側の能力と、
ball.throw(batter, catcher) というコールからそれらの事ができることを想像する人間側の能力とに、
どのような違いがある？

ちなみに、Haskell は次のように書いて処理させることも問題なくできる。
問題なくというのは、Haskell の長所（遅延評価や参照透過性など）を保ったままという意味だ。
ball # throw(batter, catcher)
たまたまドット演算子が関数結合演算に使われてるから別の記号を使った。
このように書けば、当然あなたは「ボールの行き先を曖昧なままにしている」と感じるよな。

それなら、あなたが言う OOPL の特徴は、本当に OOPL 特有の特徴なのか？
言語特有の特徴ではなく、書き方に備わる特徴なのではないのか？

332 ：デフォルトの名無しさん：2010/11/13(土) 14:57:09

そこでいってるOOPLの特徴ってただの.表記のこと言ってるだけでしょ?
そんなんOOPLだからとか関係ないやん。

333 ：デフォルトの名無しさん：2010/11/13(土) 20:31:05

まあ回避法があることと本質の議論とは別だからなぁ
>>328にはそれは本質的でないように見えたんだろう
俺はわからんｗ

334 ：デフォルトの名無しさん：2010/11/13(土) 20:47:21

なんかもう、何の議論をしてるのかすら分かんなくなってきた

335 ：デフォルトの名無しさん：2010/11/13(土) 23:17:21

普及しないのは、使っている会社が少ないからだよ。

336 ：デフォルトの名無しさん：2010/11/13(土) 23:39:14

>>335
って言うか、普及の度合いを量る指標のひとつが、使ってる会社の多さなんじゃないの？

337 ：デフォルトの名無しさん：2010/11/14(日) 00:20:57

いわゆる悪循環になってる。
いろいろ言ってるけど、多分使ってみたら普通に使えるんじゃないかと思う。
研修やらドキュメントの作成やらはもちろんしないといけないけど。

338 ：デフォルトの名無しさん：2010/11/15(月) 04:07:38

プロジェクトレベルの仕事としては受注できそうにはないな
せいぜい業務ツールとして内輪で使うだけ
しまいには業務そっちのけでｔｒｙ

339 ：デフォルトの名無しさん：2010/11/15(月) 12:33:46

>>326
階乗・・・orz
>>331
神の俯瞰でならOOPLもこのような書き方ができる
umpire<=(catcher<=(batter<=(pitcher<=(ball))))
ball.pitcher.batter.catcher.umpire
この書き方は結果からバグを見付けるのを困難にする
ピッチャーがキャッチャーに直接渡すこともある
同名のメソッドを持つインスタンスが返ってくることもある
文が長くなることを想像してみて欲しい
従ってOOPLではやってはいけない書き方なのだ
そしてOOPLならメソッドとして定義しなければ書けない
関係を簡単に表せない代わりに知らなくて済む仕組みになっている
逆に関数型では準備無しに<==を使って表せる
当然知らなくても良い関係も知ってしまう
OOPLは関係を曖昧にすることで自由な発想を手に入れた
関数型は関係を明確にすることで簡潔な表現を手に入れた
それだけの違い

340 ：デフォルトの名無しさん：2010/11/15(月) 15:26:19

>>339
自由は曖昧ではない
曖昧な感じがするのは最初だけ

341 ：デフォルトの名無しさん：2010/11/15(月) 18:13:32

>>339
> 逆に関数型では準備無しに<==を使って表せる
> 当然知らなくても良い関係も知ってしまう

意味が分からない。

どういう関係を知ってほしくてどういうプログラムを書いた時、
知らなくてもよいどのような関係を知られてしまうのか、
具体的に説明してくれ。

> 逆に関数型では準備無しに<==を使って表せる
お前、関数型でプログラミングをしたこと全くないだろ。

準備無しに <== 演算子を使えるわけない。
<== 演算子がどのような意味なのかを正しく定義しなければ使えない。

342 ：デフォルトの名無しさん：2010/11/15(月) 19:06:14

>>339
って言うか、そもそもお前の言う「準備」って何のことだ？

343 ：デフォルトの名無しさん：2010/11/15(月) 20:04:57

マンガでわかるHaskell がもし出たなら、流行るかな？

344 ：デフォルトの名無しさん：2010/11/15(月) 20:47:51

流行らない

345 ：デフォルトの名無しさん：2010/11/15(月) 21:01:08

>>344
理由を聞かせてもらおうか

346 ：デフォルトの名無しさん：2010/11/15(月) 21:02:36

漫画でわかる言語解説書なんかが話題になったことなんて
未だかつて一度も無いからだ

347 ：デフォルトの名無しさん：2010/11/15(月) 21:08:51

Haskellが流行るくらいならアセンブラが流行る

348 ：デフォルトの名無しさん：2010/11/15(月) 21:24:05

>>346
そもそも今まで「漫画でわかる言語解説書」の類が出版されたことあったっけ？
ベーマガのつぐみちゃんくらいしか知らんぞ

いくつか出たが話題にならなかった、て言うなら分かるがな

349 ：デフォルトの名無しさん：2010/11/15(月) 21:51:11

こんにちはマイコンをなめてる

350 ：デフォルトの名無しさん：2010/11/15(月) 21:51:42

おいしいですか

351 ：デフォルトの名無しさん：2010/11/15(月) 21:55:49

マンガで分かる JavaScriptプログラミング講座

352 ：デフォルトの名無しさん：2010/11/15(月) 21:56:55

>>349
調べてみた
http://www.m-sugaya.com/arashi/pc-index.html
この付録は欲しいな

>>346
おい、嘘つくなよ
しっかり話題になってたんじゃねぇか

353 ：デフォルトの名無しさん：2010/11/15(月) 22:00:51

文法くらいなら漫画より入門書を読んだ方が効率いいな

関数型言語の「心」を漫画で描いてほしい

354 ：デフォルトの名無しさん：2010/11/15(月) 22:05:03

もうハローワールドはたくさんだ

355 ：デフォルトの名無しさん：2010/11/15(月) 22:20:53

ハローワークに見えた

356 ：デフォルトの名無しさん：2010/11/15(月) 23:23:21

Cygwin使っている人いますか？その20
http://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

です。

357 ：デフォルトの名無しさん：2010/11/16(火) 23:38:46

素直に rf -nf / で教えておけ。

358 ：デフォルトの名無しさん：2010/11/17(水) 05:47:40

学ぶのも大変なのに，性能もゴミだと？
そんなクズみたいな言語は使いたくありません．
http://shootout.alioth.debian.org/

359 ：デフォルトの名無しさん：2010/11/17(水) 11:06:27

>>358
rm -rf /

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

>>1
ラムダ計算の概念が数学的素養の欠けた一般的プログラマ候補者にとって、
理解し難いから。この話の出てくるタイミングが大変微妙。

361 ：デフォルトの名無しさん：2010/11/17(水) 11:42:48

ラムダ計算ごときで数学的素養言われてもｗｗｗ

362 ：デフォルトの名無しさん：2010/11/17(水) 12:33:59

>>360
まずは、ラムダ計算とは何なのか、
それが関数型言語のプログラミングにおいて
何故＆どくらい重要か、お前自身の言葉で説明してくれ

万が一にも説明できなければ、
数学的素養の欠けた一般的プログラマ候補者には理解が難しいことも、
この話の出てくるタイミングが大変微妙なのも、共に根拠のない戯言だ

363 ：デフォルトの名無しさん：2010/11/17(水) 12:47:57

>>360
一般的にはべつに数学の話ではなくて
スコープの話の出てくるタイミング

1. 関数とローカル変数
2. ポインタと関数ポインタとOOP
3. C#のdelegateとか、Pythonのnonlocalとか
のような流れになる

数学的素養が必要になるのは
ポインタやOOPの話を省略していきなり理解させようとする場合だけだ

364 ：デフォルトの名無しさん：2010/11/17(水) 13:13:58

OOPは全く関係なくね？

365 ：デフォルトの名無しさん：2010/11/17(水) 13:31:48

OOPは関係ない

366 ：デフォルトの名無しさん：2010/11/17(水) 13:42:38

いや
Emacsのlambdaよりも
OOPのほうが本物のlambdaに近い

367 ：デフォルトの名無しさん：2010/11/17(水) 13:49:18

>>366
OOPとlambdaの関係性についてもっと詳しく解説を要しますね。

368 ：デフォルトの名無しさん：2010/11/17(水) 13:51:00

>>366
その考え方は一般的でないと考えられるので、
是非ご教授願いたく思います。

369 ：デフォルトの名無しさん：2010/11/17(水) 13:57:15

プログラミング全く知らない人なら、javaとhaskellで簡単なテキスト処理書くまでの
習得時間は多分変わらないような

370 ：デフォルトの名無しさん：2010/11/17(水) 14:08:33

>>369
その程度の問題だと、言語は関係ない。
グローバル変数またはインスタンス変数またはnonlocal変数を使わないと書けない処理が
出てきた頃になってやっと言語の違いが出てくる。

371 ：デフォルトの名無しさん：2010/11/17(水) 14:16:18

>>370
そんな初級レベルの話なら大差なし

372 ：デフォルトの名無しさん：2010/11/17(水) 14:31:17

>>368
動的スコープとレキシカルスコープは全く違うが
インスタンス変数とレキシカルスコープは大差なし

373 ：デフォルトの名無しさん：2010/11/17(水) 15:15:43

関数型言語が普及しない理由は知らないが、
手続き型、それもOOPが普及した理由は何となくわかる。
OOPって仕様書に書いてあることを上から文章のように記述するだけだもの。
OOP+メソッドのオーバーロードで自然言語にかなり近くなる。

374 ：デフォルトの名無しさん：2010/11/17(水) 15:31:02

スコープの話の直後に、自然言語と言われても説得力がない

375 ：デフォルトの名無しさん：2010/11/17(水) 15:34:00

>>373
上からなぞればプログラムが出来上がる関数型言語向きの仕様書の書き方を考えれば？

376 ：デフォルトの名無しさん：2010/11/17(水) 15:40:20

うーん、手段が目的になってるような・・

377 ：デフォルトの名無しさん：2010/11/17(水) 15:42:25

OOL向きに書かれた仕様書だからOOPしやすいのは当たり前なのであって、
関数型言語向きに仕様書を書けば関数型言語で書きやすくなるに違いないよ。

378 ：デフォルトの名無しさん：2010/11/17(水) 15:43:39

30年前の他のプロジェクトの仕様書が見つかるなら見比べてみればどう？

379 ：デフォルトの名無しさん：2010/11/17(水) 18:10:46

>>378
常識的に考えて、今から30年前の仕様書が残ってる訳がない

任天堂ですら、初代スーマリの仕様書はスーファミの時代には消えていたというのに

380 ：デフォルトの名無しさん：2010/11/17(水) 18:18:44

>>379
俺のところは有史以来の全文書を5年前に電子化したから、
鯖探せば見つかるぞ。
だいたい、見つからないってことは大切な情報をちゃんと管理してない証拠。
ずさんな会社って事だ。

381 ：デフォルトの名無しさん：2010/11/17(水) 18:22:08

うちの巫・・いや司書様は整理の鬼だからな

382 ：デフォルトの名無しさん：2010/11/17(水) 21:23:52

OOPが普及したのは、グローバル変数を使わない言語が必要だったから。
関数型言語が普及しないのは、副作用をなくす必要がなかったから。

何かをなくす必要がないなら、既存の言語に機能を加えるだけで良い。

383 ：デフォルトの名無しさん：2010/11/18(木) 19:52:12

>>380
黒歴史に意味はないからね
過去を文書化できる自信がある会社なんてどれだけあるか

384 ：デフォルトの名無しさん：2010/11/18(木) 22:16:21

>>379
＞任天堂ですら
といっても、あくまでゲーム企業だぞ？

385 ：デフォルトの名無しさん：2010/11/19(金) 00:50:52

>>384
いや、任天堂はゲーム企業ですら無い、実質的にそう呼ばれるようになっただけで
そもそもは玩具メーカーだし、今もそういうスタンスみたい
やたらハードウェアが頑丈なのも、基準が精密機械じゃなくてオモチャだからだしな

386 ：デフォルトの名無しさん：2010/11/19(金) 05:39:32

若干大げさ

387 ：デフォルトの名無しさん：2010/11/21(日) 14:09:55

普及しないってか少しずつ普及してきたじゃん

388 ：デフォルトの名無しさん：2010/11/21(日) 14:20:34

関数型パラダイムは何故普及してきたのかを考える

389 ：デフォルトの名無しさん：2010/11/21(日) 22:08:42

普及したものは関数型じゃないといって貶す。この仕組みがなくならない限り関数型は普及しない。

390 ：デフォルトの名無しさん：2010/11/21(日) 22:16:18

例えばどの言語？

391 ：デフォルトの名無しさん：2010/11/21(日) 23:02:24

普及したものは関数型の中でも最弱といってもうちょっとだけ続く仕組み

392 ：デフォルトの名無しさん：2010/11/22(月) 00:26:49

>>388
歴史的には Robin Milner が発案/実証した --- 型推論 --- が、現在の普及に大きな好影響を与えたのだろね。

393 ：デフォルトの名無しさん：2010/11/22(月) 00:31:57

型推論さえあれば動的言語は不要という意見も目にするようになってきたね。

394 ：デフォルトの名無しさん：2010/11/22(月) 08:28:22

実際 LISP は手続き型過ぎるだろ。
破壊的リスト操作はあるし。
>>389 みたいな FUD が一番有害。

395 ：デフォルトの名無しさん：2010/11/22(月) 10:38:32

Haskellにだって破壊的リスト操作があるから、
手続き型である根拠にそれを出すのは不適切。
それにLispと一口で言ってもCLとSchemeとClojureじゃ全然違うし

396 ：デフォルトの名無しさん：2010/11/22(月) 11:08:36

Haskellの進む道はスクリプト言語のような気がする

397 ：デフォルトの名無しさん：2010/11/22(月) 11:08:42

>>395
>Haskellにだって破壊的リスト操作があるから、

Haskellのmutableなリストは(nativeじゃなく)ライブラリとして実装されている。
だからアプリからは破壊的操作に見えても、参照透明性が保証されている。
ただし、その代償として破壊的リストを使ってもメモリ効率や実行速度は向上しない。

LISPの破壊的リスト(あるいはMLの参照型)とは意味あい(= 導入目的)が全く違うから、
Haskellを引き合いに出す事そのものが不適切だと思う。

398 ：デフォルトの名無しさん：2010/11/22(月) 12:02:00

>>389
パクりパクられは世の常。それを言い訳にしている内は、普及なんて夢のまた夢。

関数型言語マニアはリスト等のパターンマッチ機能を自慢するけど、あれは論理型言語(Prolog)のパクリ。
かつて記号処理(狭義の人工知能)の分野で関数型言語と論理型言語が激しく競っていた時代があった。(LISP vs. PROLOGの時代)
結局、PROLOGにパターンマッチ機能はあったけど、当時の(LISPを含む)関数型言語には無かったこともあって、
リスト処理に関しても論理型言語の評価が高かった。時代は進み、最近設計された関数型言語の大半は、
その反省を活かしてパターンマッチ機能を取り込み、少なくともリスト処理に限れば論理型言語の優位性は消え失せた。

振り返って、元々は関数型言語から生まれた継続(continuation)、閉包(closure)、結合子(combinator)といった概念は、
いくつかのOOPでは言語機能に取り込まれ、そうでない言語でもプログラミング技法として活用されている。
そういった状況については、平然かつ生暖かくニヤニヤしながら上から見下ろしていればいいのではないかと。

今のところ(今しばらくは)、たとえば>>392の型推論のような関数型言語の独壇場にある概念は、まだまだ存在している。
その絶対的な優位性の存在に、まだ多くの人が気付いていないだけだと思う。

399 ：デフォルトの名無しさん：2010/11/22(月) 12:11:12

ユニフィケーションとは違うだろ。似てるけど

400 ：デフォルトの名無しさん：2010/11/22(月) 12:16:52

>>398
パターンマッチは、まるで動的型のように見えるので
静的型の絶対的優位性に気付いている人ほど、戸惑いが大きいのだと思います

401 ：デフォルトの名無しさん：2010/11/22(月) 12:17:24

>>399
関数型言語のパターンマッチがユニフィケーションと同じなんて、どこにも書いてないよ。(curryのような例外を除く....)
言語の表層(構文)として、関数型言語がパターンマッチ機能をパクったとは書いたけどね。

402 ：デフォルトの名無しさん：2010/11/22(月) 13:39:53

>>395と>>397は何の話をしてるの？
Haskellの標準のリストはimmutableで、破壊的操作はまったく定義されてない
破壊的に更新できるリストは別に用意する必要があるけど、それを使っても実行速度が向上しないなんてことはもちろんなくて、
通常のリストでは遅い演算(連結とか)を効率的に実行できる

403 ：デフォルトの名無しさん：2010/11/25(木) 23:18:30

Haskellのリストって、consセルのチェーンじゃないの。
むしろ、要素の定数性を利用して効率よく連結できそうだが。

404 ：デフォルトの名無しさん：2010/11/26(金) 07:22:30

>>403
少なくともインターフェイスはconsセルのチェーンに見える
内部実装は知らん

>>402 の言ってる連結演算は恐らく ++ 関数の事だ
リスト同士の連結をする

通常のリストだと第１引数のリストの要素数に関して O(n) の時間がかかる

405 ：デフォルトの名無しさん：2010/11/27(土) 16:02:38

>>404
> 通常のリストだと第１引数のリストの要素数に関して O(n) の時間がかかる
なるほど。tailを保持する実装になっていて、かつ、x ++ yに際して、
xを破壊して良ければ、O(1)にできますね。

406 ：デフォルトの名無しさん：2010/11/27(土) 16:06:40

言語処理系は鉄板だろうが(だから、各種フォーマットの翻訳には、
ML+yaccとかHaskell+BNFCとかがそれなりに使われていると想像して
いるが、その方面の人に補足願いたい)、HPCでない数値計算にも
もっと使われてもよいと思う。もっとも、RとMathematicaを数える
ならば、十分普及しているとは云えるが。

407 ：デフォルトの名無しさん：2010/11/27(土) 16:15:13

で、ありきたりだが、知られていない&利用できるかどうか不明という
ところだろう。

・大学でデータ構造の演習になにを使うだろうか。Cが多いのではないか、
どこかのWebページで、ある助手がデータ構造の教育に関数型言語を使う
ことを教授Aに提案したが、横で聞いていた教授Bで鼻で嗤われたという
記事を読んだことがある。

・Unix系を使っていて、C/C++/Fortran/Perlがインストールされてないこ
とを心配する必要はないだろう。だが、SML/Ocaml/Haskellは、期待できな
いだろう。インストーラが良くできているので、DLしてmakeするだけなのだ
が、「そこまでしないと使えないようなマニアックな言語を使うな」とはい
は云われる。

408 ：デフォルトの名無しさん：2010/11/27(土) 16:18:20

大学ではSMLやらされた記憶があるけどなあ
まあ大学にもよるんだろうけどさ

409 ：デフォルトの名無しさん：2010/11/27(土) 16:25:09

何学科のどんな授業ですか。

410 ：デフォルトの名無しさん：2010/11/27(土) 17:26:46

とはいは云われる。

411 ：デフォルトの名無しさん：2010/11/27(土) 22:56:30

まぁC言語で生のアドレスをガリゴリ使って血みどろのプログラミングを経験しやがれ、
ってのも教育目的としては一理ある主張。

ただ単にその教授がものを知らないだけって可能性もあるが。

412 ：デフォルトの名無しさん：2010/11/27(土) 23:06:01

大学は教育をするところではない、みたいなことを犀川先生が言ってた

413 ：デフォルトの名無しさん：2010/11/28(日) 00:34:48

うちは C, Lisp, Java をやる。他にもやるのかもしれない。

414 ：デフォルトの名無しさん：2010/11/28(日) 09:05:01

>>413
中途半端だな
C、Lisp、Smalltalkでいいんじゃね
あ、でも関数型言語と論理型言語が足りないか……HaskellとPrologも追加で

415 ：デフォルトの名無しさん：2010/11/28(日) 09:15:21

>>414
Smalltalk持ち出してくるとか、お前ただの学生だろ

416 ：デフォルトの名無しさん：2010/11/28(日) 10:02:36

>>415
確かにそうだけど、でも大学でやるんならそれでよくね
職業訓練所ならJavaだろうけど

それともSmalltalkよりEiffelの方が契約による設計を学べていいとか
Simulaを差し置いてSmalltalkを挙げるなとかそういうこと？

417 ：デフォルトの名無しさん：2010/11/28(日) 10:25:31

>>416
馬鹿か。
オブジェクト指向なんて別に原点がどこにあるかなんて気にするほど
ご大層なものでもないし、学術的な意義があるものでもないし、
そもそも何が"純粋"なのか気になるほど数学的厳密性もないし、
オブジェクト指向の明確な機能の定義もない。
言語機能としてオブジェクト指向のサポートを謳っているかどうかすら関係ない。
だからSmalltalkだろうとJavaだろうとPerlだろうとオブジェクト指向的には関係ない。
関係ないなら仕事で使えるJavaを選ぶほうが幾分マシだろう。

418 ：デフォルトの名無しさん：2010/11/28(日) 10:46:37

>>417
俺は原点を気にしてはいないし、純粋さも重視してない（そんなことを書いたつもりもない）

ただ、逆に「仕事で使うことになるんならわざわざ教えなくても自分で学ぶ」とは思う

419 ：デフォルトの名無しさん：2010/11/28(日) 10:47:34

>>418
じゃあSmalltalkをわざわざ覚えるメリットはなんだ？

420 ：デフォルトの名無しさん：2010/11/28(日) 10:54:01

>>418
別に言語をすぐ覚えられることをこんなところでアピールしなくてもいいよｗ
このスレの住人にとってそれぐらいのことは当たり前だからｗ

421 ：デフォルトの名無しさん：2010/11/28(日) 10:59:22

>>412
大学は就職活動をするところですよね

422 ：デフォルトの名無しさん：2010/11/28(日) 11:04:26

>>419
Smalltalkの考え方を学べること
CにはCの、JavaにはJavaの、LispにはLispの、HaskellにはHaskellの、EiffelにはEiffelの、PrologにはPrologの考え方がある

そして問題解決に別の言語の考え方を生かせる場面はあると思う
商業プロジェクトに関わったことがないから断言はできないけど

そして特定の言語の考え方に縛られすぎて遠回りするのも防げる
自分で言語を設計するのにも役立つ（これは今のところ仕事になることは少ないから些細な利点だけど）

こっちも訊くけど、仕事で使う言語が変化していくかもしれない（今までの流れからすれば多少は変わらない方がおかしい）のに
そこまで「今仕事で使われていること」を大学で教える言語に強く求めるのはなぜ？

423 ：デフォルトの名無しさん：2010/11/28(日) 11:06:36

>>420
いや、俺はむしろ覚えるの遅い

424 ：デフォルトの名無しさん：2010/11/28(日) 11:32:24

>>422
言いたいことも分かるんだけど、発想が言語オタク的のような気がするなー
SICPとか、Schemeひとつでやってることは随分多岐に渡るけど
別にSchemeを教えているわけでもなければSchemeの考え方を教えてるわけでもなくて
そこでのSchemeは計算機科学の基本を教えるための、ただの道具でしょ

俺としては大学で計算機科学を学ぶ人に言語「ごとき」（あえて言うが）に
拘泥してほしくはないねえ

425 ：デフォルトの名無しさん：2010/11/28(日) 11:35:56

>>422
大学は就職活動をするところだとトップが思い込んでる大学では、
「今仕事に使えること」が最重要だからな

426 ：デフォルトの名無しさん：2010/11/28(日) 11:41:50

学校がというより企業側の問題だな
会社も4月採用で学校も4月開始だから余裕がなくなるだろう
9月採用とかするだけでだいぶ違うと思うんだけど
3年から就職活動とかあるし関係ないか・・・

427 ：デフォルトの名無しさん：2010/11/28(日) 11:44:32

>>424
確かに言語の学習に大きく時間を割くんじゃ考え方を学ぶも何もないか

>>425
俺が大切じゃないかなと思うことは大学や世間からしたら
実際は大したことじゃないってことか
よく考えたら、本当に大切なら実際に大切にされるはずだもんな
俺が世間知らずなだけだった

428 ：デフォルトの名無しさん：2010/11/28(日) 13:14:47

最近だと、大学でSmalltalkとか言ってる奴は、たぶん京産大生。

429 ：デフォルトの名無しさん：2010/11/28(日) 13:22:15

HTMLも関数型言語ってことでいいの？

430 ：デフォルトの名無しさん：2010/11/28(日) 13:58:35

>よく考えたら、本当に大切なら実際に大切にされるはずだもんな

それはない

431 ：デフォルトの名無しさん：2010/11/28(日) 14:18:04

いやいや、結局広まったものには、広まったなりの理由がある。
仮に悪貨が良貨を駆逐しても、悪貨は悪貨なりの良貨をしのぐ利点があるのだよ。

432 ：デフォルトの名無しさん：2010/11/28(日) 14:43:46

俺は利点≠大切なものとは限らないと言っている

433 ：デフォルトの名無しさん：2010/11/28(日) 14:52:44

人間の進化の成れの果てを見ると
必ずしも進化とは思えないみずぼらしさを感じるよ
2000年もたてば美形ぞろいになってもおかしくなかったのになｗ

434 ：デフォルトの名無しさん：2010/11/28(日) 15:00:28

>>433
それは人間なりの戦略で、
わざと改悪も許すことで多様性を維持していると解釈できる
何が良いかなんて環境によって変わる

435 ：デフォルトの名無しさん：2010/11/28(日) 17:06:16

>>422
> そこまで「今仕事で使われていること」を大学で教える言語に強く求めるのはなぜ？
・大学卒業後就職する人が多いから。
・今後10年以上は使われることが予想できる言語だから。
・SmalltalkだろうがJavaだろうがパラダイムや原理にさほど違いがないから。

436 ：デフォルトの名無しさん：2010/11/28(日) 17:07:33

>>428
京産大生乙
黒田元気？ｗ

437 ：デフォルトの名無しさん：2010/11/28(日) 17:34:19

まとめると俺の使ってる言語以外はカス、俺以外の奴らはカス、こういうことだな。わかりやすいプログラマ心理だ。

438 ：デフォルトの名無しさん：2010/11/28(日) 17:36:02

言語多すぎなんだよ

439 ：デフォルトの名無しさん：2010/11/28(日) 19:08:11

だな、Haskell ひとつで十分

440 ：デフォルトの名無しさん：2010/11/28(日) 19:12:57

>>437
それは当たり前だろ。
自分が使いたくない言語が糞だと思わないわけがない。

441 ：デフォルトの名無しさん：2010/11/28(日) 20:53:26

自分の使っていない言語と自分の使いたくない言語が等価とは限らないし
自分の使いたくない言語と使うべきではないと判断できるくらい熟知した言語も等価とは限らない

そもそもその存在を知らない言語とか
名前は聞いたことあるけど良い言語かどうか判断できない言語とか
悪評をよく聞くから手を出す気になれない言語とかあるでしょ？
もしないなら過小評価してごめん

442 ：デフォルトの名無しさん：2010/11/28(日) 21:13:05

最も良いと思うから使う。
最も良い物以外は多少なり劣っているから糞。

443 ：デフォルトの名無しさん：2010/11/29(月) 12:09:32

例えば選択科目で人工知能を取ればprologとかやるけどな。

単に色々必修にするほどコマ数無くて、開発スキルの向上は
大学的にはさほど重要じゃないだけ。

444 ：デフォルトの名無しさん：2010/11/30(火) 07:20:33

>>406
Lispとくみあわされる鉄板は何になるの？
やっぱりYacc?

445 ：デフォルトの名無しさん：2010/11/30(火) 15:51:43

>>444
Lispなら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

446 ：デフォルトの名無しさん：2010/12/01(水) 22:39:03

使いやすいIDEが無いから。

447 ：デフォルトの名無しさん：2010/12/08(水) 16:02:50

>>1
何かを「返す」という事が実はたいして大事ではない。
日常的には。

448 ：デフォルトの名無しさん：2010/12/08(水) 20:24:39

？

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

>>439
lazy-MLがあるように、eager-Haskellが登場したら、考えなくもない。

450 ：デフォルトの名無しさん：2010/12/09(木) 18:04:31

>>449
言う前に検索してみれば良かったのに

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

>>450
そういうのは揚げ足取りという。検索すると'研究'は出てくるが、実用になる'実装'は出てこない。

452 ：デフォルトの名無しさん：2010/12/09(木) 19:44:27

>>451
そういうのを言い訳という。

453 ：デフォルトの名無しさん：2010/12/09(木) 19:55:28

早とちりして、引っ込みがつかなくなったのかな。

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

>>449
そもそも、なんで eager-Haskell が登場したら
Haskell ひとつで済ませようと考えなくもないのか、理由を聞きたいな

君にとって Haskell ひとつで済ませるには不足だった何が、
eager-Haskell によって改善されるだろうと考えているのか

455 ：デフォルトの名無しさん：2010/12/09(木) 22:04:24

>>450
lazinessはHaskellをHaskellたらしめている部分だから、まさか、あるとは
思わなかった。これは面白そうだ。じっくり、読むことにしよう。

>>454
破壊的代入がただで使えること。むろん、lazinessで支えられている美しい
記述のいくつかは失われるだろうが、型クラスとか、functional record
updationとかは、残るだろう。

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

>>455
Eager Haskell だとなんで破壊的代入がただで使えるの？
遅延評価と参照透過性は別物なんじゃないの？

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

そういや、関数型言語について語るスレはあるけど、
関数型言語を使って何かを作るスレはないよな。

もっと現実的な○○を実現するには
どういうライブラリを使えばいいかとか。
そういうの。

誰も関数型言語でなにかをつくろうなんて
考えてないのかな？

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

>>457
> どういうライブラリを使えばいいかとか
そこまでいってしまうと、個々の言語スレで訊いた方がいいと思う。

参照透過性はどの関数型でもたいていはデフォで備えてるから、
それを考慮した関数型らしいアルゴリズム表現くらいまでだろうね、
共通の話題で盛り上がれるのは。

> 誰も関数型言語でなにかをつくろうなんて
> 考えてないのかな？

今、reyes アルゴリズムを使った RenderMan 互換レンダラーを Haskell で作ってる。
パイプラインを逆向きに作ってて、画像ファイル出力から初めて、
今はサブピクセルのフィルタリングまで作れた。
次は、サンプルからサブピクセルのカラー値を計算するところを作る。

今のところ他人に訊くことも特に無いから、独りで黙々と作ってるよ。

459 ：デフォルトの名無しさん：2010/12/10(金) 00:27:19

それは関数型で作ったほうが作り易いのか？

460 ：デフォルトの名無しさん：2010/12/10(金) 00:44:40

関数型というよりGCだよ問題は
GC必要な言語では本気出せないじゃん？

461 ：デフォルトの名無しさん：2010/12/10(金) 00:47:41

完全無欠のhaskell>Cのトランスレータが出たら考える

462 ：458：2010/12/10(金) 07:22:37

>>459
完全に趣味でやってるから、作りやすいかどうかなんて考えてない。
ガンプラ好きな人が作りやすいかなんて考えないのと、たぶん同じ心境だ。
（おそらく、一般的には作りにくいのではと思われてるんだろうな）

少なくとも俺は手続き型より関数型の方が楽に考えられるし、
考えたことを素直にプログラムできるから、楽しんでやってるよ。

まぁ分かってはいたが処理速度は出ないな。
ただ、最適化はまだ何も施していないから、
最後にその辺りを追求するのも楽しみの一つ。

463 ：デフォルトの名無しさん：2010/12/10(金) 07:24:56

>>460
本気の意味が分からん

464 ：デフォルトの名無しさん：2010/12/10(金) 09:27:37

>>457
使ってる言語のARM非対応やらAndroid非対応やらのデメリットを無視できなくなってきたから
最近は簡単なツールにしか使わなくなった

465 ：デフォルトの名無しさん：2010/12/10(金) 17:01:57

Lisp愛用してるけどHaskellの良さが良くわからない
OCamlの良さはわかるけど

466 ：デフォルトの名無しさん：2010/12/10(金) 17:18:29

>>465
ストリームを感じるのだ

467 ：デフォルトの名無しさん：2010/12/10(金) 21:25:08

haskellは高度なことやりすぎてて実装が見えてこないのだ
それが問題だ
実装が見えてこないと出力がよくわからない
出力されるコードがすべてだ
速さこそ正義だ
効率こそ正義だ

468 ：デフォルトの名無しさん：2010/12/10(金) 21:35:11

>速さこそ正義だ
>効率こそ正義だ
関数型言語死亡

469 ：デフォルトの名無しさん：2010/12/10(金) 21:35:44

STG機械の論文を読むとGHCが出力するコードをある程度想像できるようになるよ

470 ：デフォルトの名無しさん：2010/12/10(金) 21:39:25

>>467
実装が見えなくても、Cほどの速くなく非効率でも、
普通に商業利用もされてる。
たんに君個人の好みに合わないだけだよ。

471 ：デフォルトの名無しさん：2010/12/10(金) 22:58:18

>>470
わけのわからんものを勉強して、
遅かったら時間の無駄だろうが。
バカですか？
Rubyとか糞遅い言語は、
「判り易いから」という条件付きで存在が許されてんの。
「判りにくくて遅い」なんて、
言語の存在価値を問うのに、
もはや好みも糞もねーんですよ
判りませんかねえ？
そんな単純なことが

472 ：デフォルトの名無しさん：2010/12/10(金) 23:01:07

>>471
解りにくいのはお前の頭が悪いから、という可能性はありませんか？

473 ：デフォルトの名無しさん：2010/12/10(金) 23:02:06

>>471
分かる　解る　判る
それぞれの違いは分かりますか？

474 ：デフォルトの名無しさん：2010/12/10(金) 23:03:24

時間の無駄ってことは判ってる

475 ：デフォルトの名無しさん：2010/12/10(金) 23:34:14

>>471
きみの組むプログラムはきっとＣ言語でも遅いだろうな。
なんかこう、効率的なアルゴリズムはとても考えられずに、
ごり押しでプログラムしそうな感じがするよ。

あるいは、どうでもいいところでループを展開して最適化しましたとか、
変数使わないスワップ関数を作って最適化しましたとか言いそう。

で、一週間前の自分のコードすら解読不能になって、飽きて投げ出す。

476 ：デフォルトの名無しさん：2010/12/11(土) 00:39:12

レベルひくっ

477 ：デフォルトの名無しさん：2010/12/11(土) 02:05:38

関数型言語でウェブサービスを作ろうと思っています。

JavaScriptからJSON形式でデータを受け取るのですが、
どうやって処理すればいいのでしょうか？

478 ：デフォルトの名無しさん：2010/12/11(土) 07:20:50

どこを聞きたいのか（＞＜；）わかんないんです！

479 ：デフォルトの名無しさん：2010/12/11(土) 10:09:37

たとえばocaml jsonで検索すればライブラリが見つかるわけだが

480 ：デフォルトの名無しさん：2010/12/11(土) 11:48:06

>>477
haskellのライブラリだとこの辺：
http://www.haskell.org/hoogle/?hoogle=json

481 ：デフォルトの名無しさん：2010/12/11(土) 11:49:00

>>471
haskell分かりやすいよ？

482 ：デフォルトの名無しさん：2010/12/13(月) 02:59:49

Haskellなんかを実用に使うならPython辺りと競合する人が多いんじゃないか
だからどうしてもライブラリの多いPythonに軍配があがる。

483 ：デフォルトの名無しさん：2010/12/13(月) 03:13:15

言語を生涯で１つだけやるってならどんなパラダイムの言語を選んでもいいと思うが、
プログラミングにある程度首を突っ込むなら
どうしてもメジャーな言語を数個習得する事になる。

しかし今のところメジャーな言語といえば殆どが手続き型だから
そこに関数型を加えるのは一手間かかることになる。

484 ：デフォルトの名無しさん：2010/12/13(月) 05:08:36

結局のところメインストリームとパラダイムが離れすぎてる、でFAでしょ

485 ：デフォルトの名無しさん：2010/12/13(月) 06:13:11

Win32APIを呼び出すってhaskellだとどう書くの？
CreateFile成功したらReadFileで適当に読んで
CloseHandleするまでちょっと書いてみてよ。

486 ：デフォルトの名無しさん：2010/12/13(月) 12:19:16

Win32APIを直接叩きたければ
import System.Win32.File　して
openFile, win32_ReadFile, closeHandleを使う

487 ：デフォルトの名無しさん：2010/12/13(月) 12:21:26

パラダイムが離れてるから関数型言語をやるんじゃないのか

488 ：デフォルトの名無しさん：2010/12/13(月) 12:28:33

>>487
それならPrologがもっと普及したはず

489 ：デフォルトの名無しさん：2010/12/13(月) 12:29:18

>>484
メインストリームにパラダイムなんて
言えるもの、あるか？

490 ：デフォルトの名無しさん：2010/12/13(月) 12:32:30

>>488
何が「それなら」なのかわからんｗ

491 ：デフォルトの名無しさん：2010/12/13(月) 12:39:53

>>490
1980年代には関数型と比較にならないくらい、
勢いがあったろう。

492 ：デフォルトの名無しさん：2010/12/13(月) 12:43:02

>>489
ひと昔と比べてマルチパラダイムになってきたが、
少なくとも関数型がメインでは無いのは確か

493 ：デフォルトの名無しさん：2010/12/13(月) 12:50:07

まったくの素人の質問なんですが、
インテルが心を改めて、関数型言語に最適化した、
CPUの設計・製造に腐心するようになったら、
関数型は普及するものですか？

494 ：デフォルトの名無しさん：2010/12/13(月) 12:53:16

経験15年のOCaml ユーザーが Haskell を仕事で半年使ってみた
http://d.hatena.ne.jp/camlspotter/20101212/1292165692

おまいら的にこのエントリーはどうよ

495 ：デフォルトの名無しさん：2010/12/13(月) 12:58:11

>>493
ちょっとやそっと頑張ったところで、量産効果でやっすくなってる現行チップと、
現行チップで性能を出すために基本設計のレベルからチューニングされてる
GHCの組み合わせにはC/P的にかないません。

496 ：デフォルトの名無しさん：2010/12/13(月) 13:12:21

>>491
その時代、俺はまだ生まれてないしｗ

それにいくら探しても過去にPrologに勢いがあった痕跡なんて皆無なんだが。

497 ：デフォルトの名無しさん：2010/12/13(月) 13:19:24

>>496
かつて国家プロジェクトでprolog使った時代があったのよ

498 ：デフォルトの名無しさん：2010/12/13(月) 13:23:44

>>497
第五でしょ、それは知ってる。
国鉄の情報システム設計にZ言語をつかって、Prologでプログラミングしたりなどの成果はあったけど
コスト的にあまり良くなかったでしょ。
流行っていたというより実験的プロジェクトだったと思う。

499 ：デフォルトの名無しさん：2010/12/13(月) 13:26:30

>>485
書いてみた。
普段、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

500 ：499：2010/12/13(月) 13:28:27

あれ？　変なところで改行されてる。
「fILE_SHARE_NONE Nothing」と「oPEN_EXISTING」の間は半角空白だと考えてね。

501 ：デフォルトの名無しさん：2010/12/13(月) 13:29:22

>>499
常識的に考えてwin32apiはhaskellで使うもんじゃないよなぁ。
普通はhaskellに親和性の高い関数をCで書いてffiで呼び出すもんだよなぁ。

502 ：デフォルトの名無しさん：2010/12/13(月) 13:29:52

>>496
Prologの本は50冊以上出版されているが、49冊は
1999年以前にそのうち30冊以上が1980年代に
出版されている。1980年代に出版されたLISPを
含む関数型言語の本は十数冊のはず。

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

>>502
なるほど、結構本が出ているんだね。
Haskellの日本語本なんて数えるほどしかでてないもんね。
だとしても1980年代と現代ではインターネットの存在や選択肢の多さや並列処理の必要性やCPUの処理速度や
どんな力を持った何者が推進しているのかなどいろんな点で違うから、単純比較は難しいよね。

504 ：デフォルトの名無しさん：2010/12/13(月) 13:38:05

今よりは確かに流行っていたが、主流だったとは言えない気がする

505 ：デフォルトの名無しさん：2010/12/13(月) 13:40:17

1980年代に出版されたプログラミング本のうちのProlog本の割合は何％か分かれば判断しやすいな。

506 ：デフォルトの名無しさん：2010/12/13(月) 13:42:11

>>504
もともと、パラダイムシフトだけで押せるのものなら、
そういう立場の代表格だったPrologが萎むことは
なかったんじゃないか、という話だろ。

507 ：デフォルトの名無しさん：2010/12/13(月) 13:43:20

>>503
なに因縁つけてんのwww
そんなこと言い出したら、JavaもPerlもいずれは「単純比較は難しいよね」といわれるようになって、all time standardは回路図だけになるじゃん。

508 ：デフォルトの名無しさん：2010/12/13(月) 13:46:51

そういえばPrologってなんで廃れたの？

509 ：デフォルトの名無しさん：2010/12/13(月) 13:48:08

>>506
パラダイムシフトしなかったから廃れたんじゃないの。

510 ：デフォルトの名無しさん：2010/12/13(月) 13:49:10

>>505
1980年代はCOBOL,FOTRAN,PL/Iなどが勢いを失って、
Pascal,Ada,Smalltalkは不振、C,BASICの独壇場で、90年
近くになってようやく、C++が漸くでてくるという特殊な年代。
30数冊はかなり突出した数字だね。

511 ：デフォルトの名無しさん：2010/12/13(月) 13:50:18

>>507
過去にPrologが流行らなかったからHaskellも流行らない、とは言えないよね？
歴史から学ぶことは大切なことだけど、周りの環境も違うのだから
単純にPrologと同じ運命をたどって廃れると予言するのは難しいよね？

512 ：デフォルトの名無しさん：2010/12/13(月) 13:52:13

ごめん、後半にVisualBasicがでてくるね。これは
Basicには数えないとして。

513 ：507：2010/12/13(月) 13:52:50

>>511
ああ、そういうことを言いたかったのか。
悪かった、オレが誤解していた。ごめん。

514 ：デフォルトの名無しさん：2010/12/13(月) 13:55:35

>>511
いや、もとはと言えば>>487がパラダイムが離れているから
関数型をやるというレスでPrologの話が出てきた。
その理屈ならPrologがもっと流行ってもいいんじゃないかと

515 ：デフォルトの名無しさん：2010/12/13(月) 13:59:22

>>511
問題はHaskellのあまりの助走の長さ。20数年w

516 ：デフォルトの名無しさん：2010/12/13(月) 14:04:22

>>513
haskellに限るわけじゃないけど、
このスレは飽くまで関数型言語がなぜ普及しないのかを考えるスレだぜ

517 ：デフォルトの名無しさん：2010/12/13(月) 14:08:05

VB黎明期は稼がせてもらった
結局お金に結びつきやすいかどうかですよ

518 ：デフォルトの名無しさん：2010/12/13(月) 14:08:56

名前が悪かった
LazyBadAssだったら普及した

519 ：デフォルトの名無しさん：2010/12/13(月) 14:10:50

VBが特に儲かった時代なんて一度もない。
庶民レベルの「儲かった」なら中には儲けた人もいたかもしれん。

520 ：デフォルトの名無しさん：2010/12/13(月) 14:13:28

VBはGUIを手っ取り早く作るのには便利だったな

521 ：デフォルトの名無しさん：2010/12/13(月) 14:18:33

VBといえばGUIだけしか取り柄のない言語だよな。
GUIだけで作れるソフトなんて小物アプリしかないだろ。

522 ：デフォルトの名無しさん：2010/12/13(月) 15:56:32

>>494
「Offside rule は何もいいこと無い」には賛成できないなぁ。
オレはOffside ruleがあることはすばらしいと思う。

また、そう思わないとしても、この記事の筆者も分かっているように、これはHaskellの欠点ではない。
Offside ruleは使用しなくても良いオプションだから。

「Laziness」で書かれていることは、ちょっと違うと思う。
遅延評価より正格評価のほうが高速であると確信できるなら、正格データ型を作れば回避できる問題。
遅延評価がどうしてもいやなのならば、自分が書き下すデータ型はすべて正格にすればよろしい。

ただし、心理的傾向として、Haskellプログラマは計算量に鈍感になりがちかもしれない。
一般的傾向として、そういうのはあると思う。

「Purity」で書かれている、参照透明なコードをモナディックに書きなおすっていうことは起きることがあって、それが面倒っていうのは、たしかにそのとおり。

ただ、そこでの例示は良く分からない。
「あるデータファイル群が何度も何度もロードされるのを気づいたので」って、それは始からモナディックなコードになっていたのでは？

523 ：デフォルトの名無しさん：2010/12/13(月) 16:03:50

>>508
萎んではいるけど、廃れてはいない。

524 ：デフォルトの名無しさん：2010/12/13(月) 16:06:15

今の時代にしてPrologのウリはなに？

525 ：デフォルトの名無しさん：2010/12/13(月) 16:19:30

>>524
http://hibari.2ch.net/test/read.cgi/tech/1289016056/107

526 ：デフォルトの名無しさん：2010/12/13(月) 16:20:33

>>525
誘導してくれとは言っとらん。
ウリを教えてくれと言ってるんだよ。

527 ：デフォルトの名無しさん：2010/12/13(月) 16:28:37

>>526
仕様記述言語のZのことが、>>498に出てきたが、
これはプログラマにとって最も難解な言語のひとつ。
一方、ほぼ同じ目的に使用した場合、Prologは
現在存在するプログラム言語の中で、最も易しい
言語。

528 ：デフォルトの名無しさん：2010/12/13(月) 16:32:22

>>526
そのスレの107番のレスを見ろってことじゃないの？

529 ：デフォルトの名無しさん：2010/12/13(月) 16:37:45

>>527
ちょっとまって、Z言語はプログラマの為の言語じゃないよ。
顧客と意思疎通するための言語だよ。

530 ：デフォルトの名無しさん：2010/12/13(月) 16:45:23

>>529
そこをプログラマが簡単に兼ねられるのがProlog環境と
いうこと。たとえば、電話を受けながら。

531 ：デフォルトの名無しさん：2010/12/13(月) 16:46:59

>>526
このスレ的な切り口でいうなら、数学的知識(論理学を含めて)が
まったく必要ない、ということじゃないかな。
数学的どころか、1985年以降に発明された概念、ほとんどすべてを
必要としないことではないか。たとえば、このスレ、
http://hibari.2ch.net/test/read.cgi/tech/1289397085/
で議論するのに必要となる知識はPrologにとってはすべて無意味。

532 ：デフォルトの名無しさん：2010/12/13(月) 16:51:51

>>522
>遅延評価より正格評価のほうが高速であると確信できるなら、正格データ型を作れば回避できる問題。
GHCは「評価済みだと分かっている値をもう評価しない」という最適化をしないから、完全に正格なコードを書いても
正格な言語の性能には及ばない
>遅延評価がどうしてもいやなのならば、自分が書き下すデータ型はすべて正格にすればよろしい。
リスト、Maybe、タプルを全部自分で書き直して、さらにそれらを扱う標準関数も全部書き直して
…ってやってたら時間がいくらあっても足りないぞ

533 ：デフォルトの名無しさん：2010/12/13(月) 18:53:21

>>529
ZとUMLを比較してください。

534 ：デフォルトの名無しさん：2010/12/13(月) 23:32:57

prologすげーんだな
それにくらべてhaskelときたら

535 ：デフォルトの名無しさん：2010/12/14(火) 00:51:27

まあごちゃごちゃいいたいのは分かるが
結局はシステムなんて入力を処理して出力するだけなんだから
コアの部分はCOBOLで十分ってことなんだよ。

536 ：デフォルトの名無しさん：2010/12/14(火) 00:52:28

prologだから第5世代もまだ成果が残ったんだ
haskellごときじゃ日本の国費投入されたら跡形も残らず忘れ去られる

537 ：デフォルトの名無しさん：2010/12/14(火) 00:53:22

よし、COBOLでtwitterクローンつくってみてください

538 ：デフォルトの名無しさん：2010/12/14(火) 00:54:57

>>536
prologでtwitterクローン作ったらどうなるの？

どれだけ便利な言語なのか推し量るには実際のプログラムを見ないことには判断できない

539 ：デフォルトの名無しさん：2010/12/14(火) 00:55:40

twitterクローンもしくは簡単なwikiでもいいわ

540 ：デフォルトの名無しさん：2010/12/14(火) 01:00:37

>>535
> 結局はシステムなんて入力を処理して出力するだけなんだから

本当にそれだけなら、コアの部分は BrainFuck でも十分じゃないのか？

もし十分ではないのなら、COBOL には有って BrainFuck には無い何かが、
そのシステムを君が構築するのに必要な要素なのだろう（例えば分りやすさとか）

541 ：デフォルトの名無しさん：2010/12/14(火) 01:50:26

>>532
> GHCは「評価済みだと分かっている値をもう評価しない」という最適化をしないから、完全に正格なコードを書いても
> 正格な言語の性能には及ばない

正格な『データ型』を使えば、それを二度評価したりしないと思うが。
そうじゃないと、RWHの最適化の章に書いてあることの意味が分からなくなる。

また、「完全に正格なコードを書いても正格な言語の性能には及ばない」というのは、もし一般論としていっているのなら、間違いでしょ。
単純なBASICインタプリタやLISPインタプリタよりは速かろう。

> リスト、Maybe、タプルを全部自分で書き直して、さらにそれらを扱う標準関数も全部書き直して
> …ってやってたら時間がいくらあっても足りないぞ

すべての標準関数を書き直す必要はなくって、自分が使う関数だけ書き直せば良いのだから、そんな深刻な問題ではないと思うが。
実際、いまでも、Cプログラマなら、リストや辞書などのデータ構造を自分で書くのは普通のことじゃない？

もっとも、もともとは、「遅延評価によって計算コストの見積もりができなくなる」という趣旨の話についてのコメントだから、C並の速度がでるとかそういう話はしていないんだけど。

542 ：デフォルトの名無しさん：2010/12/14(火) 02:47:54

時間ってプログラマ側の時間のこと…だよな？

543 ：デフォルトの名無しさん：2010/12/14(火) 14:43:38

http://blog-imgs-44-origin.fc2.com/n/i/c/nicovip2ch/20101129oriento01.jpg
これ買った。
高かった。
気持ち良い。

544 ：デフォルトの名無しさん：2010/12/14(火) 15:31:41

Brainfuckでechoサーバ書いてみてよ

545 ：デフォルトの名無しさん：2010/12/14(火) 16:55:17

>>541
Ｃ言語でいうなら基本的な構造たとえば配列やポインタがサポートされてない状態に相当する。
配列がないなら当然文字列もないのでハローワールドしたかったら
コンパイラを全面的に書き直してからprintfを自作しないといけない。絶対無理。

546 ：デフォルトの名無しさん：2010/12/14(火) 19:07:54

そもそも、遅延評価だと何で計算コストの見積もりが立てられないんだ？

ある変数（関数）がいつ評価されるかといえば、
それは必要な時に初めて評価されるんであって、
タイミングは完全に分ってるはずだろ。

あと、正格評価で計算量 O(nlogn) の計算は、
遅延評価でも同じ O(nlogn) の計算量だよな。
違うのか？

547 ：デフォルトの名無しさん：2010/12/14(火) 19:29:16

>>546
その通りであるが、そこでの「計算コスト」は空間コストも含まれているのではなかろうか。
実際に体感される(測定される)計算時間には空間コストも当然反映されるでしょう。

まえに紹介された、eager haskell ttp://csg.csail.mit.edu/pubs/haskell.html
には、「なんで末尾再帰で書いたのにスタックオーバーフローが起こるんだばかやろう」
というメイルが毎月Haskellメーリングリストに送られてくる」と書かれている。

#これで遊びたいのだが、personal communicationでしか手に入らんのかな。

548 ：デフォルトの名無しさん：2010/12/14(火) 19:29:36

>>546
>タイミングは完全に分ってるはずだろ。
それはそうだが、直感が働きにくい

>あと、正格評価で計算量 O(nlogn) の計算は、
時間計算量についてはその通り
空間計算量は正格評価より悪くなることがある

549 ：デフォルトの名無しさん：2010/12/14(火) 19:57:41

>>548
>>あと、正格評価で計算量 O(nlogn) の計算は、
>時間計算量についてはその通り
>空間計算量は正格評価より悪くなることがある

例えばどんな計算で？

550 ：デフォルトの名無しさん：2010/12/14(火) 20:00:08

>>546
変数がモジュール間で共有され、モジュール内部の情報は隠蔽されている場合
タイミングが分からなくなる。
代入のタイミングと同じ。

ある変数がいつ代入されるか
必要な時に代入される
タイミングは完全に分ってる

551 ：デフォルトの名無しさん：2010/12/14(火) 21:40:12

とりあえず

評価順序（遅延か正格か）は時間計算量には影響を与えない（見積もり簡単）。
しかし、遅延評価をさせるための仕組みが空間計算量を複雑にする＆多くする（見積もり難しい）。

という認識でいいの？

もしそうなら、たとえば C 言語に比べて C# や Java などは、
メモリ領域の確保や解放をランタイムが引き受けてくれる仕組みを作るために GC が働き、
いつメモリが解放されるか分らないから、空間計算量は C 言語に比べて見積もり難い、
という言い方も正しい？

552 ：デフォルトの名無しさん：2010/12/14(火) 21:59:06

>>543
かわいいね
誰？

553 ：デフォルトの名無しさん：2010/12/14(火) 22:21:32

ドールでしょｗ

554 ：デフォルトの名無しさん：2010/12/14(火) 23:41:21

>>551　正しいと思う。
>>554　時計でないほうのオリエントね。
こっちの人生も魅惑的であるんだよね。

>>545に戻るが、
ところで、リストの場合は正格版が
ダッシュがついた名前であるのでは。

555 ：デフォルトの名無しさん：2010/12/14(火) 23:44:10

>>552
サユリ１号

556 ：デフォルトの名無しさん：2010/12/14(火) 23:51:17

>>554
ダッチワイフについて自己レスしている男の人って…

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

最近のダッチワイフってクオリティ高杉
http://blog-imgs-38-origin.fc2.com/m/u/d/mudainodqnment3/5872462_500.jpg

558 ：デフォルトの名無しさん：2010/12/15(水) 00:16:07

俺も買おうかな

559 ：デフォルトの名無しさん：2010/12/15(水) 00:43:26

買う気はないが一度御相手したいｗ

560 ：デフォルトの名無しさん：2010/12/15(水) 00:54:17

>>559
どっかでレンタルしてたぞ

561 ：デフォルトの名無しさん：2010/12/15(水) 01:49:36

人肌のぬくもりはあるんだろうか

562 ：デフォルトの名無しさん：2010/12/15(水) 01:53:52

風呂で温めろ

563 ：デフォルトの名無しさん：2010/12/15(水) 02:58:22

池上「いい提案ですね」

564 ：デフォルトの名無しさん：2010/12/15(水) 03:03:34

565 ：デフォルトの名無しさん：2010/12/15(水) 10:47:48

>>483
Yaccみたいなラブラリーで他言語への変換を簡単に書けるのがいいな

566 ：デフォルトの名無しさん：2010/12/15(水) 11:24:38

頭のいい人たちには普及してるんじゃないの？
みんな自分の頭のレベルや得意な思考スタイルに応じて
VBやったりHTML書いたりマシン語やったりしてるだけだと思ってた

567 ：デフォルトの名無しさん：2010/12/15(水) 12:10:10

ゆとり世代の俺からするとマシン語に慣れたマイコン世代は天才に見える

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

>>567
その代わりコンピュータそのものを理解している割合が極端に少ない世代だぞ。

569 ：デフォルトの名無しさん：2010/12/15(水) 12:15:39

>>568
まじですか！？
マシン語を触っていればハードを意識するというもんでもないのか

570 ：デフォルトの名無しさん：2010/12/15(水) 12:23:34

oopは頭が良くないと出来ないみたいな意見もあったのに一応普及はした。

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

>>566
関数型ですか？全然だめでしょう。

572 ：デフォルトの名無しさん：2010/12/15(水) 12:31:35

>>569
いや、そういう意味じゃなくて、
年配の一部のオタクはプログラミングもできるしマシン語も分かるけど、
一方でオタク以外は全くコンピュータやインターネットの知識をほとんど持っていない。
若者のほとんどは広くコンピュータリテラシを学んでいるから、どんな底辺でもそれなりにコンピュータの知識がある。
街中のド底辺DQNでも普通に携帯でネット使ってるだろ？

573 ：デフォルトの名無しさん：2010/12/15(水) 12:36:16

>>572
なるほどすいません誤解しました。

574 ：デフォルトの名無しさん：2010/12/15(水) 12:40:58

頭の良いマイコン世代に関数型を覚えてもらうしかないな

575 ：デフォルトの名無しさん：2010/12/15(水) 12:47:59

学校で初めに教える言語が手続型言語だから、関数型の考えがとっつきにくいてのがあると思うんだ

576 ：デフォルトの名無しさん：2010/12/15(水) 12:51:01

>>575
私が初めて読んだプログラムは学芸会ので、
完全に手続き型だったな。

577 ：デフォルトの名無しさん：2010/12/15(水) 12:52:28

有史以来、主流が手続き型からパラダイムシフトした事は一度も無い

578 ：デフォルトの名無しさん：2010/12/15(水) 12:54:02

>>575
そういえば、高校数学とかでも何で BASIC なんだろうな
関数型を使うとまずい問題でもあるんかな

579 ：デフォルトの名無しさん：2010/12/15(水) 12:55:17

>>576
いや、あれは読み手が手続き的解釈をしているだけだよ。僕の番はいつくるかとね。

580 ：デフォルトの名無しさん：2010/12/15(水) 16:30:58

だから、鉄好き型が人間の思考に一番マッチしているんだよ

581 ：デフォルトの名無しさん：2010/12/15(水) 16:32:11

うぉ　俺は鉄が好きなのか…
いや、手続き型ね　　orz

582 ：デフォルトの名無しさん：2010/12/15(水) 17:36:45

機械語プログラミングはアドレス計算フェチがやるもの
関数型言語は何フェチの人がやるの？

583 ：デフォルトの名無しさん：2010/12/15(水) 17:40:10

理論フェチ

584 ：デフォルトの名無しさん：2010/12/15(水) 19:22:54

OOは外向的
関数型は内向的

585 ：デフォルトの名無しさん：2010/12/15(水) 20:04:33

元々東京都の青少年保護育成行政というのは、２００４年までは生活文化局という局がやっていたんですよ。
ところが、２００５年になって青少年治安対策本部というのができたんですよ。
そこに警察庁からキャリア官僚が都庁に出向で来て、その青少年治安対策本部というのを作って、そこの本部長になるわけですよ。
それ以降、さっき言った青少年の保護育成というのは、生活文化局という、つまり生活文化のカテゴリーではなくて、
治安対策になっちゃったわけですよ。

今回のこの条文の改正というのも、この青少年対策本部の本部長とその下についている女性のキャリア官僚がいるんですけど、
この２人が主にというか、この２人が主導してやろうとしているわけですよ。

なぜそれをやろうとしているかということを、さらに都庁関係者に取材したところ、今本部長についている警察庁から出向してた方というのは、
実はあの志布志事件ってご存知ですか。あの選挙違反の世紀の冤罪事件と呼ばれている志布志事件の時の鹿児島の県警本部長なんですよ。
つまり、何かって言うと、そこで彼は汚点を作ってしまったわけですよ。キャリアとしての傷を負ってしまったが故に、出世が今遅れているんですよ。その汚名挽回と名誉回復のために、この条例を通して警察庁に帰りたいと。

さらに彼の今下についている、これはけっこう若手の女性のキャリア官僚なんですけれども、これは非常に優秀な方らしくて、
警察庁としても一押しで、日本初の県警本部長にしたいというふうに思ってらっしゃる方がいらっしゃって、その人にも手柄を与えたい。
そのためにこの条例をどうしても今回通したいということでですね。

586 ：デフォルトの名無しさん：2010/12/16(木) 00:01:31

>>585
まじか!?
Lazy-Ocamlだいじょうぶかなぁ。

587 ：デフォルトの名無しさん：2010/12/16(木) 01:34:14

>>585
第一段落は手続き的だな。

588 ：デフォルトの名無しさん：2010/12/16(木) 02:31:41

産まれて始めて覚える母国語（日本語）が手続き型
手続き脳が完成した後に覚える第二言語(英語)が関数型

589 ：デフォルトの名無しさん：2010/12/16(木) 05:56:04

それじゃあ、と外人夫婦に里子に出す→ＤＶに遭う→スラム街で裏のボスを目指す
これは何型ですか

590 ：デフォルトの名無しさん：2010/12/16(木) 06:50:23

雲竜型

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

>>572
DQNが携帯でネット見てるのを見ると
まず料金が気になってこなイカ？
月いくら払ってんの？って聞きたくならなイカ？

592 ：デフォルトの名無しさん：2010/12/16(木) 13:06:20

条文法（日本　ドイツ）　手続き型
命文法（英米）　関数型

593 ：デフォルトの名無しさん：2010/12/16(木) 13:35:37

>>592
？？？　「命文法」って初めて聞いた。
「成文法」と「判例法」って言いたいのか？

594 ：デフォルトの名無しさん：2010/12/16(木) 19:49:06

日独はパンデクテン方式だから論理型だろ。

595 ：デフォルトの名無しさん：2010/12/17(金) 15:54:52

条文法　文章をそのまま解釈　
命文法　法律が作られた時の意味を解釈

596 ：デフォルトの名無しさん：2010/12/17(金) 17:05:03

>>595
誰が使っている用語法？

597 ：デフォルトの名無しさん：2010/12/20(月) 00:57:39

>>588
逆にいえば大学や専門学校で純粋関数型言語を１年生に強制すれば関数型が普及するかもしれない

598 ：デフォルトの名無しさん：2010/12/20(月) 01:07:11

強制しないと普及しない時点で駄目だろｗ

599 ：デフォルトの名無しさん：2010/12/20(月) 02:27:13

始めて触る言語が何型なのかは後々の習得に影響大きいかもなあ。
言語心理学のプログラミング言語版みたいな研究はないのか

600 ：デフォルトの名無しさん：2010/12/20(月) 07:14:33

>>599
まずサンプルを探すのが大変そうだ

601 ：デフォルトの名無しさん：2010/12/21(火) 00:53:48

日本に住んでて初めて学ぶ言語が日本語以外ってことが
まずないのと同じように、プログラミング言語で
初めて学ぶ言語が関数型言語になることはまずないな。

なぜなら、日本語以外も、関数型言語も
まわりで普及してないから

602 ：デフォルトの名無しさん：2010/12/21(火) 02:12:28

2chはレベル低いな。
レベル高い人が集まるコミュニティ見つけたからそっちに移住するわ。

603 ：デフォルトの名無しさん：2010/12/21(火) 02:28:22

2chは規制ばっかりで移住や掛け持ちしてる人が多い

604 ：デフォルトの名無しさん：2010/12/21(火) 02:57:07

何故かネットで流行るほとんどの話題は先にそのコミュニティ内で話題になってる。
恐ろしい場所です。

605 ：デフォルトの名無しさん：2010/12/21(火) 12:32:44

http://sukima.vip2ch.com/up/sukima005265.gif

606 ：デフォルトの名無しさん：2010/12/22(水) 00:21:34

>>601
俺は Haskell 大好き人間だが、
初めて学ぶ言語が関数型言語というのは、
まず無いどころか、絶対に避けていただきたい。
初めてが Haskell なんて以ての外。

語句と、その語句の並びから、
動作（操作的意味論）を頭の中で容易に変換できる言語を使って、
プログラミングの本質をよ～く感じ取ってほしい。
理解はしなくてもいいから、感覚でいい。

そういう意味では BASIC は今のところ最も優れた言語だ。
これを越える教育用言語は他にないな。

関数型を学ぶのは手続き型言語にどっぷりとつかってからでいい。
むしろ、手続き型言語のハッカーほど関数型を簡単に学べる。

だから、関数型を普及させるには、
その前に手続き型言語を計算機科学としてしっかりと学ばせる必要がある。

607 ：デフォルトの名無しさん：2010/12/22(水) 00:33:14

gccより速いコードを生成出来ればあっという間に普及するでしょ
普及しないのはとろいコンパイラしか作れないから
PerlやPythonのようなインタプリタが最適化の部分で大した苦労せずに普及したからって
自分らも同じようにいくなんてかんがえちゃだめ～

608 ：デフォルトの名無しさん：2010/12/22(水) 00:36:58

関数型言語が普及するべき場所はPerlやPythonと同じ土俵なんだよ。
型推論バンザイだな

609 ：デフォルトの名無しさん：2010/12/22(水) 00:45:16

PerlやPythonと張り合ってる間は普及することはないでしょう

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

>>606
> むしろ、手続き型言語のハッカーほど関数型を簡単に学べる。

うーんその根拠は？

単にそいつがハッカーだから
どんな言語でも楽勝なだけでは？

611 ：デフォルトの名無しさん：2010/12/22(水) 01:08:42

606みたいなのがいる限り普及しない気がする

612 ：デフォルトの名無しさん：2010/12/22(水) 02:47:57

いやーでも>606の意見には同意。
サイテーでもC++でヒープとかスタックとかVTableとかわかってからでいいと思ふ

613 ：デフォルトの名無しさん：2010/12/22(水) 03:05:32

MSが現在C#やVBに担わせてるポジションに純粋関数型言語を置くだけで良い

614 ：デフォルトの名無しさん：2010/12/22(水) 03:26:29

615 ：デフォルトの名無しさん：2010/12/22(水) 07:32:36

>>611
おまえ馬鹿か？

俺みたいなのが日本に数万人いたって、
普及するかどうかにはほとんど影響ないよ

俺は単にここで持論を発してるだけで、
普及を妨げる活動は一切していない。

>>610
> 単にそいつがハッカーだから
> どんな言語でも楽勝なだけでは？

そうだよ
手続き型に慣れまくってると関数型を学ぶ時にハードル高いよね
という根拠のほとんど無い馬鹿げた意見を時々見るが、
そんなことはない、むしろハードルを低くしていると言いたかった

616 ：デフォルトの名無しさん：2010/12/22(水) 08:23:05

>>615
中学受験で算数の難問を解いておけば、
中学で方程式も楽勝、的な議論だなぁ。

617 ：デフォルトの名無しさん：2010/12/22(水) 08:31:25

関数型も結局手続きを書いてるにすぎないってことだな

618 ：デフォルトの名無しさん：2010/12/22(水) 08:42:18

違うけど

619 ：デフォルトの名無しさん：2010/12/22(水) 08:47:54

そしてそれこそがパラダイムシフトが起きない原因

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

プログラミングが示す範囲が相互に異なると会話が成り立たない
パソコンを制御するのが目的なら手続き型だし
数式を解くのが関数型の役割だろう
学生は関数型に触れる機会がわりとあるかもしれないが
社会に出てからは関数型が必要になるような問題を表現する機会はない
このスレの対立構図は学生対社会人であるに違いない

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

> 社会に出てからは関数型が必要になるような問題を表現する機会はない

どんだけ狭い社会だ。
おまえの住む社会には論理回路も金融デリバティブも存在しないのか。

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

どんだけ狭い社会だ。
おまえの住む社会には論理回路や金融デリバティブやってる人間がそんなにいるのか。

623 ：デフォルトの名無しさん：2010/12/22(水) 10:06:08

流石、論理の逆裏対偶もわからないようなら、関数型言語が理解できないのも道理だ。

624 ：デフォルトの名無しさん：2010/12/22(水) 10:26:05

言葉の問題にすりかえても意味はない
結局頭の中で手続きを考えていたら手続きを書いているんだよ

625 ：デフォルトの名無しさん：2010/12/22(水) 11:02:02

> 結局頭の中で手続きを考えていたら手続きを書いているんだよ
　↑言葉の問題にすりかえても意味はない

626 ：デフォルトの名無しさん：2010/12/22(水) 11:02:49

むしろ業務系こそ関数型でやるべきだと思うぞ

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

>>615
> 手続き型に慣れまくってると関数型を学ぶ時にハードル高いよね
> という根拠のほとんど無い馬鹿げた意見を時々見るが、

馬鹿と一蹴するくらいだから

> そんなことはない、むしろハードルを低くしていると言いたかった

というのはよっぽど根拠があるんだろうな？

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

>>614
M$は本気で流行らす気ないからなぁ

629 ：デフォルトの名無しさん：2010/12/22(水) 13:29:11

マルチパラダイムは、文字通りパラダイムの壁を壊す
その壁はただ壊すだけで良い
創造性とか才能とかマーケティングとか必要ない

630 ：デフォルトの名無しさん：2010/12/22(水) 13:35:16

>>613
俺はExcelがいいと思うよ
スプレッドシートは手続き的でなくて宣言的・関数的な世界なので
もともと相性がいいと思う
今だってワークシート関数のifとか全部関数だし

ワークシート関数をもうちょっときれいにして
ラムダ式を使えるようにして
VBAとかいうロクでもないものの代わりに関数型言語でユーザ定義関数を
記述できるようにすればいいと思うんだ

631 ：デフォルトの名無しさん：2010/12/22(水) 14:50:31

ロータスノーツってLISP系じゃなかったか

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

>>606
意見としては分かるけど、いまさらBASICはどうかと思う。
現行のコンピュータの何たるかを学ぶということでは、アセンブリ言語のほうが良いし、次点でC言語。

逆に、たんに手続き的なフローチャートの思考法を学ぶということでは、perlとかPHPで良いんでは。
Webページを動的に生成できたら楽しいし。

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

現代風の BASIC なら悪くないと思うけどね。ちゃんとサブルーチン書けるし。

もしグローバル変数しかない古典的な BASIC がベストとか思ってるなら見識を疑う。

634 ：デフォルトの名無しさん：2010/12/22(水) 19:11:40

>>633の視点だとアセンブリ言語は真っ先にアウトになるな

635 ：デフォルトの名無しさん：2010/12/22(水) 19:13:36

宗派関係ない勉強会に参加したらHaskellerだというだけでおもしろがられた。
関数型言語は漫才言語じゃねーぞ

636 ：デフォルトの名無しさん：2010/12/22(水) 19:14:00

>>620
> 数式を解くのが関数型の役割だろう

関数型プログラミング言語の役割は数式を解くことではないよ。
役割というと語弊があるが、手続き型も関数型も、
ともに目的はコンピュータを制御することだ。

>>627
> というのはよっぽど根拠があるんだろうな？

どうせ俺が何を言っても君は信じないだろう。
そこで百聞は一見にしかずだ。
その辺の（自他共に認める）ハッカーに関数型を学ばせてみろ。
初めは大いに戸惑うだろうが、すぐに理解し、使いこなすようなる。

637 ：デフォルトの名無しさん：2010/12/22(水) 19:43:25

>>632
現行のコンピュータの何たるかを学ぶのが目的なら、アセンブラもいいと思うよ。

でも、プログラミングというものに初めて触れ、
「コンピュータを制御するためにうまく文を構成する」ことを学ぶのなら、
やはり俺は BASIC を奨めるな。
アセンブラではプリミティブ過ぎて「文を構成する」というのが理解しにくい。
それに BASIC は意味を理解させるのが容易だ。

あくまで、初めてプログラミングを学ぶ者を対象とした話ね（>>606 はそういう話）。
学問として学ぶのは、おそらく小学校の授業が最初だろうと思われる。

およそコンピュータを制御するためのプログラミング言語全てに共通する、
根底にある考え方や、仕組み、なんたるかなどを学ばせる必要がある。
その目的なら BASIC でなくともビジュアルプログラミング言語でもいいとは思うが、
そうすると今度は教師の方が「教え方」を改めて学ぶ必要があるからね。

枯れているというのも BASIC の強み。

638 ：デフォルトの名無しさん：2010/12/22(水) 20:02:02

別にいきなりHaskellでも良いと思うけどな
操作的意味論については、IOをやるときに嫌というほど考えることになるだろう

そんなことより初心者向け言語で重要なのは、
・本質的でない面倒臭さがない
・型安全(動的型含む)
だと思う

639 ：デフォルトの名無しさん：2010/12/22(水) 20:21:08

>>638
> 別にいきなりHaskellでも良いと思うけどな

だれが教えるんだね

640 ：デフォルトの名無しさん：2010/12/22(水) 20:24:01

さあね
>>606に反論しただけ

641 ：デフォルトの名無しさん：2010/12/22(水) 20:27:45

>>636
天才ハッカー君が関数型を容易に覚えても
「むしろハードルを低くしている」根拠にはなってないで。

まあ俺も関数型の普及しない第一の原因は
最初に習わないからというよりも
ゲームが作りにくい、金になりにくいからだと思うが

642 ：デフォルトの名無しさん：2010/12/22(水) 20:34:42

>>638
型安全(動的型含む)
ここのところを解説を。

643 ：642：2010/12/22(水) 20:36:08

ここのところの解説を。

644 ：デフォルトの名無しさん：2010/12/22(水) 20:37:12

タイプシステムがC/C++みたいに不定／未定義な動作を引き起こさないってことを
言っているのでは

645 ：デフォルトの名無しさん：2010/12/22(水) 20:39:46

>>644
Prologのように事実上型がない(型概念がない)言語は
どういう扱いになるのだろうか。

646 ：デフォルトの名無しさん：2010/12/22(水) 20:40:03

>>642
変なコードを書いたときにすぐ未定義動作が起こって、
・アクセス違反で強制終了
・メモリが黙って書き換えられて誤動作
・まったく問題なく動作
という現象が一貫性なく起こる言語は、
・初心者にとってデバッグが異様に難しいことがある
・間違ったコードが間違っていることが分かりにくい
という点で教育向きではないと思う

647 ：デフォルトの名無しさん：2010/12/22(水) 20:40:52

初心者ならCよりよほど取っ付き易いかもな

648 ：デフォルトの名無しさん：2010/12/22(水) 20:47:25

型安全というのは、コンパイル時に型検査によって、不正な操作をしない
ことが保証されているという意味だと思っていたが、コンパイル時という
のは狭すぎ? たとえば、JAVAは中身と違う型にダウンキャストしようとする
と、例外が出るよるが、これも型安全の範疇にはいるのか?

649 ：デフォルトの名無しさん：2010/12/22(水) 21:12:25

それは型チェックをちゃんとしてて、それゆえ例外を出すという
定義された動作をしてるわけだから、立派に型安全なのでは

一方Cでprintf()やscanf()に書式指定と違う型の引数渡しても
Cの仕様の範疇では誰もチェックしないし、挙動も未定義
（gccは拡張仕様でprintf()の引数の型をチェックするけど）

650 ：デフォルトの名無しさん：2010/12/22(水) 21:47:52

なるほど。printf&scanfは可変長引数をとる「やくざな」関数なので、
いたしかたないとは思うが、こういう基本的な関数がやくざな関数
で提供されているところが(初心者向けとしては)よくない言語だな。

Cのような言語でもう少し安全な言語としてはFortran(90以降)がよい
のではないか。
・組み込みの強力なI/O (read/write「文」)
・強い静的な型付け
・モジュールの概念
・配列の境界検査が可能 (コンパイルオプションで指定)

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

>>650
printf()は端的な例だから挙げたけど、
例えばCのポインタはvoid*とキャストも何も無しで
相互に変換可能なので、いずれにせよ型付けは弱いと思う

まあ俺は>>638ではないので、>>638がどういうつもりでのレスだかは知らないけどｗ

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

>>631
あーそうなん？
悪貨が良貨を駆逐した例ってことなんかな？ｗ

653 ：デフォルトの名無しさん：2010/12/22(水) 22:30:03

初心者なればこそCはやるべきでしょ
Cできないんじゃお話にならない

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

初心者は高級言語から入ったほうがいい

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

>>653
誰もCをやるなとは書いてないじゃん
Cから始める人、Haskellから、VBからと多様性があるのは悪い事でもあるまい

656 ：デフォルトの名無しさん：2010/12/22(水) 22:42:17

なんでもいいが、
最低限実行ファイルが作れる言語な

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

>>656
なぜ

658 ：デフォルトの名無しさん：2010/12/22(水) 22:43:36

初心者こそマシン語アセンブリ語からやるべき
その次はLisp、その後にC

659 ：デフォルトの名無しさん：2010/12/22(水) 22:52:34

>>651
haskellのunsafeCoerceはどうよ？
その論理だと、haskellもC同様型付けは弱い言語になるのでは

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

>>659
Cだとキャストとかcoerceのために何の呪文も唱えず
ごく普通にこういう風に代入できるし、勿論誰もチェックしないし、
ポインタを使ったunsafeなコードを隔離するのも困難なので
さすがに一緒にはできないのでは

void *p = "Don't do this" + 1;
int *np = p;
*np++ = 12345;

661 ：デフォルトの名無しさん：2010/12/22(水) 23:22:25

>>657
作ったプログラムを配布しやすいからじゃないか?
初心者が自習するのには、関係ない話ではあるが。

>>659
void*、union、...(さらに、マクロも入れるべきか)は、一種の「呪文」だと思う。安上がりで、
genericityを手に入れるための。

662 ：デフォルトの名無しさん：2010/12/22(水) 23:27:45

なるほど、そういう見方もあるか
Cの問題は、ごく普通のプログラムでもしばしばその種の呪文に触れる
必要があるってことかな

663 ：デフォルトの名無しさん：2010/12/22(水) 23:49:01

Cのvoid*型とJavaのObject型の違いは、実行時のチェックだよ

なのに、静的な型付けのおかげで安全だ、とミスリードする
こういう呪術的なものは本当にごく普通にある

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

コンパイルチェックや実行時チェックは、いざ正常に出来上がって動き出したら無駄な負荷でしかない
デバッグモードで詳細が取れれば言語仕様を安全にする必要はないんだが

665 ：デフォルトの名無しさん：2010/12/23(木) 00:10:50

なんか今日になってみんな書きこみだしたけど、もしかして規制解かれたの？

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

>>664
お前の言う「正常に出来上がって動き出したら無駄な負荷でしかないコンパイルチェック」
って何の事だ？

667 ：デフォルトの名無しさん：2010/12/23(木) 00:16:40

JIT

668 ：デフォルトの名無しさん：2010/12/23(木) 02:21:28

Rがいいんじやないか。手続き型、関数型両方書けるし。

669 ：デフォルトの名無しさん：2010/12/23(木) 02:36:51

>>658
マシン語アセンブリ語やれば自動的にCもできるじゃん
Cなんて汎用アセンブラ以外の何者でもないだろうに

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

Mathematicaやってろよ

671 ：デフォルトの名無しさん：2010/12/23(木) 02:44:05

ためして見るには目玉が飛び出るお値段

672 ：デフォルトの名無しさん：2010/12/23(木) 08:58:29

>>634 スタック使えよ

673 ：デフォルトの名無しさん：2010/12/23(木) 13:11:16

関数型言語って何？それ極めると、C言語で再帰関数が簡単に書けるようになるの？

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

>>673
頭が良くなる

675 ：デフォルトの名無しさん：2010/12/23(木) 13:23:50

すげぇや！^q^

676 ：デフォルトの名無しさん：2010/12/23(木) 13:34:31

>>673
たとえば10進数を2進数に変換するときに
順番に2で割っていって最後に逆順に表示
ってことをやるんだけどこれを再帰的に
プログラムに書くとどうなりますうか？

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

>>676
Haskellだと、例えばこんな感じかな：
num2binlist n = let{ f 0 [] = [0]; f 0 l = l; f n l = f (n `div` 2) (n `mod` 2 : l) } in f n []

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

>>673
大雑把に言えば、関数型言語は
全ての計算を（写像とほぼ同義な）関数の評価によって行う言語だよ。

一方Ｃ言語なんかの手続き型言語は、
状態を変化させる命令によって全ての計算を行うんだよ。

> それ極めると、C言語で再帰関数が簡単に書けるようになるの？

「再帰」というものの考え方はどの言語でも同じだよ。
だから、例えば Java を極めればＣでの再帰関数が簡単に書けるようになる、
とも言えてしまう。
Ｃ言語で再帰が理解できない人は関数型でも他言語でも理解できないよ。
どれでも理解するのに同じくらいの努力が必要になるね。

ちなみに関数型では、現実的には再帰計算を明示的に記述することはあまりないよ。
ふつうは再帰計算を暗黙的に行う高階関数（関数を引数に取ったり返したりする関数）が
すでにライブラリで用意されているから、可能な限りそれを駆使するよう努める。

その方がプログラムソースの見通しが良くなるし、
おまけとしてコンパイラの最適化機能を働かせるのが簡単になるからね。
（これについては私が知ってるのは Haskell だけだが、他の言語でも似たようなものでしょ）

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

(defun num2binlist (n)
　(labels ((f (i binlist)
　　　　　　　(if (zerop i)
　　　　　　　　　(or binlist 0)
　　　　　　　　　(f (truncate (/ i 2)) (cons (mod i 2) binlist)))))
　　(f n nil)))

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

>>676 すちぇめ
(define (f x)
(if (= x 0) '()
(begin (f (quotient x 2)) (display (logand x 1)))))

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

Cだと
void printbin(unsigned n)
{
if (n > 1) printbin(n >> 1);
printf("%u", n & 1);
}
ってとこだろ

これだけだとCでも十分短くて大して変わらんけど、
これでは印字する以外の使い道が無いので汎用性が低い

リストのような形で数の列を簡単に扱える言語なら、印字するのではなく
リストを返す関数にすれば汎用性を高められる

この例だと生成される数の列が有限にしかならないが、
そうとは限らない問題の場合は、無限リスト的な物を扱える言語なら、そう作ることで
より汎用性を高められる

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

haskellだとモナドのおかげで
とりあえずprintしといて後でreverseできるよって例を書こうとして
ググってもビット演算子が出てこんから挫折した＼(＾o＾)／

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

たとえば10進数をｎ進数に変換するときに
順番にｎで割っていって最後に逆順に表示
ってことをやるんだけどこれを再帰的に
プログラムに書くとどうなりますうか？

684 ：デフォルトの名無しさん：2010/12/23(木) 16:44:51

>>682
あるよー。超あるよー　bit演算子:
http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Data-Bits.html

685 ：デフォルトの名無しさん：2010/12/23(木) 16:46:21

>>683
http://hibari.2ch.net/test/read.cgi/tech/1289292155/477
関数型言語でどうやるかはしらない。

686 ：デフォルトの名無しさん：2010/12/23(木) 17:18:24

>>682
2進数は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

687 ：デフォルトの名無しさん：2010/12/23(木) 19:20:00

>>684
超ありがとう。満足♪
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

688 ：339：2010/12/23(木) 19:36:49

>>341
規制で書けなかった
おまえは一行で言語の仕様を全て把握できるんだな？
定義しようが同じ関数には違いないんだろ？
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の思想を優先したに過ぎない
「プログラマーのできることを制限しない」という思想だ
すなわち高級言語とは真逆の思想だ

689 ：339：2010/12/23(木) 19:38:22

ボール投げる方は単純化した
a(b)
aとbが関数でありxクラスを受け取ってxクラスを返すものとする
するとaとbを入れ替えて書くこともできる
入力に関わらず同じ値を返す関数を想像してくれ
全体の関係は変わるがaとbの定義は変わらない
述語と目的語が場面によって換わるので自然言語的とは言えない
e.f
OOPLで入れ換えるにはf.eを別に定義することになる
同じ名前であってもオブジェクトとメソッドという定義が変わる
したがって入れ換えることができず自然言語的と言える

人は理由も無く面倒なことはしたがらない
ましてそれが良くないと判っていればなおさら
つまり面倒であることが抑止力になるということ
関数型は自然言語的でないしそれっぽく書くのも面倒
上の例で判るように一文に関数を詰め込んだ方が書き易いから
思想が反映された書き方の違いこそ言語の違い
高級言語は何をできるかより何をできないかに存在意義がある
関数型はOOPLより少しできてしまうから低級なだけ
低級な言語を理由無く使おうとしないのが人間の心理
普及させたければ使う理由を作ってやれば良い

690 ：339：2010/12/23(木) 19:40:57

概念を説明するのって難しいな
じゃあ自分と何かとの関係を考えてみてくれ
├──関係─→┤＿＿何か＿＿│
関数型であればこうなる
├──関数─→┨＿＿何か＿＿┃
何かが関数であればこうなる
├──関数─→┨＿＿関数＿＿┃
関数は直接扱える
扱えないと既に関係を扱っていることと矛盾するため
関数を直接扱えるということは関数を知ることができる
関数は関係そのものだから関係も"知ることができる"
どこからどの関数なのか境界が曖昧になるところに注目
それこそが参照透過性や遅延評価の有無になる

OOPLであればこうなる
┃＿＿＿オブジェクト＿＿＿＿┃
├─メソッド→┨＿＿何か＿＿┃
何かがオブジェクトであればこうなる
┃＿＿＿＿＿＿＿オブジェクト＿＿＿＿＿＿＿┃
├─メソッド→┨＿＿＿オブジェクト＿＿＿＿┃
├─メソッド→┼─メソッド→┨＿＿何か＿＿┃
オブジェクト以外の何かは直接扱えない
直接何かを扱うことがオブジェクトの定義に反するため
従ってメソッドは直接扱えず知ることができない
メソッドは関係そのものだから関係も"知ることができない"

関数型はミクロの関係を扱おうとする
OOPLはマクロの関係を扱おうとする
相反する概念なのだから良いとこ取りはできない
関数型言語を知らなくても本質は語れる
関数とオブジェクト指向を理解してればな
これでも解らないならもう知らん

691 ：デフォルトの名無しさん：2010/12/23(木) 20:33:55

>>339
そうだな、俺が悪かった、もう許せ

692 ：デフォルトの名無しさん：2010/12/23(木) 21:25:59

純粋関数型が流行るとして主として何に使われるの？
>>622は論理回路、金融デリバティブと書いてるが他にもある？

693 ：デフォルトの名無しさん：2010/12/23(木) 21:31:32

要するに
科学技術計算ではFORTRANに勝てず
低水準の仕事ではCやアセンブラに勝てず
事務計算ではCOBOLに勝てず
WebではJavaやLLに勝てないから
きんゆうでりばてぃぶとかになるのか？

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

構文解析

695 ：デフォルトの名無しさん：2010/12/23(木) 22:00:50

>>692
おもちゃとして遊びに使われるに決まってる

おれは Haskell で遊んでるぞ

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

結論　：　実用に使えない高級なおもちゃ

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

市民講座で年寄りに覚えさせればボケ防止になる

698 ：デフォルトの名無しさん：2010/12/23(木) 22:25:29

GHC：ばあさんや、manyはまだかの？
parseん：じいさん、manyはさっき(コンパイラが)食ったばかりですよ

699 ：デフォルトの名無しさん：2010/12/23(木) 22:44:52

ボケってのは知能が低下するんじゃないんだよ
状況とか価値の判断がおかしくなるんだよ
幼児よりもキチガイに近い
もともと頭の悪かったやつにプログラミングなんてやらせても意味ない

700 ：デフォルトの名無しさん：2010/12/23(木) 22:49:11

>>693
さすがにCOBOLには勝ってるのでは…

それと、低水準の処理でアセンブラに「勝てる」言語など、永遠に登場しないだろう。
コンピュータ・アーキテクチャが変わりでもしない限り。

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

>>700
いやマジでつっこまれてもｗ

COBOLって任意桁数のBCD演算やらISAMやらを組み込みで持ってて
メインフレームの固定長データセットに非常に相性が良いようだし
COBOLが使われてる分野では未だに圧倒的なシェアを誇る言語だと
思っていたけど、何しろ全然詳しくないので…

事務処理の世界はもう関数型の独壇場だったのか？

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

そんなことない。絶賛Javaで書き直しまたはそのままCOBOLで放置プレイ中だよ。

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

関数型で事務処理は聞いた事がないが、探せばあると思う。

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

あんまよく知らないんだけどいわゆる事務処理って何？
例えば給与明細の紙を出力するためにデータベースからデータを取ってきて
それを整形表示して印刷とかそんなの？

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

会社が事務処理をコンピュータ化したものが事務処理の定義でいいだろう。
相当範囲は広い。

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

やはり今時なら、Webアプリが簡単に組めるよ！と言い張れないと流行らないな。

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

まあ科学技術計算、低水準、組み込み、事務、webで
勝てないのに普及させるのは相当難しくないか？

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

>>704
うん俺もそんなんをイメージしていた
汎用機にもツリー型とかリレーショナルなデータベースはあるはずだけど
固定長のISAMファイルって要するに簡易的なデータベースだから
ただのISAMでやってるケースも多いのではと思われ
バッチだけでなくオンライン的な処理が必要な場合は
資源管理のためにトランザクションモニタとかジョブキューとか使うんだろう

Javaは特別にその種の仕事に特化した言語じゃないから、
J2EEあたりのブクブクに太ってた頃のJavaでリプレースしようとして
泣いた会社は結構あるのでは
全然詳しく無いし、ただの想像だけど

709 ：デフォルトの名無しさん：2010/12/23(木) 23:50:11

ゲームで勝てるとある程度普及する

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

>>700 そういえばデータフローマシンのアセンブラはアセンブラじゃなかったわな

711 ：デフォルトの名無しさん：2010/12/23(木) 23:53:35

老人ホームが特許庁の大規模システム開発を受注するくらいだからな

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

今ゲームで多用されてるのって何だろ
C++, Java, C#, Flash/ActionScript, Luaといったあたり？

713 ：デフォルトの名無しさん：2010/12/24(金) 00:06:06

VHSもインターネットもアダルトの貢献は大きい。
アダルトに特化するしかない

714 ：デフォルトの名無しさん：2010/12/24(金) 00:06:32

>>712
メーカによりけりだろ？
メーカー固有のゲーム製作言語とかあったりするし…

715 ：デフォルトの名無しさん：2010/12/24(金) 00:09:36

>>713
つまり「大人のおもちゃ」か！

716 ：デフォルトの名無しさん：2010/12/24(金) 00:22:33

人間は禁止されると無性にしたくなるからな
Real World Haskell を成人図書コーナーに置けば
中高生が隠れて読み耽るだろう

717 ：デフォルトの名無しさん：2010/12/24(金) 05:45:44

>>700-701
http://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は普及が続くかも知れません。

718 ：デフォルトの名無しさん：2010/12/24(金) 07:46:13

なんで関数型の「流行る分野」を考えようとするのか分らんな
プログラムしてて楽しければ、役に立たなくてもいいじゃん

（応用じゃない）純粋な数学と同じだよ

719 ：デフォルトの名無しさん：2010/12/24(金) 07:48:44

>>718
なんで考えるかというとそういう趣旨のスレだから

720 ：デフォルトの名無しさん：2010/12/24(金) 07:49:13

>>706
Webアプリを簡単に組めないプログラム言語を
探す方が難しい。

721 ：デフォルトの名無しさん：2010/12/24(金) 07:52:41

俺はこんな難解な言語もマスターしているんだぜ！
数学的思考が出来ないドカタは理解出来なくて当然！

こういう上から目線が多いから、いつまでたっても普及しない。

722 ：デフォルトの名無しさん：2010/12/24(金) 07:53:07

プログラム言語の選択では、不適合な分野が
あると、将来その分野に進出するケースも
想定して忌避することはある。関数型言語の
場合ここら辺はあるのかな。

723 ：デフォルトの名無しさん：2010/12/24(金) 07:54:35

>>721
それは、はっきりいって、あると思う。

724 ：デフォルトの名無しさん：2010/12/24(金) 09:33:09

関数型言語は超高級関数電卓として大いに使われていると思うが。
まあ、プログラム言語としての利用じゃないわけだけどね。

725 ：デフォルトの名無しさん：2010/12/24(金) 10:14:05

Rとかかな？あれは関数型といっていいのか？

726 ：デフォルトの名無しさん：2010/12/24(金) 10:33:39

>>724
数値計算とか数式処理って専用のソフト使わないの？
matlabとかmathematicaとか

727 ：デフォルトの名無しさん：2010/12/24(金) 10:58:42

>>721
そもそも関数型を本当に普及させたいのかと疑問に思う
自分はポルシェを乗り回せるぜ、というひとは、ポルシェがカローラになるより
ポルシェのままのほうがうれしいのでは？

728 ：デフォルトの名無しさん：2010/12/24(金) 12:36:18

>>727
それもあるし、関数型が普及する必要があるとみんな思ってるのかも疑問

普及する必要あるのか？

無ければ普及しないぞ

729 ：デフォルトの名無しさん：2010/12/24(金) 13:23:24

>>721
Haskellは、IOモナドが分かりにくいのが一番の理由じゃないかな。
副作用を分かりやすく形式化したもののはずなのに、これが分かりにくくて普及しないって、にんともかんとも。

730 ：デフォルトの名無しさん：2010/12/24(金) 15:37:43

>>728
部分評価とか非正格評価は分散サーバとかに使える。
純粋ナンタラで美しいｨｨ！とか
モナドはストリームより表現力が上ｪｪｪ！
とかはどうでもいい。

731 ：デフォルトの名無しさん：2010/12/24(金) 15:56:03

>>728
普及した方が、給料は上がる。

732 ：デフォルトの名無しさん：2010/12/24(金) 16:29:50

>>731
一般に、普及すると仕事は増えるけど給料は下がるのでは

需要「だけ」が増えれば給料も上がるかもしれないが
そういう都合のいい普及の仕方ってあるのだろうか

733 ：デフォルトの名無しさん：2010/12/24(金) 16:49:37

>>732
普及の程度にもよるけど。10年後に世の中の主流が
Haskellになると周知されたら、今、ソフトウェアハウス
で月給40万のHaskellプログラマの月給は転職前提で
100万を超える。そういう意味で。それを夢見て。

734 ：デフォルトの名無しさん：2010/12/24(金) 17:01:22

なるほど、一種の先行者利益的なものを狙うわけか

735 ：デフォルトの名無しさん：2010/12/24(金) 17:43:36

2番じゃダメなんですよ。
1番でなくては。

736 ：デフォルトの名無しさん：2010/12/24(金) 19:11:45

>>731
その給料を出す方から見た関数型の必要性は？

737 ：デフォルトの名無しさん：2010/12/24(金) 21:20:09

>>726
最近の数値計算はMatlabとC、C++が主流っぽい

738 ：デフォルトの名無しさん：2010/12/24(金) 21:22:46

数式処理はMathematicaが圧倒的。遅いけど

739 ：デフォルトの名無しさん：2010/12/24(金) 21:29:58

金無いから Maxima 使ってる

740 ：デフォルトの名無しさん：2010/12/25(土) 00:21:59

数値計算に向いていようが普及とは殆ど関係無いだろ。
やはり、Webかクラウドに最適だと言えなきゃね。

741 ：デフォルトの名無しさん：2010/12/25(土) 00:53:53

erlangがほとんど話題に上がらないのはなぜ？

742 ：デフォルトの名無しさん：2010/12/25(土) 01:04:59

エロランゲージ？

743 ：デフォルトの名無しさん：2010/12/25(土) 01:15:03

一時期良く言われてた、関数型言語の方がマルチスレッド向きで、
マルチコアCPU時代のプログラム言語は関数型言語でウッドボールって
説はどうなったの？

最近、あんまり聞かないから、フカシだったの?

744 ：デフォルトの名無しさん：2010/12/25(土) 01:57:05

>>742
「ねぁ、はやく。はやく、あなたを感じたいの！」
「ふふ…　ここかい？　ここが君のメールボックスなのかい？」
「そうそうよ。はやく、あなたの…　あなたのメッセージを私にいれて」
「いいね？　一緒に動くんだよ」
「いいから、はやくあなたのメッセージをいれてったら！」

>>743
「あら？　早漏？」

745 ：デフォルトの名無しさん：2010/12/25(土) 02:34:54

>>743
ItaniumのEPIC向けの最適化にも関数型言語が適してるなんて話もあったなｗ

746 ：デフォルトの名無しさん：2010/12/25(土) 02:52:54

＞関数型言語の方がマルチスレッド向き
って、以下の考え方でおｋ？

(L1 L2 L3 ... Ln)
で、L(k+1)はLkの結果とは関係がない
Lｋは互いに無関係だから別々のスレッドで処理できる
さらにLkは
(M1 M2 ... Mn)
で、M(k+1)は以下略

どんどんスレッド増えていくからうまくいってないのかな

747 ：デフォルトの名無しさん：2010/12/25(土) 03:00:50

参照透過性がスレッドの独立性を保証するというコンセプトなんだと思うけど
条件が厳しすぎると思う。状態の概念は導入しないと。

748 ：デフォルトの名無しさん：2010/12/25(土) 05:50:09

コンパイラが重過ぎてヤバイ空気が漂ってる

749 ：デフォルトの名無しさん：2010/12/25(土) 09:12:08

あと数年の辛抱

750 ：デフォルトの名無しさん：2010/12/25(土) 11:18:39

簡単にスレッドとして切り裂けても実用的な縦方向の長さを確保するコンパイラ技術が伴ってなかったからだと思うなー

751 ：デフォルトの名無しさん：2010/12/25(土) 13:20:41

>>721
関数型って難解なのか？

何年もかけて習得した手続き型でのテクが使えないから
最初は手も足も出ないが

752 ：デフォルトの名無しさん：2010/12/25(土) 13:40:50

手続き型でのテクって何だ？

753 ：デフォルトの名無しさん：2010/12/25(土) 13:56:00

haskellの日本の第一人者っていないの？
結城浩とかえぴすてーめーとかやねうらおｗとか

754 ：デフォルトの名無しさん：2010/12/25(土) 13:56:51

単純に比較できないがHaskellの仕様書のページ数はC++の1/3以下、Javaの半分しかない

俺選　ザ・手続き型コード
while(*p++=*c++){}

755 ：デフォルトの名無しさん：2010/12/25(土) 13:56:56

難解というわけではないな
ただ鉄痔木型のノウハウがあまり通用しなかったりするのもたしか

756 ：デフォルトの名無しさん：2010/12/25(土) 13:59:12

>>752
例えばJavaを書いてる人がRubyを習得するのは「比較的」楽だろう。
その習得を容易にさせた何かの総称。

Rubyを触った時は方言が聞き取りにくいが日本のどっかって感じだが
Hakellを触るのは外国に来た気分だった。

757 ：デフォルトの名無しさん：2010/12/25(土) 14:03:16

既出だがその手続きプログラマの習得コストが普及を妨げてるよな

758 ：デフォルトの名無しさん：2010/12/25(土) 14:15:54

長年の手続き型の経験で手続き型の考えが染み付いてるというのはすごいある

ワードカウントといったら辞書にワードを挿入、カウントをインクリメント
するんだろ、とかまず発想するし
深さ優先探索といったらスタックの出し入れだの枝のマーキングだのを考える
そもそも「深さ優先」とかいう時点で計算の順序を思いっきり想定している

759 ：デフォルトの名無しさん：2010/12/25(土) 14:22:42

>>752
ループと外部イテレータ。
ループが外部に晒され、副作用も晒される。

外部イテレータがあれば内部イテレータも簡単に書けるが、逆は難しい。
つまり、副作用ありの言語で副作用を隠蔽するのは簡単だが、逆は難しい。

760 ：デフォルトの名無しさん：2010/12/25(土) 14:51:30

ところで関数型の一番の利点ってどういう所なんだろ？
それとおすすめの関数型言語の本があったら教えて欲しい
来年はとりあえずその言語の習得から始めようかと思ってるんで

761 ：デフォルトの名無しさん：2010/12/25(土) 15:04:32

調べる木がないならまた来年な

762 ：デフォルトの名無しさん：2010/12/25(土) 16:07:37

>>760
もう「関数型の」利点なんて大して無いんじゃね
俺にとって使い易い言語がたまたま関数型だっただけだと思ってる

「プログラミングHaskell」おすすめ

763 ：デフォルトの名無しさん：2010/12/25(土) 16:13:27

>>762
それを読んだら、「関数プログラミング」もおすすめ

764 ：デフォルトの名無しさん：2010/12/25(土) 17:30:30

再帰書いたら「わかりにくいのでfor文で書き直す様に」と言われるこんな世の中じゃ

765 ：デフォルトの名無しさん：2010/12/25(土) 17:36:03

意味もなく末尾再帰で最適化されてもいない、
スタックを浪費するだけのアホ再帰は有害。
半端に関数型かじった生半可な奴がよく書く糞コードの典型例。

766 ：デフォルトの名無しさん：2010/12/25(土) 17:38:53

再帰がスタック制限で実用的でないのがポイズン

767 ：デフォルトの名無しさん：2010/12/25(土) 17:41:41

>>765
再帰が見えない連中の典型的なコメント。
ここで、「見える」とは棋士が「読む」のでは
なく、一瞥で決める。そういう意味。

768 ：デフォルトの名無しさん：2010/12/25(土) 17:45:06

「なんとなく再帰」は許されないのか？
世知辛い世の中だな。

769 ：デフォルトの名無しさん：2010/12/25(土) 18:06:51

再帰で書かれたクイックソートよりループ展開したクイックソートのほうが
わかりやすいという奴がいたらお目にかかりたいものだよなw

770 ：デフォルトの名無しさん：2010/12/25(土) 18:22:19

>>757
自分の知っている事を事前条件にしようとしてるって意味で
プログラム言語だというくくりで学習しようとするから成長曲線が鈍るんだよね

パラダイムシフトって単語使うのはいやだけど考え方が違う物なのだから、
一度自分は何も知らないって地点に立ってくれるだけで楽に学習可能なハズなんだけど
そういう事をするには既存言語で得た地位が高いプライドになって邪魔してる感じ

771 ：デフォルトの名無しさん：2010/12/25(土) 18:32:25

>>767
「早すぎる最適化は諸悪の根源である」という格言を知らない人なのかも
知れないけど、たんに再帰を苦手な人が「パフォーマンスが悪いから書くな」と
言っているだけのことが多いんだろうな

772 ：デフォルトの名無しさん：2010/12/25(土) 18:36:05

手続き型で再帰書くときは、一旦関数型でコード書いてる
なんつーか手続き型でいきなり書くとしっくりこないw

773 ：デフォルトの名無しさん：2010/12/25(土) 18:37:21

>>770
> 一度自分は何も知らないって地点に立ってくれるだけで
簡単にいうけど、そう簡単なことではないのでは

多くの人にとってプログラミング言語は単に目的を達成するための手段で、
慣れた言語なら簡単に達成できることのために一度全てを捨てるほどの
多大な努力を必要とするなら、よほどの動機付けやメリットが必要になる

774 ：デフォルトの名無しさん：2010/12/25(土) 18:37:50

>>760
一番の利点はプログラミングに対する学習コストが下がることだと思う
駆け出しの頃、iとかjとか色々な変数の意味の解析からしなきゃならなくて
クイックソートのコードってなんて難しいんだって思ったものだけど
あれがHaskellであったなら、すっきり理解できただろうと思う。
短い上、リスト内包表記と再帰理解すればいいだけだし

775 ：デフォルトの名無しさん：2010/12/25(土) 18:40:48

>>774
それぐらいの話なら関数型言語である必要は無い気がする
要は高級言語であればいいんだよね、Pythonみたいな
リスト内包も再帰も使えるよ

776 ：デフォルトの名無しさん：2010/12/25(土) 18:42:05

>>774
クイックソートは末尾再帰じゃないから、手続き型でもループは使わないよ
その思い出話は捏造くさい

777 ：デフォルトの名無しさん：2010/12/25(土) 18:42:33

>>1
高階関数の使用に原因がある、という意見はあまり聞かないが。
人間の問題の解く際の理解力、構成力の個人差を考えると、凡庸
な頭脳の持ち主にとって、障壁になりそうなのは、ここら辺り。
頭がオーバーヒートして、思考停止に陥る危険があるのかも知れ
ない。この問題が原因だとすれば深刻。

778 ：デフォルトの名無しさん：2010/12/25(土) 18:44:56

>>777
higher order functionを難しい人は確かにいるだろうけど、
そういう人はCでqsort()やsignal()、コールバックを使うにも困るはずなので、
別にぜんぜん関数型に限った話じゃない
そうした人はたんにプログラマに全く向いていない人であるというだけのこと

779 ：デフォルトの名無しさん：2010/12/25(土) 18:51:52

>>778
多くのプログラマが現に使えないし、多分、プログラマと
して向いていない。それにもかかわらず、プログラマとして
何十万人(多分もっとずっと多い)も存在している。

780 ：デフォルトの名無しさん：2010/12/25(土) 18:52:39

>>775
なんというかPythonはわりと関数型言語に近いと思うんだよね
何故関数型言語が普及しないのかってスレだけどさ
普通の言語にどんどん関数型の機能が取り入れられてるから
関数型の考え方はどんどん普及してるってのが個人的な思い

少し言えば、理解コストについては、
型がある言語のほうが低いと思う
引数の型を調べるコストが減るからね
>>776
手続き型でも再帰の理解が必要ってのは省いたよ

781 ：デフォルトの名無しさん：2010/12/25(土) 18:59:54

>>780
うん、現に今のメジャーな手続き型言語の多くが何らかの形で
ファーストクラスの関数的なものを扱えて、LISPのリスト処理能力をある程度
パクってる
手続き型をベースとしているけど、関数型の便利なところをどんどんパクっている
C#、JavaScript、Ruby、Pythonのような言語で特に困っていない人たちに
アピールできるようなメリットがなければ、なかなか普及は難しいんじゃないの

782 ：デフォルトの名無しさん：2010/12/25(土) 19:01:26

駆け出しの頃は関数って考え方があまりなかった
だから、コード量が多いと、些細な事でもこれはどういう意味だろうって考えて
アルゴリズムの重要な部分とは違う所で止まってしまう
関数型は手続き型に比べてそういうのが少ない

Win32APIとかでコードを書こうとしてた頃にやっと
「全部理解しようとすると結局挫折する」ってことを学んだけど
最初はそういうのわからなかったから結構勉強は時間かかった

あと、クイックソートは非再帰版も良く見るよ。スタック使うやつ
まぁスタック使えばどんな再帰もループに展開出来るわけだが

783 ：デフォルトの名無しさん：2010/12/25(土) 19:06:04

今時、スタックサイズの平均はどれくらい？　8MB？

無限ループしてない限りは、オーバーフローしないよね。

784 ：デフォルトの名無しさん：2010/12/25(土) 19:09:33

>>781
個人的には代数的データ型が欲しい
オブジェクト指向でinstanceofで派生クラスチェックとか、
全く型システムの恩恵を受けてる気がしない

785 ：デフォルトの名無しさん：2010/12/25(土) 19:13:28

>>783
長大なログファイルの1文字ずつ統計を取るような操作をしたらハングした

786 ：デフォルトの名無しさん：2010/12/25(土) 19:18:29

>>784
OOの人はそうした場合には継承とポリモーフィズムを使うのが染み付いていると思う
instanceofなんて使わないんじゃないの

787 ：デフォルトの名無しさん：2010/12/25(土) 19:24:10

>>786 つかうよ、マルチメソッドがなければ…

788 ：デフォルトの名無しさん：2010/12/25(土) 19:27:20

引数の型についても動的に解決するオーバーロードがあったらなぁ、ってことじゃないの？
CLOS の総称関数なんかはそうだけど。

789 ：デフォルトの名無しさん：2010/12/25(土) 19:31:04

instanceofはうまく書けば使わなくてすむgotoみたいなもの。必要になるとしたら書き方が間違ってる。
だから本来文法にinstanceofみたいなものを含むべきじゃない。
まあやっぱりgotoみたいなもので必要じゃないけど特定操作を簡潔に書くのに使えるような場面があれば別だけど。

790 ：デフォルトの名無しさん：2010/12/25(土) 19:35:25

>>786
List<Object>的なものを返すAPIとかどうしようもないよ
代数的データ型なら、パターンマッチだから
全てにマッチするパターンをわざと書かない手法(おすすめ)で
マッチ漏れは検出出来るし
新しく増やしてもコードを直すべき箇所はコンパイラが教えてくれる

791 ：デフォルトの名無しさん：2010/12/25(土) 21:35:52

>>753
Haskell布教を10年続けているnobsunこと山下伸夫さんと
Haskell連載を4年続けているshelarcyあたりでしょう。
継続性という点でこの二人が突出しています。

WWW.SAMPOU.ORG
http://www.sampou.org/
本物のプログラマはHaskellを使う
http://itpro.nikkeibp.co.jp/article/COLUMN/20060915/248215/

792 ：デフォルトの名無しさん：2010/12/25(土) 22:21:13

「本物のプログラマはHaskellを使う」は最近、
目次リストに reverse 関数が適用されて見難くなった

793 ：デフォルトの名無しさん：2010/12/26(日) 06:36:46

>>783
それで16M行あるCSVファイルを末尾再帰になってないアホ再帰で処理したらどうなる？

794 ：デフォルトの名無しさん：2010/12/26(日) 07:36:47

末尾再帰を最近覚えたのでうれしくてたまらないんだろうな

795 ：デフォルトの名無しさん：2010/12/26(日) 08:45:33

>>793の例も極端だけど>>783の考え方も良くないのは確かだろ

と思ったけど、もしかしてこういう考えはもう古いのか？

796 ：デフォルトの名無しさん：2010/12/26(日) 10:43:50

いや、古くないと思うけど
クイックソートあたりだと空間計算量がO(log n)だから再帰でも問題に
なりにくいけど、空間計算量がO(n)以上なら、わりと簡単に
スタックオーバーフローするでしょう

上で出てたpythonとか、デフォルトの再帰リミットは高々1000ですよ
1000回なんてループで回すならなんてことのない数字だけど

797 ：デフォルトの名無しさん：2010/12/26(日) 10:52:50

Schemeのような言語なら末尾再帰として書かれていればループに最適化されることが
保証されているけどそうでない言語も多いし
最近の賢いCコンパイラのように、末尾再帰として書かれていなくとも
（単純な例では）ループに最適化するものもある

要はケースバイケースかと

再帰＝悪、と単純に決め付けるのも良くないし、再帰で問題ないよ、と
言い切ってしまうのも良くない

798 ：デフォルトの名無しさん：2010/12/26(日) 11:56:13

再帰もそうだけど、手続き型言語に安易に関数型の考えを持ち込むのはうまくいかない
ことが多いな。
関数型を学び始めた頃、Javaコードがfinalだらけになったけど可読性を下げただけだった。
再帰だと木構造やグラフ構造の操作くらいにとどめておくのがいいと思う。

799 ：デフォルトの名無しさん：2010/12/26(日) 12:04:23

再帰とかダサいｗ
コンビネーションのほうが分かりやすく安全。

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

リストはグラフ構造ではないのかな？

801 ：デフォルトの名無しさん：2010/12/26(日) 12:39:22

>>798
関数型はべつにIORefを使うなとかfinalを使えとか言ってない。
実際、IORefを使うことが許されている。

関数型の考えを持ち込んだというのは嘘なんだよ。
本当は、誰が言ったか不明の匿名の意見を持ち込んだ結果うまくいかなかったんだ。

802 ：デフォルトの名無しさん：2010/12/26(日) 12:47:50

>793
スタックに積むのが1回当たりint 4つぐらいだとすると、16M回で256MBでしょ？
あらかじめulimitしとけば、実用上別に問題無いんじゃない？

803 ：デフォルトの名無しさん：2010/12/26(日) 13:15:22

スタックを自動で伸ばしてくれる言語を使っているかどうかで違うな

804 ：デフォルトの名無しさん：2010/12/26(日) 13:16:17

>>802
>>796

805 ：デフォルトの名無しさん：2010/12/26(日) 13:29:58

>>799
再帰で書いてあったコードをコンビネーションで
書き直した例を示してください。お願い。

806 ：デフォルトの名無しさん：2010/12/26(日) 13:59:31

>>799
コンビネーション？組み合わせ？コンビネータの間違い？ｗ

807 ：デフォルトの名無しさん：2010/12/26(日) 14:13:32

関数型言語で数十万行ほどのプログラムを問題なく書ける?
むかし書いたときは小さなプログラムだけで、大きなシステムは書ける気がしなかったのだが。
最近は違うのか?

808 ：デフォルトの名無しさん：2010/12/26(日) 14:15:32

>>807
Cで10万行ならhaskellで1000行だな

809 ：デフォルトの名無しさん：2010/12/26(日) 14:16:52

説得力が全然無いな、具体的な例有る?

810 ：デフォルトの名無しさん：2010/12/26(日) 14:17:18

>>807
簡単な問題を標準ライブラリ以外使わずに書いてみて比べてみればわかるんじゃない。

811 ：デフォルトの名無しさん：2010/12/26(日) 14:19:33

>>810
小さなプログラムなら。その様になるのは知ってる。
しかしだ、基本的によく使う処理は小さな関数群に集約する。
数十万行ともなると、ほとんどが目的のロジックだけになるんだが。いかが。

812 ：デフォルトの名無しさん：2010/12/26(日) 14:24:02

数えてみたらGHCは23万行くらい(コメント含む)

>>811
ロジックそのものが短く記述できるってことだろ
1/100は明らかに誇張だけど1/2くらいにはなるはず

813 ：デフォルトの名無しさん：2010/12/26(日) 14:31:26

>>812
GHCてなんですか？GHCの説明ページを教えて貰えませんか。

1/2ぐらいなら、妥当な気がする。でも1/2ぐらいだと、説得力が薄い気がする。
1/100なら広まらない理由が見あたらないので、嘘と確信できる。

814 ：デフォルトの名無しさん：2010/12/26(日) 14:32:18

>>813
http://www.haskell.org/ghc/

815 ：デフォルトの名無しさん：2010/12/26(日) 14:38:26

セミコロンで改行しなかったらインチキ臭いが
>>とか>>=なら改行減らしてもごまかせる

816 ：デフォルトの名無しさん：2010/12/26(日) 14:39:36

確かに行数よりトークン数で比較した方がそれっぽい
数えるのが面倒だけど

817 ：デフォルトの名無しさん：2010/12/26(日) 14:40:02

なんか上のほうで関数型言語は数値演算に向いているとかいうアフォがいるが、
機械学習とかであるような、100万 * 100万の行列同士の乗算をするような処理を
full lazyな関数型言語で書くことを想像するだけで気が遠くなる。

818 ：デフォルトの名無しさん：2010/12/26(日) 14:40:45

行数で比較とか、どこのドカタよ？
せめてサイクロマティック数とかで比較しようぜ。

819 ：デフォルトの名無しさん：2010/12/26(日) 14:41:09

>>813
Cの100分の1のプログラムを10倍の時間掛けて作るのがhaskell

820 ：デフォルトの名無しさん：2010/12/26(日) 14:47:41

>>818
言いたい事は分かるが。ここで、そこまでする必要性は感じなかったな。
そうやって、細かくする事で、一般的な簡単な理解を阻む事が。
関数型言語の広がりを阻害する例だね。

821 ：デフォルトの名無しさん：2010/12/26(日) 14:49:33

>>819
関数型は久しぶりだけど、ちょっとhaskellやってみるかな。

822 ：デフォルトの名無しさん：2010/12/26(日) 14:49:36

ゴチャゴチャ言わずhaskell使ってみろよ。
1年間どっぷり浸かれば良さも見えてるわな。
だいたい言語の良さなんて定量化できるもんでもないだろ。
ゴミみたいな数字なんか捨てろ。
いいか、プログラムってのは工業生産品じゃなくて工芸品なんだよ、カス
覚えとけ

823 ：デフォルトの名無しさん：2010/12/26(日) 15:01:13

悪いが、今、私は工業製品としての評価で何故広まらないか検討した。
工芸品だと言っている間は、普及は無理との結論だ。

824 ：デフォルトの名無しさん：2010/12/26(日) 15:08:38

>>819
作業量保存の法則だなｗ

825 ：デフォルトの名無しさん：2010/12/26(日) 16:02:51

>>824
保存していないように見えるのは俺だけか

826 ：デフォルトの名無しさん：2010/12/26(日) 17:06:34

>>825
俺も思ったｗ
時間10倍かかるんなら、作業量／コストも10倍
何文字／何行タイプしたかどうかははっきり言ってどうでもいい話

まあ普通はメンテやデバッグのコストも考えなければならないので
プロファイラ、デバッガ、リーク解析なんかのツールがどれぐらい使いやすいかとか
そういうのも響いてくるのでは

827 ：デフォルトの名無しさん：2010/12/26(日) 17:13:02

伝えたいことを無視して考えれば
1/100作るのに10倍かかったら、効率はCの1/1000

828 ：デフォルトの名無しさん：2010/12/26(日) 17:23:12

つまり関数型はゴルフという名前の工芸向けの言語ということだろう

829 ：デフォルトの名無しさん：2010/12/26(日) 17:27:43

>>813
Jなんかだと、本当に100分の1だけどね。

830 ：デフォルトの名無しさん：2010/12/26(日) 17:29:29

OSの記述には関数型が優れているという
話を聞いたが実際はどうなんだろう。

831 ：デフォルトの名無しさん：2010/12/26(日) 17:32:07

LISPマシン？

832 ：デフォルトの名無しさん：2010/12/26(日) 17:34:48

CだろうとPerlだろうと工業生産物には成り得ない。
ソフトウェアってのは一度作ったらコピーは自由なのだから、
本質的に創造の力が必要になる。
工場で大量生産するような類のものじゃない。
ソフトウェアの大量生産は簡単に一瞬でできるコピーでしかない。

833 ：デフォルトの名無しさん：2010/12/26(日) 17:36:58

>>831
そう。
日本人ではないけど、INTERLISPに関わってた人から聞いた。

834 ：デフォルトの名無しさん：2010/12/26(日) 17:41:20

ソフトウェアを開発する、ということに使用方法を限定し過ぎだと思う。
例えばマテマティカの言語は別にソフト開発するために便利なわけじゃなくて
数式取り扱うのに便利でそれなりに普及している。
統計処理のR言語もよく知らないけど、統計処理するために便利なので
普及している、と思われる。
こういう文脈でムリヤリ考えると、C++やJavaはそもそもソフトウェアを
開発するのに便利な言語として普及している、と限りなくそのままだけど、
考えることができる。

何が言いたいのかというと、関数型言語としての特徴をフルに発揮できる
分野自体を見つけるほうが筋がいいんじゃないか、ということ。

835 ：デフォルトの名無しさん：2010/12/26(日) 17:41:48

最近は時間計算量より空間計算量の最適化のほうがいいっていう話も聞くから
それがある面真実なのであれば
immutableなデータによりコピーが多発する関数型は
速度的に不利なんじゃないかと思う
OSの記述は楽だとしても

836 ：デフォルトの名無しさん：2010/12/26(日) 17:42:51

ソフトウェア開発を"工業生産"と位置付けているから
日本のソフトウェア産業は世界に遅れをとっているんだよ。

いわゆる詳細設計＝プログラミング
生産＝コピー
だと考えればもうちょっとマシになる。

837 ：デフォルトの名無しさん：2010/12/26(日) 17:43:23

>>833
それは凄い
LISPマシンなんて実物を見たことも無いよ…

>>834
面白い考え方だ

838 ：デフォルトの名無しさん：2010/12/26(日) 17:45:19

>>833
LISPがシステム記述に向いているのは、関数型だからじゃなくて、メタ機能が柔軟で強力だからだろ。

つうか、関数型言語の長所としてLISPの例を出されるとは思わなかった。

839 ：デフォルトの名無しさん：2010/12/26(日) 17:46:39

つまり本当に最強だったのはLISPということで

840 ：デフォルトの名無しさん：2010/12/26(日) 17:52:30

関数型言語で取り扱おうとする領域を狭く考えすぎだ。
むしろ関数型言語によって定量的だか定性的だかわからんが
一般的に低コストで取り扱いが可能になるような領域を明らかにする方向で
考えたほうが発展性があるよ。全然具体性がないけれど。

841 ：デフォルトの名無しさん：2010/12/26(日) 17:58:31

>>830
> OSの記述には関数型が優れているという
> 話を聞いたが実際はどうなんだろう。

実際にモノを作って証明するまでは
全部マユツバだと思えばいいよ。

842 ：デフォルトの名無しさん：2010/12/26(日) 18:00:06

ソフトウェアってのは最終的には
ハードウェアを動かすためのもので、
そのハードウェアが関数型言語で作られてない以上
関数型言語でハードウェアを効率良く動かすことはできない。
なんらかの変換が絶対に必要になる。

843 ：デフォルトの名無しさん：2010/12/26(日) 18:01:59

>>834
であれば、

1. 関数型言語としての特徴とは何か？
2. それがソフトウェアを開発するのに何故・どう妨げになっているか？

（C や Java ほどソフトウェア開発分野で普及しないのは
その特徴が妨げになってるからという前提の話）

と考えて、初めて「3. ではその特徴が活かせる分野は？」と
段階を踏んで考えないとまとまらないと思う。

まぁ、当たり前だが。

>>842
バーチャルマシンという考え方もある

844 ：デフォルトの名無しさん：2010/12/26(日) 18:03:30

ハードウエアは何型言語で作られているんだ？

845 ：デフォルトの名無しさん：2010/12/26(日) 18:04:19

>>842
> そのハードウェアが関数型言語で作られてない以上

逆に「ハードウェアが関数型ではない言語で作られている」というのは、
どういうこと？

846 ：デフォルトの名無しさん：2010/12/26(日) 18:11:29

>>843
言語の特徴が妨げになっている訳じゃないだろ
宣伝が足りない、実績が足りない、扱える人間が足りない、ライブラリが足りない、ツールが足りない

847 ：デフォルトの名無しさん：2010/12/26(日) 18:17:01

ハードウェア記述言語はどう見ても宣言型言語だぞ。
手続き的な記述のしかたもできるが。

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

今のパイプラインとかスーパースカラみたいなプロセッサアーキテクチャに対して
たとえばC言語が忠実に対応しているとも思えない

849 ：デフォルトの名無しさん：2010/12/26(日) 18:18:44

関数型言語の特徴からくる欠点
・階層キャッシュが効きにくい
・ヒープ消費の予測が立てにくい
・チューニングがむずかしい(特に非正格)
・ I/Oのオーバーヘッドが大きい
・トイプログラムと実用のギャップが大きい

850 ：デフォルトの名無しさん：2010/12/26(日) 18:25:39

>>849
>・階層キャッシュが効きにくい
これはオブジェクト指向言語も一緒だと思っていい？

>・ヒープ消費の予測が立てにくい
非正格だけじゃね

>・ I/Oのオーバーヘッドが大きい
>・トイプログラムと実用のギャップが大きい
そんなことないと思うが。何か例ある？

851 ：デフォルトの名無しさん：2010/12/26(日) 18:35:04

>>850
OOの場合は世代コンパクションで同世代オブジェクトが集められて若干マシじゃなかろうか。
関数型の場合はヒープ上での生成/消滅のタイミングがバラバラ。

852 ：デフォルトの名無しさん：2010/12/26(日) 18:39:56

>>850
OOPLのC++の場合基本的に自己管理。だから、階層キャッシュ自由自在。
LL言語の場合>>815

853 ：デフォルトの名無しさん：2010/12/26(日) 18:42:23

>・トイプログラムと実用のギャップが大きい
言語だけでなく、言語周りのいろいろな環境やサポート含め、とても大きいと思っている。
これが一番のネックじゃないかな?

854 ：デフォルトの名無しさん：2010/12/26(日) 18:42:36

>>852
>>851のタイポだろうか…

Bind演算子でなにかインチキをやるとかやらないとかいう
いけない話が目に入ったけど

855 ：デフォルトの名無しさん：2010/12/26(日) 18:49:02

Haskellだと教科書はStringを使っているけど実際はそれだと遅すぎる、とかそういうことかな
それなら分かるけど、そもそもデフォルトで非正格という言語設計が糞なのであって、
関数型言語の問題というのとは違う気がする

856 ：デフォルトの名無しさん：2010/12/26(日) 18:54:41

逆にOCamlのstringがmutableなのも僕はどうかと思いました

別にトイ向けでもいいんじゃないかなー
ただ、エロ画像を高速にダウンロードしたり
エロ画像を高速に仕分けしたりするような
俺の俺のための俺だけのトイプログラミングをするときって
LLしか使わないな俺は
楽だし！

857 ：デフォルトの名無しさん：2010/12/26(日) 18:57:01

>>855
糞は言い過ぎじゃない？
非正格のおかげで考えやすくなった経験を持つ人は少なからずいるし。

言うなら、＊＊というケースには非正格という言語設計は合わない、くらいでしょ。

その＊＊が多いから、じゃあ合っているケースは何なの？に繋がる話ならわかるが

858 ：デフォルトの名無しさん：2010/12/26(日) 19:01:14

細かいことだけどトイプログラムって言語やライブラリの学習/実験/デモ用のコードのことで、
書き捨ての実用コードは含めないよね、普通

859 ：デフォルトの名無しさん：2010/12/26(日) 19:04:34

なんでそんな言葉を使わなくちゃならないのか
理解できない。

860 ：デフォルトの名無しさん：2010/12/26(日) 19:04:35

俺にとって、書き捨ての実用コードはトイプログラム

861 ：デフォルトの名無しさん：2010/12/26(日) 19:04:47

>>857
でも、非正格性による考え易さの恩恵が、
非正格性によるチューニングの面倒臭さのデメリットを上回る分野ってそんなにあるかな

862 ：デフォルトの名無しさん：2010/12/26(日) 19:07:59

俺にはこの世にメンテするほどの価値ある他人のコードなんてあるとは思えないな。

863 ：デフォルトの名無しさん：2010/12/26(日) 19:09:03

>>861
一回haskell製のソフトのソースコードでも読んでこい。
読んでから発言しろ。

864 ：デフォルトの名無しさん：2010/12/26(日) 19:09:44

ゴチャゴチャ揚げ足取りたいだけの奴に反応するだけ時間の無駄。

865 ：デフォルトの名無しさん：2010/12/26(日) 19:50:44

>>863
Haskellなら日常的に使ってるが

866 ：デフォルトの名無しさん：2010/12/26(日) 19:53:02

>>865
お前のゴミコードじゃなくて人が書いたコードだよ

867 ：デフォルトの名無しさん：2010/12/26(日) 19:55:11

>>866
アプリを丸ごと読んだことはないような気がするけど、ライブラリの実装は良く読むよ

868 ：デフォルトの名無しさん：2010/12/26(日) 20:21:03

>>861
> 非正格性によるチューニングの面倒臭さ

どの程度を面倒臭いと言ってるの？
何か例を示してほしい

869 ：デフォルトの名無しさん：2010/12/26(日) 20:48:51

>>868
うっかりspace leakを入れてしまったときに特定するのが面倒
ループをチューニングするのにGHCのcoreを見ながらやるのが面倒
Stringが遅すぎるのでByteStringを使おうと思えば、
Stringほど手厚いサポートがない(たとえばshowの結果はString)ので面倒

それに遅延評価のオーバーヘッドが広く浅くかかるからトータルで性能が出にくいし

870 ：デフォルトの名無しさん：2010/12/26(日) 20:58:48

プログラムなんて結局は機械語になるわけだろ。

開発効率は置いといて、究極的には
機械語にするのが一番効率がいいんだよ。

で、機械語は手続き型で動作する。

871 ：デフォルトの名無しさん：2010/12/26(日) 21:11:58

>>870
なにを今さら

872 ：デフォルトの名無しさん：2010/12/26(日) 21:20:56

アセンブリ最強説再び

873 ：デフォルトの名無しさん：2010/12/26(日) 21:24:08

>>869
なるほど

> うっかりspace leakを入れてしまったときに特定するのが面倒
これは分る、同感。

> Stringが遅すぎるのでByteStringを使おうと思えば、
> Stringほど手厚いサポートがない(たとえばshowの結果はString)ので面倒

Stringほど手厚いサポートがない例が「showの結果はString」って何だ？
show の結果が String では困るケースがあるのか？

> ループをチューニングするのにGHCのcoreを見ながらやるのが面倒

ループのチューニングとやらが具体的にどのようなものを指しているのか分らん。

それほどまでのチューニングが必要なケースには
今の Haskell は不向きであることはよーく分る。

べつの分野を開拓した方が良さそうだよね。

874 ：デフォルトの名無しさん：2010/12/26(日) 21:30:25

>>870
> で、機械語は手続き型で動作する。

CPU に入力する機械語や解釈の構造が関数型というのは、
机上の空論だとしても理論的には可能なのかな？

そもそも、どういうのか想像もできんが

875 ：デフォルトの名無しさん：2010/12/26(日) 21:34:59

>>870
RISCとかVLIW系のCPUだとおまえの書いた機械語より
コンパイラの吐き出したコードの方が早いと思われる

876 ：デフォルトの名無しさん：2010/12/26(日) 21:46:19

>>874
そもそも「関数型」という理論はない
あるのは、一見関係ありそうで関係ない理論や
イデオロギーや風説などの社会現象だ

877 ：デフォルトの名無しさん：2010/12/26(日) 21:53:55

>>876
Lispマシンも手続き型の機械語ということ？

878 ：デフォルトの名無しさん：2010/12/26(日) 21:55:44

>>877
Lispマシンが手続き型なのか関数型なのかを判定する理論的な基準はないということ

879 ：デフォルトの名無しさん：2010/12/26(日) 22:21:30

>>878
それは、そもそも手続き型とは何か？関数型とは何か？
が論理的に定義されていないからなの？

それとも、そのレベルのものは論理的に定義されているが、
CPU に入力する機械語とは何か？ Lispマシンとは何か？
の方が論理的に定義されていないからなの？

前者なら、このスレ自体議論できないよ

880 ：デフォルトの名無しさん：2010/12/26(日) 22:54:06

>>877
主記憶がタグサポートしてるだけでCPU自体はスタックマシンだよ

881 ：デフォルトの名無しさん：2010/12/26(日) 23:04:56

スタックっていらなくね？
スタック使うようになってからだろプログラマがバカになったのは

882 ：デフォルトの名無しさん：2010/12/26(日) 23:49:10

経験者は語る

883 ：デフォルトの名無しさん：2010/12/26(日) 23:55:30

むしろスタックすら無い時代のプログラマって想像がつかない
マシン語でもスタックって使うよね？

884 ：デフォルトの名無しさん：2010/12/26(日) 23:56:17

スタックを使うとバカになる理由が見えない、そこんとこ詳しくおね。

885 ：デフォルトの名無しさん：2010/12/26(日) 23:58:41

8080CPU時代からスタックはあったわけで。　スタックがないって何時の時代だ

886 ：デフォルトの名無しさん：2010/12/27(月) 00:00:09

真空管を入れ替えてプログラミングしてた時代じゃね
それにしたってスタック的な何かを自前で実装して概念自体は存在した可能性はあるが

887 ：デフォルトの名無しさん：2010/12/27(月) 00:08:17

>>885
MN1617はなかった
あとIBMのメインフレームにも無いのあったきがする
iTMS9900シリーズも無かったかも（コレはレジスタがCWPしか無いのだったかも)

888 ：デフォルトの名無しさん：2010/12/27(月) 00:12:02

>>879
>関数型とは何か？

内包表記のような定義はできないが、ごく一部を具体的に列挙することはできる
いかにもありがちなシチュエーション

889 ：デフォルトの名無しさん：2010/12/27(月) 00:17:53

>>887　　
MN1617ちょっと調べたけど、命令表や内部構造は見つからなかった。
がしかし、関数コールが出来る以上。戻り先保存のスタックはあるはず。
無ければどうやって関数コールのネストするんだ?　それがスタックだろ。

890 ：デフォルトの名無しさん：2010/12/27(月) 00:27:01

>>889
私も MN1617 はしらないが、そのスタックは関数コールの戻り位置を記録する意外には使えないシステムスタックではないだろうか？
他にも、6809 や 68000 ではシステムスタックとユーザースタックが区別されている。

891 ：デフォルトの名無しさん：2010/12/27(月) 00:33:17

>>890
脱線しすぎる気がするけど、8080はSP（スタックポインタ）レジスターがあって、
それを書き換える事で、スタックデータの処理をしていた。
もし、MN1617がそのレジスターが書換え不可なら（あり得ないと思いますが、
最初にメモリーアドレス決めないといけないので）
理解します。が、たぶん書き換える事が出来るでしょう。それすなわちスタックですよ。

892 ：デフォルトの名無しさん：2010/12/27(月) 00:45:42

>>891
でもそのスタックにユーザがデータを載せることができるかどうかは？できないシステムスタックなら、応用は限定されてしまう。

893 ：デフォルトの名無しさん：2010/12/27(月) 00:48:34

ん？元々は関数コールでのスタックの話題だろ？
ユーザがデータを載せるのは関係なくないか

894 ：デフォルトの名無しさん：2010/12/27(月) 00:49:08

>>892
当時のCPUにメモリーガードなど有りませんので何処でも書き換えられます。
SPレジスターが書換え計算可能なら＋２して、2バイトのスタックデータデータエリアにします。
何の問題もありません。ちなみにMN1617が関数コールが出来るとの仕様は見てます。

895 ：デフォルトの名無しさん：2010/12/27(月) 01:20:07

おまえら口先ばっかでコードなんかサンプル程度しか書かないだろ

896 ：デフォルトの名無しさん：2010/12/27(月) 02:05:03

関数型言語で書かれた、サンプル以上の何かって公開されてるのは少ないよね。
Emacs関係を除いて、ここ数年のを挙げると、Darcsぐらい？

897 ：デフォルトの名無しさん：2010/12/27(月) 02:12:42

みんな普及のためにライブラリ書こうぜ

898 ：デフォルトの名無しさん：2010/12/27(月) 02:13:28

書き捨てのが多いんだろうな・・・
でも再利用できない書き捨てなんてプログラムとして書く価値もないと思う。
場当たり的な問題はUIで手作業すればいいのだから。
精密で複雑で慎重に取り組まざるを得ないのにそれでも書くのは、何度でも使えるからだ。

899 ：デフォルトの名無しさん：2010/12/27(月) 02:16:28

RubyのRailsみたいな目玉商品を作れば普及するかも

900 ：デフォルトの名無しさん：2010/12/27(月) 03:13:36

>>889
R3000とかと一緒
戻りアドレスが記録されたレジスタが１つある
プログラマが戻りアドレスをどのように保護するか決める(listでもstackでもarrayでも)

901 ：デフォルトの名無しさん：2010/12/27(月) 06:11:37

>>898
そういう作業は何度も起こったりしないよ。

902 ：デフォルトの名無しさん：2010/12/27(月) 06:35:08

>>754
while(*p++=*c++);

903 ：デフォルトの名無しさん：2010/12/27(月) 07:19:05

>>896
Yi や Snap はどう？

904 ：デフォルトの名無しさん：2010/12/27(月) 07:21:49

>>889
MN1610がSP持ってるから、発展型の1617もSPもってるんじゃねぇの？

905 ：デフォルトの名無しさん：2010/12/27(月) 09:32:41

schemeは企画統一できないのか
行列計算が処理系ごとに独自行列構造体を導入してて
他の処理系から移植できない

906 ：デフォルトの名無しさん：2010/12/27(月) 10:32:55

>>876
クロージャが普通の関数と同様に扱えるかどうか、という基準はあるんじゃないの？

907 ：デフォルトの名無しさん：2010/12/27(月) 10:35:21

>>898
ええ！　書き捨てコードこそ、プログラマの本懐だと思うが。

908 ：デフォルトの名無しさん：2010/12/27(月) 10:49:35

>903
元々その言語を使ってたプログラマの為のWebフレームワークを含めてもいいのなら、
ScalaのLiftが一番実際に商用に使われてるだろう。でも、あんまり挙げる意味が無いと思う。

やっぱ、その言語を使ってなかったプログラマが使い始めるようなrailsみたいなのや、
その言語のプログラマでない人も広く使うようなツールとかじゃないとね。
その意味で、darcsを挙げた。

909 ：デフォルトの名無しさん：2010/12/27(月) 11:04:57

>>908
そういう基準ならバージョン管理システムのdarcsより
タイル型ウィンドウマネージャのxmonadの方が
広く使われているのでは？

910 ：デフォルトの名無しさん：2011/01/05(水) 00:27:14

全然例が挙がらないところを見ると、やはり、関数型言語はサンプル作成専用のようだ。

ポジティブな言い方をすると、プロトタイピングに向いている、って事か。

911 ：デフォルトの名無しさん：2011/01/05(水) 00:48:25

何のサンプルか知らないが、一般的なソフトなら関数型でなくても速い。

912 ：デフォルトの名無しさん：2011/01/05(水) 01:56:28

>>910
公開されているという条件が無ければ、
次のサイトで「決してサンプル作成専用ではない」と反論はできる。

http://cufp.org/conference

ただ、広く当たり前のように活用されているとは言えないだろうね。
まだまだだからこそ、こんなカンファレンスが毎年開かれるわけで。

913 ：デフォルトの名無しさん：2011/01/05(水) 10:40:25

>>910
手続き型で本格実装するなら参考にもならないんじゃないか
原理が違いすぎる

914 ：デフォルトの名無しさん：2011/01/05(水) 11:15:20

>>910
なんでそう思ったの？
プロトタイピングにはぜんぜん向いてないように見えるけど…

その手の用途なら言語的にはLLのほうが向いてるだろうし
さっさと何かをデッチあげたいときには
RADのような開発環境やライブラリが整備されてるかどうかも重要だと思うな

915 ：デフォルトの名無しさん：2011/01/05(水) 12:42:19

今度トレーディングツールF#でつくるお(´・ω・｀)

916 ：デフォルトの名無しさん：2011/01/05(水) 21:41:30

>> 898
Excelでプロットをたくさんつくると手がしびれてくるじゃないか。

917 ：デフォルトの名無しさん：2011/01/05(水) 21:46:46

>>914
数値シミュレーションのプロトタイプはときどきMLでやったりするが。
同じ関数型のRでやってもよいのだが、型がないのでやりにくい。

918 ：デフォルトの名無しさん：2011/01/05(水) 22:47:17

機械学習系だがプロトタイプはMathematicaが楽でいい。
純粋じゃなくてマルチパラダイムだが

919 ：デフォルトの名無しさん：2011/01/06(木) 01:41:25

Schemeに代表されるLisp系やML系の言語はcall-by-valueだから関数型プログラミングに破壊的代入（Cなんかでの普通の代入演算）も
問題なく追加できて手続き的プログラミングとが共存できる。
ところがHaskellのようなcall-by-need (lazy evaluation) の関数型言語はそうはいかない。
lazｙな関数型言語に破壊的代入なんて追加しようものなら整合性のあるすっきりした意味論が構築できない。
だから手続き的なスタイルの方が自然なケースでも強引に関数型プログラミングのスタイルで書かなければならなくなって不自然。
ところが関数型プログラミングの信徒はlazyな言語こそが関数型プログラミング言語の正統派だと主張するから、ますます現実とかけ離れてしまう。
関数型プログラミングが世の中に広まらないのはこういう宗教的とさえ言えるファナティックな原理主義が原因の大きな部分なのは確か。

920 ：デフォルトの名無しさん：2011/01/06(木) 10:26:25

純粋なままで手続き的スタイルを可能にするためにモナドやらdoやらがHaskellにあるんだろ
それで足らないというのなら分かるけど

921 ：デフォルトの名無しさん：2011/01/06(木) 10:28:08

>>919
> だから手続き的なスタイルの方が自然なケースでも強引に関数型プログラミングのスタイルで書かなければならなくなって不自然。

モナド使えばいいじゃん。

あと、Lazyであることには、関数型プログラミングの正統云々じゃなくて、実際上利点があるよ。
だからこそ、LISPやJavascriptで引数なしのクロージャを使うことがあるんじゃない。
そうすることによって、ロジックとデータ構造が分離せず、書きやすくなる。
ロジックとデータ『構造』を分離させたいときは、クラス使えばいいしね。

922 ：デフォルトの名無しさん：2011/01/06(木) 11:51:23

>引数なしのクロージャを使うことがある

使うことがあるが、使わないこともある。
使わないケースで不自然になると言ってるのに、使うことがあると言うのは
論点がずれている。

923 ：デフォルトの名無しさん：2011/01/06(木) 12:35:35

>>922
え？　いや、それに対する応答は「モナド使えばいいじゃん」で終了している。

たしかに、lazyな言語で手続き的に書くためにはトリックが必要。
そういうトリックがないと仮定すれば、lazyな言語であることは、手続き的に書けない/書きにくいということに直結する。

だけど、実際には、そのトリックは使いやすい形ですでに用意されているのだから、手続き的に書けるかどうかとlazyかどうかは別の問題になる。
手続き的に書くためにはモナドを使えばよい。以上。

そこで、別の問題としてlazyであることに利点があるか？
関数型として純粋であるという宗教的情熱以外に？
ということに対する答えが、「LISPやJavascriptで引数なしのクロージャを使うことがある」から利点があることははっきりしている、と言っている。
Haskellerは、その利点がたまにではなく広範に活用できると思っている、ということ。

924 ：デフォルトの名無しさん：2011/01/06(木) 13:17:51

>>923
広範に活用すると、モナドを使う範囲が狭くなるよな。
仮にモナドを使えば不自然にならないとしても、
実際はモナドを使う範囲を狭くするのなら、結局不自然じゃないか。

925 ：デフォルトの名無しさん：2011/01/06(木) 13:53:38

>>924
え？　それはプログラマがやりやすいスタイルでやれば良いじゃん。

手続き型の書き方が自然なアルゴリズムや処理、あるいはプログラマが個人的にそうしたいときはモナドで書けばよい。
遅延評価で、ロジックをカプセル化(?)したいときはそう書けばよい。
手続き的である必要はないけど、あるいは純粋な関数だけど、なんらかの理由で遅延評価をしたくないときは、正格型をつかえばよい。

あなたがしたいようにすればよい。
オレが言っているのは、遅延評価には利点がある、広範に使えるということであって、つねに使えということではない。

926 ：デフォルトの名無しさん：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は確かに無限データ構造を簡単に扱えるとか便利な点もあるけれど、その為に犠牲にしてる部分の方が
実用的な観点からは大きいと思うなあ。
無限リスト（ストリーム）とか無限木なんて、それらのデモ用のトイプログラムならばともかく、実用プログラムを書く上で
そんなに必要になるものじゃないもの。

927 ：デフォルトの名無しさん：2011/01/07(金) 04:17:17

基本的にプログラミング言語って、性能がどれだけ出るとか、
プログラマの意図をどれだけ正確に記述できるとかにあると思うし、
その辺りしか興味がないんだけど、遅延評価する言語とはいえ、
処理系が作り出す評価順序というものは事実としてあるわけで、
性能を第一とするなら、プログラマはそこを熟知して意識しながら
書く事をやっぱり求められるはず。
haskellはそこがぼやけてはっきりしない。
本来なら一番把握してないといけない部分のなはずなのに。
そこの言及を避けて通っていたら使われないに決まってる。

928 ：デフォルトの名無しさん：2011/01/07(金) 05:45:40

>>927
> haskellはそこがぼやけてはっきりしない。

ハア？それはあんたが不勉強なだけでしょ・・・

929 ：デフォルトの名無しさん：2011/01/07(金) 07:32:15

>>928
今までとは考え方を変えて勉強しなければならない時点で
普及はできないよと言いたいんじゃないかな。

俺は Haskell 大好きだし、
Haskell の表示的意味論の美しさには感動すら覚えるが、
痛いところ突かれて反論でなくとても悔しい。
でも、>>926 や >>927 は正論だと思うよ。
実用的じゃなければ、コンピュータの制御が簡単にできなければ、
流行るはずもない。

>>296
> モナドは手続き風の書き方ができるだけで

その後の書き方で君が分っているのは承知しているが、
見てる方が勘違いするともどかしいので一応言っておくと、
それは Haskell の do 記法のことね。
あと、その後の話はモナドの中でも IO モナドの話ね。

モナドスタイルなんて言葉はあまり適切じゃないな。
モナドがいかにも何か特別なプログラミングテクニックみたいじゃないか。

930 ：デフォルトの名無しさん：2011/01/07(金) 08:35:12

>>929
だったら、Haskellの言語としての特徴を「モナド」という言葉を使わずに説明してみろよ。
そこにはMirandaが残るだけだぞ？それでいいのか？

931 ：デフォルトの名無しさん：2011/01/07(金) 09:30:30

>>926
意味論的なゴマカシって？
imprecise exceptionが黒魔術っぽいというのなら分かるけど、その話じゃないよね

>>927
性能を考えるときに評価順序が重要なのはみんな知ってるし、Haskellの入門書でも取り上げられてるだろ

932 ：デフォルトの名無しさん：2011/01/07(金) 09:32:58

モナドって継続スタイルで裏でゴニョゴニョ出来るシンタックスシュガーでそれを使えば状態的なものを引き回せたり実行順序を制御できるぐらいの認識でもいいかすら？第一段階として。

933 ：デフォルトの名無しさん：2011/01/07(金) 09:35:44

>>926

934 ：デフォルトの名無しさん：2011/01/07(金) 09:56:23

俺は仕事がゲーム関連なんで>>927と同じような印象を持ってる
もちろんHaskellすげーと思うし、OCamlでサンプル書いたりすることもあるけど
関数型言語メインでってのは考えられない

935 ：デフォルトの名無しさん：2011/01/07(金) 10:04:25

HaskellならともかくOCamlなら>>927は全く的外れじゃね？
OCamlの評価順が分からんというのはJavaの評価順が分からんと言うようなものじゃないか

936 ：デフォルトの名無しさん：2011/01/07(金) 12:03:09

Haskell の表示的意味論ってどっかにあったっけ？

仕様ではシンタクティックシュガー的な言語機能について、Core と呼ばれてる基本的な機能への
変換は形式的に示されてるけど、Core そのものの形式的な定義や意味論は無かったと思うんだが。

>>930
Type Class は？

937 ：デフォルトの名無しさん：2011/01/07(金) 20:01:31

>>936
こんなのはどう？
http://en.wikibooks.org/wiki/Haskell/Denotational_semantics

べつに公式仕様として公開されてなくても、
意味領域への変換関数がちゃんと示せるという事はわかると思う。

ただ、「言語設計者たちが考えること」でも触れられてるけど、
Haskell の表示的意味論は 100% 完全には定義されていないようだね。
100% にするのは労力に見合わないとかで。
それでも多くの機能についてまず意味論から考えて設計したそうだ。

まぁ脱線だが、この辺りでも興味深いことが語られてる。
http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/

938 ：デフォルトの名無しさん：2011/01/07(金) 20:19:37

>>926
> それにプログラム全体で使うグローバルな手続き的変数に相当するものをモナドのスタイルで書こうとしたら
> プログラム全体を覆う巨大なモナドが必要になって後での機能追加とか削除の変更がやりにくくなる。

プログラム全体で使うグローバルな手続き的変数って何だ？
何に使うんだよ、そんなもの

939 ：デフォルトの名無しさん：2011/01/07(金) 23:10:52

こんな議論が続くようでは「普及」はしないな。
プログラミング言語なんて、誰にとっても平明
なものでなくては。

940 ：デフォルトの名無しさん：2011/01/07(金) 23:16:45

誰でも分かる関数型言語なんか、何のありがたみもないじゃん。
誰得だよ？

941 ：デフォルトの名無しさん：2011/01/07(金) 23:17:51

>>940
だから普及はしないんだろ。

942 ：デフォルトの名無しさん：2011/01/07(金) 23:46:11

わかった振りしてる奴らが役に立つプログラムをまったく書かない件

943 ：デフォルトの名無しさん：2011/01/07(金) 23:56:03

Haskell と C や Java と比べて、後者の方が圧倒的に平明とは思えん
むしろ Haskell の方が平明に感じる

944 ：デフォルトの名無しさん：2011/01/08(土) 00:13:22

Cのほうが実際の挙動に近く、Haskellのほうが思考に近い。
どっちの視点かの問題かと。

945 ：デフォルトの名無しさん：2011/01/08(土) 00:26:30

>むしろ Haskell の方が平明に感じる

>Haskellのほうが思考に近い。

どちらも奇妙な考えにしか思えない。

946 ：デフォルトの名無しさん：2011/01/08(土) 00:30:07

全部わかりたい人は、何も隠さないのが平明に感じる
必要なさそうな部分はわかりたくない人は、色々見えないのが平明に感じる

947 ：デフォルトの名無しさん：2011/01/08(土) 00:33:06

平明平明煩いから平明がゲシュタルト崩壊した

948 ：デフォルトの名無しさん：2011/01/08(土) 00:35:30

Haskell難しい、は否定しようのない定説だろ。
いまさらこれにケチ付けるやつが居るのが信じられん。

949 ：デフォルトの名無しさん：2011/01/08(土) 06:26:58

どの言語でもそうなんだが文法はそう難しくないんだけど
ライブラリとそのドキュメントを探して機能を解釈して使うのがややこしくて困る
公理のように明快でない人工的で文系的な機能が頭に入らない
やはりネットの情報だけじゃ無理か

950 ：デフォルトの名無しさん：2011/01/08(土) 10:46:56

>>948
Haskell の何と C の何を比べて、どの程度難しいというのだ？

951 ：デフォルトの名無しさん：2011/01/08(土) 10:55:41

Cは難しいねえ。メモリの確保と解放は言語の性質上仕方ないけど
配列や文字列ごときで領域外アクセスしないように気を使うとかは本気であり得んと思う。

952 ：デフォルトの名無しさん：2011/01/08(土) 11:10:33

ノイマン型の現実から目をそらしても現実は変わらない

953 ：デフォルトの名無しさん：2011/01/08(土) 11:23:35

>>951
領域内でも間違った場所を指すことはあるから、領域の内か外かに気を使うことはない
内なら正しいと意識するとむしろ偏見になる

954 ：デフォルトの名無しさん：2011/01/08(土) 11:29:59

>>953
ますます難しいや…

955 ：デフォルトの名無しさん：2011/01/08(土) 12:07:44

>>952 一生機械語のバイナリでプログラミングし続ければいいと思うよ

956 ：デフォルトの名無しさん：2011/01/08(土) 12:10:57

現実が変わらないといってるだけなんだがｗ

957 ：デフォルトの名無しさん：2011/01/08(土) 12:15:59

Haskell が普及しているという現実からは必死に目をそらすのであったw

958 ：デフォルトの名無しさん：2011/01/08(土) 12:18:45

関数型言語は副作用の問題を勘違いしている。
人間は状態機械を把握できる。問題は以下に構造化して把握するか。
その視点が致命的にない。

959 ：デフォルトの名無しさん：2011/01/08(土) 12:19:38

>>957

960 ：デフォルトの名無しさん：2011/01/08(土) 12:31:54

Cは池沼向け言語だよwww

961 ：デフォルトの名無しさん：2011/01/08(土) 12:32:15

物理学が描く世界ってオートマトン的だよね。

962 ：デフォルトの名無しさん：2011/01/08(土) 13:03:57

> 人間は状態機械を把握できる。問題は以下に構造化して把握するか。
> その視点が致命的にない。

ステートモナドないしIOモナドが構造化されていない、という証明を。

963 ：デフォルトの名無しさん：2011/01/08(土) 13:07:41

Cでバグのない実用的なプログラム書く難しさと、Haskellでトイプログラム書く簡単さを
比べてるだけだろ。

964 ：デフォルトの名無しさん：2011/01/08(土) 13:08:53

>>958
お前の中の「構造化」って何なのか説明してほしいな

そして、それが関数型言語の「副作用の有るものと無いものをしっかり分ける機能」
とどう関係しているのか説明してほしい

965 ：デフォルトの名無しさん：2011/01/08(土) 13:11:02

つーかまともな実用プログラム書く気ないんだろ

966 ：デフォルトの名無しさん：2011/01/08(土) 13:18:01

構造化とはプログラム構造をマジカルナンバー7+-2に最適化することである

967 ：デフォルトの名無しさん：2011/01/08(土) 13:52:18

組み込みの構文糖や、組み込み型だけで7±2になる。
つまり
Lispを除くオブジェクト指向ではない動的言語
が最適である

968 ：デフォルトの名無しさん：2011/01/08(土) 13:58:09

Prologのことかっ！

969 ：デフォルトの名無しさん：2011/01/08(土) 14:00:21

意味論の話なんだが

970 ：デフォルトの名無しさん：2011/01/08(土) 15:00:35

>>961
古典力学も量子力学も電磁気学も方程式で記述されてるけど、なんで？

971 ：デフォルトの名無しさん：2011/01/08(土) 15:42:37

> Lispを除くオブジェクト指向ではない動的言語

具体的に何よ

972 ：デフォルトの名無しさん：2011/01/08(土) 15:56:37

方程式を解けばわかるが、
方程式だけを記述するということは、まともに解く気がない。

973 ：デフォルトの名無しさん：2011/01/08(土) 17:11:23

差分方程式なんか、そのまんま計算機にかけて解けるわけですが

974 ：デフォルトの名無しさん：2011/01/08(土) 17:26:12

差分方程式の数値計算も理解せずに数学語っちゃうやつって

975 ：デフォルトの名無しさん：2011/01/08(土) 17:45:41

>>972
方程式自体をデータとして扱うようなコード(定理を使って簡約とか)が書きたい
項書き換え系を理論的背景とする言語だと楽かと思い
以前elanだとか他にも何個か落としてみたが、情報がなさ過ぎて。
現状一番マシなのはMaxima(Mathematicaは買えないんで)

976 ：デフォルトの名無しさん：2011/01/08(土) 19:14:04

>>975 reduce ってオープンソース化されたんじゃなかったけ？

977 ：デフォルトの名無しさん：2011/01/08(土) 19:30:33

reduceってこれですか？
ttp://www.uni-koeln.de/REDUCE/
未チェックだったので今度調べてみようかな

978 ：デフォルトの名無しさん：2011/01/08(土) 20:36:59

>>971
つ >>968

979 ：デフォルトの名無しさん：2011/01/09(日) 00:36:42

モナドって関数型言語なんですか？

980 ：デフォルトの名無しさん：2011/01/09(日) 00:44:37

LISPじゃだめなんですか？

981 ：デフォルトの名無しさん：2011/01/09(日) 00:47:10

モナドは数学の用語です
関数型言語のHaskellが
モナドの特殊なバージョンを言語の機能としてサポートしているというだけ
それとは別に哲学にもモナドという語があります

982 ：デフォルトの名無しさん：2011/01/09(日) 13:58:11

特殊なバージョンって？

983 ：デフォルトの名無しさん：2011/01/09(日) 16:42:37

モナドとモコナの違いがわからない。

984 ：デフォルトの名無しさん：2011/01/09(日) 18:37:54

モナコはF1グランプリの開催地の名前だよ。

985 ：デフォルトの名無しさん：2011/01/09(日) 19:34:36

モコナは1モコナ、2モコナと数える

986 ：デフォルトの名無しさん：2011/01/09(日) 19:43:02

Cが最強なんだよって萩谷先生がいってたの信じててよかった

987 ：デフォルトの名無しさん：2011/01/09(日) 19:48:58

C は仕事できるが、面白くはないな

プログラムしてて一番面白いのは Haskell

988 ：デフォルトの名無しさん：2011/01/09(日) 20:09:35

そりゃ、トイプログラムしか書かないんだから面白いわな。

989 ：デフォルトの名無しさん：2011/01/09(日) 20:34:38

>>988
当然だ
仕事の悩みなんて一切考えずに、数学や計算機科学に没頭できる至福の時だよ
おもちゃとして最高のプログラミング言語だと思う

Haskell に勝るおもちゃんなんて、そうそう無いよ

990 ：デフォルトの名無しさん：2011/01/09(日) 22:34:17

普及しないのも無理は無い

991 ：デフォルトの名無しさん：2011/01/09(日) 23:35:04

既存のプログラミング言語でパズルすることが数学・計算機科学？

992 ：デフォルトの名無しさん：2011/01/10(月) 00:32:20

>>991
本気でそんな頓珍漢な質問をするのなら、真面目に勉強してみてくれ

そのレベルのヤツにここで説明するのは骨が折れる
どうせ説明できないんだろと言われるだろが、説明を拒む理由も分るはず

993 ：デフォルトの名無しさん：2011/01/10(月) 00:59:04

どうせ説明できないんだろ

994 ：デフォルトの名無しさん：2011/01/10(月) 01:01:26

>>987
ただし、そこまでたどり着くには何度もゲームオーバーにならなければいけないという。
もっとも今では組み込みインタプリタやCトランスレータなり資料あるから、
うまく使えばゲームオーバーの回数も減るが。

>>990
多くのマイナー言語に共通することだが、普及させたかったら良いライブラリ、
良いテキスト、豊富なサンプル、あと目標にできる人といったものが必要になる。

あとは、所詮一般人の度肝を抜くようなデモも必要。ギークのおもちゃでは普及しないよ。
HSPの言語仕様は色々負けているが、ライトユーザーを取り込めているという点では
では上手い戦略太都重う。

995 ：デフォルトの名無しさん：2011/01/10(月) 06:35:15

つまりこのスレの住人はだれも普及させるつもりもないし
度肝抜くデモも作れないと

996 ：デフォルトの名無しさん：2011/01/10(月) 09:32:39

>>992
何かコード晒して下さい

997 ：デフォルトの名無しさん：2011/01/10(月) 11:25:02

今度F#メインでサービスつくるから、リリースしたら後出しで言うわ。

998 ：デフォルトの名無しさん：2011/01/10(月) 11:28:51

どういう形であれ、金になれば普及する

999 ：デフォルトの名無しさん：2011/01/10(月) 11:36:44

金になるかどうかは言語ではなく企画による。

1000 ：デフォルトの名無しさん：2011/01/10(月) 13:09:57

企画によって適切な言語を選ぶ会社なんてほとんど無いよ。
どんな企画でも今まで使ってて手慣れている言語、
つまり C や Java などの有名な手続き型言語のひとつを使うに決まってる。

関数型なんて頭の片隅にも入っていない。

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。