トップページ⇒tech
1001コメント379KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/10/11(月) 19:07:49
あくまで、関数型言語は何故普及しないのかをメインに考えるスレです。
このテーマの存在をどうかお忘れなきよう願います。

前スレ
　関数型言語は何故普及しないのかを考える
　http://hibari.2ch.net/test/read.cgi/tech/1277215506/l50
0153デフォルトの名無しさん2010/10/15(金) 22:59:54
>>151
おぉそうだった、言い直すわ

関数型の開発規模を測るための指標の一つとして、
コールしてる関数の数ってのはどうだ？
0154デフォルトの名無しさん2010/10/15(金) 23:02:12
>>152
一般論だが、関数型言語では記述行数が極めて少ないということをウリにしている事が多いから。
現実的には、>>146のとおり、プログラマの質によって行数の幅が広い。
C言語などの手続き型言語では、同じアルゴリズムなら一般的に同じような行数になるから、
行数を開発規模の指標に使われることが多い。
0155デフォルトの名無しさん2010/10/15(金) 23:04:28
>>135
一般的なマネージャーってファンクションポイント法は使わないのか？
0156デフォルトの名無しさん2010/10/15(金) 23:09:53
>>155
実に教科書的な回答だが、実際にはFP法は経験的な面が大きいし、
マネージャーに熟練が求められるのでメインで使われることはほとんどない。
行数を数えるだけなら誰でも簡単にできるでしょ？
まぁ、プログラミングの腕も高いマネージャの場合はその仕事が難しいか簡単か分かるから、
そのへんを考慮することも多いね。
0157デフォルトの名無しさん2010/10/15(金) 23:10:31
> C言語などの手続き型言語では、同じアルゴリズムなら一般的に同じような行数になるから、

ならない
0158デフォルトの名無しさん2010/10/15(金) 23:11:50
>>157
そりゃ無理に短く書こうとすれば短くなるかもしれんが、
普通に書いている分には同じような行数になるよ。
経験的にそうだとしか言えないけどな。

統計データとかあるなら教えて欲しいぐらいだ。
0159デフォルトの名無しさん2010/10/15(金) 23:14:47
そんなことよりお前ら明後日の試験勉強しろよｗ
0160デフォルトの名無しさん2010/10/15(金) 23:21:02
１＋１を計算する関数と、未来を予測する関数が同じ価値でないのは誰でもわかることだが、どのくらい違うのかをだれも定量化できない。
プログラミングは本質的に単純労働じゃないんだよ。強いて言えば小説家が得る収入と同じ意味がある。
売れるコードを書く奴が高収入になるべきなんだ。
0161デフォルトの名無しさん2010/10/15(金) 23:21:24
本当に行数を数えてるとでも思っているのかな
KLという単位は抽象的比喩的なものにすぎないのだが
0162デフォルトの名無しさん2010/10/15(金) 23:22:43
前日の夜に写真を撮り忘れた事に気付く
0163デフォルトの名無しさん2010/10/15(金) 23:31:24
漠然とした感覚であれば役に立つ
1万行のプログラムと100万行のプログラムは、
たぶん後者のほうが複雑なのだろう

もっとも、行数以上にまともな指標が無いだけでもあるのだがｗ
ソフトウェアメトリクス屋がんばれ〜
0164デフォルトの名無しさん2010/10/15(金) 23:31:42
>>161
定量的でないものなのですか？

定量的に評価できないから関数型言語はダメで、定量的に評価できる手続き型言語がいいんだ、
という話だとばかり思っていたのですが、抽象的比喩的な単位で評価できるから手続き型言語が良くて、
抽象的比喩的な評価もできないのが関数型言語だ、ということなのですか？
0165デフォルトの名無しさん2010/10/15(金) 23:39:24
ソフトウェア規模とは人月であり、人月から行あたりいくらで行数を逆算して
資産あるいは費用の根拠にするというだけの事であって
それが実際に作成されたプログラムの行数と同じかどうかなど誰も知らない

クライアントが気にするなら編集してつじつまの合うように行数を増減させるだけの話
0166デフォルトの名無しさん2010/10/15(金) 23:40:18
>>165
何かそういうの気持ち悪い
0167デフォルトの名無しさん2010/10/15(金) 23:43:05
事実あるいは現実を気持ち悪いとしたところで何の解決にもならない
鏡をなくせば不細工な自分は存在しなくなるか?
0168デフォルトの名無しさん2010/10/15(金) 23:45:10
>>135
そもそもなんだが・・・

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

それ以前に、議題にすら挙がらず無視されるような気がするんだが
0169デフォルトの名無しさん2010/10/15(金) 23:49:31
>>168
どうやって運用したらいいものやらわからないから
議論に上がる前にみんな引っ込むんだよ。
誰も新しい試みをして責任とりたくないからね。
0170デフォルトの名無しさん2010/10/15(金) 23:54:12
日本のダメな所。
言いだしっぺの法則という厄介な法則があるので、新しい事ができない。
基本的にマインドストーミングとか無くて、上司から部下への一方通行。
0171デフォルトの名無しさん2010/10/16(土) 00:55:01
本来は逆の意味なんだけど。
2chでそういわれる奴の殆どが、口だけの外野ばっかりだからなぁ
0172デフォルトの名無しさん2010/10/16(土) 01:32:03
日本の良い所。
スタンドプレーから生じるチームワークというのがあってだな
0173デフォルトの名無しさん2010/10/16(土) 05:51:25
ﾜｰﾜｰｻｯｶｰはつまらん
0174デフォルトの名無しさん2010/10/16(土) 07:18:37
>>154
バカな質問なんだろうけど、この際。 <- 積年の疑問
COBOLのステップ数っていうのは
PROCEDURE DIVISION だけを勘定するんですか？
0175デフォルトの名無しさん2010/10/16(土) 13:33:59
使われてない言語の方が圧倒的多数なのだから
使われている言語は何故使われるようになったかを考える方が有用
0176デフォルトの名無しさん2010/10/16(土) 15:33:58
該当言語のWeb情報の多さと普及度には相関があるってのをどこかで見た
シンプルな事実だけど、逆に考えれば
関数型言語の情報が他に比べて少ないってことでもあると思う
0177デフォルトの名無しさん2010/10/16(土) 18:07:29
>>175
そうだと思う

>>176
それは普及してるから情報が多いんであって
情報が少ないから普及しないとは限らない。
0178デフォルトの名無しさん2010/10/17(日) 10:34:05
最初が馬鹿でもわかるのが重要

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

「関数型の魅力」みたいなのを語る時点ですでに失格なのかもしれない。
0179デフォルトの名無しさん2010/10/17(日) 10:40:37
初心者と馬鹿は全然違うだろ
0180デフォルトの名無しさん2010/10/17(日) 10:55:43
馬鹿は馬鹿なりに知恵があって馬鹿でも判るのを使うよ
そんな馬鹿のことを気にしても仕方がない
0181デフォルトの名無しさん2010/10/17(日) 11:08:57
「馬鹿」という言葉がダメなら「サルでもわかる」にしておくか。
残念だけど、2:8の原則に従い、どうやったって8割はそんなに賢くはならないんだ。
「賢くないと使いこなせない」ものはどうやったって普及しない。

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

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

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

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

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

例外的だなと感じているのは Python かなぁ。
これはじわじわ普及する感じがしている。
0182デフォルトの名無しさん2010/10/17(日) 12:03:09
賢いやつほど無駄に手間のかかるものを嫌うはずだけど
0183デフォルトの名無しさん2010/10/17(日) 12:05:50
>>181
「CGIはどの言語でも書ける」ということを教えるよりも
Perlを教えるほうが楽だと思ったからPerlが流行った。

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

馬鹿でもわかるようにしたいなら
「クラスは構造体のようなものだ」とか
「クロージャはクラスのようなものだ」とか
「モナドはイテレータのようなものだ」と説明すればいいが
それを言ったらおしまいだという空気がある。
0184デフォルトの名無しさん2010/10/17(日) 12:16:58
>>175
C言語は何故普及したのかというと
「CPUなんてどれでも同じ」って言っちゃったからです
0185デフォルトの名無しさん2010/10/17(日) 12:26:43
>>183
クロージャとクラスならクロージャのほうが簡単じゃない？
0186デフォルトの名無しさん2010/10/17(日) 12:40:11
>>185
それは、ノーテーションが簡単ってことでしょ
モデルは共通だということをふまえた上でノーテーションにこだわるなら良いんじゃね
0187デフォルトの名無しさん2010/10/17(日) 12:44:26
モデルからして比較にならないくらい簡単だろ
0188デフォルトの名無しさん2010/10/17(日) 12:48:02
>>183
クラス、構造体、クロージャ、モナド、イテレータ
どれも初心者にはわからない。
君の話は、手続き型言語を使い込んでる
人を対象にしている。すでに。
0189デフォルトの名無しさん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 が使える状況でそんなことやろうという奴はいないだろう。
0190デフォルトの名無しさん2010/10/17(日) 13:09:29
>>187
単純なモデルは学者にとってメリットがあるが、プログラマにメリットないよね
学者が「利息つけて借りを返します」って書いてハンコ押してくれるなら話は別だが
0191デフォルトの名無しさん2010/10/17(日) 13:25:46
少し言い過ぎたか
でもまあ理系なら口約束じゃなくて形式にこだわるような気もする
0192デフォルトの名無しさん2010/10/17(日) 13:29:24
>>189 単なる茶々だが
> サーバー
をレンタル出来ない時代があった
0193デフォルトの名無しさん2010/10/17(日) 13:32:46
>>188
手続き型言語を教えるノウハウがあるのに、なんで使わないの
わざわざノウハウを再発明してどうすんの
0194デフォルトの名無しさん2010/10/17(日) 13:43:42
>>190
モデルが単純ってのは、プログラマから見れば「一つのことしかしない道具」ってことだろ
理解しやすく使いやすく組み合せやすい、メリットはたくさんある
0195デフォルトの名無しさん2010/10/17(日) 14:01:11
>>193
もっと絡繰り人形レベルで説明、理解できないものかな。
0196デフォルトの名無しさん2010/10/17(日) 14:50:10
>>194
モデルが単純でも、それが汎用の言語であるならプログラムは簡単にならない。

正規表現は単純で便利だが、汎用ではないから
他の複雑な言語と組み合わせないとプログラムは書けない。
0197デフォルトの名無しさん2010/10/17(日) 15:16:35
>>187は>>186に対するレスなんだが、分かってる？
もちろんクロージャだけではプログラムは書けない
0198デフォルトの名無しさん2010/10/17(日) 17:21:27
>>185
やりたいことによってはそうじゃない気もする。
変更が可能な変数を扱う場合に
オブジェクトの中にオブジェクトを生成するのはやりやすいが
クロージャの中でクロージャを生成するのはバグりやすい
(内側のクロージャを複数生成すると、最初のクロージャの環境が内側クロージャで共有されてしまう)
外側のクロージャの環境は、全てクラス変数/静的フィールドみたいな感じ

クロージャで変更可能な変数を扱わなければ問題はないけど
01991852010/10/17(日) 17:56:40
>>198
>>185で簡単と書いたのは、クラスとは何か理解するよりも、クロージャとは何
か理解することのほうが簡単じゃないか、てこと。使い方はそれぞれ向き不向
きがあると思う。

クロージャ＋色々でオブジェクトシステムを実装できるイメージがある。
0200デフォルトの名無しさん2010/10/17(日) 19:14:33
関数型言語で一番簡単なのはLISP系だろうけど、
quoteの概念て関数型言語として見るとどうなの？
0201デフォルトの名無しさん2010/10/17(日) 19:29:23
backquote(quasiquote)って数学的基盤ってあるの？
LISPでリスト処理を書く時って、無意識的に参照透過性を
維持しながら書くと思うけど、あれが関数型言語のルーツ？
なんじゃないかって思う。
まあ手続き的に書いちゃう人もいるだろうけど。
0202デフォルトの名無しさん2010/10/17(日) 20:17:11
>>201
参照透過でなくなる最大の原因だな >(古典的マクロ + backquote)
# gensym の使い方を覚えるまでだけど…
0203デフォルトの名無しさん2010/10/17(日) 20:28:32
バリアントとパターンマッチのルーツ
文字列と正規表現の最大のライバル
0204デフォルトの名無しさん2010/10/17(日) 20:39:33
仮想関数のライバルでもある
0205デフォルトの名無しさん2010/10/19(火) 03:54:05
関数型言語スレって、やっぱいるかね？
普及とかどうでもいいんだけど
0206デフォルトの名無しさん2010/10/19(火) 04:12:52
一般論としての関数型言語スレが無いせいで
ここが受け皿になっている感はあるが、
スレタイを変えて繁盛するかは分からん
0207デフォルトの名無しさん2010/10/19(火) 04:15:39
こういうスレも一応あるんだけどな

関数型言語Part5
http://hibari.2ch.net/test/read.cgi/tech/1252470706/

関数型と手続き型
http://hibari.2ch.net/test/read.cgi/tech/1145115971/
0208デフォルトの名無しさん2010/10/19(火) 07:42:13
関数型言語Part4の最後辺りは興味深い議論をしてるのに
Part5になってからもう・・・
0209デフォルトの名無しさん2010/10/19(火) 21:36:40
>>198
> オブジェクトの中にオブジェクトを生成するのはやりやすいが
> クロージャの中でクロージャを生成するのはバグりやすい


つまり、クロージャの中でクロージャを生成するのは、苦労するんじゃぁ。
0210デフォルトの名無しさん2010/10/21(木) 00:20:55
http://www.infoq.com/jp/news/2010/07/objects-smalltalk-erlang

Armstrong博士は、アドバイザの議論によって完全に納得させられたのではないと述べたが、Erlangは「唯一のオブジェクト指向言語かもしれない」と考えているようだ。
0211デフォルトの名無しさん2010/10/21(木) 01:37:01
お前ん中ではな
0212デフォルトの名無しさん2010/10/23(土) 10:53:13
>>210
そのErlangの部分も含めて、なぜそうなのかの説明不足の
箇所が多く、翻訳が日本語と思えないこともあり、かなり
意味不明だなぁ。私にとっては。
0213デフォルトの名無しさん2010/10/23(土) 11:52:25
実装をモデルに合わせるのが良くて、モデルに忠実でない実装はダメだ
って当たり前のように語られるけど、これは本当は物凄く異常なことじゃないか？
普通はモデルの方を現実に合わせるべきだろ？
0214デフォルトの名無しさん2010/10/23(土) 12:07:00
それは設計の段階でやること
0215デフォルトの名無しさん2010/10/23(土) 12:19:52
お前らアホだな−ｗ
抽象化ってのは現実を別の考え方で捉えることをいうのにｗ
要するに、どっちかに合わせろってことじゃなくて、
現実を抽象化しやすい抽象化法を用いて、
現実を抽象的に捉えるって事をしなきゃいけないんだから、
どっちかがどっちかに合わせなきゃいけないってことはないんだよｗ
0216デフォルトの名無しさん2010/10/23(土) 12:42:01
>現実を別の考え方で捉える
「別」ということは、少なくとも単一のモデルではありえない。
複数のモデルがある方が良い。そうすると、なんかカオスになって現実っぽくなる。
0217デフォルトの名無しさん2010/10/23(土) 13:30:26
>>216
そうは思いません
0218デフォルトの名無しさん2010/10/24(日) 20:07:35
>>212
そもそも, 何で日本語に訳されてないといけない？
原文を読むには, 中学/高校の英語で十分なんだが…

0219デフォルトの名無しさん2010/10/24(日) 21:37:50
>>218
無理です。
0220デフォルトの名無しさん2010/10/24(日) 22:04:52
中学生からやり直せ
0221デフォルトの名無しさん2010/10/24(日) 22:58:06
>>218
原文で読んだけど大田さん日本語の方がましでした。
0222デフォルトの名無しさん2010/10/24(日) 22:59:35
>>221
大田さんの日本語
0223デフォルトの名無しさん2010/10/27(水) 00:55:48
メッセージループをもったスレッドやプロセスこそオブジェクト。

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

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

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

あー、今夜はなんかよく眠れそう。
0224デフォルトの名無しさん2010/10/27(水) 18:15:12
メッセージループを中心に
考えればいいのかも。

メッセージループ指向。

オブジェクトの前にメッセージループありき。
プログラミングもメッセージループから
入る。
システムにメッセージループが
どれだけ必要か、また、その
メッセージループの処理から考えはじめる。
0225デフォルトの名無しさん2010/10/27(水) 21:58:32
↑キチガイって一日中こんなこと考えてるのか
0226デフォルトの名無しさん2010/10/27(水) 22:05:04
>>224
Functional Reactive Programmingの考え方がそれっぽいな
小さい回路を関数的に組み合わせて大きい回路を作り、まとめて実行
完成した回路一個がメッセージループ一個に相当する
0227デフォルトの名無しさん2010/10/27(水) 22:08:07
全てのデータ構造とアルゴリズムは、メッセージループによって記述できる
自然数の１０とは、メッセージループに１０回メッセージが送られた状態の異名である
0228デフォルトの名無しさん2010/10/27(水) 22:16:21
メッセージループを受け持つ関数はステートマシンにもなってんのかね？
0229デフォルトの名無しさん2010/10/27(水) 22:31:24
>>228
なっている
0230デフォルトの名無しさん2010/10/27(水) 22:38:22
>>228
もしもその関数が状態(ステート)を持っているのであれば、なっている
0231デフォルトの名無しさん2010/10/27(水) 23:10:54
＞224
どうみてもBeですね。
0232デフォルトの名無しさん2010/10/28(木) 12:52:57
>>226
FRP は「実行する」という概念をできるだけ排除して、
システムとメッセージとの間にある応答を伴った「性質や関係」を宣言的に記述しよう
というのが目論見のような気がする
0233デフォルトの名無しさん2010/10/28(木) 17:49:42
何をやっても結局パフォーマンスの問題に突き当たる
0234デフォルトの名無しさん2010/10/28(木) 22:34:05
プログラミングを教えるとき、
メッセージループまで必ず教えよう。

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

0235デフォルトの名無しさん2010/10/29(金) 21:27:29
新規作成メニューから
メッセージループを選択しクリックする

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

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

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

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

一昔前まえに、スモールトークという
開発環境に初めてあった時の感動を
覚えた。
0236デフォルトの名無しさん2010/10/31(日) 05:48:28
関数型言語とCってどっちの方が最適化しやすいの？
0237デフォルトの名無しさん2010/10/31(日) 09:07:44
C だよん。

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

他の関数型言語、たとえば Haskell 処理系である GHC は、SML/NJ と比較しても圧倒的に遅い。
0238デフォルトの名無しさん2010/10/31(日) 09:09:20
fortranが最速
0239デフォルトの名無しさん2010/10/31(日) 09:19:35
最適化とは処理時間のことなのか。
0240デフォルトの名無しさん2010/10/31(日) 09:25:25
定数倍なら同じだよな
0241デフォルトの名無しさん2010/10/31(日) 09:39:58
コンパイラによる最適化を意図して聞きました。処理時間による評価です。
なんとなく手続きじゃないから最適化しやすいのではないかと考えて質問した次第です。
0242デフォルトの名無しさん2010/10/31(日) 09:44:08
Cコンパイラのほうが圧倒的に投入されている労力が大きいから、比較にならない。
関数型なら動的解析とかないし、ある意味最初から静的単一代入形式だったりするわけだけどさ。
0243デフォルトの名無しさん2010/10/31(日) 09:48:36
なるほど、どちらかといえば普及したら速くなるかもって感じなんですね。
0244デフォルトの名無しさん2010/10/31(日) 10:17:38
「最適化しやすい」というのが、
ソースコードを解析して最適化できるヶ所を見つけるということなら、
一般的には関数型の方が最適化しやすいと思う。

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

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

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

関数型は喩えるなら英文を機械翻訳するようなものだと思う。
0245デフォルトの名無しさん2010/10/31(日) 10:37:45
なるほど、熟練したプログラマ並のコスト評価と適応的なロジックの適用ができないと
最終的に速くはならないだろうということですね。賢くなってほしいなぁ。
0246デフォルトの名無しさん2010/10/31(日) 10:38:45
GUESSじゃなくて、HOWを書けよ。
0247デフォルトの名無しさん2010/10/31(日) 10:44:38
私に言ってるならGUESSでもなくHOPEですが
0248デフォルトの名無しさん2010/10/31(日) 11:40:07
沈思黙考するよりもheuristicな実験をする方が賢いですよね
0249デフォルトの名無しさん2010/10/31(日) 15:53:03
関数型言語葉、C言語でつくってる。
広い意味での外部DSL
0250デフォルトの名無しさん2010/10/31(日) 16:07:40
>>249
意味が分からん
もう少し詳細に語ってくれ
0251デフォルトの名無しさん2010/11/03(水) 07:58:09
>>250
いや、Erlangなんかは1991年マイク　ウィリアムズが
C言語で仮想マシンを書いたんだけど、
要は関数型言語を使うためにC言語でまずつくってるっていう
ビルディングブロックになってるというか階層構造になってるので
言語VS言語みたいな議論はその辺をちゃんと押さえないとってこと。
ある目的のために、低レベルな言語でスクリプトかいてそのスクリプトで効率的に
開発するっていう手法もある。
で、つまり究極的にはその関数型言語やスクリプトで書いたシステムは
C言語でかけるわけで。。。（Cでつくった仮想マシンでうごいてるんだから。）
最後はマシン語におちるから。
つまり、関数型言語っていうのは、フレームワークとか外部DSLにすぎないっていう
視点があって、それは言語論争をする際には記憶の片隅においておかないといけないことなんだよね。
0252デフォルトの名無しさん2010/11/03(水) 08:11:06
片隅においておいて、
なんかいいことあるわけ？
■ このスレッドは過去ログ倉庫に格納されています