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

消えてなくなれよ >オブジェクト指向 part.2

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2009/03/22(日) 06:57:59
前スレ
http://pc11.2ch.net/test/read.cgi/tech/1198822420/
0492デフォルトの名無しさん2009/05/22(金) 16:03:49
いいこと思いついた
引数で「例外ファクトリ」を指定する仕様にすればスローするのが当然だよね
0493デフォルトの名無しさん2009/05/22(金) 18:13:48
ああーやっぱり明確な仕様の記述なしに例外投げんなでFAか
まあ、そうじゃねぇと邪魔でしょうがねぇよな
0494デフォルトの名無しさん2009/05/22(金) 19:39:15
ドキュメントをまったく書くつもりのない俺は例外を書く資格なしということで
このスレの例外議論を終了したいと思います。2009年5月22日(金)
0495デフォルトの名無しさん2009/05/22(金) 19:52:02
C++が最強
0496デフォルトの名無しさん2009/05/22(金) 21:35:47
ABIがCな時点でCが最強なんだよタコ
0497デフォルトの名無しさん2009/05/22(金) 21:37:45
お前はABIが何か分かってないな
0498デフォルトの名無しさん2009/05/22(金) 21:37:49
C++にしても基本はCだからね
0499デフォルトの名無しさん2009/05/22(金) 21:55:13
なんだか、継続の代わりに例外を使ってる人が居そう。
0500デフォルトの名無しさん2009/05/22(金) 22:03:55
え?w
0501デフォルトの名無しさん2009/05/22(金) 22:10:28
失敗を恐れているんじゃねぇよ。
エラーになるかもなんていっていたら何もできやしない。
俺はエラー処理なんて一度も書いたことねぇ。
やれるって信じたら絶対できる。
0502デフォルトの名無しさん2009/05/22(金) 22:20:20
最適化と同じで、エラーを気にしだすときりがない気はする
0503デフォルトの名無しさん2009/05/22(金) 22:30:20
例外処理ってビミョーだよな。

投げる側では「ある条件のとき例外を投げる」
として、普通におもっくそ想定を置いている。
例外でもなんでもない。
ゼロで割る? ファイルがない? 数値化できる文字列じゃない?

んなもん事前に調べれ。
0504デフォルトの名無しさん2009/05/22(金) 23:18:44
例外なんて投げたことないな。
そんな機能があったことも忘れたよw
0505デフォルトの名無しさん2009/05/22(金) 23:30:10
>>503
ファイルの存在を確認してから
開くまでの間に消されるかもしれないじゃないか。
そんなのどうやって事前に調べるんだよ
0506デフォルトの名無しさん2009/05/22(金) 23:31:26
ライブラリが下手に例外投げる仕様だと
受け手がいなくて死んだりする
リンクのミスとかで他の不具合も出る
投げないにこしたことない
0507デフォルトの名無しさん2009/05/22(金) 23:32:39
落ちなければいいってわけでもないが
0508デフォルトの名無しさん2009/05/22(金) 23:37:36
>>505
それは「ファイルを消すな」という問題じゃね?
プログラムが責任を持つのはせいぜい、
プログラム内での排他処理でよくね?

OSレベルのことで困れば、
オチてプログラム呼び出し側で責任取らせればよくね?

呼び出し元の事情を気にするのは、
よくない設計じゃね?
0509デフォルトの名無しさん2009/05/22(金) 23:45:48
次のfreadがしける程度だろ?
0510デフォルトの名無しさん2009/05/23(土) 03:37:44
例外イラネとか言ってるやつのどれだけが、
malloc()の返り値のNULLチェックをやっているのやら。
0511デフォルトの名無しさん2009/05/23(土) 04:13:00
>>503
> ゼロで割る? ファイルがない? 数値化できる文字列じゃない?
> んなもん事前に調べれ。

文句言うまえに、そんな糞パラメータ送ったおまえが調べろよ。
0512デフォルトの名無しさん2009/05/23(土) 04:47:38
例外は"スタックを調整してデータを積んでGOTOしてるだけ"なので

a();
v = f();
b();
c(v);

一見正しくみえるが、f()が例外を飛ばすのを忘れていると
例外自体は他でキャッチするのでテストはキチンと失敗するにも関わらず
f()が失敗したのに誤ってa()したり、誤ってb()しなかったりする

OO的に

Any f() {
if (!hoge()) reterun new Error("Can't hoge!");
return fuga();
}

のように正常な経路でメッセージを戻せばその種の不整合問題は発生しづらい
エラー処理を忘れたらc(v)の内部でとまるので原因はすぐわかる
実際はc(v)内部で引数のチェックくらいするからエラーを記録して何もしないという選択もできる

例外投げたらそこで終了だよ
0513デフォルトの名無しさん2009/05/23(土) 05:33:56
>>512
Javaの場合、トラップするべき例外をトラップしていなければ
コンパイラがそれを指摘してくれますが何か?

返り値でエラーコードを返す場合にはそうはいきませんなあ。

で、君はmalloc()するたびにちゃんとNULLチェックしてるの?
0514デフォルトの名無しさん2009/05/23(土) 05:38:46
>>512
おまえ、本当にマか?

> Any f() {
> if (!hoge()) reterun new Error("Can't hoge!");
> return fuga();
> }

コンパイラさんからreterunって何?って叱られるぞw

> のように正常な経路でメッセージを戻せばその種の不整合問題は発生しづらい

f()の返り値がおかしいかどうかちゃんとチェックしていなければ、
原因をトレースするのが厄介になるぞ。c(v)が悪いのかf()が悪いのかa()が悪いのか
ワケワカラン状態になるのがオチだ。
例外を使えばちゃんとスタック保存してくれているから原因は一目瞭然。

> 実際はc(v)内部で引数のチェックくらいするからエラーを記録して何もしないという選択もできる

空のハンドラ渡すのと何が違うの?
0515デフォルトの名無しさん2009/05/23(土) 05:41:47
>>512
>f()が例外を飛ばすのを忘れていると
処理に失敗したのにも関わらず例外を投げ忘れたf()は、返値
として一体何を返すの?

>if (!hoge()) reterun new Error("Can't hoge!");

ここでエラーを返すか例外を投げるか、それだけの違いでは。
if (!hoge())をチェックすべきことが分かっているか否か、大切
なのはその事であって、この事に気づいていればエラーを返す
とか例外投げるとかは単に実装の違いに過ぎないと思う。

>f()が失敗したのに誤ってa()したり、
関数の呼び出し順が間違っているのでは。a()の実行の前提と
してf()の成功が必要なら、f()の後にa()呼ぶでしょ。
これは例外とか返値云々とは無関係な、因果律の問題。

>誤ってb()しなかったりする
何のためにensureやfinallyがあると思っているんだ。

>c(v)の内部でとまるので原因はすぐわかる
止まったときには結局例外が投げられるんじゃない?

>Any f() {

言語にもよるけど、静的型付けの言語の場合には結果と
詳細なエラー情報を共に返値で返すとなると返値の型や
セマンティクスで悩むことは少なく無いと思う。
Anyですか。そうですか。
0516デフォルトの名無しさん2009/05/23(土) 05:50:56
>>515
> 言語にもよるけど、静的型付けの言語の場合には結果と
> 詳細なエラー情報を共に返値で返すとなると返値の型や
> セマンティクスで悩むことは少なく無いと思う。

そうそう。存在しないキーでハッシュマップ引いた時に
例外を投げずにNullを返しちゃったりしたら、
ハッシュマップで対応する値がNullだったのか、
ハッシュマップで対応する値がなかったのか、
判別つかないんだよな。
その判別をするための特殊なクラスをつくると、
とたんに返り値の型が問題になる。
Objectとかにしたら、今度は使う側でナローキャスト
してやらなきゃならなくなって静的型のメリットがなくなるし。
0517デフォルトの名無しさん2009/05/23(土) 06:27:10
>>515
f()が例外を返すことを書いた時は覚えていた
その例外は別の階層でトラップされるから正しい記述である
が翌日忘れてあるいは別人が修正したとするそんな感じのバグが生まれる話
言語仕様が関数が例外を投げると宣言することを強制しても
例外を戻す関数が他にあれば紛れてしまうでしょ

a()の位置が違うのは分かってワザとそこに書いたの
v=f()のところにエラー処理の記述があればレビューの時に誰か気付くんだよ
0518デフォルトの名無しさん2009/05/23(土) 07:33:56
>>516
C#の場合だが例外を発生させないためにTryGetValueがある。
bool result = dictionary.TryGetValue(key,out val);
キーのない値をひくのは通常処理の場合が往々にしてあるからこれも必要と思う
0519デフォルトの名無しさん2009/05/23(土) 08:49:42
お前らが言ってるのは、例外処理以前の話じゃん

「ドキュメントやコメントをちゃんと書きやがれ」

って次元の問題じゃん
0520デフォルトの名無しさん2009/05/23(土) 09:50:34
Cだったら戻り値の意味書くぐらいでいいのに例外だと説明すんのがめんどくさいんだよね
0521デフォルトの名無しさん2009/05/23(土) 09:52:13
GetValueとFindがあればいいだけの話。
GetValueは例外、FindはNo Such Keyを表す何かを返す。
0522デフォルトの名無しさん2009/05/23(土) 10:23:07
どんどん話が低脳者の会話になっていってるな
もうオブジェクト指向が無くなれとか言う問題じゃなくなってるwww
0523デフォルトの名無しさん2009/05/23(土) 10:40:46
>>518
outがなければ例外を投げればいいじゃない(キリッ
0524デフォルトの名無しさん2009/05/23(土) 11:30:50
例外は>>486で結論出てるのにな…
ライブラリが例外を返すようなコードを書くな。書くならそのリスクを覚悟しろってことだ
0525デフォルトの名無しさん2009/05/23(土) 12:49:19
>>524
486のリンク先は言ってることが良く分からない。
内容が有益であるのなら、だれか要点をまとめてくれない?

# だらだらした文書である上、罰則だの精神とかの妙な単語が頻出していて
# 頭のおかしなやつが書いたようにしか見えなかった…
# (ソースのインデントの仕方も一番ダメだと思っているスタイルだったし…)
0526デフォルトの名無しさん2009/05/23(土) 13:00:45
>>518
実際例外使わないバージョンを書くときにその手の事前チェックの
関数と実処理の関数に分けることは常套だけど、前提もある。

一つはそのハッシュがスレッド間で共有されてたり、データが実は
ネット上にあってそれを参照しに行くような実装ではないこと。
チェックしてから実処理するまでの間にハッシュの内部状態が変わる
可能性があるからね。

もう一つは事前チェックが非破壊的に、しかも低コストで行える事。
例えばXML等のパース。事前に「パース可能か」なんて確認しよう
と思ったら、その後のパース本番と併せて2度XML文書をスキャン
する事になる。

つまり何時でも使える手ではないし、それを回避するために色々工夫
するよりは(ハッシュのロックを取得する関数を追加したり、パース後
にエラーを 取得する関数を追加したり)サクッと例外を投げる仕様に
した方が見た目も使い勝手もシンプルになるケースもある。
0527デフォルトの名無しさん2009/05/23(土) 13:23:27
>>525
しっかり読んだうえでまだなにかあるなら
正規OS買ってMSにメールだせよw
だいたいあの程度の文章理解できないってありえないだろ
英文なわけでもないし
捻った表現してるわけでもない
0528デフォルトの名無しさん2009/05/23(土) 13:24:11
>>525
結局のところは>>450って事だろ
0529デフォルトの名無しさん2009/05/23(土) 13:25:17
>>528
全然違うよ
読んでないなら無理やりレスをつけるな
0530デフォルトの名無しさん2009/05/23(土) 13:26:13
大雑把にまとめちゃうと

そんな細かいこと気にしてるから禿げるんだよ!!!

ってこった
0531デフォルトの名無しさん2009/05/23(土) 14:34:01
>>521
> GetValueは例外、FindはNo Such Keyを表す何かを返す。
そしてFindはGetValueを使って実装されている。
例えばPythonなんかはそういう実装。
0532デフォルトの名無しさん2009/05/23(土) 14:58:56
その関数内でのエラーの発生が引数に対して非決定的であるときは例外を使う
0533デフォルトの名無しさん2009/05/23(土) 15:38:21
>>532
日本語でおk
0534デフォルトの名無しさん2009/05/23(土) 16:58:12
public static int parseInt(String s)
throws NumberFormatException

パラメータ:
s - 構文解析対象の int 表現を含む String
戻り値:
10 進数の引数で表される整数値
例外:
NumberFormatException - 文字列が構文解析可能な整数型を含まない場合

こういうときは例外のほうが素直な気がするね。
intでどうのこうのやりくりしたりするよりは。
0535デフォルトの名無しさん2009/05/23(土) 17:14:35
>>534
文字列の数値変換なら、変換不能な場合は素直に0を返したほうが良くね?
例外にする意味が分からん...
エラーとして扱うにしても、エラーにする意味も分からん...
0536デフォルトの名無しさん2009/05/23(土) 17:18:37
0が渡されたのか、解析不能な文字列が渡されたのかわからんやん。
解析不能は0として扱うでいい場合もあるけど。
0537デフォルトの名無しさん2009/05/23(土) 17:27:37
そこで多値ですよ

まあ現実的にはWin32APIみたく戻り型をBOOLにして
引数側で結果を受け取れば問題ないね
0538デフォルトの名無しさん2009/05/23(土) 17:29:16
>536
そういうのは、Javaなら参照型のInteger、C#ならNullable型とかの抜け道があるし。
0539デフォルトの名無しさん2009/05/23(土) 17:33:01
ここまでオブジェクト指向とは全く関係ないな
既に消えてしまったようだ
0540デフォルトの名無しさん2009/05/23(土) 18:47:32
例外なんて元をたどればC言語に出て来るlongjumpがルーツなんだけど
間にobjectのnewとかdeleteが入るとまずいってんでthrow catchにしたわけですよ。

例外を使いたくない奴は使わない、使いたい奴は使うということでいいんじゃないの?

でもthrowした奴は投げっぱなしじゃなくて責任持ってcatchしろよな ボケ!
0541デフォルトの名無しさん2009/05/23(土) 18:58:11
>>523
例外を返したければインデクサをそのまま使えばよい
C#では2種類用意されていると言うこと

>outがなければ例外を投げればいいじゃない(キリッ
キーが存在して、値がnullの場合があるからそれじゃダメなんだよ
516も読んでるか?
0542デフォルトの名無しさん2009/05/23(土) 19:03:11
>>540
BASICのON ERROR GOTOが先じゃね?
0543デフォルトの名無しさん2009/05/23(土) 19:04:37
ハッシュとかの場合はノードそのものを返すようにするんだよ
受け側はノードが返ったら値を得る
見つからなかったらNULLでいいじゃない
特殊なクラスだとか、おまえら頭悪すぎですよ
0544デフォルトの名無しさん2009/05/23(土) 19:08:24
>>543
ちょっとした工夫だな。でも、それでいいと思う。

メソッドの返り値がすべてその仕組みになってたら、
nullか否かで全部扱えるのにな。例外なく。
0545デフォルトの名無しさん2009/05/23(土) 19:29:26
>>543
自己紹介乙
0546デフォルトの名無しさん2009/05/23(土) 19:31:13
>>543
ノードそのものを渡してしまうと、ちんたらしている間に
ノードの中身を他スレッドとかに書き換えられる恐れも
あるんだよね。

1) Node node = map.getNode(key);
2) if(node != null){
3) chintara();
4) chintara();
5) chintara();
6) chintara();
7) return func(node.value);
8) }else
9) return ERROR;

ちんたらするんじゃね〜とも言いたくなるけど、3〜6の間に
node.valueの値が書き換えられたりnode自体がmapから
removeされていても、文句は言えん。
仮にmap自身が自前で排他制御して複数スレッドのアクセスを
認めるマルチクライアントな実装になっていても、これでは
殆ど意味がない。結局node.valueを取得するまでmapをロック
するコードを毎度クライアント側で書く必要がある。
nodeへの参照ではなくコピーを返すのも一つの手だけど、
それだと処理値をエラーコード付きの構造体でラップして
返すのと大差無いような気もする。
0547デフォルトの名無しさん2009/05/23(土) 19:39:32
管理の基本は、何かをした人が、責任を持って後始末することだろ?
0548デフォルトの名無しさん2009/05/23(土) 19:39:36
543, 544についつられてしまうところだった


0549デフォルトの名無しさん2009/05/23(土) 19:43:50
冷害最高
楽楽マルチインスタンス

継承はまああってもいいんじゃない?
0550デフォルトの名無しさん2009/05/23(土) 20:21:51
>>546
そんな構造にしてるやつはアフォ
そうしないといけない構造はこの世にない
0551デフォルトの名無しさん2009/05/23(土) 20:47:41
>>546はスレッド間の排他の話ではあっても、
例外の話ではない。

> 結局node.valueを取得するまでmapをロック
> するコードを毎度クライアント側で書く必要がある。

あくまでそういう処理ならば、そう書くしかないのでは。
0552デフォルトの名無しさん2009/05/23(土) 21:30:18
>>551
その通り。だからノードを渡す、という動作は値を渡す、という
動作をそのまま置き換えるものではない、ということ。
ノードを渡すことによって確かに例外いらずになるかもしれない。
でも異なるものを渡す以上別のところで振る舞いが変わってくる
可能性もあって、例えばスレッドが絡んできた場合などがその一例
ということ。
0553デフォルトの名無しさん2009/05/23(土) 21:48:44
抽象論はきらいです
消えてなくなれー
0554デフォルトの名無しさん2009/05/23(土) 21:50:05
抽象論なんて、片手間で理解できなきゃプログラマーと言えん。
0555デフォルトの名無しさん2009/05/23(土) 21:54:01
ある事柄を説明するためには、必要以上に抽象的な概念を仮定するべきでない。
0556デフォルトの名無しさん2009/05/23(土) 21:58:33
オッカムの剃刀は「必要以上に多くの実体を仮定するべきでない」だけど、
抽象は多くのものをひとくくりにする技術だから、
結局のところ多くの実体を仮定しているのと同じことなんだよ。
0557デフォルトの名無しさん2009/05/23(土) 22:00:55
メタ抽象論
0558デフォルトの名無しさん2009/05/23(土) 22:11:45
おまえら、プログラミングそのものが象徴されたものの操作に他ならないのをわかってるのか。
データは現実の有り方のひとつの象徴だし、プログラムによる操作は、現実を象徴化した
モデルの操作なんだよ!
0559デフォルトの名無しさん2009/05/23(土) 22:25:39
既に、例外の話でもなくなっている...
どんなけメス会話してるんだよ...
0560デフォルトの名無しさん2009/05/23(土) 22:30:28
象徴ww
抽象だろうが馬鹿が
0561デフォルトの名無しさん2009/05/23(土) 22:46:25
単純に、不必要な情報を見えないようにするとか言えばいいのに
余計な意味を加えて
これは抽象化、モデル化、象徴化なんだよ!
っていうのが怪しい。
0562デフォルトの名無しさん2009/05/23(土) 22:47:33
>>560
大差なくね?
というか一般層が考える抽象の意味よりは象徴の方がまだ意味が近い気がする。

まぁ真の意図は>>558に聞かんとわからんが
0563デフォルトの名無しさん2009/05/23(土) 23:00:49
>>562
学が無さ過ぎだろ。
抽象と象徴は日本語でも英語でも意味が違うし、具象と対をなす概念だ。
象徴の対義語は具象ではない。しっかり自分で調べてこい。
0564デフォルトの名無しさん2009/05/23(土) 23:26:38
>>563
一般層の話な。
0565デフォルトの名無しさん2009/05/23(土) 23:32:06
まぁプログラマ以外に抽象を説明するときは困るな。
大抵、いい加減とかそういう意味に取られる。
いい加減自体の意味も厳密に言い出すとキリがないが…
0566デフォルトの名無しさん2009/05/23(土) 23:38:43
ノードにアクセスしてるときは基本アクセスできねぇだろ
っていうか仕様どおりであってその辺の仕様があいまいなのを
プログラムに押し付けること自体すでに間違いだろ

何をいってるのかさっぱりわからない
頭悪いのにえらそうにしてるやつはずかしいから発言やめろ
0567デフォルトの名無しさん2009/05/23(土) 23:46:14
>>565
>まぁプログラマ以外に抽象を説明するときは困るな。
ちょっと理解しがたいシチュエーションだな。
>>564 の必死な弁解に付き合う必要はないと思うが。
0568デフォルトの名無しさん2009/05/23(土) 23:53:16
むしろプログラマに通じなくて困る
俺の会社だが
0569デフォルトの名無しさん2009/05/24(日) 06:57:02
>>543
> ハッシュとかの場合はノードそのものを返すようにするんだよ

毎回ノードをインスタンス生成しますか?
それともハッシュマップ中のノードをそのまま返して、
どっかのアフォがノードの中身を書き替えて、
滅茶苦茶トレースしにくいバグを作り込む元をつくりますか?
0570デフォルトの名無しさん2009/05/24(日) 06:58:23
>>540
longjumpは例外というより継続なのだが。
まあ継続で例外を実装することは可能だけど、
例外の元になったのがlongjumpかと言われると
それは間違いと答えるしかない。
0571デフォルトの名無しさん2009/05/24(日) 10:31:21
>>569
アクセスと切るまで他の人間はアクセス不能(もしくは読み取り専用)
っていうか仕様はどうなってるの?
0572デフォルトの名無しさん2009/05/24(日) 10:40:01
このペースで行くと、人間がプログラムすることが悪って話になるな
0573デフォルトの名無しさん2009/05/24(日) 10:41:57
マルチスレッドのプログラムの複雑さをオブジェクト指向のいいわけに使うやつがいるけど
大抵は仕様が決まってないことが問題でオブジェクト指向とはなんの関係もないよね?
問題の切り分けもできない人が現場で報告もせずに勝手に騒ぎ立てるとか結構多い
0574デフォルトの名無しさん2009/05/24(日) 11:29:32
仕様を厳密に決めることと
仕様を抽象的にすることは
両立できるのか? という話だな。

まず厳密さだけ考えて、後でリファクタリングするとか。
0575デフォルトの名無しさん2009/05/24(日) 12:16:21
>>573
>いいわけに使うやつがいるけど
幸いにして、そこまでの莫迦は見たことがない。
>オブジェクト指向とはなんの関係もないよね?
肯。
0576デフォルトの名無しさん2009/05/24(日) 12:21:10
>573
マルチスレッドで思い出したけど、最近は並行処理にはオブジェクト指向的な
解決法より関数型言語のやり方の方がうまくいくって風潮じゃない?

オブジェクト定義するにしても可能な限りimmutableにしたりして、従来とは
ちょと違うよね。
0577デフォルトの名無しさん2009/05/24(日) 12:39:17
>>576
そういう風になることは10年以上前から予測済み。
オブジェクト指向に期待したことなんて今まで一度もなかった。
単にセミナー屋が騒いでるな ぐらいにしか思わなかったからな。
0578デフォルトの名無しさん2009/05/24(日) 12:52:02
最初から関数型言語をやってればよかったけど
当時はVBとC++とfortran、pascal、機械語、あとはlisp 2とprologぐらいしか知らなかったので
仕方なくVC6を使って未完成のC++と腐ったOOPの狭間で藻掻いてた
でもlisp 2やprologの存在を知っててSchemeやMLとかMirrandaにまで至らなかったのは俺のミスだ…
0579デフォルトの名無しさん2009/05/24(日) 12:58:49
>>578
そこが英語が得意な奴と苦手な奴の差
0580デフォルトの名無しさん2009/05/24(日) 14:00:53
>>578
Mirrandaなんかに騙されたのか?かわいそうな奴だ。
俺はちゃんとMirandaを使ってたぞ。
0581デフォルトの名無しさん2009/05/24(日) 16:03:08
Mirandaってみんな処理系買ってやってた?

あとどんくらい実用的なアプリ作ってた?
0582デフォルトの名無しさん2009/05/24(日) 16:36:27
>>581
学校がサイトライセンス持ってた。
それで関数型言語の処理系を書いた。
0583デフォルトの名無しさん2009/05/24(日) 16:48:46
なるほど考えてみればああいうのに手をだすのって学校とか研究関係だもんな。

俺みたいな趣味の人はMirandaなんてHaskellが有名になってきてから初めて知ったわ。
0584デフォルトの名無しさん2009/05/24(日) 16:51:58
ただ近年になって一般人に関数型言語が注目されたのは大きいね。
Haskellは院時代に講義で使ったけど、なんでHaskellが一般人に流行ったのか
分からん。そういう俺はOCaml使い。
0585デフォルトの名無しさん2009/05/24(日) 16:53:35
>>583
Haskellも有名じゃないと思うんだが・・
どっちかというとOCamlの方が有名じゃないか
0586デフォルトの名無しさん2009/05/24(日) 17:01:09
Haskellは2004年のICPCで有名になった
0587デフォルトの名無しさん2009/05/24(日) 17:05:29
>>585
むしろ東大がOCamlをで講義に使ってるから東大生の間では有名に見えちゃうだけじゃないすか?
プログラミング言語の講義で最初にPrologやったら「ああ、みんなPrologでソフト作ってるんだなー、へー」
みたいに思っちゃうのと同じ。

一般的に満たらHaskellのほうが全然有名だと思うなー。

http://www.google.com/trends?q=Haskell%2COCaml&ctab=0&geo=all&date=all&sort=0


と思ってみたらやっぱHaskell圧勝ですたw
0588デフォルトの名無しさん2009/05/24(日) 17:14:02
>>587
おまえ頭悪いな。
Haskellは地名や人名でありふれているから、そんなものは全く比較にならないぞ。
0589デフォルトの名無しさん2009/05/24(日) 17:57:59
>>588
じゃあどうやって比較すればいいか示してみろよ。

すぐ「おまえ頭悪いな。」とか言っちゃう所がアレだよねw
0590デフォルトの名無しさん2009/05/24(日) 18:03:17
人名、地名であふれてると言ってもHaskellで検索して上位にくるのはやっぱり言語のHaskellばかりだし
全くアテにならないってことはないと思うよ。
0591デフォルトの名無しさん2009/05/24(日) 18:06:10
>>589
人に責任転嫁するな。お前が勝手に比較しようとしたんだろうが。
俺は比較しろなんて一言も言っていない。

何も考えずにGoogle Trends使ってデータを出して、確認もせずに
「と思ってみたらやっぱHaskell圧勝ですたw」
なんて言うような奴は頭が悪いとしか言いように無いだろうが。
0592デフォルトの名無しさん2009/05/24(日) 18:10:28
>>591

wがついてるからある程度シャレなわけだが。
別に厳密に比較する方法なんて無いことは最初から分かってるわけだし、

>お前が勝手に比較しようとしたんだろうが。
>>585氏の
>どっちかというとOCamlの方が有名じゃないか

こういう発言をうけて試しにGoogle trendで比較してみただけなんだが。

なんかOCamlのほうが有名じゃなきゃ困るのw?
■ このスレッドは過去ログ倉庫に格納されています