1 :デフォルトの名無しさん2011/09/25(日) 02:57:26.96
OO関連及び動的言語関連で事あるごとに争っている
静的型付け厨と動的型付け厨が、思う存分飽きるまで仲良く
罵り合う為のスレです。

スレの進行を妨げる型安全議論を見かけた場合は、
こちらへの誘導をお願いします。

関連スレ:
やっぱり動的言語では安全なソフトは作れない 4
http://hibari.2ch.net/test/read.cgi/tech/1316016777/

【OOP】オブジェクト指向総合 part3【OOA/OOD】
http://hibari.2ch.net/test/read.cgi/tech/1312982517/

-OOP限定-プログラム設計相談室
http://hibari.2ch.net/test/read.cgi/tech/1127547359/

オブジェクト設計&デザパタ
http://hibari.2ch.net/test/read.cgi/tech/1272806908/
2 :デフォルトの名無しさん2011/09/25(日) 03:00:55.26
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

                  京都大学霊長類研究所
4 :デフォルトの名無しさん2011/09/25(日) 03:33:45.33
型チェックがあろうがそもそもテストしてない機能は動作保証外なんだから変わらん
6 :デフォルトの名無しさん2011/09/25(日) 04:04:28.83
366 名前:デフォルトの名無しさん [sage]: 2011/09/25(日) 03:50:13.66
Steve曰く、Rubyはreliableじゃない。

Steve Jenson: Another thing we really like about Scala is static typing that’s not painful.
Sometimes it would be really nice in Ruby to say things like, here’s an optional type annotation.
This is the type we really expect to see here.
And we find that really useful in Scala, to be able to specify the type information.
7 :uy2011/09/25(日) 15:05:53.25
あったま悪そうなやつがスレたてたなぁ


こういうのを重複スレっていうんだよ 削除対象か、まぁ次スレにでも使えばいいか
8 :デフォルトの名無しさん2011/09/25(日) 15:22:59.12
アナタのような基○外のためのスレですよ
9 :デフォルトの名無しさん2011/09/25(日) 15:25:55.53
ケアレスミスだけど、影響が大きいバグを、
1.コンパイル時、あるいは気の利いたIDEならソース入力時にエディタがその場で問題の箇所を漏れなく検出する
のと、
2.単体テスト等の結果が不正であることから、原因を自分で調査、場所を特定、変数の型付けが原因と自分で突き止める
のと、どっちが良いか?って話だな。
10 :デフォルトの名無しさん2011/09/25(日) 15:30:10.76
今時のIDEなら動的型言語でもスペルミスを見付けてくれるだろ。
11 :デフォルトの名無しさん2011/09/25(日) 15:36:47.52
>>10
それは不可能だよ。
定義がなければ、間違っていることはわからない。
13 :デフォルトの名無しさん2011/09/25(日) 15:42:16.29
スペルミス程度ならあるいは可能かもしれないけど、実行前に型の誤りを見つけるのは無理だろ>動的
14 :デフォルトの名無しさん2011/09/25(日) 15:46:18.58
メソッドを呼び出した時の戻り値がちゃんと仕様を満たしているか把握すんのは動的型付けじゃ難しい
17 :デフォルトの名無しさん2011/09/25(日) 16:18:01.17
>>14
それ、現段階じゃ静的型でもほぼ不可能だし。
18 :デフォルトの名無しさん2011/09/25(日) 16:20:04.83
>>14
静的型ったって、返り値の型ぐらいしか保障されない。
整数が返り値だとして、それが期待されている「範囲内の」整数かどうかなんて
静的型はこれっぽっちも保障してくれない。

くやしかったらゼロ除算が絶対に発生しない言語でもつくってみろ。
22 :デフォルトの名無しさん2011/09/25(日) 16:39:18.36
>>18
お前はなにを言ってるの?
23 :デフォルトの名無しさん2011/09/25(日) 16:47:53.34
>>18
静的型付けであれば、自分がオーバーライドしたメソッドが、
どんな仕様を満たさなければならないか、把握してる。

静的型付けであれば、自分が使用するオブジェクトが、
どの仕様に沿って作られたかは把握している。

コーディングミスで仕様が保証されないとかいう問題じゃなく、
どの仕様に基づいているか、定義側、使用側で合意が取れており、
合意外の記述がしづらい事が重要。
38 :デフォルトの名無しさん2011/09/25(日) 18:58:26.15
>>23
> 静的型付けであれば、自分がオーバーライドしたメソッドが、
> どんな仕様を満たさなければならないか、把握してる。

バーカ、それは事前条件、事後条件、不変条件の証明をやってから言え。
型がわかるだけで「どんな仕様を満たさなければならないか、把握してる(キリリッ!」とか、笑えるw

> 静的型付けであれば、自分が使用するオブジェクトが、
> どの仕様に沿って作られたかは把握している。

バーカ、それは各属性の不変条件の証明をやってから言え。
型がわかるだけで「どんな仕様を満たさなければならないか、把握してる(キリリッ!」とか、笑えるw

> コーディングミスで仕様が保証されないとかいう問題じゃなく、
> どの仕様に基づいているか、定義側、使用側で合意が取れており、
> 合意外の記述がしづらい事が重要。

型がわかる程度じゃ意味ねえよ!
静的厨の言う安全性/健全性って、この程度の浅いものなの?バカなの?
50 :デフォルトの名無しさん2011/09/25(日) 21:23:43.28
>>38 は不変条件だのなんだの書いてるが、そんなもの範囲付き型検査で済むから
本当に言いたいのは、そういう話じゃないんだろうな。sin関数が正弦を返してないとか
そんな話なんだろ。でもそれは型チェック云々の範疇じゃなくていいと思うが。
15 :デフォルトの名無しさん2011/09/25(日) 15:52:53.14
カバレッジ90%超えるならテストで見つかる v.s. カバレッジ60%超えるぐらいなのが現実
16 :デフォルトの名無しさん2011/09/25(日) 15:58:36.92
静的型付け厨が嫌うのはテスト範囲外の動作が不安で不安で仕方ないからなんだろ

じゃ問題になるのはテスト範囲外の動作で停止したらどうするのが正しいのか。
19 :デフォルトの名無しさん2011/09/25(日) 16:29:53.81
要するに戻り値型のインターフェース仕様が無いから分かりづらいという所か

process.method(source)

ここでmethodがsource.example()を呼び出したとして、
methodが戻り値にどのメソッドを持ったオブジェクトを
返すのを期待しているかまでは、methodの実装を覗くまで
把握しづらい。
上手く回避するためには、sourceの仕様とsource.methodの仕様
それからsource.methodの戻り値オブジェクトの仕様まで文書かする必要がある。
静的言語でも親クラスで定義してあるから同様だけど。
20 :デフォルトの名無しさん2011/09/25(日) 16:30:34.88
で、テストで返り値をチェックするコードを書くと、
そのまま型のテストも兼ねることになるんだよね
21 :デフォルトの名無しさん2011/09/25(日) 16:33:02.43
ダックタイピングは別に動的型付けのメリットでは無いよな。
GoのインターフェースやG++のsignatureの様な形で静的型づけでも実現されてるし。
24 :デフォルトの名無しさん2011/09/25(日) 17:03:25.36
ようは、(コメントやドキュメントじゃなくて)コードの中に
アプリケーションの仕様を記述できる量が多いってことなんだよな。
静的言語っていうのは。
25 :デフォルトの名無しさん2011/09/25(日) 17:06:21.91
ばかじゃねーの
んなもん静的型付け/動的型付けなんて関係ないだろ
動的型付けだと仕様をコードに記述出来ない理由があるのか?
27 :デフォルトの名無しさん2011/09/25(日) 17:08:45.29
>>25
よく読んでね。

出来る出来ないなんて一言も言ってない。
静的言語のほうが、”多い”って言ってるの。
73 :uy2011/09/26(月) 03:07:45.81
>>8
で、キチガイこんなにいんの?wwwwwwww

重複スレまでこのスレ勢いってどんだけだよ


>>27
え・・・・・・なにこの初心者

初心者っていうか、何?
専門学校入って、半年目なんだけど、学校サボっちゃっててぜんぜん知識身についてないような
そんな感じの奴か
26 :デフォルトの名無しさん2011/09/25(日) 17:07:38.07
コードとドキュメントの両方を同期させてメンテナンスするのは
同じ事を二度書くということで、KISSの考えに反するんだよね。
29 :デフォルトの名無しさん2011/09/25(日) 17:13:15.23
動的言語でも「変数は宣言してから使いましょう」って考えは同じだろう。

宣言はめんどくさない。宣言しないで使えたほうが記述量は減る。
どうせテストをするのだから、宣言は不要。

本当なら、動的言語擁護派ならこのように言うはず。

だけど、なぜか動的言語擁護派も変数は宣言してから使いましょうという。不思議!w





まあ、結局、これと同じなんだよ。宣言してから使ったほうが間違いが減る。
それは変数に限るわけがなく、型とかインターフェースとか、
変数の宣言と同じ理由で、宣言してから使ったほうが間違いが減るんだよ。
31 :デフォルトの名無しさん2011/09/25(日) 17:26:48.75
>>29
その宣言ってただのスコープ指定だろ
32 :デフォルトの名無しさん2011/09/25(日) 17:53:01.07
>>29
Python,Rubyには無いし、言語に依るんじゃないか?
33 :デフォルトの名無しさん2011/09/25(日) 18:11:13.12
何故、変数の型宣言みたいなレベルの低い話になるのだろう。

せめてオープンクラスは柔軟な変更が可能になるけど
影響範囲がグローバルになるからClassbox的な機構が必要
みたいな議論にならんものか。
35 :デフォルトの名無しさん2011/09/25(日) 18:15:35.54
クラスにパッチ当てて修正/拡張するときに、それが効く範囲を限定できる。
一種の名前空間。
36 :デフォルトの名無しさん2011/09/25(日) 18:20:22.13
実行時メタプログラミングは動的言語スレの方のねたじゃないか?
ここは型安全ネタのすれだからな
39 :デフォルトの名無しさん2011/09/25(日) 19:06:13.35
別に100%のチェックをコンパイル時に求めてる訳じゃない。
100やらなきゃならないチェックのうち70%のチェックを自動化してくれるならそれで十分。
40 :デフォルトの名無しさん2011/09/25(日) 19:35:08.84
HaskellとHoareぐらいかじってから言えよ、ってJava厨の言動に思うことは多い。
41 :デフォルトの名無しさん2011/09/25(日) 19:40:14.04
Adaなんかは、全然使った事ないし知らんけど
比較的安全さと厳格さを重視して設計されてるんでしょ

http://en.wikipedia.org/wiki/Ada_(programming_language)
ここ見るといわゆるintみたいな型が無いのか、range 1..31とかmod 24とかいう形で
いちいち独自に型指定してて面白いよ、コンパイル時か実行時か知らんけど常に
境界チェックやってるんだろうな
43 :デフォルトの名無しさん2011/09/25(日) 20:07:01.69
>>41
コンパイル時に検査できると思うほど馬鹿なわけ?
実行時の検査なら動的型だってできるぜ?
46 :デフォルトの名無しさん2011/09/25(日) 20:29:07.06
>>43
そりゃ全部コンパイル時にチェックするのは無理だろうよ
ただ、関数fの引数型Numberがrange 1..12と定義されていれば、
とにかく実行時だろうがその範囲外の入力は弾かれるし、
f(13)みたいな呼び出しはコンパイル時にエラーにすることが可能なわけだべ?

それって動的型で自前でチェックするよりはなんぼか楽だし意図も明確じゃね?
関数fが取る引数がどのようなものであるか、動的型言語では意図を示す
方法がないよね?

別に静的型の型チェックでプログラミングエラーを全て無くせるなんて話は誰も
してないと思うけど
42 :デフォルトの名無しさん2011/09/25(日) 20:05:43.80
型検査だけで70%もカバーできるわけねえだろw
静的型厨ってどこまで楽観的なんだか…
44 :デフォルトの名無しさん2011/09/25(日) 20:15:23.00
>>42
いや、動的型言語で組んだら全バグの70%が実行時型エラーになったのかもしれんぞwww
そんな馬鹿なプログラマには会った事無いけどw
45 :デフォルトの名無しさん2011/09/25(日) 20:26:18.65
開発中のケアミスも含めれば、
静的検査で見つかるものは多い。
47 :デフォルトの名無しさん2011/09/25(日) 20:48:17.74
範囲付き数値型を作って使ったらどうなるんだろうな。
なんか不都合がでるんだろうか

Int<0,5> value = 5; //コンパイルエラー
Int<0,5> value = ConstInt<5>(); //代入可
Int<0,5> value = Int<2,4>( ConstInt<3>() ); //代入可
Int<0,5> value = Int<-1,4>( ConstInt<3>() ); //コンパイルエラー

int n = map["key"].readInt();
Int<0,5> value = n; //範囲外であれば実行時エラー

Int<0,3> a;
Int<0,4> b;
Int<0,5> value = a + b;//コンパイルエラー

Int<0,2> a;
Int<0,2> b;
Int<0,5> value = a + b;//代入可
49 :デフォルトの名無しさん2011/09/25(日) 21:03:05.30
0に関しては-n〜nを表現しなきゃならないから
0状態だけはコンパイルエラーとなるNZInt型でも作らなきゃならんだろ
51 :デフォルトの名無しさん2011/09/25(日) 21:47:58.86
範囲付き型検査で済むというなら、実行時エラーが一切出ないように頼む
52 :デフォルトの名無しさん2011/09/25(日) 21:54:33.81
IO以外は、範囲外エラーが無くなるだけましだろ。
IOだけ妥協すんのはモナドと似たようなもんだ。
53 :デフォルトの名無しさん2011/09/25(日) 22:23:54.56
このスレの静的厨は普段はどんな言語使ってるの?Agda?Coq?
Javaとか言うなよ?
54 :デフォルトの名無しさん2011/09/25(日) 22:25:37.60
>>53
静的言語でも動的言語でも何でも使うよ。
でないと動的言語よりも静的言語のほうが
すぐれてるってわからないだろ。

で、それ聞いてどうするつもり?
Javaと答えたら、ぷぎゃーとかいって逃げる予定だったの?w
55 :デフォルトの名無しさん2011/09/25(日) 22:25:45.00
>>53
俺はJavaかな
57 :デフォルトの名無しさん2011/09/25(日) 22:26:34.72
>>53
俺はJava
70 :デフォルトの名無しさん2011/09/25(日) 23:01:32.05
>>54
> 静的言語でも動的言語でも何でも使うよ。
> でないと動的言語よりも静的言語のほうが
> すぐれてるってわからないだろ。

どんな動的型言語を使ってるの?
75 :デフォルトの名無しさん2011/09/26(月) 04:56:47.08
>>54
動的言語ったって、どうせルビーとかピーエッチピーとかでしょ?
パール?えらいでちゅねーww
76 :uy2011/09/26(月) 16:49:33.51
>>54
「バカは効率がわからない」
80 :デフォルトの名無しさん2011/09/26(月) 20:38:01.38
大体動的言語は仕事無いだろ
>>75
が言うような動的言語は仕事有るが
でも動的厨からみたら話にならないんよね!!!!ね?>>75

uyくん、君に土方(笑)とかいう意見は求めてないからね!
キリッ!!!とかいうのも結構です
81 :デフォルトの名無しさん2011/09/26(月) 21:00:02.39
>>80
いやいや、そういうのもいいから、早く使った事のある動的型言語を書いてよ。
使った事なきゃ比較できないって>>54も言ってるしね。
使った事あるんでしょ?

ま、どうせ100%逃げるだろうけどw
100 :uy2011/09/27(火) 13:24:20.99
>>54
こいつみたいに、

どう見ても、是と思っていることを否とするバカっているんですよ

科学者や数学者や評論家みたいな奴が、意外性みたいなもんを狙った文章の・・・ だったら、1行目に「え?」っと思わせといても
最後まで読むと「なるほどなー」ってなる場合があるから、許せるんだけど
そうじゃない。本気で思ってる、山も谷もないオチのない文章

なんていうか・・・・・・アレなんだよ、100%論破できる、100%これは正しい、ってわかってるんだけど、
匿名だから、こんなゴミみたいな奴を論破して矯正してもあまり意味ないから、

いちいち相手すんの疲れるよね


あまりにもバカなこといわれると、あまりにバカすぎてふらつくわ
最近じゃ小学生でもこの板出入りしているんだろうしなぁ・・・ 2chはもう議論の場として終わり
101 :デフォルトの名無しさん2011/09/27(火) 17:37:58.18
>>100
jkかuyかしらんが
>いちいち相手すんの疲れるよね
だったら、一言でいいんじゃない?1分か2分それ以上かけてコメントする
ほどでもなかろう
114 :uy2011/09/28(水) 11:20:20.04
>>101
ゴミは
潰さないと、さ。

お前たちゴミも訂正しやすい書き込みだけ訂正するんじゃなくてちゃんと仕事しろよ
ゴミがゴミ管理すんのは当たり前だろ?

ゴミの勘違いを放置すんなゴミ  放置するから、そのまま冗長して、すっげーとんでもない場所で、バカみたいなことしゃべっちゃうゴミになっちゃうんだよ・・・・
61 :デフォルトの名無しさん2011/09/25(日) 22:33:19.10
Javaに範囲付き型検査ってあったっけ?
NullPointerExceptionならあるけど。
あと配列使うと簡単に型安全じゃなく出来るとかアホとしか思えんが。
62 :デフォルトの名無しさん2011/09/25(日) 22:34:45.38
C++を母言語としてても、仕事じゃJavascriptとか使わされる事が多い。
んで実行してから何処ともなく現れる構文エラーにうんざりする。
まぁ型の問題じゃなくインタプリタ全般の問題だけど。
63 :デフォルトの名無しさん2011/09/25(日) 22:35:40.73
> 配列使うと簡単に型安全じゃなく出来るとか
ほう、具体的どういうことなのか
君が知っていることのすべてを教えてくれ。
65 :デフォルトの名無しさん2011/09/25(日) 22:41:04.08
なんだ、馬鹿のくせに型安全って言葉を使ってみたかっただけかw
66 :デフォルトの名無しさん2011/09/25(日) 22:45:14.04
Object[] x = new Integer[1];
x[0] = new String();
x[0].charAt(0); //コンパイルエラー

ここでエラーが発生するから十分型安全なわけだけど
68 :デフォルトの名無しさん2011/09/25(日) 22:55:16.66
>>66
ぬるぽに比べたら些細な問題だな
67 :デフォルトの名無しさん2011/09/25(日) 22:46:32.20
まあ、「静的な」型安全性って言わないとダメだったね。
でも、これで実行時にArrayStoreExceptionが出ても型安全だと主張するなら、
動的型言語も完全に型安全だわwww
69 :デフォルトの名無しさん2011/09/25(日) 22:59:54.52
何度も言ってるけど、量の問題であって、
静的言語のほうが、見つけられることが多いのなら
抜けがあったとしても、優れているんだよ。
74 :デフォルトの名無しさん2011/09/26(月) 04:54:16.94
>>69
はっきり言って、誤差の範囲内。
むしろ、型エラーを取っただけでバグがなくなったと安心するバカがいる分、
静的型のほうが危険とも言える。
77 :デフォルトの名無しさん2011/09/26(月) 19:19:27.32
>>74
型まわりは、メモリ状態によっては正常に動いてしまったりして
というか正常に動いてしまうケースの方が多かったりで、
見つけるのに結構手間どる場合があるから、コーディング時に
多少キーボードを叩く回数が増えてても、リリース後の深夜に
電話で呼び出されたり、リリース直前に謎バグで徹夜したりする確率を
下げたい人は、静的型付け、その逆に、修羅場になると寧ろ燃えて
生き生きするタイプは、動的型付けを使うと良いんじゃないかな。
79 :デフォルトの名無しさん2011/09/26(月) 20:17:54.28
>>77
動的型言語は型安全だバカ
72 :デフォルトの名無しさん2011/09/25(日) 23:28:27.07
Javaはinterfaceで表現できるからって
constを導入しなかったのが失敗だったな。
const配列の場合のみ配列間のアップキャスト可能というなら
ArrayStoreExceptionは発生しなかった。
78 :デフォルトの名無しさん2011/09/26(月) 19:22:51.08
> メモリ状態によっては正常に動いてしまったりして

C/C++かよw
笑わせんなバカwww
82 :デフォルトの名無しさん2011/09/26(月) 21:08:57.01
Rubyistですすいませんでした
84 :デフォルトの名無しさん2011/09/26(月) 21:15:17.84
>>82
Rubyでは安全なソフトは作れないと思ってるってこと?
97 :デフォルトの名無しさん2011/09/27(火) 07:51:32.27
>>82-85
動的厨涙目
86 :デフォルトの名無しさん2011/09/26(月) 21:44:25.58
たとえばPerlだとさ、
obj->foo()とか書いても、その行を実行するまでは
foo()が定義されているかどうかチェックされないでしょ。
動的言語ってのは大抵同じだと思う。

ここでさ、これって変数の定義の話と同じだと思う人いないの?

Perlとか変数を定義しなくても使える言語あるけど、
警告オプションとか設定して、変数の定義を強制するでしょ?

それは、定義があれば、スペルミスしても分かるようにするため。
そのメリットに変数も関数も違いはないと思うんだけど。
87 :デフォルトの名無しさん2011/09/26(月) 23:12:19.95
>>86
OOPはメソッドがどこで定義されたかを隠す。
せっかく隠したのに定義はどこですかとチェックするわけがない。

C/C++だと定義と宣言があって、定義をチェックできなくても宣言をチェックできる。
90 :デフォルトの名無しさん2011/09/27(火) 00:04:35.92
>>88
>>87ではないけど
ダックタイピングや、遅延バインディングによるポリモーフィズムをOOつってるんなら
自動的にそうなるんじゃね
実体を(vtblなどを使って)実行時に検索するから遅延バインディングなのであって
どの実体が呼ばれるかは静的には分かるわけがないし、確定しているのなら
それはポリモーフィズムじゃない
ただし、静的型のOOPLの場合は、とにかく実体がちゃんとあることだけは保障される

ってことだよな
91 :デフォルトの名無しさん2011/09/27(火) 00:08:21.04
>>90
ぬるぽを除く
93 :デフォルトの名無しさん2011/09/27(火) 02:41:28.28
>>90
そのことを、
「OOPはメソッドがどこで定義されたかを隠す」と
表現している文献はあるのかと。

だいたい、いくつか候補を見つけることが出来る時点で
隠してはいないから。
94 :デフォルトの名無しさん2011/09/27(火) 06:20:18.45
>>90
Smalltalkだと簡単に解るけど?
君の言う動的OOって、perlのことなのか?
95 :デフォルトの名無しさん2011/09/27(火) 06:49:27.16
>>94
静的に分かってるわけじゃあるめぇ
96 :デフォルトの名無しさん2011/09/27(火) 06:59:44.77
>>93
遅延バインディングでロードするDLLを実行時に決定するなら
コンパイル時に全ての候補を見つける事はできない
99 :デフォルトの名無しさん2011/09/27(火) 09:28:07.06
>>93
いや、型の隠蔽、実装の隠蔽、あるいはインタフェースと実装の分離と表現されるけど
普通に
GOFだってそう

>>94
実行時に実際のオブジェクトなり型なりが分からないんなら、そもそも
メソッド呼べんでしょ……
実行時には当然確定するし、分かる
静的には確定していないからポリモーフィズムなのであって
102 :デフォルトの名無しさん2011/09/27(火) 20:47:10.96
>>96
そういうことじゃないよ。

定義を隠すというのは、どんなものが定義されているか
実行時にならないとわからないってことだよ。

遅延バインディングとか、ポリモーフィズムとか、
それは実装がわからないだけで、定義されていることは分かるだろ。
104 :デフォルトの名無しさん2011/09/27(火) 22:03:10.44
>>102
何を言ってるのかぐちゃぐちゃすぎて俺にはさっぱりだぜ
まあ言いたいことはなんとなく分かるけど

void parse(ILexer lexer) {...}
のような関数があるとして、この関数を書いたりコンパイルする際には
実際に渡ってくるオブジェクト(インタフェースILexerを実装した実体)が
何であるか知る必要がないし、存在する必要すら無いってことだろ

そういう意味では確かに実体の定義は隠蔽はされているんだが、
「定義を隠す」っていう言葉遣いはあんまり聞いたことが無いな
普通は「実装を隠す」という言い方をすることが多い
abstraction(抽象化)はプログラミングの鍵なので、本質的には
OOPに限った話ではない
106 :デフォルトの名無しさん2011/09/27(火) 23:07:40.27
おいおい、定義を隠すと言い出したのは俺じゃなくて >>87だぜ。

>>87
> OOPはメソッドがどこで定義されたかを隠す。
88 :デフォルトの名無しさん2011/09/26(月) 23:43:04.37

> OOPはメソッドがどこで定義されたかを隠す。

それは一体どの文献に、そういうものだって書いてあるんだい?

それとも、今考えたのかい?
89 :デフォルトの名無しさん2011/09/26(月) 23:56:28.64
Perlは基本的に変数を定義して書くものだよ。そうでないように設定も出来るけど、商用レベルでそうする事はほぼ100%ない。
配列、連想配列、その他の3つしかないけど、一応型も定義出来る。
RubyやPythonよりはマシ。
Perl6になると、完全に静的型付けで書けるし。
92 :デフォルトの名無しさん2011/09/27(火) 01:04:51.40
いやこれを遅延バインディングっつーのはなんか言葉がおかしかったな
まあいいかー
105 :デフォルトの名無しさん2011/09/27(火) 22:17:26.50
全然流れを読んでないが例えば下のコードだと、
実装は不定と言う方が自然じゃなかろうか。

windows.Control( phisical_machine );
windows.Control( virtual_machine );

unix.Control( phisical_machine );
unix.Control( virtual_machine );
107 :デフォルトの名無しさん2011/09/27(火) 23:12:33.88
変数は宣言しないで使うことは悪いというのに、
なんでメソッドは宣言しないで使おうとするの?

その違いがわからない。
109 :デフォルトの名無しさん2011/09/27(火) 23:31:41.30
>>107
静的型でのインタフェース、継承ベースのポリモーフィズムの場合は
実体がわからなくとも特定のインタフェースを備えていることは
保障されるので困らない、という考え

def add(x, y) = x + y
みたいなものを考えるとき、動的型でもx, yは暗黙に加算ができる
オブジェクトとプログラマは仮定しているが、それを保障する方法は無い
実際に+が定義されないオブジェクトをaddに渡すと、その時点で実行時エラー
この場合は単純だが、もっと複雑な内容の関数の場合は
もっとワケのわからないところで実行時エラーが起きたり、あるいは
エラーにすらならず黙って誤った結果が生じる可能がある
それが嫌なら引数チェックを自分の手で書かないといけない

継承ベースのポリモーフィズム静的型だと
IAddable add(IAddable x, IAddable y) = x + y
みたいな発想をする
xやyは整数かも知らんし浮動小数点数かもしれないがそれは問わない
とにかくIAddableというインタフェースを実装したオブジェクトであって、
加算が定義されていることは保障される
ただし、加算の「意味」が関数add()が期待しているものと同じであるかを
保障する手段はない
110 :デフォルトの名無しさん2011/09/27(火) 23:46:12.54
>>109
そのadd()は俺なら number(x) + number(y) みたいに書くかな(number()は引数を数値に変換する関数ね)
112 :デフォルトの名無しさん2011/09/28(水) 08:48:49.13
>>107
定義すれば宣言はしなくて良いよ
メソッドは「どこか遠くで定義されているからここでは定義しない」ってケースが多い
変数は「地産地消」
115 :デフォルトの名無しさん2011/09/28(水) 17:16:16.27
>>109
>動的型でもx, yは暗黙に加算ができる
>オブジェクトとプログラマは仮定しているが
プログラマによるだろう。
JavaScriptの例だと、typeofする関数群使って、
各オブジェクトのプロパティをeveryで回したり、
数値計算では文字列は parseInt とかに通したり、
evalしたいならsandboxつくる。

これぐらいの発想は当たり前だよ。
想像で語ってる人が思いの外多いような気がする。
108 :デフォルトの名無しさん2011/09/27(火) 23:18:00.87
変数はスコープの問題だろ。
定数や関数は、無限ループや、意図しない分岐ミスを誘発しないが
変数はそれを起こす。
113 :デフォルトの名無しさん2011/09/28(水) 09:14:22.80
だねー

メソッドはインタフェースだけど、変数はローカルなもの
116 :uy2011/09/28(水) 17:51:07.56
>想像で語ってる人が思いの外多いような気がする。

それ、いまさらって感じ

このスレかなり素人混ざりこんでるよ
このム板の平均レベルそのものも低いが、その中でもさらに下の下の下種がきてる
正確には下の中くらいだけど
117 :デフォルトの名無しさん2011/09/28(水) 19:20:02.14
静的なら機械がチェックするところを、
動的だとプログラマ側のそういった工夫が必要なのか。
118 :デフォルトの名無しさん2011/09/28(水) 19:46:11.13
機械がやるから手間も要らないし、抜けも無いわけだ
121 :デフォルトの名無しさん2011/09/28(水) 21:41:51.50
>>116
お前何様だ?
LLで組んでるならそれぐらいの動作を考える、と言っただけで、
プログラマとして下だ上だなんて主張はしていない。

>>118
それを言ったら極論として型安全性の高い言語が優秀になってしまうのでは…。
でも人間の言うバグがなくなるわけじゃない。
124 :uy2011/09/29(木) 02:24:05.41
>>121
話しかけんなよ気持ち悪い
125 :デフォルトの名無しさん2011/09/29(木) 02:48:31.93
>>121
型安全性の高い言語の弱点「記述が冗長」をIDEで補う、これ最強。
人間はただでさえ間違いを犯しやすいんだから、機械でチェックできるところは
機械にやらせるのがよし。
127 :デフォルトの名無しさん2011/09/29(木) 04:41:39.66
>>125
逆だよ
型検査は人間に型宣言をさせずに、型推論ベースでやればいい
130 :デフォルトの名無しさん2011/09/29(木) 09:12:48.70
>>125
最近の流れだと、型安全性というと型推論を言うんじゃないかと。
C++ですら型推論の時代だし、記述量はむしろ少なくなる。
136 :デフォルトの名無しさん2011/09/29(木) 13:11:03.08
>>130
簡潔に記述出来るようになる一方で、盛り込みたい概念が順番待ちしてるから、ある程度の複雑さで妥協すると思う。
119 :デフォルトの名無しさん2011/09/28(水) 20:23:41.91
そりゃ動的型言語は静的型検査の代りに
実行時に型システムを拡張できる自由を得たわけで、
静的型言語と同じように書いてたらデメリットしか無いだろ

昔、OOPがまだ受け入れられてなかった頃、
C上がりのプログラマがCと同じようなコードを書いて、
OOPは遅いだけでメリットが無いと言ってたが
言語/パラダイムが変わっただけで全く同じ構図だな
122 :デフォルトの名無しさん2011/09/28(水) 22:16:36.20
ちゃんと動くのにコンパイラが型エラーで弾いたりするけどな。
くやしかったらYコンビネータに型をつけてみろw
128 :デフォルトの名無しさん2011/09/29(木) 05:53:33.15
Rubyは今からでも静的言語に変更した方がいい。
このままではクリティカルなビジネスに使えないので
普及しない。
131 :デフォルトの名無しさん2011/09/29(木) 09:24:23.82
言語を変更したら人間が対応に追われるし
もし機械的に翻訳できる事を保証したらむしろ安心して古い言語を使い続ける。

言語の論争は、機械は翻訳ができないっていう無力感を前提としているから
機械の力に特別な期待を持つのは不自然だと思う。
134 :デフォルトの名無しさん2011/09/29(木) 12:18:10.00
>>131
実現する処理とその表現を混同してるねえ。
実現するだけなら機械語でも万能。
問題は表現だ。
135 :デフォルトの名無しさん2011/09/29(木) 12:42:17.77
>>131
> 機械の力に特別な期待を持つのは不自然だと思う。
単に「機械でも出来る程度のことは機械にやらせろ」ということであって
「特別な期待」うんぬんじゃないよ
人間様が一々機械語なんて記述してられないから、プログラミング言語という
形式言語を発明して、機械語への翻訳は機械にやらせることにしたわけです
137 :デフォルトの名無しさん2011/09/29(木) 13:34:32.84
>>135
どの程度なら機械でも出来るか
もし自分が機械だったらここまでは出来るって想像できる人が機械を作る
自分は機械とは違うって感覚だと、自分に出来ないことを機械に期待してしまう
133 :デフォルトの名無しさん2011/09/29(木) 10:05:09.62
混同したら一敗
区別すれば一勝一敗かもしれないけど二敗かもしれない
139 :デフォルトの名無しさん2011/09/29(木) 17:14:41.98
ここで不思議なことって?lisperとhaskellerはさほど不仲ではないよ。
このスレの中では不仲みたい。
2つの言語の共通するところってプログラムを組む前の戦略を立てるときに
大変頭を使う事かな。lispは思考直結型ではあるけどhaskellは型直結から
思考をする感じ。(最初のデータ型を決めるのが大変重要だしな。そこさえ
綺麗に決まってくれば後はそんなに時間はかからんでしょ?)型推論が
あるために柔軟な言語に仕上がってると思うよ。

他の共通点は少人数で開発をしていく向けの言語かな。lispの場合型チェック
は任意だけど、ここは絶対型チェックをしたいというところならassertを組み
込むよね。これはcommon lispでもclojureでも共通してるかな。

JavaとかってIDEに代わりをやらせればいいというような意見が出る
くらいだし頭を使う必要はないわな。そうゆう意味では対極だし、
javaを使ってる人の愚痴が多いのもわからないでもないな。java依存症で
javaに愚痴が多い人はbetter javaとしてscalaを使ってるのかな?

rubyも柔軟な言語だから、考えてることを実現しやすいだけの
言語のパワーってのを持ってると思うよ。必要以上に複雑で扱いにくい
言語ってのはその制約に引っ張られて思考をそのまま実現しようとすると
問題を抱えやすいな。無駄に書かなけれいけない処理が増えればふえるほど
柔軟性は失われるから、言語の制約に縛られたくない人にとって見れば
不向きなのが多いな。

ここの人って、二分論で語るような人が多いし、会話が成り立たない場所
だけど、現実は使い分けでいいんだと思うよ。どんなことをするかってこと
でずいぶん違うだろうからな。前提を抜きにしてあれがだめだこれがだめだ
って論争って間抜けなんだと思う。
140 :デフォルトの名無しさん2011/09/29(木) 17:47:19.81
>>139
みんなわかってて暇潰ししてるだけなんですが…

極論同士のぶつかり合いじゃないと盛り上がらないだろ
別に満場一致の結論なんて求めてねえんだよハゲ
141 :デフォルトの名無しさん2011/09/29(木) 17:54:07.17
>>140
極論でしか盛り上がらないという発想そのものが底辺だと言われる所以
だと思う。気の毒ですが。
142 :デフォルトの名無しさん2011/09/29(木) 18:59:20.19
>>141
せっかくの長文が相手されなかったからって泣くことないだろw
143 :デフォルトの名無しさん2011/09/29(木) 19:17:51.80
>>142
やっぱりなんか感覚がずれてるね。おまいらの暇つぶしに付き合う気がないんでこれ以上はコメントしない。
146 :デフォルトの名無しさん2011/09/29(木) 20:00:50.40
>>139
> 2つの言語の共通するところってプログラムを組む前の戦略を立てるときに
> 大変頭を使う事かな。

それは言語の問題じゃない。プログラマの問題だ。
LispだろうがHaskellだろうがドカタ産業の標準になったら、クソの山になる。
159 :デフォルトの名無しさん2011/09/29(木) 23:45:24.04
>>139
このスレは、なんちゃってxxxerの隔離スレ。
161 :デフォルトの名無しさん2011/09/30(金) 01:29:49.90
>>139
うーん。。。
当たってるような、当たってないような。。。
自分の感覚だと、javaやrubyはリファレンス本(またはリファレンスサイト)をちょくちょく参照しないと書けない感じで、haskellは割とリファレンス参照しなくても、自分で何時の間にか組込関数と同じモノ自作してました。みたいな、リファレンスの使用頻度が低い感じを受ける

まだ勉強中だけど、練習問題解いたりする際のリファレンスのお世話になる頻度が違う気がする

印象としては記憶力勝負のjava
発想力勝負のhaskell?
163 :デフォルトの名無しさん2011/09/30(金) 02:31:13.30
>>161
単に、単純な代物しか作っていないからでは> haskell
164 :デフォルトの名無しさん2011/09/30(金) 04:55:33.55
>>163
おれもそう思う
覚えたての言語に対しては大抵「この言語は発想力がモノを言うなあ」と思うものだ
166 :デフォルトの名無しさん2011/09/30(金) 09:29:00.28
>>163-164
そうかもだけど、その単純なプログラムでも、オブジェクト指向はまず「こう言う事したいけど、そう言うクラスやメソッドは無いか?」って探す所から始まる事が多い気がする


168 :デフォルトの名無しさん2011/09/30(金) 11:16:05.06
>>166
関数型は部品の再利用には向いてないってこと?
169 :デフォルトの名無しさん2011/09/30(金) 11:29:01.57
>>167
簡単なのだと探すより作っちゃった方が速いけど。。。

>>168
そうじゃなくて、まだ覚えたりなんとなくでも知ってる関数が少なくても自分で作れちゃうから困る事が少ない

あと、ぶっちゃけオブジェクト指向のデザパタとか全然で、オブジェクト指向言語使ってた時はあんまり再利用出来なかったけど、関数型言語では、そんな自分でも結構コードの再利用出来てる

底辺でも再利用出来るのが関数型言語の良い所?
174 :デフォルトの名無しさん2011/09/30(金) 15:07:31.56
>>166
OOPL脳の俺には、非OOPLのほうがむしろ数が多過ぎて覚えるのも探すのも大変なんだが…
175 :デフォルトの名無しさん2011/09/30(金) 16:11:28.26
>>174
何の数が多すぎるんだろう。。。
関数?
180 :デフォルトの名無しさん2011/09/30(金) 20:05:30.51
>>175
一覧に並ぶ項目の数…かな
だいたいの目星を付けるのが出来ないから「うわっ」ってなる
181 :デフォルトの名無しさん2011/09/30(金) 20:17:15.29
>>180
何で?モジュールくらいあるだろ
182 :デフォルトの名無しさん2011/09/30(金) 23:38:54.61
>>181
クラス別のドキュメント場合、来る値の型や欲しい型、使いたい型は既に解ってるのだから
その型について調べればいいのよ

もちろん欲しい型や使いたい型が判らないときは大変だけど
それの労力は別にモジュール分けでも何ら変わりないし
183 :デフォルトの名無しさん2011/09/30(金) 23:46:47.13
>>182
モジュール別のドキュメントでも同じ話では?
184 :デフォルトの名無しさん2011/10/01(土) 00:12:19.97
>>183
どれと同じなのかkwsk、俺的には型が不明なまま探すのとは決定的に違うが…
185 :デフォルトの名無しさん2011/10/01(土) 00:21:40.35
>>184
いや、だって関数型言語でもListやHash、Monad等の単位でモジュールが分かれてるだろ?
何にも整理されずに関数群がモジュールに突っ込まれてると思ってるの?
186 :デフォルトの名無しさん2011/10/01(土) 00:23:22.14
>>182
型の仕様はわかっても、型の実装は実行時に値がくるまでわからない罠
187 :デフォルトの名無しさん2011/10/01(土) 00:39:38.38
>>185
Preludeは分かれてないよね

>>186
まあ、その辺まで来ると流石に好みの問題かも知れないな
俺も昔OOPLに初めて触れた頃はドキュメント読めなかった
…が、慣れた今では却って読みやすくなっちゃった
189 :デフォルトの名無しさん2011/10/01(土) 00:50:45.27
>>187
ルート、PreludeList、PreludeText、PreludeIOに分かれてる
190 :デフォルトの名無しさん2011/10/01(土) 02:16:03.80
>>187
ん・・・
Preludeの関数なんて、putStrとかの副作用関係の関数以外(getCharはData.Charモジュールへ移動した)どんなに下手な作り方でも4行で作れるじゃん。
作れなかったときだけ探せばいいだろ。
そもそも何を受け取って、何がほしいのか。から考え直せ。

関数型言語は元々、手続き型言語と違って数学を基にしてるから、1から作るのも再利用するのも向いてるんだよ。
(数学で再利用できないのはかなりキツイと言う文化的背景的にも)

関数型言語はまさしく算数や数学と同じだ。
初心者は算数・中学数学並みの少ない知識でも結果的には同じ意味のコードが掛けるし、知識が付けば、効率的で無駄のないコードが書ける。
198 :デフォルトの名無しさん2011/10/01(土) 07:43:51.44
>>190
> 関数型言語は元々、手続き型言語と違って数学を基にしてるから、1から作るのも再利用するのも向いてるんだよ。

関数型初心者にありがちな迷信だねw

> 関数型言語はまさしく算数や数学と同じだ。

算数や数学よりもずっと窮屈だよ
算数や数学では書き換え規則が双方向なのに対して
関数型言語では書き換えは一方通行だから
200 :デフォルトの名無しさん2011/10/01(土) 08:25:48.45
>>198
数学の計算って何を指して言ってんの?
LKは一方向に進むけど?
202 :デフォルトの名無しさん2011/10/01(土) 09:15:05.45
>>198
ガウディ本ぐらいは読もうぜ。
205 :デフォルトの名無しさん2011/10/01(土) 09:52:34.29
>>204
で、>>198はどんな数学の計算規則について言ってんの?低能さん?
147 :デフォルトの名無しさん2011/09/29(木) 20:54:33.58
つーか、土方かどうかって
言語じゃなくて作るシステムで決まるもんだろ。

土方呼ばわりしている奴って、Rubyを使って
同じようなマスタメンテ画面が何十個もあるシステムを
作っています自信を持って言える?

言語で土方かどうかが決まると思っている奴なら
Rubyだから土方ではない!と言うはずだ。
148 :デフォルトの名無しさん2011/09/29(木) 21:12:50.26
>>147
言いたいことはわかるけど、もう少し日本語の練習をしてからまたおいで
149 :デフォルトの名無しさん2011/09/29(木) 21:15:14.26
>>148
言いたいことがわかっていて、
そのことに反論してないのなら、
それで十分だ。目的は達成した。
150 :デフォルトの名無しさん2011/09/29(木) 21:25:25.14
>>149
書き込みの内容自体はどーでもいいー
154 :uy2011/09/29(木) 22:58:17.55
>>147
JAVAは土方だよ 高確率で。

あの言語みてそう思わないならセンスが狂ってる
C++は土方ではない。 扱うのが難しいし、出来る奴が少ない。 C++PG。 それは「技術屋」という
151 :デフォルトの名無しさん2011/09/29(木) 21:29:24.25
じゃあ、それはただの揚げ足取りってことだなw
156 :デフォルトの名無しさん2011/09/29(木) 23:02:32.26
>>151
短絡的だなあ…。

端的に言うとその言語が用いられる対象システムから、
開発手法を想定し、土方と呼んでいるに過ぎない。

必ずしも当てはまらないのは自明の事だし、
いちいち主張することでもない。
152 :デフォルトの名無しさん2011/09/29(木) 21:52:04.37
当然、土方仕事かどうかは作るシステムで決まる。

だが、土方仕事しか経験の無いプログラマは
冗長なコピペコードをIDEで生成するのが最上の手法だと認識してる。
そういうプログラマが "IT土方" と呼ばれているだけの話。
153 :デフォルトの名無しさん2011/09/29(木) 22:52:46.39
スクリプト言語で仕事って言うと、ほぼウェブ系だよな。つまり、スクリプト言語はドカタ用言語と言って過言ではない。
155 :uy2011/09/29(木) 23:02:14.65
言語仕様はさておいて。
C++が出来ること。 C++で作られたプログラムのメンテが出来る事。
まさに技術を売っている感じ。

はっきりいって人の平均的スペックではC++扱えないから、JAVAやC#が生まれたってだけで、
使える奴で集まればC++でいいんだよ?

ゴミしかいねーからJAVAになる。。。 人の頭脳は、年々、子々孫々進化していて、
次の世代次の世代で、どんどん今の世代よりは頭が良い。 いずれC++復権すると思うよ
JAVA?C#? いらねーんだよw
人の進化の速度にも、よるけどな
157 :uy2011/09/29(木) 23:05:04.74
とりあえず、さっさと言語統一はかったほうが、いいんだけど

世界はまとまんねーのなぁ

この世に1つしか言語がなければ、多分、効率は100倍を超えると思うよ
剣道やったことあるか? 片手で振るのと、両手で振るのとでは、威力の差が
 2 倍 で は な い   1+1って計算にはなっていないから、それ以上になる。
 
165 :デフォルトの名無しさん2011/09/30(金) 07:28:28.70
>>157
てめえ剣道やったことあんのか?
両手で二倍にならねえよ、それ以下だ
167 :デフォルトの名無しさん2011/09/30(金) 10:16:41.67
関数型でも手続き型でも、そういう関数や手続きはないか、って探すけど
170 :デフォルトの名無しさん2011/09/30(金) 11:29:05.62
むしろ純粋関数型以外に、例えば「このサブルーチンを呼んでも、例外とかでない限り
標準出力に何か書き出したりしない」を保証できるような、安心して再利用できるような
言語ってないと思うんだが。
171 :デフォルトの名無しさん2011/09/30(金) 11:43:35.19
ま、その保証のおかげでprintfデバッグがやり難いんですがね
(実は方法はあるけど)
172 :デフォルトの名無しさん2011/09/30(金) 12:35:15.46
実は保証できてない面があるってことでしょ
一面的な見方では安全にならないので
なにを保証するかだけでなく、なにを保証しないかを言わないと
173 :デフォルトの名無しさん2011/09/30(金) 12:38:18.64
馬鹿なこの町並みは基底クラスの変数の状態に依存するはずだろ。
日曜大工だと探すより作っちゃった方が速い場合が多いけど。。。
176 :デフォルトの名無しさん2011/09/30(金) 17:51:16.53
腹の脂肪…
177 :デフォルトの名無しさん2011/09/30(金) 17:52:54.38
>>176
必死だなwwww
188 :デフォルトの名無しさん2011/10/01(土) 00:43:42.59
OCamlだと調べものはOcamlBrowserで済む事が多いな。
関数の型から関数名を検索することもできるし。
191 :デフォルトの名無しさん2011/10/01(土) 03:21:55.53
ただ読みやすいコードか? とか速いコードか?と
聞かれると必ずしも関数型言語風の書き方が
最善というわけじゃないんだよな。
193 :デフォルトの名無しさん2011/10/01(土) 04:09:05.68
>>191
速いコードを書こうとするときは泥臭くなりがちだね。lispのwith-typeマクロ
みたいなのがあると、その泥臭いところは隠すことはできるけど、初心者では
手におえんわな。
TCO(末尾再帰)があるかないかで関数型言語風の書き方が強力になるのか毒に
なるのかが決まってくるかな。
197 :デフォルトの名無しさん2011/10/01(土) 04:16:13.18
>>193
ループ
→再帰
→畳み込み
という風に、抽象化が進むんじゃ?
192 :デフォルトの名無しさん2011/10/01(土) 04:01:32.97
元々解くべき問題の複雑さ度合いとか問題領域に応じて、複数のプログラミング言語が在る訳だ。
乱数を10^10(10の10乗)回足しこむような単純な処理なら、現在でもCが最速だろう。
ただし、こんな単純な処理でも10000^10000回とかなった途端に、ライブラリを探すか、自分で車輪を再発明する事になる。
更に問題なのは、ほとんどのアプリケーション・プログラマーが使う範囲では、複数の言語間のスピード比較は、単純な処理でしか出来ない事。
鳥とライオンとで、地上走行のスピード比較をするようなもんだ。
飛ぶことによって得られる自由度は、最初から比較対象にならない。
194 :デフォルトの名無しさん2011/10/01(土) 04:11:20.50
どの言語でも基本的なライブラリを覚えるのは基本だと思うけどな。
この辺は語学と同じさ。英語も2000語の壁、5000語の壁があるのと同じ。
195 :デフォルトの名無しさん2011/10/01(土) 04:12:48.64
>>194
直行概念でまとめられる分が大きい方が楽だとは思う。
196 :デフォルトの名無しさん2011/10/01(土) 04:13:32.69
>>195
X 直行
O 直交
199 :デフォルトの名無しさん2011/10/01(土) 07:53:50.64
頭のとろそうな書き込みが見つかるばかりで、
五次以上の方程式については(俺は)全く分かっていなかった。
201 :デフォルトの名無しさん2011/10/01(土) 08:33:51.71
5 を 1 + 4 と 2 + 3 と 3 + 2 と....の全てに書き換えた、その全てが並列に存在する宇宙を
知覚できる人なんだろう、多分。
203 :デフォルトの名無しさん2011/10/01(土) 09:42:14.27
何時も思うけど、なんで知りもしないことのアンチになれるんだろうね?
少しやり取りするだけで無知なのがハッキリ分かるし。
204 :デフォルトの名無しさん2011/10/01(土) 09:51:37.82
自分の言葉で説明できないから
○○読めとかいって逃げるだけだしw
ほんと無知だな。
206 :デフォルトの名無しさん2011/10/01(土) 09:59:17.00
関数型言語は関数が一杯あってお目当ての関数が探せませーん
みたいなアホが無知でなくて何なの?w
219 :デフォルトの名無しさん2011/10/01(土) 17:46:06.64
>>206
それは俺だ、無知だなの人と一緒にしないでくれ…
自分は自分が無知なのは充分承知してるよ。
221 :uy2011/10/01(土) 18:39:59.51
>>219
はぁ?????
>自分は自分が無知なのは充分承知してるよ。


だったらスレに参加すんな
   
 ふ ざ け ん な  死ね 


  知   識  が  な  い  な  ら  書   き  込  む  な


 ゴミって自覚してんなら死ね

207 :デフォルトの名無しさん2011/10/01(土) 10:01:33.44
Haskellの演算子は確かにググれないなw

メジャーなライブラリならHoogleがあるが、どっかの誰かのライブラリだと皆目わからんことがある
208 :デフォルトの名無しさん2011/10/01(土) 10:11:08.80
プログラムってのは、読みやすい解説書のように
書くべきだと思う。

関数ってのは、数学的な関数に解説書が存在するように
読みやすいものではないと思うんだ。
209 :デフォルトの名無しさん2011/10/01(土) 10:14:25.81
誤読の可能性がいっぱいある文章のように書いて、
いっぱい誤動作させるのがプログラムの目的ならそれは正しいね。
210 :デフォルトの名無しさん2011/10/01(土) 11:24:30.71
自然言語と違って書いた通りの動きしかしないので
お前の言う誤読は関係ない話だろ。

読み手の力不足で誤読するというのなら
それは関数でも同じように誤読する。
211 :デフォルトの名無しさん2011/10/01(土) 11:24:35.76
動的言語のなりたちは
シェルとかで簡単にコンピュータに
コマンド打ち込むため。
そこにちょっと欲がでて
制御構造や変数使えるようにした。
話は本来そこまでのはずだった。
214 :デフォルトの名無しさん2011/10/01(土) 12:20:56.98
>>211
動的言語はGCを作りやすかった
GCがないC++より、Lispの方がましだった
Javaは当初はgenericsがなくて静的言語としては微妙だった
あと、共用体に否定的なC++と部分型に否定的な関数型言語の間でブレがある
212 :デフォルトの名無しさん2011/10/01(土) 11:53:47.81
つーか、関数型が読み難いって何を根拠に言ってんだ?
適当にコード貼ってみてくれよ
261 :デフォルトの名無しさん2011/10/02(日) 02:24:24.43
それ、OOPで書いても大して長くならんぜ。
ていうか、>>212は読み易さを比べようって言ってるんであって
長さ比べをしてるわけじゃねぇ。
263 :デフォルトの名無しさん2011/10/02(日) 02:57:58.64
>>261-262
話はコードを貼ってから。
265 :デフォルトの名無しさん2011/10/02(日) 03:31:57.84
>>263
めんどくせーやつだな。
ここだけあれば十分だよな?

Collections.sort(list, new Comparator<int>() { public int compare(int v1, int v2) { return v1 - v2; }});
266 :デフォルトの名無しさん2011/10/02(日) 03:41:45.58
>>265
全然十分じゃねーよ。
バカじゃないの?
267 :デフォルトの名無しさん2011/10/02(日) 03:45:46.30
>>266
あとは自分で補間できるだろ?
一行を一行で書きなおすだけ。
268 :デフォルトの名無しさん2011/10/02(日) 03:49:22.75
>>267
それのどこがStrategyパターンなんだよ。バカすぎる。
213 :デフォルトの名無しさん2011/10/01(土) 11:55:53.53
例を出すのならコードは現実的な長さ、
30行ぐらいのやつでお願いね。
218 :デフォルトの名無しさん2011/10/01(土) 17:38:56.84
>>212,>>213
ここのコードがコメント空行抜きで40行くらいだし丁度良い
これと等価なコードを関数型言語で書いてみて比べたらいいさ

http://en.wikipedia.org/wiki/Strategy_pattern#Example
223 :デフォルトの名無しさん2011/10/01(土) 19:46:43.20
>>218
え?Javaってこの程度のコードに何十行も必要なの?www
225 :デフォルトの名無しさん2011/10/01(土) 21:42:58.30
>>223-224
話はコードを貼ってから。
226 :デフォルトの名無しさん2011/10/01(土) 23:14:00.05
変数名、関数名は>>218のリンク先コードと合わせてある


let execute_strategy f a b = f a b

let context = execute_strategy (fun x y -> print_endline "called +"; x + y)
let result_a = context 3 4
let context = execute_strategy (fun x y -> print_endline "called -"; x - y)
let result_b = context 3 4
let context = execute_strategy (fun x y -> print_endline "called *"; x * y)
let result_c = context 3 4
227 :デフォルトの名無しさん2011/10/01(土) 23:36:57.62
>>226
それは違う。

Strategyってのは、予め用意しておいて
状況に応じてそれらを切り替えて使うもんだから、
まず名前を付けて、別の場所で定義したものでないといけない。
228 :デフォルトの名無しさん2011/10/01(土) 23:38:08.06
>>226は移植に加えて、無名関数に置き換えてるようなもんだから
違うものになってるよな。
229 :デフォルトの名無しさん2011/10/01(土) 23:45:49.46
>>227
なるほど一理ある。修正した


let execute_strategy f a b = f a b

let strategy_add x y = print_endline "called +"; x + y
let strategy_subtract x y =  print_endline "called -"; x - y
let strategy_multiply x y = print_endline "called *"; x * y

let context = execute_strategy strategy_add
let result_a = context 3 4
let context = execute_strategy strategy_subtract
let result_b = context 3 4
let context = execute_strategy strategy_multiply
let result_c = context 3 4
230 :デフォルトの名無しさん2011/10/02(日) 00:17:45.98
>>229もStrategyのコードの意図とは微妙に違うんだがなw
まあ頑張ったから逆に>>229にコードにあわせてJava側を修正したよ。

interface Strategy { int execute(int a, int b); }
class StrategyAdd implements Strategy { public int execute(int a, int b) { System.out.println("called+"); return a + b;} }
class StrategySubtract implements Strategy { public int execute(int a, int b) { System.out.println("called -); return a - b; } }
class StrategyMultiply implements Strategy { public int execute(int a, int b) { System.out.println("called *"); return a * b; } }

class StrategyExample {
 public static void main(String[] args) {
  Strategy context;
  context = new StrategyAdd();
  int resultA = context.execute(3,4);
  context = new StrategySubtract();
  int resultB = context.execute(3,4);
  context = new StrategyMultiply();
  int resultC = context.execute(3,4);
 }
}
231 :デフォルトの名無しさん2011/10/02(日) 00:21:38.55
>>230
>>218はexecuteStrategyメソッド内でexecuteを呼ぶのが本質じゃないのか?
それじゃダメだろ。
232 :デフォルトの名無しさん2011/10/02(日) 00:23:27.64
>>230
あんまし行数変わらんな。

改行の位置をどうするかとか
class宣言のために決まった行数上げ底される程度か。

実際はクラスとか関数の宣言よりも
実装コードのほうがずっと長くなるんで、
相対的な差はなくなるよね。
その差もコード補完で埋まったりするし。
233 :デフォルトの名無しさん2011/10/02(日) 00:25:32.96
context内部にstrategyを保持して、executeStrategyが実行されるときに
strategyを呼び出すのがStrategyパターン。
>>230は違うものになってる。
234 :デフォルトの名無しさん2011/10/02(日) 00:30:51.26
>>231
その部分だよ。>>229が本来のStrategyのコードの意図と違うっていうのは。

executeStrategyの中でexecuteを呼ぶのが本質なのではなく、
本当はContextというオブジェクトでないといけない。

例題が悪くて、Contextというオブジェクトは状態を持ってなくて
単にexecuteを呼ぶだけのものになってしまっている。

正しくは>>229にContextオブジェクトを追加しないとJavaコードと等価とは言えない。
このContextオブジェクトはexecuteStrategyだけではなく、
他のメソッドと共に状態を表すいろんなフィールドを持っているものとして考える。
236 :デフォルトの名無しさん2011/10/02(日) 00:36:00.54
>>229はカリー化を使ってstrategyの保持を実現してて、execute_strategy経由で呼んでるぞ。
237 :デフォルトの名無しさん2011/10/02(日) 00:42:25.33
>>236
それはメソッド1つだけだろ。

今回の例はたまたまメソッド1つだけだからいいけど、
本来のStrategyはcontext.executeとかcontext.execute2とか
contextが持っているその他のメソッドも呼び出せるものなんだ

> let result_a = context 3 4
これだと、 予め与えられた一つのメソッド、strategy_?しか
呼び出せないcontextになっているだろう。

だからJavaコードと等価にはなってないんだよ。
238 :デフォルトの名無しさん2011/10/02(日) 00:43:41.43
>>234
関数型言語ではクロージャが状態を保持できる
オブジェクトである必要は無い
239 :デフォルトの名無しさん2011/10/02(日) 00:45:05.74
>>238
そこは問題じゃない。
contextの使い方が変わってるから
等価になってないという話。
240 :デフォルトの名無しさん2011/10/02(日) 00:45:39.86
>>237
いや、それは分かる。この例じゃオブジェクト指向の強みが活かせないのは。
でも>>229と>>230なら>>229の方がずっとオリジナルに近い。
241 :デフォルトの名無しさん2011/10/02(日) 00:47:13.18
>>240
近くても違っている以上別物。
等価なコードになっていないというだけ。
243 :デフォルトの名無しさん2011/10/02(日) 00:55:44.24
>>240
> いや、それは分かる。

それが分かっているのなら障害は何も無い。
等価になっていないと分かっているのなら、
あとはちゃんと等価になっているコードを書けばいいだけだと思う。
262 :デフォルトの名無しさん2011/10/02(日) 02:34:51.90
>>260
>>213が例を出すなら現実的な長さ(30行以上)って言ってるぞ。
それとも、オブジェクト指向言語なら30行超えるとでも思ってんのか?
216 :デフォルトの名無しさん2011/10/01(土) 15:26:01.60
チャーチ性も知らずに「関数型言語は数学と同じ」とか、マジでバカすぎw
220 :uy2011/10/01(土) 18:37:55.88
お前たちゴミには理解できない話なんだろうけど

OOによって書きやすいプログラムのほうが
関数型によって書きやすいプログラムよりも「多い」から、OOが使われてんだよ・・・

ほんっとーに、目の前の事実から目をそむけてよく考えず逆論ばっか唱えるゴミッカスが「多い」なw
222 :デフォルトの名無しさん2011/10/01(土) 19:34:09.77
全体の設計とかライブラリを OOP で書いて、局所的にはできるだけ副作用のない関数っぽく書けば良いのでは?
235 :デフォルトの名無しさん2011/10/02(日) 00:33:48.82

Java側のコードが
> int resultA = context.execute(3,4);
こうなっており、context.foo()などと
contextオブジェクトが持っている別のメソッド
を呼び出せるであろうことは明らか

だから
> let result_a = context 3 4
この言語はよく知らんが。
> let result_a = context.execute 3 4
のような形にしないといけない。
242 :2292011/10/02(日) 00:55:40.49
えーと、複数の関数を渡せればOK?
244 :デフォルトの名無しさん2011/10/02(日) 00:57:32.82
>>242
contextオブジェクトが内部にstrategyオブジェクトを所持しており、
contextオブジェクトが複数のメソッドや状態を持っていても
問題ないようになっていればOK
245 :デフォルトの名無しさん2011/10/02(日) 00:59:01.17
もう一つあった。Strategyオブジェクト自身も
複数のメソッドを持っていることも考慮すること。
246 :デフォルトの名無しさん2011/10/02(日) 00:59:19.26
渡す関数が二つとか三つとかなら、そのまま引数に渡すのが関数型言語なら一番簡潔
そしてOOPにおけるStrategyパターンでもそういう使い方が多い
247 :デフォルトの名無しさん2011/10/02(日) 01:02:09.20
> 渡す関数が二つとか三つとかなら
それはスマートじゃないね。


そもそもStrategyパターンってのは、
Contextオブジェクト(これはいろんな機能を持ったオブジェクト)を
使ってあれこれプログラミングをするときに
その内部のstrategyというオブジェクト(これもいろんな機能を持っている)を
入れ替えることでContextオブジェクトの動作を変えるもの

どちらも関数単体で分離するようなもんじゃないんだよ。
249 :デフォルトの名無しさん2011/10/02(日) 01:16:33.05
>>247
Strategyパターンがそんな巨大なStrategyオブジェクトをやりとりするなんて初耳だぞ。
アルゴリズムを入れ替えるのが目的なのに、ひとつのオブジェクトに沢山アルゴリズムを
パッケージする理由が無い。

http://ja.wikipedia.org/wiki/Strategy_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

ここのPythonの項にも「関数が第一級オブジェクトであり、このパターンを明示的に定義する必要はない」と書いてある。
251 :デフォルトの名無しさん2011/10/02(日) 01:23:58.45
>>249
ちげーよ。

たくさんアルゴリズムをパッケージするんじゃなくて、
一つのアルゴリズムつーか、機能な。
一つの機能が複数のメソッドからなっている場合もあるってことだ。
252 :デフォルトの名無しさん2011/10/02(日) 01:25:57.08
>>251
> 一つの機能が複数のメソッドからなっている場合もあるってことだ。
例を挙げてくれ
254 :デフォルトの名無しさん2011/10/02(日) 01:31:15.83
>>252
class Context {
 private Strategy strategy;
 private int count = 0;

 ・・・ その他のコード省略
 
 void func123() {
  strategy.init(this.count);
  for(int i=0; i<10; i++) {
   strategy.do(i);
  }
  strategy.finish();
  count++;
 }
}

見ての通り、strategyはinit、do、finishの3つのメソッドで
一つの機能を提供するオブジェクト。
255 :2292011/10/02(日) 01:35:28.70
>>254
それを関数型で書けばOK?あとでオブジェクト指向じゃないとか言わない?
258 :デフォルトの名無しさん2011/10/02(日) 01:41:51.25
>>254
何それ?お前が勝手に作った疑似コードじゃなくて
もっと実際の例は無いのかよ?

本当に>>247の通りならいくらでも見つかるだろ。
248 :デフォルトの名無しさん2011/10/02(日) 01:04:08.18
つまり、関数型言語っぽい書き方をしたら、オブジェクト指向っぽくないという理由で却下
250 :デフォルトの名無しさん2011/10/02(日) 01:23:23.94
クロージャで状態保持できるのは関数型言語だけじゃないしwww

にわか関数型プログラマって、ほんと無知だなw
253 :デフォルトの名無しさん2011/10/02(日) 01:28:03.49
>>250
誰がクロージャで状態保持できるのは関数型言語だけって言ったんだ?
308 :デフォルトの名無しさん2011/10/02(日) 19:54:30.18
>>253
関数型言語ではクロージャが状態を保持できる(キリリッ
って人ならいるねww
256 :デフォルトの名無しさん2011/10/02(日) 01:36:55.67
> あとでオブジェクト指向じゃないとか言わない?
言わない。


それはオブジェクト指向じゃない。

今いったw
257 :デフォルトの名無しさん2011/10/02(日) 01:39:28.39
>>256
そうか。じゃあいいや
というか、関数型ではそういう副作用のあるコードは書かないね
259 :デフォルトの名無しさん2011/10/02(日) 02:04:56.63
結局、手続き型に比べて大して短くもならなければ、読みやすくも、ましてバグが少なくもならないようだ>関数型
260 :デフォルトの名無しさん2011/10/02(日) 02:19:43.16
ソートアルゴリズムと比較関数をStrategyとして受け取って、
ソートした後に出力するというStrategyパターン


let print_sorted_list sort comp x =
  let x = sort comp x in Std.print x

let execute = print_sorted_list List.stable_sort (fun x y -> x - y)
let _ = execute [3;1;2;4]
let execute = print_sorted_list List.fast_sort (fun x y -> y - x)
let _ = execute [3;1;2;4]


オブジェクト指向で書いても、あとで関数型じゃないと文句を言ったりはしない
302 :デフォルトの名無しさん2011/10/02(日) 18:56:54.54
ま、>>260は静的型だから変数の型にも答えられるけどな
264 :デフォルトの名無しさん2011/10/02(日) 03:28:23.86
そのletがなぜ必要なのかばっかり気になってダメだな俺…
270 :uy2011/10/02(日) 04:55:41.16
関数型厨は、現実みろって感じ



どこか局所的な部分においては
OOでかくよりも1.1倍の効率が出るのかもしれない

しかし、そのプログラムをメンテするプログラマは関数型言語になんて慣れていないから
開発効率が0.1倍以上も低下するんだよ
結局全部OOでやったほうがマシ  関数型は中途半端な概念
271 :デフォルトの名無しさん2011/10/02(日) 05:05:42.36
面倒なのでストラテジは1パターンのみ(標準に一種類しかソートアルゴリズム無いし)

import java.util.*;
interface SortStrategy<T> { void sort(List<T> l,  Comparator<T> comp); }
class CollectionsSortStrategy<T> implements SortStrategy<T> {
public void sort(List<T> l, Comparator<T> comp) { Collections.sort(l, comp); }
}
class Context<T> {
private SortStrategy<T> sort;
private Comparator<T> comp;
public Context(SortStrategy<T> sort, Comparator<T> comp) { this.sort = sort; this.comp = comp; }
public void execute(List<T> l) { this.sort.sort(l, this.comp); System.out.println(l.toString()); }
}
class StrategyExample {
public static void main(String[] args) {
Context<Integer> context = new Context<Integer>(new CollectionsSortStrategy<Integer>(),
new Comparator<Integer>() { public int compare(Integer v1, Integer v2) { return v1 - v2; }});
context.execute(Arrays.asList(new Integer[] {3,1,2,4}));
}
}
296 :デフォルトの名無しさん2011/10/02(日) 18:35:51.66
そうそう。Javaも他の言語も全然変わらんよ
>>260と>>271を比べてみろよ
似たようなもんだろ?
298 :デフォルトの名無しさん2011/10/02(日) 18:39:26.44
>>296
うん。結局、改行とか宣言とか
そういうタイピングの差レベルの違いしかないよね。

そしてそれらはコード全体を○倍にする類のものではなく、
コードに対して+α増えるだけ。

しかもIDEサポートでその差は消えるって寸法だ。
272 :デフォルトの名無しさん2011/10/02(日) 05:47:14.59
わー読みやすーい
むりやり改行減らして行数少なく見せようとする努力もステキ
279 :デフォルトの名無しさん2011/10/02(日) 13:06:39.21
彼女が「おめこ」連呼しても平気とか
それのどこがStrategyパターンなんだよ。バカすぎる。
280 :デフォルトの名無しさん2011/10/02(日) 13:17:31.90
OOP使いが低能なのか
Java使いが低能なのか
あるいはその両方か
281 :デフォルトの名無しさん2011/10/02(日) 14:51:21.29
>>280
低能向けに仕様を固めた言語がJavaだからなぁ…
OOP自体はもはや「使い」なんて付けるほどじゃなく、基礎知識の域だと思う
強いて言うなら「狂信者」ってとこ?OOPさえあれば何でも出来る…と思ってる奴は確かに痛い
282 :デフォルトの名無しさん2011/10/02(日) 15:30:33.74
>>281
ほう。どの点が「低能向けの仕様」なのですかな?
その理由も一緒にお願いね。
283 :uy2011/10/02(日) 15:46:54.58
>>282
あいたたたた


285 :デフォルトの名無しさん2011/10/02(日) 17:03:56.78
単に低脳つーたら怒るわな
一山いくらの分業を可能にしたOOPとしてプロのお給料を支えるJava
pjに一人二人クズが混ざってても計画立てて差し替えられるJava
それは素晴らしい事だよ

あまり言語自体の自由度高いと馬鹿が一人二人暴走したら目も当てられない
286 :デフォルトの名無しさん2011/10/02(日) 17:41:33.65
まだ、低能向けの仕様がどういった所で
その理由がでてないのかよ。
289 :デフォルトの名無しさん2011/10/02(日) 18:08:30.04
Javaのコードの冗長さもIDEで補完できるという意見もあるけど、
それってつまりJavaのコードの大半は自動生成できる、書くのに人間の知性が要らない
記述する必要のないコードなんだよね。
ライン工場が殆どの処理を自動化して、一部の(それも知性の要らない)作業だけ工員に
やらせるのと同じで、Java PGは自動生成されたコードの一部に単純なコードを挿入するだけ。
290 :デフォルトの名無しさん2011/10/02(日) 18:10:36.75
>>289
自動生成と補完は意味が全く違うぞ。

補完で終わらせられるような単語の「キーを入力すること」は
人間の知性がいらない、記述する必要のないコードとは言えるが。
295 :デフォルトの名無しさん2011/10/02(日) 18:29:30.25
>>289
お前、コード書けないでしょ
たったそれだけの文章なのに、いちいち論理を誤ってんじゃねえよw
297 :デフォルトの名無しさん2011/10/02(日) 18:37:14.50
>>289
俺なら、開発の中で効率化出来る部分、つまり自動化ができる部分があるのなら、
極力自動化が可能なように、いろんな部分を改善して、
人間がやる部分は自動化できない所、自動化出来る部分を機械に
やらせようと思うけどな。

Javaで自動化できる部分があるとすれば、それは言語とは関係なく
開発全体の中で自動化が出来る部分が存在するってことでしょ。

なら機械にやらせるべきだし、それを人間がやらないといけないとしたら
手間がかかっているということ。

俺が言語を作るなら、自動化できるような言語を作るな。
328 :uy2011/10/03(月) 02:00:09.21
2chでバカを見つける方法だけど、

>>282
>>286
>>289

JAVAはすごいんだ! ってレスしてるやつってね
こうやって、ちょっとしゃべらせると
このように段階的にボロをだしていくのwwww

面白いよ! 試してみ!
330 :デフォルトの名無しさん2011/10/03(月) 02:47:48.82
>>328
お前のおかげで思い出したわw

結局Javaの「低能向けの仕様」(=優れた点)は
誰も言わなかったなw
332 :デフォルトの名無しさん2011/10/03(月) 03:29:50.41
>>330
あれ、その認識でいらっしゃる割に俺のコメがスルーされてるような
いや別に良いけど
333 :uy2011/10/03(月) 04:14:50.56
>>330
ガチ勢だからな、これ


まぁ、お仕事でJAVA使わされている けど自分は優秀だと思いたい

そういう奴は、JAVAはすごいんだ! って思い込むしかないよねぇ・・・・・・・・・・・・・あはは
291 :デフォルトの名無しさん2011/10/02(日) 18:16:05.92
型推論があれば必要無い型注釈や、
構造的部分型があれば必要無いインターフェース宣言の話じゃねーの
ここは型付けスレなんだし
292 :デフォルトの名無しさん2011/10/02(日) 18:23:07.83
Javaの素晴らしいところは、どんなに腕の立つPGでも
一定以上洗練されたコードを書く事は出来ないところだね。
誰が書いても芋臭い冗長なコードになる。
それゆえに引き継ぎの際に人員のスキルが問題になり難い。
294 :デフォルトの名無しさん2011/10/02(日) 18:24:39.49
>>292
宣言の書き方が決まってるだけで、
実装コードはどちらも大差ないよ。
293 :デフォルトの名無しさん2011/10/02(日) 18:23:51.99
型推論って型宣言のシンタックスシュガーにすぎないので
宣言文が簡単に書けるってだけで静的型付けであることに
代わりはないんだけどね。
299 :デフォルトの名無しさん2011/10/02(日) 18:44:05.55
そうそう。可読性はかなり落ちるが
どうせ一度書いたコードなんて読まないしな
300 :デフォルトの名無しさん2011/10/02(日) 18:49:27.84
可読性は落ちてないけど?

それよりも、動的言語の
変数にどんな型のオブジェクトが入っているのか、
見ただけではわからないってほうが問題。

obj と書いてあって、さあこれが一体どんな
メソッドを持っているでしょうか? と
質問しても動的言語では答えられないだろう。

オブジェクトはメソッド内で生成しているとは限らず
メソッドの引数として渡されるかもしれない。
そうすると呼び出し元を全部洗わないと、どんな型が来るかわからない。

もしこれがString objなら一発でわかる。
301 :デフォルトの名無しさん2011/10/02(日) 18:53:21.89
>>300
メソッドの引数に型を
コメントで書いておけばいいんだよ。

ま、コメントで書くぐらいなら
コードで書いたほうがはるかにいいけどなw
304 :デフォルトの名無しさん2011/10/02(日) 18:59:16.22
つーか、JavaはScalaやC#と比べても冗長だろ……
305 :デフォルトの名無しさん2011/10/02(日) 19:04:12.07
>>304
そうなんだよね。
Javaの構文が冗長なだけで、別に静的型付けが冗長というわけではない。

せっかく色々宣言してあるのだから、それらをうまく使って
簡易にかける言語がこれからできるだろう。

型推論もその一つ、静的型付け言語の宣言をうまく利用することで
簡単に書くことができる文法。
306 :デフォルトの名無しさん2011/10/02(日) 19:15:39.95
皆スレタイを思い出せ
動的型付け言語で安全なソフトを作れるか?だろ
普通に作れる。ただしソースコードの行数が100行以下なら
307 :デフォルトの名無しさん2011/10/02(日) 19:49:45.28
100行以上でも作れる
ただしコード内へアサーションを十分に埋め込み、
十二分なテストケースを用意できるのであれば

要は、お手軽さが魅力の動的言語で、
どこまで品質保証にコスト(労力)をかけるのか?という事
作れる/作れないの二元論だけじゃ語れないんだよ
309 :デフォルトの名無しさん2011/10/02(日) 19:55:40.71
>>307
> 要は、お手軽さが魅力の動的言語で、

これだから静的厨は馬鹿だというのだ
310 :デフォルトの名無しさん2011/10/02(日) 20:33:35.33
このスレではJavaやC++は静的型付け(=強い型付け)の言語という分類なのかな?
どっちも静的でコーディング/テストに手間がかかる割には型検査が甘いよね
これじゃ動的厨がグダグダと文句をたれるのもしかたない....のかも
315 :デフォルトの名無しさん2011/10/02(日) 21:00:42.26
>>310
静的が、コーディング/テストに手間がかかるって
誰か証明できてたっけ?
316 :デフォルトの名無しさん2011/10/02(日) 21:21:08.91
>>315
コーディングはいちいち変数宣言が必要だから議論の余地はねえだろ
テストは静的のほうが相対的には手間がかからんはずだけど、
静的な言語なんだから、もっとしっかり処理系でコンパイル時に検査してよ!!ってのはある

静的なのにナゼNullPointerExceptionなんてのが実行時に起きるわけ?!
ゼロ除算例外やI/Oエラーならテストで確認するしかないと思うんだが
319 :デフォルトの名無しさん2011/10/02(日) 21:42:29.46
>>316
> コーディングはいちいち変数宣言が必要だから議論の余地はねえだろ

変数宣言をしたおかげで、
使用するときは逆に楽になるだろ。
そのぶんのメリットをお忘れか?
320 :デフォルトの名無しさん2011/10/02(日) 21:44:38.28
>>316
> 静的なのにナゼNullPointerExceptionなんてのが実行時に起きるわけ?!

C++のように起きない言語もある。
お前が言ってるのは静的の欠点ではなく
Javaに「C++の参照」に近い仕様を入れろと言ってるにすぎないよ。
311 :デフォルトの名無しさん2011/10/02(日) 20:36:52.40
たのむから、型付けの強い/弱いと静的/動的の区別はつけろバカ
312 :デフォルトの名無しさん2011/10/02(日) 20:47:41.72
弱い静的型付けと強い動的型付けのどっちが
安全なソフトを作るのに向いてるんだろうな
313 :デフォルトの名無しさん2011/10/02(日) 20:53:38.27
>>312
日本語が違う
型付けの弱い静的言語vs強い型付けの動的言語
と言いたいんだろ?
314 :デフォルトの名無しさん2011/10/02(日) 20:56:52.45
317 :デフォルトの名無しさん2011/10/02(日) 21:30:55.65
そうやな
関数型言語なのにtotalな関数じゃないとか詐欺みたいな事してるもんな
だからtotal function programmingとか
318 :デフォルトの名無しさん2011/10/02(日) 21:40:03.59
あほか、なんで関数型言語の関数が全て全射でなきゃならんのだ
全射でないから安全でないコードが書けるけど、そもそも「関数型 = 安全」の図式が幻想だ
322 :デフォルトの名無しさん2011/10/02(日) 22:01:34.26
たとえば強い型付け&動的言語であるSMLで以下のようなデータ型/関数の定義があった場合、
 datatype Color = Blue | Red | Yellow

 fun signal color =
   case color of
    Blue => "BLUE"
   | Red => "RED"
   | Yellow => "YELLOW"
関数 signal の引数が Color型で戻り値が文字列型であることは処理系が保証する。(これは当然)
しかも「うっかり」ケースの書き漏れ(たとえばRedを忘れた...)があったとしても、
静的な型検査で「実行前に」処理系(インタプリタ/コンパイラ)が警告メッセージを出してくれる

弱い型付け&動的言語であるPython/Ruby/Perlがテストでなければ
このようなケース漏れを確認できないのは、弱い型付け言語である以上はしかたがない
でもJava/C++の処理系がコンパイル時に検査してくれないのは不満がある(ストレスが溜まる)
やっぱり「Java/C++は弱い型付け&静的言語」だからしかたがないのかな....
338 :デフォルトの名無しさん2011/10/03(月) 07:18:43.41
>>322みたいな「強い型付け」「弱い型付け」「動的型付け」「静的型付け」の
区別がつかないアホって、一体どうやったら学ぶ事ができるのかな?
RubyやPythonは「強い型付け」でかつ「動的型付け」なんだけどね(それを通常「強い動的型付け」という)
339 :デフォルトの名無しさん2011/10/03(月) 08:36:46.25
>>338
静的の定義を書けば?
340 :デフォルトの名無しさん2011/10/03(月) 08:42:26.71
323 :デフォルトの名無しさん2011/10/02(日) 22:05:11.36
よーわからんけどぬるぽはmaybeモナドとかoption型とか呼ばれてるやつを使えばいーんでないの?
進んでる静的型付け言語はもうぬるぽは克服してるイメージがあるけどちげーのか?
325 :デフォルトの名無しさん2011/10/02(日) 22:30:06.69
>>323
Haskellは副作用を一切許さない純粋関数型言語だから、
モナドを使う以前の話でヌルポは起きようがないよ
326 :デフォルトの名無しさん2011/10/02(日) 23:30:14.68
>>325
値の検証のタイミングはMaybe外すとき、ってのが分かりやすいだけじゃね?
Nothingの時にfromJustしたら実行時エラー出た気がする。
それをヌルポと言うのかは知らんけど。
336 :デフォルトの名無しさん2011/10/03(月) 05:39:30.38
>>325
ゼロ割りその他のランタイムエラーは起こりまくりだけどなw
324 :デフォルトの名無しさん2011/10/02(日) 22:06:30.55
そこで、俺が前々から言っている、
コンパイラで自動的に検証できることを増やすという
考えで言語を作ろうという話になる。
331 :デフォルトの名無しさん2011/10/03(月) 02:59:31.46
机上で語っても仕方ないから、
ミッションクリティカル領域の実績豊富な言語が一番安全ということで。

結論:C言語
334 :デフォルトの名無しさん2011/10/03(月) 04:25:23.82
そんな煽りしかできないから
馬鹿にされるわけでw
337 :uy2011/10/03(月) 06:03:12.52
>>334-335
必死www
いいじゃん お前の中では332 = uy って事にしとけよ

それで救われるんだろ?自分を煽っていたのはuyだけで、他の奴からは煽られちゃいない uyがまちがってるんだ!そう思っておけばさ

     /: : : : : __: :/: : ::/: : ://: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ    ___
     /;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::、  /     ヽ
    /ヽヽ: ://: :!:,X~::|: /;,,;,/: :/  リ!: ::/ノ  l`ヽl !: : |: : : :l: :l: リ / そ そ お \
   /: : ヽヾ/: : l/::l |/|||llllヾ,、  / |: :/ , -==、 l\:::|: : : :|i: | /   う う  前  |
.   /: : : //ヾ ; :|!: イ、||ll|||||::||    ノノ  イ|||||||ヾ、 |: ::|!: : イ: ::|/   な 思 が
   /: : ://: : :ヽソ::ヽl |{ i||ll"ン    ´   i| l|||l"l `|: /|: : /'!/l     ん う
 ∠: : : ~: : : : : : : :丶ゝ-―-      ,  ー=z_ソ   |/ ハメ;, :: ::|.   だ ん
   i|::ハ: : : : : : : : : : : 、ヘヘヘヘ     、  ヘヘヘヘヘ /: : : : : \,|.   ろ な
   |!l |: : : : : : : : :、: ::\    、-―-,      / : : :丶;,,;,:ミヽ   う  ら
     丶: :ハ、lヽ: :ヽ: : ::\__  `~ "      /: : ト; lヽ)   ゝ
       レ `| `、l`、>=ニ´        ,  _´ : :} `   /
         ,,、r"^~´"''''"t-`r、 _  -、 ´ヽノ \ノ   /    お ・
       ,;'~  _r-- 、__     ~f、_>'、_         |  で  前 ・
      f~  ,;"     ~"t___    ミ、 ^'t         |  は  ん ・
      ,"  ,~         ヾ~'-、__ ミ_ξ丶     |  な  中 ・
     ;'  ,イ ..          ヽ_   ヾ、0ヽ丶    l         /
     ( ;":: |: :: ..          .`,   ヾ 丶 !    \____/
     ;;;; :: 入:: :: ::      l`ー-、   )l   ヾ 丶
     "~、ソ:: :い:: :     \_  ノ ,    ヾ 丶
335 :デフォルトの名無しさん2011/10/03(月) 04:37:31.95
っていうか、言語ごときで、○○使えるから俺頭いいとか、
それこそ頭悪いわw
341 :デフォルトの名無しさん2011/10/03(月) 11:58:28.68
http://www.infoq.com/jp/news/2007/12/closures-preserving-feel-of-java
「Javaはブルー・カラーの言語」
「ジェネリクスは大失敗でした。Javaの習得や理解は難しくなりましたが、それを避けることはできないのです。」
(他言語でも総称型は使われてるけど、"Javaプログラマ"には難し過ぎるってこと?)
342 :デフォルトの名無しさん2011/10/03(月) 12:12:02.62
>>341
お前がメインで使ってる言語を挙げてみろよw
349 :デフォルトの名無しさん2011/10/03(月) 14:54:17.90
>>341
言語仕様の議論で「この仕様はPGにとって複雑すぎるのでは?」という
やりとりはどの言語においても見られる。あのC++でさえ

ただJavaの場合その閾値がちょーっとばかり低いだけだw
346 :uy2011/10/03(月) 14:27:49.20
で、こんだけJAVAはすげーんだ!すげーんだぞ!!
ってやってて、最終的な逃げ道は
「どの言語使っても同じ」
だもんなぁ・・・・・・

仕事でJAVA使わされている時点で気づけよって話なんだけど
いまだにJAVA使いこなしてる自分を優秀とか思ってるのだろうか
そりゃこの業界には論外素人も入ってくるから、
ちょっとでも勉強する気があれば、先輩面できるんだけども
JAVAを後輩に得意げに鼻息荒く教えた程度で、2chで火病っちゃうくらいなら、君はJAVAをやるべきではなかった
351 :uy2011/10/03(月) 16:06:46.61
もうすぐ来るよwww JAVAERの必殺技!! みててみwww
 J A V E R 「 ど の 言 語 使 っ て も 同 じ 」 
予想では>>400-450 このあたり
352 :デフォルトの名無しさん2011/10/03(月) 16:17:42.27
どの言語使っても同じだろ全くおまいらときたら
353 :uy2011/10/03(月) 16:25:29.34
>>352
仕事中に何2chみてんだ
355 :デフォルトの名無しさん2011/10/03(月) 18:30:27.68
必死www
いいじゃん お前の中ではカレと会話って事にしとけよ
358 :デフォルトの名無しさん2011/10/03(月) 21:02:46.69
今日さ、つまらないスペルミスでバグになっていて、
その修正にちょっと時間を費やしてしまったんだけどさ
バグの原因を見つけたときに思った。

動的型付け言語だとちゃんとテストコードあっても
スペルミスの原因を探すのにこんなに時間がかかるんだ。
これがもし静的型付け言語なら一発でわかるのにって。

やっぱり静的型付け言語のほうが
コーディングが楽だよ。
363 :デフォルトの名無しさん2011/10/04(火) 03:32:08.49
>>358
メタプログラミングが常套手段の言語だと、
確かにこういう弊害あるな。

デバッグを想像しただけで泣ける。
365 :uy2011/10/04(火) 04:54:05.37
>>358
んー、
それは、たぶんお前の能力の低さだと思うけど

そんなレベルだと静的言語では静的言語特有の問題にぶち当たるんじゃないかね
366 :デフォルトの名無しさん2011/10/04(火) 05:49:29.86
>>358
まともなエディタも選べないカスはどの言語使ってもゴミしか書けねえってことだ。
367 :デフォルトの名無しさん2011/10/04(火) 05:59:40.82
>>358
宣言の有無と型付けの有無を区別できないカス?
Haskellでも↓はコンパイラ通るぞ
fil 0:xs = fil xs
fill 1:xs = 1+ (fil xs)
fil x:xs = 2 + (fil xs)
fil xs = 0
369 :デフォルトの名無しさん2011/10/04(火) 07:31:21.92
>>367
馬鹿に真面目に突っ込んでも無駄だよ
どうせ>>358もJava土方の作り話だし
359 :デフォルトの名無しさん2011/10/03(月) 21:44:59.26
方向を間違えなければ、時間をかけて進むのは苦にならない

間違った方向に全力を傾けた時の絶望感に比べたら
360 :デフォルトの名無しさん2011/10/03(月) 22:18:42.92
>>359
どっちも嫌に決まってるだろ。
361 :デフォルトの名無しさん2011/10/03(月) 22:20:23.74
そこそこメジャーな言語の中じゃC#が最強だな。monoが普及すればJavaとかスクリプト言語とか無用になるな。
362 :uy2011/10/04(火) 03:12:50.69
C#はMS言語だからね

けどスクリプト言語が無用にはならない。
可読性とか気にしないで、
ある目的達成のためだけに最も速くプログラムを作るには
スクリプト言語が必要

たとえば、どこかのサイトの画像を全てダウンロードして連番にRenameとか

Rubyであれば、純粋に記述量が少ないから
エディタ起動から60秒でかけるけど
C#になると、慣れたとしてもわからんな
364 :デフォルトの名無しさん2011/10/04(火) 03:34:50.34
コード自体の書き換えが多かったり、
使い捨てなら確かにスクリプトの方がいい。
というか適材適所だろ。
370 :デフォルトの名無しさん2011/10/04(火) 07:54:21.45
>>364
それくらいの簡単なプログラムの需要があるのは分かるけど、Rubyみたいな多機能な言語が必要かな?
Perlはuse strictしないで使うのが正しいみたいな事言う人いるけど。
371 :デフォルトの名無しさん2011/10/04(火) 09:52:04.24
Rubyなんかだと、標準ライブラリにスペルミスが入り込んだまま長い間気付かれなかったりするし。
完璧でなくてもある程度チェックしてくれる仕組みは欲しいな
372 :デフォルトの名無しさん2011/10/04(火) 10:35:47.96
えらく広く使われてたJava製の某フレームワークにもスペルミスがあったなw
375 :デフォルトの名無しさん2011/10/04(火) 15:25:30.82
>>372に言ったのではなかったがまあいいや
373 :デフォルトの名無しさん2011/10/04(火) 10:52:30.17
バレバレですよuyさん
374 :デフォルトの名無しさん2011/10/04(火) 12:10:55.56
>>373
uyがJavaのフレームワークのことなんて知ってるわけないじゃんw

所詮は知ったか坊やですし
377 :デフォルトの名無しさん2011/10/04(火) 20:44:34.79
明確な定義とかじゃなくて、コンパイルエラーを
感覚的にバグと捉えているかどうかを聞きたいのです。

特に動的型付け派の人に。
378 :デフォルトの名無しさん2011/10/04(火) 21:56:31.96
>>377
おれは日常的には lisp の人だが, バグと見なすよ.
lisp の場合, 宣言つけまくると, 下手な静的片付け言語より
型検査厳しい処理系もあるからかもだけど
380 :デフォルトの名無しさん2011/10/05(水) 04:20:53.29
>>377
動的型スキーだけど、バグだろうね。
ただ、環境のバグかプログラムのバグか、そこが問題だ。
379 :デフォルトの名無しさん2011/10/04(火) 22:56:43.29
知力                                                 青村早紀
  ↑                                           
秀│  一ノ瀬ことみ                                  裏葉 水瀬秋子
  |                               来ヶ谷唯湖                       
  │         川澄舞                   霧島聖  
優|             二木佳奈多  坂上智代    相楽美佐枝 天沢郁未
  │          能美クドリャフカ  西園美魚 倉田佐祐理
  |               遠野美凪 笹瀬川佐々美 美坂香里   
良|                          長森瑞佳        天野美汐
  │                       里村茜 川名みさき   古河早苗
  |                    七瀬留美                     
可┼                  藤林杏 藤林椋       
  |             上月澪 神北小毬
  |        三枝葉留佳 霧島佳乃 美坂栞  神尾晴子
落│         古河渚  水瀬名雪   巳間晴香
  │        伊吹風子 名倉由依  
  │         神尾観鈴   河南子            名倉友里
逝|       棗鈴  月宮あゆ                  
  │棗鈴(退行) 椎名繭 鹿沼葉子 神奈 みちる
  | 神尾観鈴(退行) 志野さいか 岡崎汐
死│  沢渡真琴(退行)                    
  ↓uy  
   ←―――――――――――――――――┼―――――――――――――――――→
    基地外     イタタ    厨房     普通     大人    君子     聖人
                         情緒的成熟度
382 :デフォルトの名無しさん2011/10/05(水) 07:37:02.89
>>379
わろた
383 :デフォルトの名無しさん2011/10/05(水) 20:42:48.53
やっぱり動的言語を使っている人って
コンパイルエラーをバグとして考えているんだね。

俺は、プログラミング=設計であり、バグは設計上の問題。
コンパイルエラーは、コンパイル=製造だから、製造上の問題と考える。
名前をつけるなら、歩留まりかねぇ。

この2つは全く別物あつかいなんだよ。
だから自然とこの2つを分けて考える。


製造は自動化出来るもの。設計は自動化できないもの。
単純作業(いわゆる土方作業)はなるべく自動化出来る製造に回し、
どうしても自動化できない設計を人間が行うという発想になる。
だから設計のテスト方法であるユニットテストで、製造のテストをするのはなんか違うだろってことになる。

やはり、基本的には静的型付け言語の方向で進みながら、動的型付け言語の機能を取り込むのが
プログラム言語の未来への正しい道だと思うな。
385 :デフォルトの名無しさん2011/10/05(水) 21:55:13.95
>>383
例えば未定義のメソッドを呼び出そうとしてエラーになったとすると
呼び出そうとしたのが悪いのか、定義していないのが悪いのか、自動的には判定できない
どっちが悪いかを考えるのは人間の仕事
386 :デフォルトの名無しさん2011/10/05(水) 22:02:33.44
>>383
論点があいまいで読んでてイライラする文章
391 :デフォルトの名無しさん2011/10/05(水) 23:42:09.09
>>383
>プログラミング=設計であり、バグは設計上の問題。
>コンパイルエラーは、コンパイル=製造だから、製造上の問題と考える。

プログラミング=設計の段階でコンパイルエラーの原因が発生するんだから
製造の問題では無いよね。そこが間違ってるので以下全部おかしい
392 :デフォルトの名無しさん2011/10/05(水) 23:51:05.25
>>391
設計は頭の中にあるんだよ(キリッ

まあ、こういうこと。
設計は頭で考えるまでで、紙に書くのは製造の段階だよ。

実際経験を積んでいる人は、設計を考えるときに
言語のことはほとんど考えないでしょ?
403 :デフォルトの名無しさん2011/10/06(木) 01:07:02.55
どちらかというとマ板の議論が続いているな

ところで、その設計 vs. 製造の話が、なぜ動的片付け/静的型付けの結論になるのか、
>>383を何度読み返してもさっぱり意味不明なんだが....
384 :デフォルトの名無しさん2011/10/05(水) 21:44:59.19
あのー、ドヤ顔してるところ申し訳ないんですが、
静的型言語派の俺もコンパイルエラーはバグだと思ってますよ、と。
387 :デフォルトの名無しさん2011/10/05(水) 22:05:20.83
コンパイル通らないのはバグ以前の問題で、バグとは思ってないな。
389 :デフォルトの名無しさん2011/10/05(水) 22:12:27.29
自分の書いたコードについては>>387と同じ
他人の書いたコードのコンパイルエラーはバグと感じる
406 :デフォルトの名無しさん2011/10/06(木) 01:30:23.27
>>403
静的型付け言語を使っている人はみんなそうだと思うけど、
コンパイルエラーはバグだとは思ってないんだよ。

動かないからね。単なる入力ミス。すぐに修正できる。
たいてい構文エラーや宣言してない変数を使ったり、メソッドを使ったりって
これはつまらないスペルミスであることが多い。

こんなくだらないことと思うかもしれないが、これだって修正しなければいけない以上
すぐにミスがわかったほうが良い。こんな下らないことだからこそ、修正に時間をかけてはいけないんだ。

だけど、動的言語だとどうしても動かさないとわからない。
そこで仮説を立てた。動的言語ばっかり使ってる人は、静的言語を使っている人に比べて
コンパイルエラー程度の小さなものを、バグとして認識しているのではないかと。
本質的に違うものが、混ざってしまっているのではないかと。
で、質問した所、実際にそのようなレスが返ってきた。
(>>387のように、バグ以前の問題と認識している人もいるけど)

じゃあ、バグとバグ以前のものはなにが違うを考えてみた所、
設計工程による不具合と製造工程の不具合の違いではないかと気づいたわけさ。
408 :デフォルトの名無しさん2011/10/06(木) 01:45:12.50
>>406
やはり下半分が意味不明だ

仮説通りだった事は何を証明してるの?
409 :デフォルトの名無しさん2011/10/06(木) 01:49:10.99
よー分からんけど少なくとも>>383はおかしいな。大体>>391と同意見。

>>406
使ってる言語はC、C#な人間だが、コンパイルエラーはバグだと思ってるよ。
言葉が気に入らなければそっちの言うバグも含めて
同列に欠陥、不具合と言いかえても良い。

ただ、管理した方が良い欠陥とそうでない欠陥があるだけ。
アクティビティを越えない欠陥は、大体管理しなくて良い。


変な線引かんで欲しい。
410 :デフォルトの名無しさん2011/10/06(木) 02:31:16.46
>>406
ていうか今どきはIDE使う人がほとんどだから、普段プログラミングしてて
コンパイルエラーなんて意識しないだろ

それにしてもイライラする文章
少し前にさ、プログラミングは設計である!ってドヤ顔するのが流行ったよね
今さらドヤ顔してる奴を見るとは思わなかった
430 :デフォルトの名無しさん2011/10/06(木) 20:43:15.05
>>389が感覚的に近いかなあ。
共同作業だと各自のライブラリやらソースやらのバージョンの差で、
自分の手元でコンパイルできて他の人がコンパイルできないコミットする場合あるし。

まあ静的言語でパーサ通っても安心て訳じゃないのは当然だけど、
型チェックくらいはパーサに任せたい。
438 :デフォルトの名無しさん2011/10/07(金) 05:51:43.32
>>406
ハスケルの偉いひとも「コンパイルはテスト!」って言ってたお?
390 :デフォルトの名無しさん2011/10/05(水) 22:17:04.04
イライラするのは、決めつける言い方が多いから

変数の型を決めつける言語にイライラするのと似ている
自分で決めつけたことはイライラしない
他人が決めつけるとイライラする
393 :デフォルトの名無しさん2011/10/06(木) 00:03:46.84
プログラミング=設計という時点で趣味グラマあるいは底辺コーダの発想
以降の内容は反論する気もうせる
394 :デフォルトの名無しさん2011/10/06(木) 00:13:06.64
>>393
お前に話しかける気も失せたんだが、武士の情けだ。

プログラミングは「設計」か「製造」か
http://techon.nikkeibp.co.jp/article/TOPCOL/20070821/137958/
> プログラミングという行為は「ソフトウエアの製造」ではなく
> 「ソフトウエアの設計」である,というのがIT分野では半ば常識です
396 :デフォルトの名無しさん2011/10/06(木) 00:41:51.02
>>394
貼ってあるリンクの続き。

>だから私は「プログラミングが製造だとするのは間違いである」と頭から信じ込んでいました。
>でも最近,この信念がゆらいできています。
398 :デフォルトの名無しさん2011/10/06(木) 00:44:08.40
>>396
それは、それを書いた人の考え。

IT分野では半ば常識であることを、
趣味グラマの発想などと言ってしまった。

自分が無知であると言ったようなものじゃないか。
その時点で自滅してるんだよ。
400 :デフォルトの名無しさん2011/10/06(木) 00:58:23.74
>>394
引用の記事は、単なる雑誌記者のブログだろ。それが絶対的真理ではない。
しかも記事の後半は、著者自身が「信念のゆらぎ」を正直に告白している。

プログラミング=設計が真実になるのは、プログラミングという行為と並行して
頭の中でモデルやアーキテクチャをイメージ(設計)できる一流のプログラマ達に限定される。
そういったプログラマであれば、いわゆる「アジャイル開発プロセス」も成功する。

この記事が書かれたのは2007年だが、あれほど騒がれたアジャイル熱も冷めているのが現実。
395 :デフォルトの名無しさん2011/10/06(木) 00:14:50.22
昔はコーダーというものがあったらしいんだが、
コンパイルエラーはコーダーによるミスになるだろう。
直感的に考えて明らかにバグとは違うものだよ。
397 :デフォルトの名無しさん2011/10/06(木) 00:41:54.27
いまどきの日本の最底辺の下請けコーダーは
プログラミング言語と一対一対応するような仕様書を受け取って
それをコードに翻訳する仕事をしてるのかい?
いや、良く知らんのだが。
399 :デフォルトの名無しさん2011/10/06(木) 00:46:15.20
>>397
良くない流れがあってね

下請けコーダーがやるようなことを
なぜかプログラマがやってるんだよ。

そんなのコンパイラにやらせとけと思うのだが、
とうとうコンパイルエラーをバグと考える人が出てきてしまっている。

本来下請けコーダーのやるような簡単なミスが、
なぜかプログラマのバグとして扱われ始めている。
良くない傾向。
402 :デフォルトの名無しさん2011/10/06(木) 01:04:45.42
>>399
ずいぶん業界にお詳しいんですね
404 :デフォルトの名無しさん2011/10/06(木) 01:08:06.43
コードと同レベルの粒度で仕様書を書くなんて無駄
自然言語じゃなく最初からプログラミング言語で書いときゃ動くものが出来るのに

プログラム書けないSEモドキの雇用創出以外の意味あんの?
405 :デフォルトの名無しさん2011/10/06(木) 01:10:05.33
「ソフトウェアアーキテクトが知るべき97のこと」という本にも書いてあるよ。

「(31)プログラミングは製造ではなく設計だ」アイナー・ランドル
http://d.hatena.ne.jp/kent4989/20091008/p1

プログラミングは設計だという考えに反対する人もいるだろうけど、
少なくとも、プログラミングは設計だという考えを知らない人は
モグリと言われてもしょうがないよ。
407 :デフォルトの名無しさん2011/10/06(木) 01:34:31.27
動的型付け言語と動的言語、静的型付け言語と静的言語が
ごっちゃになってしまったな。
全部型付けの方だから訂正しておく。
411 :デフォルトの名無しさん2011/10/06(木) 02:38:41.53
今は上から下までドヤ顔の時代
ドヤ顔しないやつはドカタと蔑まれる時代
412 :デフォルトの名無しさん2011/10/06(木) 02:45:35.96
製造業のアナロジーでプログラミングを語るのは勝手だけど
例えは例えにすぎないわけで、それが本質みたいな言い方されてもなー
413 :デフォルトの名無しさん2011/10/06(木) 02:47:32.65
静的厨からも動的厨からも反感を買う、新しいタイプの静的厨だな
414 :デフォルトの名無しさん2011/10/06(木) 03:57:43.95
Rubyは全然好きになれない。
includeされまくってると何処で定義されてるメソッドか分からねぇし、
くだらねぇタイポも実行時に初めて分かるし。
なにが生産性だよ。
416 :デフォルトの名無しさん2011/10/06(木) 07:42:30.91
>>414
Rubyという言語が嫌なんじゃなくて、IDEのサポートが貧弱なのが嫌なんでしょ?
425 :デフォルトの名無しさん2011/10/06(木) 16:35:32.69
>>416
そうかも。みんなはどうしてるんだろ。
動的言語を静的に解析するのは難しいから
諦めて根性でカバーしてんのかな。
Lispのslimeみたいなのもないだろうし。
426 :デフォルトの名無しさん2011/10/06(木) 16:56:36.26
>>425
実行しろよ
ソフトは実行するためにあるのになぜ実行したくないんだ
427 :デフォルトの名無しさん2011/10/06(木) 17:03:52.54
>>426
実行してるよ。いちいち実行して確認が面倒って話。
分岐すると両方確かめないとだめだし。
自動テストもやってるけど、カバレッジ率上げるのしんどいし。
428 :デフォルトの名無しさん2011/10/06(木) 17:35:57.91
>>427
お前の中では面倒なんだろうけど、他の人がどう思うかはその人の自由。
自由にして生産性を上げるか、徹底的に管理して生産性を上げるかという話だな。
437 :デフォルトの名無しさん2011/10/07(金) 04:27:00.97
>>416
> Rubyという言語が嫌なんじゃなくて、IDEのサポートが貧弱なのが嫌なんでしょ?

IDEのサポートが貧弱なのは
Rubyという言語が原因。
415 :デフォルトの名無しさん2011/10/06(木) 04:29:40.36
実行可能コードが生成された以降からバグが発生する。
従ってコンパイルエラーはバグとは考えていない。
417 :デフォルトの名無しさん2011/10/06(木) 09:06:22.47
どっちにしろ未婚独身女性の発するクヒヒは馬鹿ってことだな(業界にお詳しいんです。)
418 :デフォルトの名無しさん2011/10/06(木) 10:46:09.75
バグがなくても何かと理由をつけてソースコード熟読したい人もいる
速読や速記を自慢したい人ばかりではない
419 :デフォルトの名無しさん2011/10/06(木) 11:05:22.79
ソースコードの読み易さランキング

Haskell > Python >> Ruby >> 超えられない壁 >> C++ >= Perl >> Java
420 :デフォルトの名無しさん2011/10/06(木) 12:08:42.10
>>419
ただし小規模に限る
421 :デフォルトの名無しさん2011/10/06(木) 12:24:29.30
>>419
同じ文字数なら、断然Java>>Haskellだな。
Javaは良く出来てる。
沢山書いても、実現してる事は少ないから頭を使わなくていい。
423 :デフォルトの名無しさん2011/10/06(木) 12:36:06.78
>>421
文系が数式よりも記述密度が低い自然言語での説明を好むように
低能は記述密度の低いJavaを好む
424 :デフォルトの名無しさん2011/10/06(木) 15:01:12.24
いくらHaskellやPythonが仕事で使えるとしても、
お前らみたいな勘違いばかりなら確実に鬱になるな。
431 :デフォルトの名無しさん2011/10/06(木) 21:07:10.08
パーザで型チェック
450 :デフォルトの名無しさん2011/10/07(金) 14:17:55.35
>>431-433
多分、>>431を書いた人は、パースは単なる構文解析ステージであって、
型チェックを行うのは「意味解析」ステージだ、と言いたかったの
だと思う。
432 :デフォルトの名無しさん2011/10/06(木) 21:17:44.42
型は構文より後だろって?静的チェックさせたいと言いたかったんだよう。
ところでパースとパーズとどっちが一般的なんだ
433 :デフォルトの名無しさん2011/10/06(木) 22:25:08.58
カタカナ表記はパースが一般的
同僚のイングランド人の発音はパーズに近かった
434 :デフォルトの名無しさん2011/10/06(木) 23:29:39.11
rubyは断然読みづらい
言語内言語がひどい
勘違いして明後日に向かった典型例
435 :デフォルトの名無しさん2011/10/07(金) 01:25:47.98
ソフトはコンパイルするためにあるのになぜコンパイルしたくないんだ
436 :デフォルトの名無しさん2011/10/07(金) 02:55:30.03
コンパイルするためにあるんじゃない!実行するためにあるんだ!
っていう主張なんでしょ。
439 :デフォルトの名無しさん2011/10/07(金) 06:36:31.41
そりゃ、バグが見つからならテストになりうるわな。

でも、コンパイルで見つかるのなんて、スペルミスとか
構文エラーとか、そんなのだろ?

そんなのバグのうちに入るのか?
そういやこのスレ的にはコンパイルエラーもバグという定義なんだっけ?

ならまあいいんだけど。
440 :デフォルトの名無しさん2011/10/07(金) 06:37:24.01
動的言語ではスペルミスも
致命的なバグになりかねない。
441 :デフォルトの名無しさん2011/10/07(金) 07:34:27.94
スペルミス等も考慮した、大規模開発における生産性

Haskell >> Python > C++ >> 超えられない壁 >> Ruby >> Java >= Perl
442 :デフォルトの名無しさん2011/10/07(金) 07:44:27.36
Haskellで実用的なコードを書ける人員は非常に高くつくんで
利益/コストが高くなるようには思えない
445 :デフォルトの名無しさん2011/10/07(金) 08:47:56.33
ミスは許されない。
でも、人間が失敗するのは人間だから仕方ない。

この設定なら最初から危険だろ。
これが現実だと言うかもしれないが、自然法則ではない。人工的に作られた設定。

Haskellとか数学とかって、やっぱり自然科学とは違うのかね。
447 :デフォルトの名無しさん2011/10/07(金) 09:30:26.21
あたいを変える方法はないので、クロージャ間で状態を共有する必要はない。
単に同じあたいを使うだけである。そこで、クロージャが捕捉する"環境"は、
あるスコープのすべての変数の束縛の集合で"ある"ので、私はマサチューセッツ。
448 :デフォルトの名無しさん2011/10/07(金) 09:34:46.48
結局、変数は宣言する、それも型と一緒に、って事だろ?つまり、Rubyはダメって事じゃん。
449 :デフォルトの名無しさん2011/10/07(金) 10:39:44.33
その「結局」、が何を指してるのか説明プリーズ

おまえの日本語はまるでRubyだぞw
453 :デフォルトの名無しさん2011/10/07(金) 20:26:08.69
分類分けに関するコミュニケーションの行き違いであるところが味わい深い
454 :デフォルトの名無しさん2011/10/07(金) 20:43:36.98
スペルミスって、そんなにするかなあ。
てかRubyだとしても、ミスって困るのは代入のときだけだろ?それ以外だとエラーになるだろうし。
それって、変数の使い回しとかしない限りそうそう困らないような。
Hashにはfetchがあるからキー名のミスもそれで対処できるし。
455 :デフォルトの名無しさん2011/10/07(金) 20:49:11.47
> スペルミスって、そんなにするかなあ。
最初の一発間違えれば別だけど, 今時エディタが補完するし...
456 :デフォルトの名無しさん2011/10/07(金) 20:57:24.41
GUIだって、ラインコマンドだって、やれることは同じでしょ。後者の方が、何をやっているか見えていいでしょ。
コンピュータ・オタクたちはよく言っていた。確かに、マッピングはできる。しかし、計算的には等価ではない。なぜなら、
それは、時空の中で展開されるものだから。「計算」という概念が、狭すぎるのである。コンピュータという存在が、
どのように私たちの脳の感覚、認知の回路に働きかけるか。感覚と運動の連関を通して、さまざまなクオリア、情動を
引き起こすか。それは、「気のせい」や「趣味」のことなんかじゃなくって、「計算」なんだってば!

マック・ユーザーを、「こけ」にするコンピュータ・オタクたちがずっといた。いいよ、Linux使っても何やってても。
でも、そういうチューリング・マシンの枠内で理解できる「計算」と、異なる「計算」が、この世界にはあるんだって。
なんでそのことが理解できないかな! iPadが出てとき、まるで遊んでいるように情報を扱えるようになった。3歳の
子どもでも遊べる。キーボードからラインコマンドを打つコンピュータと、それは、アルゴリズムでは等価かもしれない。
しかし、「経験の質」という「計算」においては、全く違うんだ! OSで、アイコンをどのように配置するか。ハード
ウェアの曲線や、手触り、立ち上がりの時の音楽。ジョブズがやってきたことは、「趣味」の問題じゃなくて、人間の
感性における、ハードコアな「計算」なんだ。それを、「マック信者」だとか言って、「こけ」にしてきたんだよね。

Googleは、ユーザーが要求した情報以外には提示しない、という哲学で一つの「経験」を提供した。一方、世間には、
要求もしないのに余計なことをするソフトがあふれている。それは、「経験」という「計算」の領域において、やっては
いけないことなんだよ! 結局、ジョブズは、単なるアルゴリズムの箱という意味合いを超えた「計算」の領域を、
コンピュータにずっと見て来た人だった。趣味や感性の問題じゃないんだ。そこには、緻密な計算のロジックがあるんだ。
そのことを感じた人がアップルを支持した。ジョブズは、計算の未来だった。

http://togetter.com/li/197523
465 :デフォルトの名無しさん2011/10/08(土) 01:19:04.28
>>456
プログラマの立場から言わせてもらえば、コマンドラインアプリすら作れない奴にまともなGUIアプリは作れない
458 :デフォルトの名無しさん2011/10/07(金) 21:36:13.93
>>要約
オタクはCUIでの計算を好むけど、人の感性への働きかける計算も重要。

そしてGoogleが要求にだけ応じる、という感覚を提供する一方、
世間にはその感覚外の余計な事までする逸脱したソフトもある。

とにかく、ジョブズはそういう枠外の感覚の計算を考えてた人で、
それを感じた人がアップルを支持した。

>>もっと要約
考えるんじゃない。感じろ。
460 :デフォルトの名無しさん2011/10/07(金) 21:42:09.81
さらに要約

アップルはお洒落(そんなアップルを支持する俺もお洒落)
463 :デフォルトの名無しさん2011/10/07(金) 23:13:36.87
ああ、Ruby使ってる奴っていかにも茂木って感じするわ。
なんか自分だけ天啓を受けたような気がしてる、すっとこどっこいな感じ?
悦に入ってるけど、端から見ると普通に可読性低いよっていう。
464 :デフォルトの名無しさん2011/10/08(土) 01:17:25.58
茂木のツイートは読みづらいわりに面白くないのがなぁ。

とりあえず俺はRubyの方がWindowsっぽい気がする。
洗練されてなさっぷりが。
けなしては無い。
パッと使う分には使いやすい。
466 :デフォルトの名無しさん2011/10/08(土) 01:22:18.81
Macが使いやすかったのはOS9までの話だな。OSX以降は普通にウンコというか、もうAppleはiOSの会社でMacはオマケ。
468 :デフォルトの名無しさん2011/10/08(土) 01:43:46.48
>>466
言えてる
ジョブズの引退ら死去までが早過ぎたから、後継者が育ってるかも疑問
iPhone3G->3GSは劇的だったけど、iPhone4->4GSはジョブスのやり口なら5を持ってきてたはず

今回の発表ですでに現CEOの底が見えた
小出し戦略での食いつなぎ
ジョブズのパターンしか見てない

精神は引き継がれてない

byどざえもんw
470 :デフォルトの名無しさん2011/10/08(土) 09:45:07.84
要約
・同じでしょ
・等価ではない
・「計算」という概念が、狭すぎる
・チューリング・マシンの枠内で理解できる「計算」と、異なる「計算」が、この世界にはある
・等価かもしれない
・全く違うんだ!
472 :デフォルトの名無しさん2011/10/08(土) 16:02:31.12
ここの人たちはJavaの悪名高い検査例外についてどう思う?
特に静的型付け派の人に聞きたい。
475 :デフォルトの名無しさん2011/10/08(土) 20:02:38.69
>>472
考え無しに握り潰すアホは考えない前提で、
アジャイルでないプロジェクトにおいては有益。
474 :デフォルトの名無しさん2011/10/08(土) 19:04:21.18
大半をExceptionにキャストしても
1個でも強い型が残れば実質的に静的型付けの勝利
0点じゃないなら1点でいいです
479 :デフォルトの名無しさん2011/10/08(土) 23:01:30.56
>>474
Exceptionにキャストしてどうやってまともな例外処理をするつもりなんだ?
476 :デフォルトの名無しさん2011/10/08(土) 20:51:58.83
考え無しに握り潰すアホは考えない前提なら
アジャイルでも有益
477 :デフォルトの名無しさん2011/10/08(土) 21:47:50.01
じゃなくて、
メソッドをサブタイプする度に
例外のクラスをどんどん上位の例外クラスにするという
検査例外の言語仕様のアホさの話だろ?
478 :デフォルトの名無しさん2011/10/08(土) 22:31:27.29
>>477
意味が全くわからん。
検査例外の問題点がわかってないんじゃないのか?
483 :デフォルトの名無しさん2011/10/09(日) 17:14:45.18
>>478
477読んでもわからないってことは
おまえは検査例外の問題点を理解していないということだ
484 :デフォルトの名無しさん2011/10/09(日) 19:21:27.16
>>477は俺も意味が分からないな

メソッドをサブタイプする?
例外のクラスをどんどん上位の例外クラスにする言語仕様?

検査例外の問題点を考える前にJavaの入門書でも読んだほうがいいよ
485 :デフォルトの名無しさん2011/10/09(日) 19:58:27.46
>>483
よし、今からお前、
foo()というメソッドをサブタイプしてみせろ
486 :デフォルトの名無しさん2011/10/09(日) 20:19:50.93
>>485
まずはそのfooの型を示せ
話はそれからだ
488 :デフォルトの名無しさん2011/10/09(日) 20:24:44.46
>>486
お前が自由に決めていいよ。
492 :デフォルトの名無しさん2011/10/09(日) 22:11:47.81
>>488
引数の型がサブタイプで
返り値の型がスーパータイプで
例外の型がサブタイプなら
そのメソッドの型は元のメソッドのサブタイプだ、
という常識もわからないキチガイはホムセンでロープ買ってこい
493 :デフォルトの名無しさん2011/10/09(日) 22:28:41.94
>>492
で、「メソッドをサブタイプする」ってのは
どうなったんだ?
お前が言ったんだぞ
495 :デフォルトの名無しさん2011/10/10(月) 02:11:10.24
>>492
縛ってほしいのか??
496 :デフォルトの名無しさん2011/10/10(月) 06:04:05.47
>>493
ばか死ねカス
480 :デフォルトの名無しさん2011/10/08(土) 23:14:51.25
困った時は動的型に頼る
ほとぼりがさめたらまた動的型を排除する
482 :デフォルトの名無しさん2011/10/09(日) 14:49:59.06
実装の詳細を曝す
かといってあまりラップして一般的にしすぎるとthrows Exceptionと大差ない
そもそもその場で例外処理するべきでない場合は多い
487 :デフォルトの名無しさん2011/10/09(日) 20:21:27.35
つうかサブタイプも知らずに検査例外がどうこう言うほどのキチガイはそう滅多にいないな
489 :デフォルトの名無しさん2011/10/09(日) 20:27:14.10
チェック例外はJavaにラムダを導入するのが難しい大きな理由の一つらしいけど
ガチな関数型の世界ではその辺うまくやる手法ってあるの?
497 :デフォルトの名無しさん2011/10/10(月) 08:02:04.13
>>489
Scalaもチェック例外無いし、どうなのかね
498 :デフォルトの名無しさん2011/10/10(月) 09:20:09.95
>>489
例外は副作用
副作用が発覚したらファンの人が幻滅する
490 :デフォルトの名無しさん2011/10/09(日) 20:42:29.62
> チェック例外はJavaにラムダを導入するのが難しい大きな理由の一つ
なんで?
491 :デフォルトの名無しさん2011/10/09(日) 20:52:23.85
例えばCallable#call throws Exceptionてあるでしょ
一般的すぎて何投げるかわかんないからExceptionにするしかないんだわ
ラムダが入るとそういうのが激増するから、そのままだとチェック例外が無意味になる
499 :デフォルトの名無しさん2011/10/10(月) 09:34:08.56
関数型言語の中では例外を直和型で扱うのがあるけど
検査例外よかまだ筋はいいと思うわ
というか検査例外はあれを目指してたんだろうな
504 :デフォルトの名無しさん2011/10/10(月) 16:01:10.81
Haskellで型付けされた例外を使ってみれば
例外が副作用とかプププってわかるよw
507 :デフォルトの名無しさん2011/10/11(火) 14:07:16.94
Googleはちょっとした研究の成果物と実用目的のものを区別しないで大袈裟に発表するからなあ
信用無くすぞ
510 :デフォルトの名無しさん2011/10/11(火) 16:54:01.23
型注釈構文とそれを元に警告を出すlintが標準で付いてくるだけで
動的型付け言語だよね
511 :デフォルトの名無しさん2011/10/11(火) 16:56:52.34
まあActionScript程度のパフォーマンス向上はあるかもね。
でもその程度。
513 :デフォルトの名無しさん2011/10/11(火) 19:50:30.02
CoffeeScriptの後だからもうちょっと面白いの期待したがダメだったな
っていうかCoffeeScriptに型アノテーションと名前空間ついた言語を
515 :デフォルトの名無しさん2011/10/11(火) 20:25:38.40
DartはDOMがJavaScript本体とさほど変わらない時点でWeb言語として終わってる
516 :デフォルトの名無しさん2011/10/11(火) 21:35:50.82
Dartは本当に真面目にやってんのか疑いたくなる有様だが、
一応Googleは動的型でも大規模アプリを開発できると
考えてるってことになるのか……?
517 :デフォルトの名無しさん2011/10/11(火) 21:39:10.05
dart、型指定できるじゃん。
519 :デフォルトの名無しさん2011/10/11(火) 21:51:20.56
>>517
静的に型チェックするけど、間違ってる可能性があっても警告出さない場合があるってさ
どうせなら型推論にしろよ誰得だよ、と思った
518 :デフォルトの名無しさん2011/10/11(火) 21:47:08.28
ほんとに見るところのない言語だな
あくまでリサーチプロジェクトとしても目的がよくわからん
Googleが言ってるJavaScriptは中間言語だというのを実践してみたかっただけ?
520 :デフォルトの名無しさん2011/10/11(火) 22:37:22.58
なるほど。静的型付けベースで
動的型付けも許容するって位置づけなのか。
522 :デフォルトの名無しさん2011/10/11(火) 22:58:05.12
C#のdynamicキーワードはそんな感じだけどね。Dartは動的型ベースだと思う。

例えるなら、Pythonにはpylintってチェッカーがあって
簡単な型エラーを静的に見つけられるけど、それの強化版って感じ。
523 :デフォルトの名無しさん2011/10/11(火) 23:34:04.04
Dartの仕様からは「静的厨はIDEで補完できてスペルミスが見つかりゃ満足だろ?」
「動的厨は型を省略できりゃいいんだろ?」的な意図を感じるw
525 :デフォルトの名無しさん2011/10/11(火) 23:43:09.84
素人考えだけど、DartはC#で言うdynamicとautoをわければよかったのに
なんでもvarじゃ型推論されるケースとダック型になるケースが分かりにくくない?
530 :デフォルトの名無しさん2011/10/12(水) 00:29:17.17
>>525
型推論は、単相型になるケースと多相型になるケースが分かりにくい。
let i x = x in (i i) (i i);;
let i x = x in let ii = i i in ii ii;;
532 :デフォルトの名無しさん2011/10/12(水) 00:45:02.78
>>530
大丈夫だ。ちゃんとコンパイラが教えてくれるし
慣れれば息をするようにeta expansionできるようになる

let i x = x in let ii x = (i i) (i i) x in ii;;
526 :デフォルトの名無しさん2011/10/12(水) 00:09:56.80
完全な型チェックしようとすると実行開始までに時間がかかっちゃって
JavaScriptに対するディスアドバンテージが目立っちゃうのを嫌ったんじゃないかなあ
527 :デフォルトの名無しさん2011/10/12(水) 00:20:55.32
なんか動的厨房が必死だなw

要するに、大規模向けならstrictモードONにして
省略をなくしてミスを減らせる。

それと同時に、簡単なツールとか用にstrictモードOFFで
短く書けるってことでしょ。

本当に動的だけでいいのなら、静的型付け機能はいらなかったはず。
やっぱ、Googleも大規模では静的型付けが有効ってわかってるんだよ。

>>526
> 完全な型チェックしようとすると実行開始までに時間がかかっちゃって
JavaScriptにコンパイルすればいいから関係ない。
533 :デフォルトの名無しさん2011/10/12(水) 00:56:21.16
>>527
ここ読んでみろよ。マジで動的型言語にlint付けただけって
分かってガッカリするぞ
http://www.dartlang.org/articles/optional-types/
528 :デフォルトの名無しさん2011/10/12(水) 00:22:51.21
http://internet.watch.impress.co.jp/docs/news/20111011_482895.html

> 言語の特徴として、Dartは開発者になじみのあるクラスやインターフェイスを備えている。
> また、オプションとして型を利用できる。アプリケーションの初期開発段階では
> 型を使わずに開発を進め、後にプロジェクトが複雑化するにつれて型を利用できる――と
> いった使い方が想定されている。また、ライブラリや開発ツールも提供されるとしている。

やっぱり複雑化したら、型使ったほうがいいということか・・・
529 :デフォルトの名無しさん2011/10/12(水) 00:25:49.74
http://japan.cnet.com/news/service/35008825/

> 以下は、Dartの設計目標に関するBak氏の簡単な説明である。

>  Dartは、1人のプログラマーによる、特に構造を意識しないプロジェクトから、
> コード内にプログラマーの意図を記述する為に定型が必要となる大規模プロジェクトまで、
> 広範囲にわたる開発作業を対象としている。Dartにはこのような広い範囲のプロジェクトを
> サポートするためのオプションが用意されている。

> つまり、プログラマーは型を定義せずにコードを記述し始めて、後で必要に応じて型を追加することができる。
> Dartは大規模なウェブアプリケーションの記述に非常に適したものになるとわれわれは考えている。


やっぱりそうか。大規模=型か。
531 :デフォルトの名無しさん2011/10/12(水) 00:32:57.96
わかりにくい時は型をちゃんと書けばいいわけで、
型推論は難しく考えず、たんなる型を省略した書き方をしても
型を書いたのと同じ効果があると考えればいいのではないかな。
534 :デフォルトの名無しさん2011/10/12(水) 01:02:55.53
Dartには、動的言語としての強みはあるんか?
オープンクラスとか、メタプログラミングが得意とか

こういっちゃうのは早漏かもしれんけど
Googleって言語に関してはなんというかガッカリさんだな今んとこ
535 :デフォルトの名無しさん2011/10/12(水) 01:21:48.70
あるのか無いのかわからんうちから
がっかりとか言う奴は信用ならんなw
536 :デフォルトの名無しさん2011/10/12(水) 01:41:07.01
コンパイル時メタプログラミング(LispマクロやC++テンプレート等)は無さげ
evalも見当たらない
537 :デフォルトの名無しさん2011/10/12(水) 02:07:04.17
javascriptユーザーのうち使いこなせるプログラマはどれだけいるんだ?
費用対効果から考えて本当にそれらの機能は必要なのか?
なくてもjavascriptだけで書くよか、はるかに苦痛が和らぐから
539 :デフォルトの名無しさん2011/10/12(水) 03:17:57.30
GoogleってJava使ってるらしいけど、
Googleよりもお前のほうが土方じゃね?w
541 :デフォルトの名無しさん2011/10/12(水) 04:01:36.65
でもBak氏はこう言っているわけで。

> 以下は、Dartの設計目標に関するBak氏の簡単な説明である。

> つまり、プログラマーは型を定義せずにコードを記述し始めて、後で必要に応じて型を追加することができる。
> Dartは大規模なウェブアプリケーションの記述に非常に適したものになるとわれわれは考えている。
542 :デフォルトの名無しさん2011/10/12(水) 05:07:23.79
斬新な機能とか不要って事でしょう。
スクリプト言語で型が指定出来ればそれで十分だよね、っていうのがGoogleの答えだ。
俺はこれで十分だと思う。
クールな機能はいらないから、マルチプラットホームな実行環境・開発環境、バージョンアップ後も安心して使える互換性、過去バージョンも含んだバグフィックス、ドキュメント整備、そういうのを高めてほしい。
既存のスクリプト言語ってそういうのがダメじゃん。
543 :デフォルトの名無しさん2011/10/12(水) 05:58:21.89
529: デフォルトの名無しさん [sage] 2011/10/12(水) 00:25:49.74
http://japan.cnet.com/news/service/35008825/

> 以下は、Dartの設計目標に関するBak氏の簡単な説明である。

>  Dartは、1人のプログラマーによる、特に構造を意識しないプロジェクトから、
> コード内にプログラマーの意図を記述する為に定型が必要となる大規模プロジェクトまで、
> 広範囲にわたる開発作業を対象としている。Dartにはこのような広い範囲のプロジェクトを
> サポートするためのオプションが用意されている。

> つまり、プログラマーは型を定義せずにコードを記述し始めて、後で必要に応じて型を追加することができる。
> Dartは大規模なウェブアプリケーションの記述に非常に適したものになるとわれわれは考えている。


やっぱりそうか。先端的開発=動的型か。
544 :デフォルトの名無しさん2011/10/12(水) 07:18:19.13
dartは型推論がなければ俺は絶賛した
ぎりぎりでストライクをはずれた
このおっさんはvarを取り入れたことを後悔すると思う
それでも現状でpython ruby javascriptよりも
圧倒的に上の言語だという評価はする
546 :デフォルトの名無しさん2011/10/12(水) 07:44:16.63
>>544
varはDynamic型(どんな値を入れても静的型チェッカーが警告を出さない型)になるだけで
型推論するとは書いてない。
545 :デフォルトの名無しさん2011/10/12(水) 07:27:04.34
静的型検査なんてオプションでいいし、不完全でもいいと判断したわけだよね、Googleは。
どうせ実行してテストするからね。
549 :デフォルトの名無しさん2011/10/12(水) 08:41:36.35
Dartが静的型付けをサポートしたんで
動的型付け厨房が焦ってるなw
555 :デフォルトの名無しさん2011/10/12(水) 12:02:06.08
>>549
ぬるぽのあるJavaでも満足出来る人にとっては
Dartのなんちゃって静的型チェックでも満足なんだろうね
556 :デフォルトの名無しさん2011/10/12(水) 12:17:24.39

          | | ガガガガガッ
          | |
          人
           <  >_∧∩
          人`Д´)/ ←>>68
           <  >_∧∩
          人`Д´)/ ←>>91
  ∧_∧   <  >_∧∩
  ( ・∀・)   人`Д´)/ ←>>323
 と    )  <  >_∧∩
   Y /ノ    .人`Д´)/ ←>>323
    / )    <  >_∧∩
  _/し' //. V`Д´)/ ←>>555
 (_フ彡       /
550 :デフォルトの名無しさん2011/10/12(水) 08:48:06.78
型は記述を必須にして評価はしなくてもいい
開発ツールと可読性向上のための必須コメントというポジション
varはこれを汚した、絶対に許さない
551 :デフォルトの名無しさん2011/10/12(水) 09:06:11.21
隣家の夫婦のセックス現場を盗撮するとかの斬新な機能は不要って事でしょう。
552 :デフォルトの名無しさん2011/10/12(水) 10:05:55.52
つまり静的型付け派には「静的型検査至上主義」派と「型注釈至上主義」派がいるわけだな
後者にとってはHaskellやMLの型推論もイケてないんだろう
557 :デフォルトの名無しさん2011/10/12(水) 12:20:43.19
autoがなくても限定された型の中での型推論を式テンプレート使って行うテクニックは存在したよね
560 :デフォルトの名無しさん2011/10/12(水) 13:14:28.67
Googleが型のない言語は大規模開発に対応出来ないと断言した。
この事実は重い。
561 :デフォルトの名無しさん2011/10/12(水) 16:53:52.41
わざわざ型推論なんて面倒なものを実装しなくても、
型無し言語と動的型言語の区別もつかない相手(>>560)なら
動的型+lintでころっと騙されてくれるとGoogleは考えたんだろうね

実際、Java PGの受け皿の予定だろうから馬鹿を騙せれば十分なわけだ
562 :デフォルトの名無しさん2011/10/12(水) 17:10:46.67
小梨は圧倒的に人間的に上だという評価をユーロと米国がする
564 :デフォルトの名無しさん2011/10/12(水) 18:11:27.45
最適化しても大して速くならないか、もしくは最適化に途方もない時間がかかるか
好きな方選べ
565 :デフォルトの名無しさん2011/10/12(水) 18:27:57.48
型を書かなくても静的型チェックできるコード解析ツールすらあるのに、
optional typing で型チェック可能とか言われてもなぁ……
568 :デフォルトの名無しさん2011/10/12(水) 19:21:42.70
そのツールがJavaScriptと互換性が無くて、やむをえず劣化コピーを作ったのかな。
いくら安全でも互換性がなければただの箱。
569 :デフォルトの名無しさん2011/10/12(水) 19:48:23.25
まあ、Pythonは外人が「Pythonにも静的型チェック欲しい」って言ってたりするからな
ニーズがあるからツールも揃うんだろう
同じ事をRubyで言ったら「動的型の理念とはうんぬん……」とか怒られそうだし
570 :デフォルトの名無しさん2011/10/12(水) 20:02:11.17
>>569
あるあるw
571 :デフォルトの名無しさん2011/10/12(水) 20:06:44.06
Pythonは何でもはっきりきっちり書く文化だもんな
大規模なプロジェクトだと静的型で書いてるのと変わらんようなのが多い
574 :デフォルトの名無しさん2011/10/13(木) 00:24:43.41
開発者は言語仕様ばかりに目を向けすぎてる
もっと開発ツールに目を向けて欲しい
auto a=f.create()
こういうのを何度も見てきたから型推論まじむかつく
そんなに二回書くのが嫌なら
int a=new(1)
とでもやって左は省略しないで欲しいものだ

型の宣言がなかったら局所的に見ても、型がわからないからめんどくさい
そういうのに限ってツールが動かないし
言語仕様の拡張で効率を上げる時代は終わったよ
これからは開発ツールで効率を上げる時代
開発ツールを作りやすい言語が生き残る

そのための型だよ
575 :デフォルトの名無しさん2011/10/13(木) 00:32:58.65
>>574
お前の環境なんて知らないよ
型推論が適切に使われてないと感じてるなら、お前のチームの
コーディング規約をなんとかしろ

ていうか、型を二回書くのが嫌なんじゃなくて、型を書くのがいやなんです
だけど静的型付けのメリットは享受したいんです
型推論マンセー
576 :デフォルトの名無しさん2011/10/13(木) 00:36:45.71
>>574
>これからは開発ツールで効率を上げる時代
>開発ツールを作りやすい言語が生き残る

つまり Smalltalk最強、ということですね
1980年代から統合化開発環境の進化は停滞しているな....
577 :デフォルトの名無しさん2011/10/13(木) 01:06:47.99
>>576
そんなのベンダ側の思惑か、そういうのに慣らされてるだけだろ
型計算できちゃうほどのバリバリ高コスト型推論派とかRTTIイラネ派が
ツール作れないという理由で隅に追いやられてる
581 :デフォルトの名無しさん2011/10/13(木) 05:58:41.88
>>574
テンプレートはどうするの?
template <typename T> ... T a = T::create(); ...
この T が何なのか、型がわからないからめんどくさいというのか
582 :デフォルトの名無しさん2011/10/13(木) 06:33:24.38
>>574
> int a=new(1)

動的型と静的型の区別がつくようになってから出直してこい
583 :デフォルトの名無しさん2011/10/13(木) 07:08:12.15
>>581
プリミティブ型を捨てて
int float stringなんかはinterfaceにする
interface int
class int8:int
みたいなので十分
int n=new int8(123)
シンタックスシュガーとして
int n=123
となればいいだけ
弱い型付けでキャストなしにすればダウンキャストは無視できる

俺から見て難読すぎるテンプレートライブラリは最悪のモンスターだった
可読性を落としてツールにやさしくない便利な機能よりも
#defineの方がましだった

ちなみに高速化は並列でやる時代
遅いならOpenCL使えばいい
高速化を目的としてテンプレート使ってる人は考え直すべき
時代が変わった
589 :デフォルトの名無しさん2011/10/13(木) 09:01:45.32
>>583
時代が変わるというなら、自然言語を早くなんとかしないと。
自然言語は野放しにしているくせに、
プログラムの構文を「最悪のモンスター」という、そういう暴言をやめさせるのが先だ。
610 :デフォルトの名無しさん2011/10/13(木) 22:02:46.07
>>576
> ていうか、型を二回書くのが嫌なんじゃなくて、型を書くのがいやなんです

初めて聞く意見だな。
二回書くのが嫌だとばかり思っていたが。

所で聞きたいのだが、型を書かないで
どうやって特定の型のオブジェクトを生成するんだい?
578 :デフォルトの名無しさん2011/10/13(木) 01:13:45.52
慣らされているは思考停止、または甘え
普及か需要を得からはじめてただの愚痴から昇格可能
579 :デフォルトの名無しさん2011/10/13(木) 01:21:16.87
動的型付け言語のプロジェクトに参加させられると
猿になった気分になる
580 :デフォルトの名無しさん2011/10/13(木) 04:15:29.40
インタプリタ言語がなぜ型を導入しないか
実際に作ればわかる、型を使わないで動くものができるから
interfaceに関しても同じ、型がなくても動くから
ない方が楽に実装できる
つまりまともに設計せずに実装しながら適当に仕様を決めたら
今のメジャーなスクリプト言語の出来上がり
インタプリタにとって型は動作に必要ないコメントだが
型はプログラムに意味を与える最重要なコメントでもある
それを省略してすばらしいなんてなるわけがない
人や開発ツールのために型は強制すべきだった
584 :デフォルトの名無しさん2011/10/13(木) 07:25:41.68
へー、型推論や多相型を無くすかわりに型付け弱くするのか?
明らかに安全性とは逆の方向性だなw

つーか、型注釈の有無は静的型/動的型と関係ねーだろ
馬鹿じゃないの?
585 :デフォルトの名無しさん2011/10/13(木) 07:53:47.50
安全はツールで確保
ツールを作りやすくするための型
つまり安全性を後付で拡張できる言語仕様を超えた安全性

安全性には価値があるけど静的型や動的型の区別なんてどうでもいいよ
頭が固いんじゃないの
人格否定や挑発ばかりやってるとバカになるよ
588 :デフォルトの名無しさん2011/10/13(木) 08:05:32.19
ツール使わずともアノテーションなりメタデータなりでいくらでも拡張可能だし
コンパイル時間を気にしなければTMPのような型計算で静的チェックは可能
そのほうがポータビリティもあるんじゃないか?
ツールで処理すべきなのはちょっと厳しい環境向けだと思うね
たとえばSTLのイテレータのトロさが問題になるケースとか
590 :デフォルトの名無しさん2011/10/13(木) 09:12:04.69
Netbeans使っていると型を意識した補完をしてくれるんだな。
動的言語・静的言語の違いよりも、
IDEで開発するかエディタで開発するかの違いが大きいと思う。
591 :デフォルトの名無しさん2011/10/13(木) 10:17:48.96
Anders HejlsbergがC#で作ったコンポーネントをJavaScriptからシームレスに使えるというデモで
VSがコンポーネントの型情報を使ってJSで完璧なインテリセンスを実現してるのを、静的型のパワーだ
と言って笑いを取ってた
592 :デフォルトの名無しさん2011/10/13(木) 10:49:18.58
>>591
いつのデモだか知らないけど、MSのJSはずっと昔からIDispatchExだし、JSへの公開もIDispatchを必要とする。
.NetのObject型である「_Object」型もQIでIDispatchとれるし、IDispatchからITypeInfoとって補完なんていうのはクラシックVBのテクノロジ。
いまさらドヤ顔でやるようなデモじゃない気がする。
593 :デフォルトの名無しさん2011/10/13(木) 11:25:28.51
http://channel9.msdn.com/events/BUILD/BUILD2011/TOOL-816T
これかな
技術というより言語とIDEの宣伝
602 :デフォルトの名無しさん2011/10/13(木) 19:04:00.77
Dartに比べたら>>593のasyncの方がよっぽど先進的だわ
596 :デフォルトの名無しさん2011/10/13(木) 14:35:50.68
なんかMSの技術ってここ10年本質的に進歩してないような気がする
.Netに見るべきところがあるとすれば、部分信頼モデルくらいじゃない?
598 :デフォルトの名無しさん2011/10/13(木) 17:50:53.97
>>596
本質的に進歩した技術ってこの世に有ったっけ
599 :デフォルトの名無しさん2011/10/13(木) 18:05:48.22
「本質」だなんて無定義語は、「ぼくのかんがえたさいきょうの」と置き換えても意味は同じだな。
600 :デフォルトの名無しさん2011/10/13(木) 18:13:27.52
本質って言葉はバズワードって言葉ができる前からバズワード
601 :デフォルトの名無しさん2011/10/13(木) 18:39:44.01
本質を抽象する

もし「抽象」が無定義語でなければ
抽象するモノ (目的語) のことを本質と定義できる
603 :デフォルトの名無しさん2011/10/13(木) 19:15:41.98
快適にプログラミングできるなら
本質的な進歩でなくてもいい
605 :デフォルトの名無しさん2011/10/13(木) 20:08:54.29
型を書くのを省略できるのは
快適なプログラミングへの第一歩
606 :デフォルトの名無しさん2011/10/13(木) 21:20:35.72
型を省いてもIDEの補完がお馬鹿さんにならないのであれば考えても良い。
608 :デフォルトの名無しさん2011/10/13(木) 21:32:42.63
変数の型とオブジェクトの型が二つあるのややこしいやん
静的型付けも構造的部分型が主流になればいいのに
617 :デフォルトの名無しさん2011/10/13(木) 23:11:26.99
>>608
完全に同意
612 :デフォルトの名無しさん2011/10/13(木) 22:34:51.28
でも、createの中で書いてるでしょ。
614 :デフォルトの名無しさん2011/10/13(木) 22:50:01.67
>>612
createが返すのが例えばクロージャだったら?
中で型を書いてるとは限らんだろ
613 :デフォルトの名無しさん2011/10/13(木) 22:43:50.63
型は値の範囲()
型はドキュメント()
型は仕様()

パラメトリシ(笑)
615 :デフォルトの名無しさん2011/10/13(木) 22:52:42.04
ソフトウェアがクロージャだけで作れるのならそれでもいいが、
クロージャ以外だと型書いてるでしょ。
616 :デフォルトの名無しさん2011/10/13(木) 22:53:04.96
つーか、クラスを定義しなくても直接オブジェクトを生成できる言語も在るじゃん
623 :デフォルトの名無しさん2011/10/14(金) 08:38:11.97
IDEの補完程度では言語の差を埋められないのが良くわかる
624 :デフォルトの名無しさん2011/10/14(金) 13:33:52.46
テンプレートとかジェネリックを除けば
型書くのは苦というほどめんどくさくはないな。
メリットも大きいし、書いたほうがいい。

動的型のメリットは小さく、型推論は重い。
625 :デフォルトの名無しさん2011/10/14(金) 15:54:52.45
コボラーがCOBOLを「書くの面倒じゃないし、読みやすい」って言うのと一緒だね
626 :デフォルトの名無しさん2011/10/14(金) 18:07:54.63
> 型推論は重い。

何が重いの?コンパイル?時間計って比較したの?
629 :デフォルトの名無しさん2011/10/14(金) 19:24:31.61
>>626
動的言語の最適化時の型推論と
束縛時やマッチング時の型推論じゃまったく意味が違うからな
どっちの話してるのかよくわからんが一般に前者は軽くて後者は重いだろうな
627 :デフォルトの名無しさん2011/10/14(金) 18:15:54.48
(一行いくらで単価計算される土方仕事では行数が稼げるから)メリットも大きいし、(型を)書いたほうがいい。
628 :デフォルトの名無しさん2011/10/14(金) 18:49:06.43
ドカタ仕事だとロリロリなようじょの顔見れるからドカタ仕事のほうがいいよ。
630 :デフォルトの名無しさん2011/10/14(金) 19:30:07.91
何言ってんだろこいつ
型書かない方が文字数少なくて済んで、行数稼げるだろ
632 :デフォルトの名無しさん2011/10/14(金) 19:44:22.10
強い静的型を持つ言語では型レベルプログラミングが熱い
636 :デフォルトの名無しさん2011/10/14(金) 20:15:24.37
>>632
強力なチェックをかいくぐる抜け道を作ってるだけだったりして。
そんな政治的なプログラミングは嫌だ。
638 :デフォルトの名無しさん2011/10/14(金) 21:05:45.25
>>636
自分が理解出来ないことイコール危険なこと、ですか?
プライドばかり高くて頭悪い人に多いタイプですね。
634 :デフォルトの名無しさん2011/10/14(金) 20:00:58.12
対応するとすればrubyでmethod_missingにフックをかけて滅茶苦茶な事する手法かな
確かsmalltalkでも似たようなものがあったと思う
639 :デフォルトの名無しさん2011/10/14(金) 21:28:53.52
注釈としての型・チェック機構としての型システムという捉え方と
計算基盤としての型システムという捉え方がある
640 :デフォルトの名無しさん2011/10/14(金) 22:43:05.22
今さ、Perlで書かれた糞コードの修正をするという苦行をしてるんだけどさ
関数の引数がハッシュになっているのはまあ許すとしても、
そのハッシュのキーが文字列になってるのってなんなの?

たとえば、こんなの。ハイフンで始まっている文字列。
http://www.futomi.com/lecture/form/cgi-pm.html#s4
> print $q->header(-type=>'image/gif',
> -nph=>1,
> -status=>'402 Payment required',
> -expires=>'+3d',
> -cookie=>$cookie,
> -charset=>'utf-7',
> -attachment=>'foo.gif',
> -Cost=>'$2.00');


なんで定数にしないの?これってPerlの文化?
まさか動的型付け言語って全部こんなんじゃないよね。

キーが不定のものなら仕方ないけど、固定で決まっているようなものを
文字列で指定するのって開発効率下がってしょうがないんだけど。

興味あるだろうから先に言っておく、
俺はJava土方(笑)だから。

説得力ある答えを求む。
645 :デフォルトの名無しさん2011/10/14(金) 23:25:58.81
>>640
固定で決まっているって、なんでわかるの
じつは固定ではない可能性を想定するほうが安全じゃないの
647 :デフォルトの名無しさん2011/10/14(金) 23:32:44.28
>>645
> 固定で決まっているって、なんでわかるの
ソースコード見たから。

ソースコードにもご丁寧に、”文字列で”書いてあるよw
656 :デフォルトの名無しさん2011/10/14(金) 23:52:27.18
>>640なコードをJavaで書く場合、キーワード引数やデフォルト引数が無いかわりに

q.header().with_type("image/gif").with_nph(1).with_status("402 Payment required");

のようなインターフェースを用意するのが一部で流行と聞いた
660 :デフォルトの名無しさん2011/10/15(土) 00:22:18.25
>>640
PerlのCGI.pmってのは、MosaicやCERN httpdみたいに
World Wide Web(WWW)の創成期に作られたコードだから、
今時のモダンなコーディングスタイル基準で批判されるのはカワイソス
WebのCGIを手軽にスクリプティングできる唯一で画期的な存在だったのサ

当時のPerlは文字列処理に特化したシンプルな言語だったから、
明示的な直積型(Cの構造体やOOPLのクラス)に相当するデータ型は無くて、
代わりにハッシュを使って直和構造を表現するのが普通だった

今時そんな古いコード設計の保守をやるのが苦行というのは同情する
おそらく今のPHP/Railsのコードも何年かしたら同じように非難されるんだろう


641 :デフォルトの名無しさん2011/10/14(金) 23:06:33.68
フィールドの頭にアンダーバー付けるようなもんで
何らかのオブジェクトのメンバというのを明示的に書いてるんだろう
結局静的型に戻ってきてるんだな
ただ頭にアンダーバー付けるようなのって静的型でもあんまりよくないスタイルだよなぁ
C++のような言語じゃ規格違反になる場合もあるし
643 :デフォルトの名無しさん2011/10/14(金) 23:10:31.52
>>641
頭のアンダーバーは本質的なところじゃないよ。
両方共文字列扱い。

use strictだかuse warningsだかすると、
アンダーバーがない場合は、
文字列を "" でくくらないでそのまま書くなっていう警告が出る。
アンダーバーつけてればその警告を抑制できるだけ。

header関数の中では両方共文字列として渡される。
671 :デフォルトの名無しさん2011/10/15(土) 00:53:56.09
>>641
>>643
先頭にー(ハイフン)を付けるのは、連想配列のキーが文字列であることを表すため。
Perlは関数の()を省略出来て、連想配列のキーは文字列であっても引用符でくるまなくてもよいので、fooだと関数なのか文字列なのか分からない。
use strictは変数宣言を強制するのに使う。別の話。
644 :デフォルトの名無しさん2011/10/14(金) 23:11:05.76
ってか、つられてアンダーバーって書いたけど
ハイフンなw
646 :デフォルトの名無しさん2011/10/14(金) 23:27:50.55
Perlにはキーワード引数が無いからハッシュで真似してるだけじゃね
650 :デフォルトの名無しさん2011/10/14(金) 23:39:06.39
>>646
じゃあ、他の動的型付け言語なら大丈夫なんですかね。
ハッシュばかり使ってある糞コードながめて、
おいおい、このハッシュ、どんなキーが入ることがあるんだよって、
うんざりすることはないんですかね。

俺はプログラミングをしているのであって
コーダー的な作業に神経を使いたくないのよ。

だから本質的な作業ではないところ(コーディング)で発生するミス、
つまりスペルミスも検出できないようなコーディングスタイルは
大嫌いなんだよね。
651 :デフォルトの名無しさん2011/10/14(金) 23:39:53.89
>>649

>>650で書いたとおり
654 :デフォルトの名無しさん2011/10/14(金) 23:47:23.88
>>640
ハッシュに見えて、実は配列で渡される。
で、key,valueの組と単引数を区別するための識別に使うんじゃないかな。推測だけど。

>>650
-hogehoge => 'wowow!!',
を加えると、wowow!!っつー内容のhogehogeヘッダが追加されるよ。
655 :デフォルトの名無しさん2011/10/14(金) 23:49:44.50
>>650
公平を期するために言うと上の方にも書かれているようにこれは動的言語の問題と
いうよりも名前付き引数を持たない言語で同様のことを模倣した場合の問題だよね。

ただ憤りはよく解る。多分動的言語には無駄にハッシュリテラルを簡単に書ける
言語が多いという点がミソで、そういう言語では無駄にこの手の記述が多用される
ことが多い。jQueryみたいにこの書き方が作法になっているフレームワークも多いし。
APIリファレンスからキー文字列を忠実にコピペする必要があるのは確かに面倒。

逆に簡単に書けないJavaとかだとオブジェクト生成時のbuilderパターンみたいな
手間が必要なのも何とも。
657 :デフォルトの名無しさん2011/10/14(金) 23:53:06.07
>>654
> ハッシュに見えて、実は配列で渡される。
> で、key,valueの組と単引数を区別するための識別に使うんじゃないかな。推測だけど。
うん、そういう使い方をしているものもあるのは知ってる。
ただ、それは定数にしない理由にはなっていない。

> を加えると、wowow!!っつー内容のhogehogeヘッダが追加されるよ。
それは別にそれでいいんだよ。
固定で決まっているものは定数にしとけって話だから。
658 :デフォルトの名無しさん2011/10/14(金) 23:59:24.20
>>656
そうそう。

>>655
命名規則にとらわれず、似せて書けば

> print $q->header(-type=>'image/gif',
> -nph=>1,
> -status=>'402 Payment required',
> -expires=>'+3d',
> -cookie=>$cookie,
> -charset=>'utf-7',
> -attachment=>'foo.gif',
> -Cost=>'$2.00');
これも

q.header().type("image/gif").
nph(1).
status.("402 Payment required").
expires("+3d").
cookie(cookie).
charset("utf-7").
attachment("foo.gf").
extra("Cost","$2.00").print();

こっちも大差ないでしょ?
くだらないミスで時間を取られることもない。
661 :デフォルトの名無しさん2011/10/15(土) 00:23:12.05
>>658
なるほどね。
メソッド名を間違えても実行時にしかエラー検出できないけど、確実性は増す。
662 :デフォルトの名無しさん2011/10/15(土) 00:24:54.52
>>660
Perlでモダンなやり方だとどうなるんだ?

>>661
Javaのコードのつもりで書いたんだけどw
もちろんメソッド名を間違えたらコンパイルエラーでますよ。
663 :デフォルトの名無しさん2011/10/15(土) 00:26:29.23
>>658
名前付き引数がある言語なら

q.header(type = "image/gif", nph= 1, status = "402 Payment required",
     expires = "+3d", cookie = cookie, charset = "utf-7",
     attachment = "foo.gf", extra = {"Cost" => "$2.00"});

みたいなみたいな感じかな。大切なのは記法の違いじゃなくて、キー文字列を
間違えてもコンパイル時か最低でも呼び出し時にエラーではじかれること。

確かにメソッドチェインでパラメータ指定して云々、は安全なのだけれども、
実装が大きくなりがちなのが難点かな。
例えば>>658の下の書き方にしても、headerがimmutableなメソッドなので
あればheaderはqそのものではなくてその後のメソッドチェインで入力された
値を保持する専用のオブジェクトを返す必要があるよね。
そういうオブジェクトのクラスをoptionalな引数の多いメソッドごとに用意する
必要があるわけでこれはこれで面倒。
670 :6612011/10/15(土) 00:41:21.59
>>662
うん、Perlに置き換えたらの話。

一応Class::Structモジュールが古くから標準で入ってる。
モダンにやるならMooseだろうね。
677 :デフォルトの名無しさん2011/10/15(土) 07:02:19.05
>>672
コーディングの手間を減らしたいなら
名前付き引数を持ってる言語を使うべきじゃないか?
言語組み込みの機能は良くテストされてるが、
>>658のような方法は手間がかかるだけでなく
そこにバグが潜む可能性がある
678 :デフォルトの名無しさん2011/10/15(土) 07:38:35.65
>>677
良くテストされたライブラリのAPIとしては>>658の方法も十分にOK。
というか山ほどある。

コーディングの手間だけで使う言語を選べるのであればどれほど楽か。
682 :デフォルトの名無しさん2011/10/15(土) 10:47:38.90
>>677
> コーディングの手間を減らしたいなら
> 名前付き引数を持ってる言語を使うべきじゃないか?

そりゃそうだろうw
だから静的型付け言語を使うべきになるんだよ。
687 :デフォルトの名無しさん2011/10/15(土) 11:03:10.41
>>658のような方法は面倒なだけだと俺も思う。
その言語に名前付き引数機能があればベストだけど、無くてもそのメソッド内で引数のハッシュをバリデーションすれば良い。
その時にPerlならParams::ValidateとかSmart::Argsとか使えば比較的簡単にバリデーションできる。
688 :デフォルトの名無しさん2011/10/15(土) 11:05:24.90
>>687
ただし、それらは実行時にならないとわからないのが問題。

実行時にならないとわからないのと
実行前にわかるのとでは、大きな差がある。
692 :デフォルトの名無しさん2011/10/15(土) 11:57:15.73
>>688
一度も実行されてないコードをリリースするの?
693 :デフォルトの名無しさん2011/10/15(土) 11:59:10.09
>>692
なんでいきなりそんな話になるの?

アメリカにつくのであれば、
早くても遅くても交通手段は関係ないという発想の人?
649 :デフォルトの名無しさん2011/10/14(金) 23:37:39.67
キーワード引数やオプション引数そのものを批判してるのか、
上記の機能をハッシュでエミュレートしてるのを批判してるのか、
ハッシュのキーにmutableオブジェクトを使ってるのを批判してるのか、
あるいはそれ以外なのかが分からない
652 :デフォルトの名無しさん2011/10/14(金) 23:42:00.27
Pythonはキーワード引数がある
Rubyはキーワード引数は無くてハッシュ
PHPは知らない
659 :デフォルトの名無しさん2011/10/15(土) 00:00:15.35
>プライドばかり高くて頭悪い人に多いタイプですね。
反論できなくなったら人格攻撃に走るのは
敗北を認めたことになりますよ
プライドばかり高くて頭悪い人に多いタイプですね。
664 :デフォルトの名無しさん2011/10/15(土) 00:30:33.17
> みたいなみたいな感じかな。大切なのは記法の違いじゃなくて、キー文字列を
> 間違えてもコンパイル時か最低でも呼び出し時にエラーではじかれること。

そうそう。ハッシュと同じでメソッドも同じでコンパイル時に弾かれて欲しい。
ただし実行時は遅すぎる。
それが出来る言語なら何でもいいよ。

最初に定義する必要があるとか、そんなのは一回書けば済む話なので
面倒だとは思わない。

普通は定義されたものを”使う方”が複数回あるわけで
なんどもタイプしてると絶対ミスる。
665 :デフォルトの名無しさん2011/10/15(土) 00:32:53.25
そこでIDEやパラメータヒントツールの登場ですよ
引数部分が全部マジックナンバーでtoString可能なら
その一文だけ実行してフォーマット済み文字列を見ることも可能
666 :デフォルトの名無しさん2011/10/15(土) 00:34:03.56
でそうやって、高度な機能を追い求めると
静的型付け言語に分があるんだよな。

実行しないでも分かる=コードを書いているときに分かる だから。
672 :デフォルトの名無しさん2011/10/15(土) 00:58:29.92
俺らはプログラミングをやってるのであって
コーディングをしているわけじゃないからね。

だからこそコーディングの手間は極力減らすという考えにたどり着く。
そのための静的型付け言語。
675 :デフォルトの名無しさん2011/10/15(土) 01:22:28.74
>>672-674
俺が書くのもなんだけど
40秒でレス返すってどんだけ張り付いてるんだよ
673 :デフォルトの名無しさん2011/10/15(土) 00:59:09.26
コーディングに高度な機能を求めるのは、
コーディングが大好きだからじゃなくて
コーディングを極力無くしたいからなんだよ。
勘違いしないでよね。
674 :デフォルトの名無しさん2011/10/15(土) 00:59:50.27
ああやっぱりプログラミング=設計という考え方を盛大に勘違いしている人か
676 :デフォルトの名無しさん2011/10/15(土) 01:26:02.25
>>674
へぇ、なにか意見があるのかい?
なら言ってみたら。
679 :デフォルトの名無しさん2011/10/15(土) 07:47:15.37
つまり自分では名前付き引数を持つメソッドを書かず、
他所様の書いたライブラリを使うのみってこと?

> コーディングの手間だけで使う言語を選べるのであればどれほど楽か。
静的型検査の有無だけで使う言語を選べるのであればどれほど楽か。
681 :デフォルトの名無しさん2011/10/15(土) 09:33:38.95
ていうか、理論上は「変数」に型がなくても「文字列リテラル」は静的に解析できる。
リテラルは変数よりも情報が多いので、変数ばかり解析しているのは勿体ない。
683 :デフォルトの名無しさん2011/10/15(土) 10:51:59.51
理論上は、というか普通のまともな処理系なら文字列リテラルも変数の名前もハッシュ値になるでしょ
684 :デフォルトの名無しさん2011/10/15(土) 10:58:35.16
メタプログラミングを実行時にばっかりに頼る傾向にあるのが間違い。
Perlのコンパイルフェーズに処理を実行できる仕組みをみなすべき。

コンパイル時メタプログラミングを採用すれば、
実行時メタプログラミングの必要性は9割減ると思っている。
691 :デフォルトの名無しさん2011/10/15(土) 11:13:03.74
ハッシュで渡す場合省略可能な引数でなおかつその引数名をタイポで間違えたら
実行時にもエラーでなくて動かして想定と違う動きして初めて分かるとかあるんじゃ?
694 :デフォルトの名無しさん2011/10/15(土) 12:00:14.19
>>691
typoした瞬間に気付けよ
それは早すぎる?
でも実行時は遅すぎるんだろ
中間層は上にも下にも敵がいるから大変だぞ
695 :デフォルトの名無しさん2011/10/15(土) 12:01:54.06
だって、テストコードすら書かなくても、一度実行しさえすれば
動的型言語でも名前付き引数のエラーくらい分かるぜ?

動的型言語はコンパイル必要無いんだから、
コンパイルするかわりに実行してみりゃいいじゃん
手間一緒
696 :デフォルトの名無しさん2011/10/15(土) 12:04:42.16
>>695
だから、それはアメリカにつくのであれば(エラーが解るのであれば)
それが早くても遅くても関係ない人の発想だねって言ってるの。
697 :デフォルトの名無しさん2011/10/15(土) 12:08:13.49
>>696
何で早さに差がでると思ったの?
698 :デフォルトの名無しさん2011/10/15(土) 12:08:18.05
サンプルコードみたいな、ほんの数行のコードであれば
実行すればいいですむかもしれんが、

何千、何万、何十万とあるプロジェクトでは
実行してみるのも大変なんだよ。
だから、簡単に実行できる手段を追い求める。
実行しなくてもわかればなおよし。

根本的に作っているもののスケールが違うんだよね。
699 :デフォルトの名無しさん2011/10/15(土) 12:09:26.43
え?ユニットテストって一部だけ実行できるんだぜ?知らないの?
700 :デフォルトの名無しさん2011/10/15(土) 12:10:12.57
リグレッションテスト?なにそれおいしいの?みたいな会話でちょっと怖いぞ。

マイクロソフト ワイヤレス ブルートラック マウス Arc Touch Mouse RVF-00006
マイクロソフト ワイヤレス ブルートラック マウス Arc Touch Mouse RVF-00006