2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

やっぱり動的型付け言語では安全なソフトは作れない

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
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

                  京都大学霊長類研究所

3 :デフォルトの名無しさん:2011/09/25(日) 03:30:06.71
> 348 名前:デフォルトの名無しさん []: 2011/09/24(土) 17:55:27.86
> もう何度も言われてる事だろうが、静的な型付けの言語ならする必要のないテストまで動的型付けの言語はする必要がある。
>
> 359 名前:デフォルトの名無しさん [sage]: 2011/09/24(土) 23:40:41.13
> >>348
> もう何度も言われてる事だろうが、こういうことを書いて具体例を挙げられたやつを見た事が無い。
> おそらく今回も逃げるだろう。
>
> 360 名前:デフォルトの名無しさん [sage]: 2011/09/25(日) 00:44:06.19
> >>359
> 返り値の内部表現型をチェックするテストでも日々書かされまくってんじゃない


4 :デフォルトの名無しさん:2011/09/25(日) 03:33:45.33
型チェックがあろうがそもそもテストしてない機能は動作保証外なんだから変わらん

5 :デフォルトの名無しさん:2011/09/25(日) 03:42:52.21
> 363 名前:デフォルトの名無しさん [sage]: 2011/09/25(日) 03:38:44.11
> >>359
> Alexに言われるまでもない。
>
> http://www.artima.com/scalazine/articles/twitter_on_scala.html
>
> Alex Payne: I’d definitely want to hammer home what Steve said about typing.
> As our system has grown, a lot of the logic in our Ruby system sort of replicates a type system, either in our unit tests or as validations on models.
> I think it may just be a property of large systems in dynamic languages, that eventually you end up rewriting your own type system, and you sort of do it badly.
> You’re checking for null values all over the place.
> There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.”
> It is a shame to have to write all that when there is a solution that has existed in the world of programming languages for decades now.

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 :uy:2011/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
それは不可能だよ。
定義がなければ、間違っていることはわからない。

12 :デフォルトの名無しさん:2011/09/25(日) 15:41:24.12
変数宣言の有無 ≠ 型宣言の有無

13 :デフォルトの名無しさん:2011/09/25(日) 15:42:16.29
スペルミス程度ならあるいは可能かもしれないけど、実行前に型の誤りを見つけるのは無理だろ>動的

14 :デフォルトの名無しさん:2011/09/25(日) 15:46:18.58
メソッドを呼び出した時の戻り値がちゃんと仕様を満たしているか把握すんのは動的型付けじゃ難しい

15 :デフォルトの名無しさん:2011/09/25(日) 15:52:53.14
カバレッジ90%超えるならテストで見つかる v.s. カバレッジ60%超えるぐらいなのが現実

16 :デフォルトの名無しさん:2011/09/25(日) 15:58:36.92
静的型付け厨が嫌うのはテスト範囲外の動作が不安で不安で仕方ないからなんだろ

じゃ問題になるのはテスト範囲外の動作で停止したらどうするのが正しいのか。

17 :デフォルトの名無しさん:2011/09/25(日) 16:18:01.17
>>14
それ、現段階じゃ静的型でもほぼ不可能だし。

18 :デフォルトの名無しさん:2011/09/25(日) 16:20:04.83
>>14
静的型ったって、返り値の型ぐらいしか保障されない。
整数が返り値だとして、それが期待されている「範囲内の」整数かどうかなんて
静的型はこれっぽっちも保障してくれない。

くやしかったらゼロ除算が絶対に発生しない言語でもつくってみろ。

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の様な形で静的型づけでも実現されてるし。

22 :デフォルトの名無しさん:2011/09/25(日) 16:39:18.36
>>18
お前はなにを言ってるの?

23 :デフォルトの名無しさん:2011/09/25(日) 16:47:53.34
>>18
静的型付けであれば、自分がオーバーライドしたメソッドが、
どんな仕様を満たさなければならないか、把握してる。

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

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

24 :デフォルトの名無しさん:2011/09/25(日) 17:03:25.36
ようは、(コメントやドキュメントじゃなくて)コードの中に
アプリケーションの仕様を記述できる量が多いってことなんだよな。
静的言語っていうのは。

25 :デフォルトの名無しさん:2011/09/25(日) 17:06:21.91
ばかじゃねーの
んなもん静的型付け/動的型付けなんて関係ないだろ
動的型付けだと仕様をコードに記述出来ない理由があるのか?

26 :デフォルトの名無しさん:2011/09/25(日) 17:07:38.07
コードとドキュメントの両方を同期させてメンテナンスするのは
同じ事を二度書くということで、KISSの考えに反するんだよね。

27 :デフォルトの名無しさん:2011/09/25(日) 17:08:45.29
>>25
よく読んでね。

出来る出来ないなんて一言も言ってない。
静的言語のほうが、”多い”って言ってるの。

28 :デフォルトの名無しさん:2011/09/25(日) 17:08:46.10
それ以前に合意外のコードを簡単に書ける。

29 :デフォルトの名無しさん:2011/09/25(日) 17:13:15.23
動的言語でも「変数は宣言してから使いましょう」って考えは同じだろう。

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

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

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





まあ、結局、これと同じなんだよ。宣言してから使ったほうが間違いが減る。
それは変数に限るわけがなく、型とかインターフェースとか、
変数の宣言と同じ理由で、宣言してから使ったほうが間違いが減るんだよ。

30 :デフォルトの名無しさん:2011/09/25(日) 17:20:22.55
宣言はめんどくさい

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的な機構が必要
みたいな議論にならんものか。

34 :デフォルトの名無しさん:2011/09/25(日) 18:12:56.05
Classboxって何?

35 :デフォルトの名無しさん:2011/09/25(日) 18:15:35.54
クラスにパッチ当てて修正/拡張するときに、それが効く範囲を限定できる。
一種の名前空間。

36 :デフォルトの名無しさん:2011/09/25(日) 18:20:22.13
実行時メタプログラミングは動的言語スレの方のねたじゃないか?
ここは型安全ネタのすれだからな

37 :デフォルトの名無しさん:2011/09/25(日) 18:22:21.77
ああそうか。スレ違いだった。

38 :デフォルトの名無しさん:2011/09/25(日) 18:58:26.15
>>23
> 静的型付けであれば、自分がオーバーライドしたメソッドが、
> どんな仕様を満たさなければならないか、把握してる。

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

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

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

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

型がわかる程度じゃ意味ねえよ!
静的厨の言う安全性/健全性って、この程度の浅いものなの?バカなの?

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とかいう形で
いちいち独自に型指定してて面白いよ、コンパイル時か実行時か知らんけど常に
境界チェックやってるんだろうな

42 :デフォルトの名無しさん:2011/09/25(日) 20:05:43.80
型検査だけで70%もカバーできるわけねえだろw
静的型厨ってどこまで楽観的なんだか…

43 :デフォルトの名無しさん:2011/09/25(日) 20:07:01.69
>>41
コンパイル時に検査できると思うほど馬鹿なわけ?
実行時の検査なら動的型だってできるぜ?

44 :デフォルトの名無しさん:2011/09/25(日) 20:15:23.00
>>42
いや、動的型言語で組んだら全バグの70%が実行時型エラーになったのかもしれんぞwww
そんな馬鹿なプログラマには会った事無いけどw

45 :デフォルトの名無しさん:2011/09/25(日) 20:26:18.65
開発中のケアミスも含めれば、
静的検査で見つかるものは多い。

46 :デフォルトの名無しさん:2011/09/25(日) 20:29:07.06
>>43
そりゃ全部コンパイル時にチェックするのは無理だろうよ
ただ、関数fの引数型Numberがrange 1..12と定義されていれば、
とにかく実行時だろうがその範囲外の入力は弾かれるし、
f(13)みたいな呼び出しはコンパイル時にエラーにすることが可能なわけだべ?

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

別に静的型の型チェックでプログラミングエラーを全て無くせるなんて話は誰も
してないと思うけど

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;//代入可

48 :デフォルトの名無しさん:2011/09/25(日) 21:00:19.65
Int<0,2> a;
Int<0,2> b;
Int<0,5> value = Int<0 + 0, 2 + 2>(a + b);

Int<0,2> a;
Int<0,2> b;
Int<0,5> value = Int<0 * 0, 2 * 2>(a * b);

Int<0,2> a;
Int<0,2> b;
Int<0,5> value = Int<0 / 0, 2 / 2>(a / b);

Int<0,2> a;
Int<0,2> b;
Int<0,5> value = Int<0 % 0, 2 % 2>(a % b);

割り算はマズそうだが、そもそも0割状態になることが問題か

49 :デフォルトの名無しさん:2011/09/25(日) 21:03:05.30
0に関しては-n〜nを表現しなきゃならないから
0状態だけはコンパイルエラーとなるNZInt型でも作らなきゃならんだろ

50 :デフォルトの名無しさん:2011/09/25(日) 21:23:43.28
>>38 は不変条件だのなんだの書いてるが、そんなもの範囲付き型検査で済むから
本当に言いたいのは、そういう話じゃないんだろうな。sin関数が正弦を返してないとか
そんな話なんだろ。でもそれは型チェック云々の範疇じゃなくていいと思うが。


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かな

56 :デフォルトの名無しさん:2011/09/25(日) 22:26:31.40
さて、どうでるかw

57 :デフォルトの名無しさん:2011/09/25(日) 22:26:34.72
>>53
俺はJava

58 :デフォルトの名無しさん:2011/09/25(日) 22:27:18.78
Java一択

59 :デフォルトの名無しさん:2011/09/25(日) 22:29:51.00
Java大人気だなwww

60 :デフォルトの名無しさん:2011/09/25(日) 22:30:58.98
C++,C#,Delphi

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
> 配列使うと簡単に型安全じゃなく出来るとか
ほう、具体的どういうことなのか
君が知っていることのすべてを教えてくれ。

64 :デフォルトの名無しさん:2011/09/25(日) 22:37:46.85
これがコンパイルエラーにならない

Object[] x = new Integer[1];
x[0] = new String();

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); //コンパイルエラー

ここでエラーが発生するから十分型安全なわけだけど

67 :デフォルトの名無しさん:2011/09/25(日) 22:46:32.20
まあ、「静的な」型安全性って言わないとダメだったね。
でも、これで実行時にArrayStoreExceptionが出ても型安全だと主張するなら、
動的型言語も完全に型安全だわwww

68 :デフォルトの名無しさん:2011/09/25(日) 22:55:16.66
>>66
ぬるぽに比べたら些細な問題だな

69 :デフォルトの名無しさん:2011/09/25(日) 22:59:54.52
何度も言ってるけど、量の問題であって、
静的言語のほうが、見つけられることが多いのなら
抜けがあったとしても、優れているんだよ。

70 :デフォルトの名無しさん:2011/09/25(日) 23:01:32.05
>>54
> 静的言語でも動的言語でも何でも使うよ。
> でないと動的言語よりも静的言語のほうが
> すぐれてるってわからないだろ。

どんな動的型言語を使ってるの?

71 :デフォルトの名無しさん:2011/09/25(日) 23:05:06.14
Java固有の話しなんざどうでもいいわ

72 :デフォルトの名無しさん:2011/09/25(日) 23:28:27.07
Javaはinterfaceで表現できるからって
constを導入しなかったのが失敗だったな。
const配列の場合のみ配列間のアップキャスト可能というなら
ArrayStoreExceptionは発生しなかった。

73 :uy:2011/09/26(月) 03:07:45.81
>>8
で、キチガイこんなにいんの?wwwwwwww

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


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

初心者っていうか、何?
専門学校入って、半年目なんだけど、学校サボっちゃっててぜんぜん知識身についてないような
そんな感じの奴か

74 :デフォルトの名無しさん:2011/09/26(月) 04:54:16.94
>>69
はっきり言って、誤差の範囲内。
むしろ、型エラーを取っただけでバグがなくなったと安心するバカがいる分、
静的型のほうが危険とも言える。

75 :デフォルトの名無しさん:2011/09/26(月) 04:56:47.08
>>54
動的言語ったって、どうせルビーとかピーエッチピーとかでしょ?
パール?えらいでちゅねーww

76 :uy:2011/09/26(月) 16:49:33.51
>>54
「バカは効率がわからない」

77 :デフォルトの名無しさん:2011/09/26(月) 19:19:27.32
>>74
型まわりは、メモリ状態によっては正常に動いてしまったりして
というか正常に動いてしまうケースの方が多かったりで、
見つけるのに結構手間どる場合があるから、コーディング時に
多少キーボードを叩く回数が増えてても、リリース後の深夜に
電話で呼び出されたり、リリース直前に謎バグで徹夜したりする確率を
下げたい人は、静的型付け、その逆に、修羅場になると寧ろ燃えて
生き生きするタイプは、動的型付けを使うと良いんじゃないかな。

78 :デフォルトの名無しさん:2011/09/26(月) 19:22:51.08
> メモリ状態によっては正常に動いてしまったりして

C/C++かよw
笑わせんなバカwww

79 :デフォルトの名無しさん:2011/09/26(月) 20:17:54.28
>>77
動的型言語は型安全だバカ

80 :デフォルトの名無しさん:2011/09/26(月) 20:38:01.38
大体動的言語は仕事無いだろ
>>75
が言うような動的言語は仕事有るが
でも動的厨からみたら話にならないんよね!!!!ね?>>75

uyくん、君に土方(笑)とかいう意見は求めてないからね!
キリッ!!!とかいうのも結構です

81 :デフォルトの名無しさん:2011/09/26(月) 21:00:02.39
>>80
いやいや、そういうのもいいから、早く使った事のある動的型言語を書いてよ。
使った事なきゃ比較できないって>>54も言ってるしね。
使った事あるんでしょ?

ま、どうせ100%逃げるだろうけどw

82 :デフォルトの名無しさん:2011/09/26(月) 21:08:57.01
Rubyistですすいませんでした

83 :デフォルトの名無しさん:2011/09/26(月) 21:11:40.64
わろた

84 :デフォルトの名無しさん:2011/09/26(月) 21:15:17.84
>>82
Rubyでは安全なソフトは作れないと思ってるってこと?

85 :デフォルトの名無しさん:2011/09/26(月) 21:30:21.94
Perlerだがそう思う

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++だと定義と宣言があって、定義をチェックできなくても宣言をチェックできる。

88 :デフォルトの名無しさん:2011/09/26(月) 23:43:04.37

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

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

それとも、今考えたのかい?


89 :デフォルトの名無しさん:2011/09/26(月) 23:56:28.64
Perlは基本的に変数を定義して書くものだよ。そうでないように設定も出来るけど、商用レベルでそうする事はほぼ100%ない。
配列、連想配列、その他の3つしかないけど、一応型も定義出来る。
RubyやPythonよりはマシ。
Perl6になると、完全に静的型付けで書けるし。


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

ってことだよな

91 :デフォルトの名無しさん:2011/09/27(火) 00:08:21.04
>>90
ぬるぽを除く

92 :デフォルトの名無しさん:2011/09/27(火) 01:04:51.40
いやこれを遅延バインディングっつーのはなんか言葉がおかしかったな
まあいいかー

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を実行時に決定するなら
コンパイル時に全ての候補を見つける事はできない

97 :デフォルトの名無しさん:2011/09/27(火) 07:51:32.27
>>82-85
動的厨涙目

98 :デフォルトの名無しさん:2011/09/27(火) 09:09:33.65
Java厨必死だな

99 :デフォルトの名無しさん:2011/09/27(火) 09:28:07.06
>>93
いや、型の隠蔽、実装の隠蔽、あるいはインタフェースと実装の分離と表現されるけど
普通に
GOFだってそう

>>94
実行時に実際のオブジェクトなり型なりが分からないんなら、そもそも
メソッド呼べんでしょ……
実行時には当然確定するし、分かる
静的には確定していないからポリモーフィズムなのであって

100 :uy:2011/09/27(火) 13:24:20.99
>>54
こいつみたいに、

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

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

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

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


あまりにもバカなこといわれると、あまりにバカすぎてふらつくわ
最近じゃ小学生でもこの板出入りしているんだろうしなぁ・・・ 2chはもう議論の場として終わり

101 :デフォルトの名無しさん:2011/09/27(火) 17:37:58.18
>>100
jkかuyかしらんが
>いちいち相手すんの疲れるよね
だったら、一言でいいんじゃない?1分か2分それ以上かけてコメントする
ほどでもなかろう

102 :デフォルトの名無しさん:2011/09/27(火) 20:47:10.96
>>96
そういうことじゃないよ。

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

遅延バインディングとか、ポリモーフィズムとか、
それは実装がわからないだけで、定義されていることは分かるだろ。

103 :デフォルトの名無しさん:2011/09/27(火) 21:45:47.41
おいおい、宣言と定義の違いすら分かってないのかよ

104 :デフォルトの名無しさん:2011/09/27(火) 22:03:10.44
>>102
何を言ってるのかぐちゃぐちゃすぎて俺にはさっぱりだぜ
まあ言いたいことはなんとなく分かるけど

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

そういう意味では確かに実体の定義は隠蔽はされているんだが、
「定義を隠す」っていう言葉遣いはあんまり聞いたことが無いな
普通は「実装を隠す」という言い方をすることが多い
abstraction(抽象化)はプログラミングの鍵なので、本質的には
OOPに限った話ではない

105 :デフォルトの名無しさん:2011/09/27(火) 22:17:26.50
全然流れを読んでないが例えば下のコードだと、
実装は不定と言う方が自然じゃなかろうか。

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

unix.Control( phisical_machine );
unix.Control( virtual_machine );

106 :デフォルトの名無しさん:2011/09/27(火) 23:07:40.27
おいおい、定義を隠すと言い出したのは俺じゃなくて >>87だぜ。

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

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

その違いがわからない。

108 :デフォルトの名無しさん:2011/09/27(火) 23:18:00.87
変数はスコープの問題だろ。
定数や関数は、無限ループや、意図しない分岐ミスを誘発しないが
変数はそれを起こす。

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()は引数を数値に変換する関数ね)

111 :デフォルトの名無しさん:2011/09/28(水) 03:00:48.57
で?っていう

112 :デフォルトの名無しさん:2011/09/28(水) 08:48:49.13
>>107
定義すれば宣言はしなくて良いよ
メソッドは「どこか遠くで定義されているからここでは定義しない」ってケースが多い
変数は「地産地消」

113 :デフォルトの名無しさん:2011/09/28(水) 09:14:22.80
だねー

メソッドはインタフェースだけど、変数はローカルなもの

114 :uy:2011/09/28(水) 11:20:20.04
>>101
ゴミは
潰さないと、さ。

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

ゴミの勘違いを放置すんなゴミ  放置するから、そのまま冗長して、すっげーとんでもない場所で、バカみたいなことしゃべっちゃうゴミになっちゃうんだよ・・・・

115 :デフォルトの名無しさん:2011/09/28(水) 17:16:16.27
>>109
>動的型でもx, yは暗黙に加算ができる
>オブジェクトとプログラマは仮定しているが
プログラマによるだろう。
JavaScriptの例だと、typeofする関数群使って、
各オブジェクトのプロパティをeveryで回したり、
数値計算では文字列は parseInt とかに通したり、
evalしたいならsandboxつくる。

これぐらいの発想は当たり前だよ。
想像で語ってる人が思いの外多いような気がする。

116 :uy:2011/09/28(水) 17:51:07.56
>想像で語ってる人が思いの外多いような気がする。

それ、いまさらって感じ

このスレかなり素人混ざりこんでるよ
このム板の平均レベルそのものも低いが、その中でもさらに下の下の下種がきてる
正確には下の中くらいだけど

117 :デフォルトの名無しさん:2011/09/28(水) 19:20:02.14
静的なら機械がチェックするところを、
動的だとプログラマ側のそういった工夫が必要なのか。

118 :デフォルトの名無しさん:2011/09/28(水) 19:46:11.13
機械がやるから手間も要らないし、抜けも無いわけだ

119 :デフォルトの名無しさん:2011/09/28(水) 20:23:41.91
そりゃ動的型言語は静的型検査の代りに
実行時に型システムを拡張できる自由を得たわけで、
静的型言語と同じように書いてたらデメリットしか無いだろ

昔、OOPがまだ受け入れられてなかった頃、
C上がりのプログラマがCと同じようなコードを書いて、
OOPは遅いだけでメリットが無いと言ってたが
言語/パラダイムが変わっただけで全く同じ構図だな

120 :デフォルトの名無しさん:2011/09/28(水) 21:05:01.74
機械ならどれでもよかった。反省はしていない。

121 :デフォルトの名無しさん:2011/09/28(水) 21:41:51.50
>>116
お前何様だ?
LLで組んでるならそれぐらいの動作を考える、と言っただけで、
プログラマとして下だ上だなんて主張はしていない。

>>118
それを言ったら極論として型安全性の高い言語が優秀になってしまうのでは…。
でも人間の言うバグがなくなるわけじゃない。


122 :デフォルトの名無しさん:2011/09/28(水) 22:16:36.20
ちゃんと動くのにコンパイラが型エラーで弾いたりするけどな。
くやしかったらYコンビネータに型をつけてみろw

123 :デフォルトの名無しさん:2011/09/28(水) 23:18:10.32
http://r6.ca/blog/20060919T084800Z.html

124 :uy:2011/09/29(木) 02:24:05.41
>>121
話しかけんなよ気持ち悪い

125 :デフォルトの名無しさん:2011/09/29(木) 02:48:31.93
>>121
型安全性の高い言語の弱点「記述が冗長」をIDEで補う、これ最強。
人間はただでさえ間違いを犯しやすいんだから、機械でチェックできるところは
機械にやらせるのがよし。

126 :uy:2011/09/29(木) 03:00:46.23
壁に向かってしゃべってろゴミwww

127 :デフォルトの名無しさん:2011/09/29(木) 04:41:39.66
>>125
逆だよ
型検査は人間に型宣言をさせずに、型推論ベースでやればいい

128 :デフォルトの名無しさん:2011/09/29(木) 05:53:33.15
Rubyは今からでも静的言語に変更した方がいい。
このままではクリティカルなビジネスに使えないので
普及しない。

129 :デフォルトの名無しさん:2011/09/29(木) 08:27:21.32
第2のHaskellも第3のJava(第2はC#)もいらんわ。

130 :デフォルトの名無しさん:2011/09/29(木) 09:12:48.70
>>125
最近の流れだと、型安全性というと型推論を言うんじゃないかと。
C++ですら型推論の時代だし、記述量はむしろ少なくなる。


131 :デフォルトの名無しさん:2011/09/29(木) 09:24:23.82
言語を変更したら人間が対応に追われるし
もし機械的に翻訳できる事を保証したらむしろ安心して古い言語を使い続ける。

言語の論争は、機械は翻訳ができないっていう無力感を前提としているから
機械の力に特別な期待を持つのは不自然だと思う。

132 :デフォルトの名無しさん:2011/09/29(木) 09:31:50.29
自然言語の話と形式言語の話を混同するおとこのひとって

133 :デフォルトの名無しさん:2011/09/29(木) 10:05:09.62
混同したら一敗
区別すれば一勝一敗かもしれないけど二敗かもしれない

134 :デフォルトの名無しさん:2011/09/29(木) 12:18:10.00
>>131
実現する処理とその表現を混同してるねえ。
実現するだけなら機械語でも万能。
問題は表現だ。

135 :デフォルトの名無しさん:2011/09/29(木) 12:42:17.77
>>131
> 機械の力に特別な期待を持つのは不自然だと思う。
単に「機械でも出来る程度のことは機械にやらせろ」ということであって
「特別な期待」うんぬんじゃないよ
人間様が一々機械語なんて記述してられないから、プログラミング言語という
形式言語を発明して、機械語への翻訳は機械にやらせることにしたわけです


136 :デフォルトの名無しさん:2011/09/29(木) 13:11:03.08
>>130
簡潔に記述出来るようになる一方で、盛り込みたい概念が順番待ちしてるから、ある程度の複雑さで妥協すると思う。

137 :デフォルトの名無しさん:2011/09/29(木) 13:34:32.84
>>135
どの程度なら機械でも出来るか
もし自分が機械だったらここまでは出来るって想像できる人が機械を作る
自分は機械とは違うって感覚だと、自分に出来ないことを機械に期待してしまう

138 :デフォルトの名無しさん:2011/09/29(木) 17:02:51.98
安全とかいうのはランタイムエラー撲滅してからにしろって

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
やっぱりなんか感覚がずれてるね。おまいらの暇つぶしに付き合う気がないんでこれ以上はコメントしない。

144 :デフォルトの名無しさん:2011/09/29(木) 19:38:11.05
どうでもいい長文を垂れ流す馬鹿をひとり駆逐したぞ^^

145 :デフォルトの名無しさん:2011/09/29(木) 19:56:41.75
ひとを間抜けと呼んだ時点でてめぇも二元論だろ。

146 :デフォルトの名無しさん:2011/09/29(木) 20:00:50.40
>>139
> 2つの言語の共通するところってプログラムを組む前の戦略を立てるときに
> 大変頭を使う事かな。

それは言語の問題じゃない。プログラマの問題だ。
LispだろうがHaskellだろうがドカタ産業の標準になったら、クソの山になる。

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
書き込みの内容自体はどーでもいいー

151 :デフォルトの名無しさん:2011/09/29(木) 21:29:24.25
じゃあ、それはただの揚げ足取りってことだなw

152 :デフォルトの名無しさん:2011/09/29(木) 21:52:04.37
当然、土方仕事かどうかは作るシステムで決まる。

だが、土方仕事しか経験の無いプログラマは
冗長なコピペコードをIDEで生成するのが最上の手法だと認識してる。
そういうプログラマが "IT土方" と呼ばれているだけの話。

153 :デフォルトの名無しさん:2011/09/29(木) 22:52:46.39
スクリプト言語で仕事って言うと、ほぼウェブ系だよな。つまり、スクリプト言語はドカタ用言語と言って過言ではない。

154 :uy:2011/09/29(木) 22:58:17.55
>>147
JAVAは土方だよ 高確率で。

あの言語みてそう思わないならセンスが狂ってる
C++は土方ではない。 扱うのが難しいし、出来る奴が少ない。 C++PG。 それは「技術屋」という


155 :uy:2011/09/29(木) 23:02:14.65
言語仕様はさておいて。
C++が出来ること。 C++で作られたプログラムのメンテが出来る事。
まさに技術を売っている感じ。

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

ゴミしかいねーからJAVAになる。。。 人の頭脳は、年々、子々孫々進化していて、
次の世代次の世代で、どんどん今の世代よりは頭が良い。 いずれC++復権すると思うよ
JAVA?C#? いらねーんだよw
人の進化の速度にも、よるけどな

156 :デフォルトの名無しさん:2011/09/29(木) 23:02:32.26
>>151
短絡的だなあ…。

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

必ずしも当てはまらないのは自明の事だし、
いちいち主張することでもない。

157 :uy:2011/09/29(木) 23:05:04.74
とりあえず、さっさと言語統一はかったほうが、いいんだけど

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

この世に1つしか言語がなければ、多分、効率は100倍を超えると思うよ
剣道やったことあるか? 片手で振るのと、両手で振るのとでは、威力の差が
 2 倍 で は な い   1+1って計算にはなっていないから、それ以上になる。
 

158 :デフォルトの名無しさん:2011/09/29(木) 23:15:58.74
いみふ

159 :デフォルトの名無しさん:2011/09/29(木) 23:45:24.04
>>139
このスレは、なんちゃってxxxerの隔離スレ。

160 :デフォルトの名無しさん:2011/09/29(木) 23:52:57.60
haskellerはlisperなんて相手にしてないし

161 :デフォルトの名無しさん:2011/09/30(金) 01:29:49.90
>>139
うーん。。。
当たってるような、当たってないような。。。
自分の感覚だと、javaやrubyはリファレンス本(またはリファレンスサイト)をちょくちょく参照しないと書けない感じで、haskellは割とリファレンス参照しなくても、自分で何時の間にか組込関数と同じモノ自作してました。みたいな、リファレンスの使用頻度が低い感じを受ける

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

印象としては記憶力勝負のjava
発想力勝負のhaskell?


162 :デフォルトの名無しさん:2011/09/30(金) 01:39:02.71
B★RS

to turn this way Baby

163 :デフォルトの名無しさん:2011/09/30(金) 02:31:13.30
>>161
単に、単純な代物しか作っていないからでは> haskell

164 :デフォルトの名無しさん:2011/09/30(金) 04:55:33.55
>>163
おれもそう思う
覚えたての言語に対しては大抵「この言語は発想力がモノを言うなあ」と思うものだ

165 :デフォルトの名無しさん:2011/09/30(金) 07:28:28.70
>>157
てめえ剣道やったことあんのか?
両手で二倍にならねえよ、それ以下だ

166 :デフォルトの名無しさん:2011/09/30(金) 09:29:00.28
>>163-164
そうかもだけど、その単純なプログラムでも、オブジェクト指向はまず「こう言う事したいけど、そう言うクラスやメソッドは無いか?」って探す所から始まる事が多い気がする




167 :デフォルトの名無しさん:2011/09/30(金) 10:16:41.67
関数型でも手続き型でも、そういう関数や手続きはないか、って探すけど

168 :デフォルトの名無しさん:2011/09/30(金) 11:16:05.06
>>166
関数型は部品の再利用には向いてないってこと?

169 :デフォルトの名無しさん:2011/09/30(金) 11:29:01.57
>>167
簡単なのだと探すより作っちゃった方が速いけど。。。

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

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

底辺でも再利用出来るのが関数型言語の良い所?


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
馬鹿なこの町並みは基底クラスの変数の状態に依存するはずだろ。
日曜大工だと探すより作っちゃった方が速い場合が多いけど。。。

174 :デフォルトの名無しさん:2011/09/30(金) 15:07:31.56
>>166
OOPL脳の俺には、非OOPLのほうがむしろ数が多過ぎて覚えるのも探すのも大変なんだが…

175 :デフォルトの名無しさん:2011/09/30(金) 16:11:28.26
>>174
何の数が多すぎるんだろう。。。
関数?


176 :デフォルトの名無しさん:2011/09/30(金) 17:51:16.53
腹の脂肪…


177 :デフォルトの名無しさん:2011/09/30(金) 17:52:54.38
>>176
必死だなwwww


178 :デフォルトの名無しさん:2011/09/30(金) 18:16:38.76
ハスケルって馬鹿っぽいから嫌いだな
スカラおすすめ

179 :デフォルトの名無しさん:2011/09/30(金) 19:23:53.40
オキャムルおぼえるぞ

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に初めて触れた頃はドキュメント読めなかった
…が、慣れた今では却って読みやすくなっちゃった

188 :デフォルトの名無しさん:2011/10/01(土) 00:43:42.59
OCamlだと調べものはOcamlBrowserで済む事が多いな。
関数の型から関数名を検索することもできるし。

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から作るのも再利用するのも向いてるんだよ。
(数学で再利用できないのはかなりキツイと言う文化的背景的にも)

関数型言語はまさしく算数や数学と同じだ。
初心者は算数・中学数学並みの少ない知識でも結果的には同じ意味のコードが掛けるし、知識が付けば、効率的で無駄のないコードが書ける。

191 :デフォルトの名無しさん:2011/10/01(土) 03:21:55.53
ただ読みやすいコードか? とか速いコードか?と
聞かれると必ずしも関数型言語風の書き方が
最善というわけじゃないんだよな。

192 :デフォルトの名無しさん:2011/10/01(土) 04:01:32.97
元々解くべき問題の複雑さ度合いとか問題領域に応じて、複数のプログラミング言語が在る訳だ。
乱数を10^10(10の10乗)回足しこむような単純な処理なら、現在でもCが最速だろう。
ただし、こんな単純な処理でも10000^10000回とかなった途端に、ライブラリを探すか、自分で車輪を再発明する事になる。
更に問題なのは、ほとんどのアプリケーション・プログラマーが使う範囲では、複数の言語間のスピード比較は、単純な処理でしか出来ない事。
鳥とライオンとで、地上走行のスピード比較をするようなもんだ。
飛ぶことによって得られる自由度は、最初から比較対象にならない。

193 :デフォルトの名無しさん:2011/10/01(土) 04:09:05.68
>>191
速いコードを書こうとするときは泥臭くなりがちだね。lispのwith-typeマクロ
みたいなのがあると、その泥臭いところは隠すことはできるけど、初心者では
手におえんわな。
TCO(末尾再帰)があるかないかで関数型言語風の書き方が強力になるのか毒に
なるのかが決まってくるかな。

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 直交

197 :デフォルトの名無しさん:2011/10/01(土) 04:16:13.18
>>193
ループ
→再帰
→畳み込み
という風に、抽象化が進むんじゃ?

198 :デフォルトの名無しさん:2011/10/01(土) 07:43:51.44
>>190
> 関数型言語は元々、手続き型言語と違って数学を基にしてるから、1から作るのも再利用するのも向いてるんだよ。

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

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

算数や数学よりもずっと窮屈だよ
算数や数学では書き換え規則が双方向なのに対して
関数型言語では書き換えは一方通行だから

199 :デフォルトの名無しさん:2011/10/01(土) 07:53:50.64
頭のとろそうな書き込みが見つかるばかりで、
五次以上の方程式については(俺は)全く分かっていなかった。

200 :デフォルトの名無しさん:2011/10/01(土) 08:25:48.45
>>198
数学の計算って何を指して言ってんの?
LKは一方向に進むけど?

201 :デフォルトの名無しさん:2011/10/01(土) 08:33:51.71
5 を 1 + 4 と 2 + 3 と 3 + 2 と....の全てに書き換えた、その全てが並列に存在する宇宙を
知覚できる人なんだろう、多分。

202 :デフォルトの名無しさん:2011/10/01(土) 09:15:05.45
>>198
ガウディ本ぐらいは読もうぜ。

203 :デフォルトの名無しさん:2011/10/01(土) 09:42:14.27
何時も思うけど、なんで知りもしないことのアンチになれるんだろうね?
少しやり取りするだけで無知なのがハッキリ分かるし。

204 :デフォルトの名無しさん:2011/10/01(土) 09:51:37.82
自分の言葉で説明できないから
○○読めとかいって逃げるだけだしw
ほんと無知だな。

205 :デフォルトの名無しさん:2011/10/01(土) 09:52:34.29
>>204
で、>>198はどんな数学の計算規則について言ってんの?低能さん?

206 :デフォルトの名無しさん:2011/10/01(土) 09:59:17.00
関数型言語は関数が一杯あってお目当ての関数が探せませーん
みたいなアホが無知でなくて何なの?w

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
動的言語のなりたちは
シェルとかで簡単にコンピュータに
コマンド打ち込むため。
そこにちょっと欲がでて
制御構造や変数使えるようにした。
話は本来そこまでのはずだった。

212 :デフォルトの名無しさん:2011/10/01(土) 11:53:47.81
つーか、関数型が読み難いって何を根拠に言ってんだ?
適当にコード貼ってみてくれよ

213 :デフォルトの名無しさん:2011/10/01(土) 11:55:53.53
例を出すのならコードは現実的な長さ、
30行ぐらいのやつでお願いね。

214 :デフォルトの名無しさん:2011/10/01(土) 12:20:56.98
>>211
動的言語はGCを作りやすかった
GCがないC++より、Lispの方がましだった
Javaは当初はgenericsがなくて静的言語としては微妙だった
あと、共用体に否定的なC++と部分型に否定的な関数型言語の間でブレがある

215 :デフォルトの名無しさん:2011/10/01(土) 13:02:14.13
GCの作りやすさは動的静的関係ないと思うんだが

216 :デフォルトの名無しさん:2011/10/01(土) 15:26:01.60
チャーチ性も知らずに「関数型言語は数学と同じ」とか、マジでバカすぎw

217 :デフォルトの名無しさん:2011/10/01(土) 16:11:34.34
GCといえば デビット月だよ!伝説のMS-JVM

218 :デフォルトの名無しさん:2011/10/01(土) 17:38:56.84
>>212,>>213
ここのコードがコメント空行抜きで40行くらいだし丁度良い
これと等価なコードを関数型言語で書いてみて比べたらいいさ

http://en.wikipedia.org/wiki/Strategy_pattern#Example

219 :デフォルトの名無しさん:2011/10/01(土) 17:46:06.64
>>206
それは俺だ、無知だなの人と一緒にしないでくれ…
自分は自分が無知なのは充分承知してるよ。

220 :uy:2011/10/01(土) 18:37:55.88
お前たちゴミには理解できない話なんだろうけど

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

ほんっとーに、目の前の事実から目をそむけてよく考えず逆論ばっか唱えるゴミッカスが「多い」なw

221 :uy:2011/10/01(土) 18:39:59.51
>>219
はぁ?????
>自分は自分が無知なのは充分承知してるよ。


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


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


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



222 :デフォルトの名無しさん:2011/10/01(土) 19:34:09.77
全体の設計とかライブラリを OOP で書いて、局所的にはできるだけ副作用のない関数っぽく書けば良いのでは?

223 :デフォルトの名無しさん:2011/10/01(土) 19:46:43.20
>>218
え?Javaってこの程度のコードに何十行も必要なの?www

224 :デフォルトの名無しさん:2011/10/01(土) 19:52:50.28
OOPと言われて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だけではなく、
他のメソッドと共に状態を表すいろんなフィールドを持っているものとして考える。

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
のような形にしないといけない。


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
近くても違っている以上別物。
等価なコードになっていないというだけ。

242 :229:2011/10/02(日) 00:55:40.49
えーと、複数の関数を渡せればOK?

243 :デフォルトの名無しさん:2011/10/02(日) 00:55:44.24
>>240
> いや、それは分かる。

それが分かっているのなら障害は何も無い。
等価になっていないと分かっているのなら、
あとはちゃんと等価になっているコードを書けばいいだけだと思う。

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オブジェクトの動作を変えるもの

どちらも関数単体で分離するようなもんじゃないんだよ。

248 :デフォルトの名無しさん:2011/10/02(日) 01:04:08.18
つまり、関数型言語っぽい書き方をしたら、オブジェクト指向っぽくないという理由で却下

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の項にも「関数が第一級オブジェクトであり、このパターンを明示的に定義する必要はない」と書いてある。

250 :デフォルトの名無しさん:2011/10/02(日) 01:23:23.94
クロージャで状態保持できるのは関数型言語だけじゃないしwww

にわか関数型プログラマって、ほんと無知だなw

251 :デフォルトの名無しさん:2011/10/02(日) 01:23:58.45
>>249
ちげーよ。

たくさんアルゴリズムをパッケージするんじゃなくて、
一つのアルゴリズムつーか、機能な。
一つの機能が複数のメソッドからなっている場合もあるってことだ。

252 :デフォルトの名無しさん:2011/10/02(日) 01:25:57.08
>>251
> 一つの機能が複数のメソッドからなっている場合もあるってことだ。
例を挙げてくれ

253 :デフォルトの名無しさん:2011/10/02(日) 01:28:03.49
>>250
誰がクロージャで状態保持できるのは関数型言語だけって言ったんだ?

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 :229:2011/10/02(日) 01:35:28.70
>>254
それを関数型で書けばOK?あとでオブジェクト指向じゃないとか言わない?

256 :デフォルトの名無しさん:2011/10/02(日) 01:36:55.67
> あとでオブジェクト指向じゃないとか言わない?
言わない。


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

今いったw

257 :デフォルトの名無しさん:2011/10/02(日) 01:39:28.39
>>256
そうか。じゃあいいや
というか、関数型ではそういう副作用のあるコードは書かないね

258 :デフォルトの名無しさん:2011/10/02(日) 01:41:51.25
>>254
何それ?お前が勝手に作った疑似コードじゃなくて
もっと実際の例は無いのかよ?

本当に>>247の通りならいくらでも見つかるだろ。

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]


オブジェクト指向で書いても、あとで関数型じゃないと文句を言ったりはしない

261 :デフォルトの名無しさん:2011/10/02(日) 02:24:24.43
それ、OOPで書いても大して長くならんぜ。
ていうか、>>212は読み易さを比べようって言ってるんであって
長さ比べをしてるわけじゃねぇ。

262 :デフォルトの名無しさん:2011/10/02(日) 02:34:51.90
>>260
>>213が例を出すなら現実的な長さ(30行以上)って言ってるぞ。
それとも、オブジェクト指向言語なら30行超えるとでも思ってんのか?

263 :デフォルトの名無しさん:2011/10/02(日) 02:57:58.64
>>261-262
話はコードを貼ってから。

264 :デフォルトの名無しさん:2011/10/02(日) 03:28:23.86
そのletがなぜ必要なのかばっかり気になってダメだな俺…

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パターンなんだよ。バカすぎる。

269 :デフォルトの名無しさん:2011/10/02(日) 03:56:57.15
f

270 :uy:2011/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}));
}
}

272 :デフォルトの名無しさん:2011/10/02(日) 05:47:14.59
わー読みやすーい
むりやり改行減らして行数少なく見せようとする努力もステキ

273 :デフォルトの名無しさん:2011/10/02(日) 06:03:57.02
めんどくせーやつだな。
ここだけあれば十分だよな?

274 :デフォルトの名無しさん:2011/10/02(日) 06:17:20.35
&#tab;ふ

275 :デフォルトの名無しさん:2011/10/02(日) 08:04:02.32
結論: Javaは冗長


276 :デフォルトの名無しさん:2011/10/02(日) 09:45:26.15
静的言語ではクロージャの連想リストは作れないの?

277 :デフォルトの名無しさん:2011/10/02(日) 10:46:51.30
作れるよ。

278 :デフォルトの名無しさん:2011/10/02(日) 10:47:29.43
おめこ

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 :uy:2011/10/02(日) 15:46:54.58
>>282
あいたたたた




284 :デフォルトの名無しさん:2011/10/02(日) 16:23:56.18
まともにプログラム書けないやつほど簡単と言いたがる

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

あまり言語自体の自由度高いと馬鹿が一人二人暴走したら目も当てられない

286 :デフォルトの名無しさん:2011/10/02(日) 17:41:33.65
まだ、低能向けの仕様がどういった所で
その理由がでてないのかよ。

287 :デフォルトの名無しさん:2011/10/02(日) 17:47:33.75
え?そんなに悔しかったの?www

288 :デフォルトの名無しさん:2011/10/02(日) 17:56:35.93
そんな無意味な煽りはいらないから。

289 :デフォルトの名無しさん:2011/10/02(日) 18:08:30.04
Javaのコードの冗長さもIDEで補完できるという意見もあるけど、
それってつまりJavaのコードの大半は自動生成できる、書くのに人間の知性が要らない
記述する必要のないコードなんだよね。
ライン工場が殆どの処理を自動化して、一部の(それも知性の要らない)作業だけ工員に
やらせるのと同じで、Java PGは自動生成されたコードの一部に単純なコードを挿入するだけ。

290 :デフォルトの名無しさん:2011/10/02(日) 18:10:36.75
>>289
自動生成と補完は意味が全く違うぞ。

補完で終わらせられるような単語の「キーを入力すること」は
人間の知性がいらない、記述する必要のないコードとは言えるが。

291 :デフォルトの名無しさん:2011/10/02(日) 18:16:05.92
型推論があれば必要無い型注釈や、
構造的部分型があれば必要無いインターフェース宣言の話じゃねーの
ここは型付けスレなんだし

292 :デフォルトの名無しさん:2011/10/02(日) 18:23:07.83
Javaの素晴らしいところは、どんなに腕の立つPGでも
一定以上洗練されたコードを書く事は出来ないところだね。
誰が書いても芋臭い冗長なコードになる。
それゆえに引き継ぎの際に人員のスキルが問題になり難い。

293 :デフォルトの名無しさん:2011/10/02(日) 18:23:51.99
型推論って型宣言のシンタックスシュガーにすぎないので
宣言文が簡単に書けるってだけで静的型付けであることに
代わりはないんだけどね。


294 :デフォルトの名無しさん:2011/10/02(日) 18:24:39.49
>>292
宣言の書き方が決まってるだけで、
実装コードはどちらも大差ないよ。

295 :デフォルトの名無しさん:2011/10/02(日) 18:29:30.25
>>289
お前、コード書けないでしょ
たったそれだけの文章なのに、いちいち論理を誤ってんじゃねえよw

296 :デフォルトの名無しさん:2011/10/02(日) 18:35:51.66
そうそう。Javaも他の言語も全然変わらんよ
>>260>>271を比べてみろよ
似たようなもんだろ?

297 :デフォルトの名無しさん:2011/10/02(日) 18:37:14.50
>>289
俺なら、開発の中で効率化出来る部分、つまり自動化ができる部分があるのなら、
極力自動化が可能なように、いろんな部分を改善して、
人間がやる部分は自動化できない所、自動化出来る部分を機械に
やらせようと思うけどな。

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

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

俺が言語を作るなら、自動化できるような言語を作るな。


298 :デフォルトの名無しさん:2011/10/02(日) 18:39:26.44
>>296
うん。結局、改行とか宣言とか
そういうタイピングの差レベルの違いしかないよね。

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

しかもIDEサポートでその差は消えるって寸法だ。

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

302 :デフォルトの名無しさん:2011/10/02(日) 18:56:54.54
ま、>>260は静的型だから変数の型にも答えられるけどな

303 :デフォルトの名無しさん:2011/10/02(日) 18:58:54.84
そっか、ここでもまた静的型の勝利か。

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行以上でも作れる
ただしコード内へアサーションを十分に埋め込み、
十二分なテストケースを用意できるのであれば

要は、お手軽さが魅力の動的言語で、
どこまで品質保証にコスト(労力)をかけるのか?という事
作れる/作れないの二元論だけじゃ語れないんだよ

308 :デフォルトの名無しさん:2011/10/02(日) 19:54:30.18
>>253
関数型言語ではクロージャが状態を保持できる(キリリッ
って人ならいるねww

309 :デフォルトの名無しさん:2011/10/02(日) 19:55:40.71
>>307
> 要は、お手軽さが魅力の動的言語で、

これだから静的厨は馬鹿だというのだ

310 :デフォルトの名無しさん:2011/10/02(日) 20:33:35.33
このスレでは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
>>313
そういう言い回しがあるんだよ
http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%E3%81%AE%E6%AF%94%E8%BC%83

315 :デフォルトの名無しさん:2011/10/02(日) 21:00:42.26
>>310
静的が、コーディング/テストに手間がかかるって
誰か証明できてたっけ?

316 :デフォルトの名無しさん:2011/10/02(日) 21:21:08.91
>>315
コーディングはいちいち変数宣言が必要だから議論の余地はねえだろ
テストは静的のほうが相対的には手間がかからんはずだけど、
静的な言語なんだから、もっとしっかり処理系でコンパイル時に検査してよ!!ってのはある

静的なのにナゼNullPointerExceptionなんてのが実行時に起きるわけ?!
ゼロ除算例外やI/Oエラーならテストで確認するしかないと思うんだが

317 :デフォルトの名無しさん:2011/10/02(日) 21:30:55.65
そうやな
関数型言語なのにtotalな関数じゃないとか詐欺みたいな事してるもんな
だからtotal function programmingとか

318 :デフォルトの名無しさん:2011/10/02(日) 21:40:03.59
あほか、なんで関数型言語の関数が全て全射でなきゃならんのだ
全射でないから安全でないコードが書けるけど、そもそも「関数型 = 安全」の図式が幻想だ

319 :デフォルトの名無しさん:2011/10/02(日) 21:42:29.46
>>316
> コーディングはいちいち変数宣言が必要だから議論の余地はねえだろ

変数宣言をしたおかげで、
使用するときは逆に楽になるだろ。
そのぶんのメリットをお忘れか?


320 :デフォルトの名無しさん:2011/10/02(日) 21:44:38.28
>>316
> 静的なのにナゼNullPointerExceptionなんてのが実行時に起きるわけ?!

C++のように起きない言語もある。
お前が言ってるのは静的の欠点ではなく
Javaに「C++の参照」に近い仕様を入れろと言ってるにすぎないよ。

321 :デフォルトの名無しさん:2011/10/02(日) 21:50:31.72
C++はその代わりにSegmentation faultが起きるがな

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++は弱い型付け&静的言語」だからしかたがないのかな....

323 :デフォルトの名無しさん:2011/10/02(日) 22:05:11.36
よーわからんけどぬるぽはmaybeモナドとかoption型とか呼ばれてるやつを使えばいーんでないの?
進んでる静的型付け言語はもうぬるぽは克服してるイメージがあるけどちげーのか?

324 :デフォルトの名無しさん:2011/10/02(日) 22:06:30.55
そこで、俺が前々から言っている、
コンパイラで自動的に検証できることを増やすという
考えで言語を作ろうという話になる。

325 :デフォルトの名無しさん:2011/10/02(日) 22:30:06.69
>>323
Haskellは副作用を一切許さない純粋関数型言語だから、
モナドを使う以前の話でヌルポは起きようがないよ

326 :デフォルトの名無しさん:2011/10/02(日) 23:30:14.68
>>325
値の検証のタイミングはMaybe外すとき、ってのが分かりやすいだけじゃね?
Nothingの時にfromJustしたら実行時エラー出た気がする。
それをヌルポと言うのかは知らんけど。

327 :デフォルトの名無しさん:2011/10/02(日) 23:38:25.61
それがやはりtotal functional programmingこそ必要

328 :uy:2011/10/03(月) 02:00:09.21
2chでバカを見つける方法だけど、

>>282
>>286
>>289

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

面白いよ! 試してみ!

329 :デフォルトの名無しさん:2011/10/03(月) 02:34:27.15
お前はメロンパンナでも食っとけよ


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

結局Javaの「低能向けの仕様」(=優れた点)は
誰も言わなかったなw

331 :デフォルトの名無しさん:2011/10/03(月) 02:59:31.46
机上で語っても仕方ないから、
ミッションクリティカル領域の実績豊富な言語が一番安全ということで。

結論:C言語

332 :デフォルトの名無しさん:2011/10/03(月) 03:29:50.41
>>330
あれ、その認識でいらっしゃる割に俺のコメがスルーされてるような
いや別に良いけど

333 :uy:2011/10/03(月) 04:14:50.56
>>330
ガチ勢だからな、これ


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

そういう奴は、JAVAはすごいんだ! って思い込むしかないよねぇ・・・・・・・・・・・・・あはは


334 :デフォルトの名無しさん:2011/10/03(月) 04:25:23.82
そんな煽りしかできないから
馬鹿にされるわけでw

335 :デフォルトの名無しさん:2011/10/03(月) 04:37:31.95
っていうか、言語ごときで、○○使えるから俺頭いいとか、
それこそ頭悪いわw

336 :デフォルトの名無しさん:2011/10/03(月) 05:39:30.38
>>325
ゼロ割りその他のランタイムエラーは起こりまくりだけどなw

337 :uy:2011/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   ヾ 丶
     "~、ソ:: :い:: :     \_  ノ ,    ヾ 丶

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
>>339
http://ja.wikipedia.org/wiki/%E5%9E%8B%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0

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

343 :デフォルトの名無しさん:2011/10/03(月) 13:17:20.79
いいじゃん お前の中では強い子って事にしとけよ

344 :デフォルトの名無しさん:2011/10/03(月) 13:57:43.13
動的型付けって時点でもう致命的

345 :uy:2011/10/03(月) 14:08:12.23
救われたのか?

346 :uy:2011/10/03(月) 14:27:49.20
で、こんだけJAVAはすげーんだ!すげーんだぞ!!
ってやってて、最終的な逃げ道は
「どの言語使っても同じ」
だもんなぁ・・・・・・

仕事でJAVA使わされている時点で気づけよって話なんだけど
いまだにJAVA使いこなしてる自分を優秀とか思ってるのだろうか
そりゃこの業界には論外素人も入ってくるから、
ちょっとでも勉強する気があれば、先輩面できるんだけども
JAVAを後輩に得意げに鼻息荒く教えた程度で、2chで火病っちゃうくらいなら、君はJAVAをやるべきではなかった

347 :デフォルトの名無しさん:2011/10/03(月) 14:28:46.94
こいつ誰と戦ってるの?

348 :デフォルトの名無しさん:2011/10/03(月) 14:45:20.57
いつコンビニ業界のコトになったんだ。

349 :デフォルトの名無しさん:2011/10/03(月) 14:54:17.90
>>341
言語仕様の議論で「この仕様はPGにとって複雑すぎるのでは?」という
やりとりはどの言語においても見られる。あのC++でさえ

ただJavaの場合その閾値がちょーっとばかり低いだけだw

350 :デフォルトの名無しさん:2011/10/03(月) 16:02:43.13
ストーカー女神が救われたのか?

351 :uy:2011/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 :uy:2011/10/03(月) 16:25:29.34
>>352
仕事中に何2chみてんだ

354 :デフォルトの名無しさん:2011/10/03(月) 17:24:13.80
すみません

355 :デフォルトの名無しさん:2011/10/03(月) 18:30:27.68
必死www
いいじゃん お前の中ではカレと会話って事にしとけよ

356 :デフォルトの名無しさん:2011/10/03(月) 18:41:48.64
へ?

まあいいけど

357 :デフォルトの名無しさん:2011/10/03(月) 20:14:29.07
クソワロタ

358 :デフォルトの名無しさん:2011/10/03(月) 21:02:46.69
今日さ、つまらないスペルミスでバグになっていて、
その修正にちょっと時間を費やしてしまったんだけどさ
バグの原因を見つけたときに思った。

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

やっぱり静的型付け言語のほうが
コーディングが楽だよ。

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 :uy:2011/10/04(火) 03:12:50.69
C#はMS言語だからね

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

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

Rubyであれば、純粋に記述量が少ないから
エディタ起動から60秒でかけるけど
C#になると、慣れたとしてもわからんな

363 :デフォルトの名無しさん:2011/10/04(火) 03:32:08.49
>>358
メタプログラミングが常套手段の言語だと、
確かにこういう弊害あるな。

デバッグを想像しただけで泣ける。

364 :デフォルトの名無しさん:2011/10/04(火) 03:34:50.34
コード自体の書き換えが多かったり、
使い捨てなら確かにスクリプトの方がいい。
というか適材適所だろ。

365 :uy:2011/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


368 :デフォルトの名無しさん:2011/10/04(火) 06:04:37.57
やっぱり23年度国産米では安全なソフトは作れない

369 :デフォルトの名無しさん:2011/10/04(火) 07:31:21.92
>>367
馬鹿に真面目に突っ込んでも無駄だよ
どうせ>>358もJava土方の作り話だし

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

373 :デフォルトの名無しさん:2011/10/04(火) 10:52:30.17
バレバレですよuyさん

374 :デフォルトの名無しさん:2011/10/04(火) 12:10:55.56
>>373
uyがJavaのフレームワークのことなんて知ってるわけないじゃんw

所詮は知ったか坊やですし

375 :デフォルトの名無しさん:2011/10/04(火) 15:25:30.82
>>372に言ったのではなかったがまあいいや

376 :デフォルトの名無しさん:2011/10/04(火) 20:42:57.57
コンパイルエラーってバグになるんでしょうか?

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

特に動的型付け派の人に。

378 :デフォルトの名無しさん:2011/10/04(火) 21:56:31.96
>>377
おれは日常的には lisp の人だが, バグと見なすよ.
lisp の場合, 宣言つけまくると, 下手な静的片付け言語より
型検査厳しい処理系もあるからかもだけど


379 :デフォルトの名無しさん:2011/10/04(火) 22:56:43.29
知力                                                 青村早紀
  ↑                                           
秀│  一ノ瀬ことみ                                  裏葉 水瀬秋子
  |                               来ヶ谷唯湖                       
  │         川澄舞                   霧島聖  
優|             二木佳奈多  坂上智代    相楽美佐枝 天沢郁未
  │          能美クドリャフカ  西園美魚 倉田佐祐理
  |               遠野美凪 笹瀬川佐々美 美坂香里   
良|                          長森瑞佳        天野美汐
  │                       里村茜 川名みさき   古河早苗
  |                    七瀬留美                     
可┼                  藤林杏 藤林椋       
  |             上月澪 神北小毬
  |        三枝葉留佳 霧島佳乃 美坂栞  神尾晴子
落│         古河渚  水瀬名雪   巳間晴香
  │        伊吹風子 名倉由依  
  │         神尾観鈴   河南子            名倉友里
逝|       棗鈴  月宮あゆ                  
  │棗鈴(退行) 椎名繭 鹿沼葉子 神奈 みちる
  | 神尾観鈴(退行) 志野さいか 岡崎汐
死│  沢渡真琴(退行)                    
  ↓uy  
   ←―――――――――――――――――┼―――――――――――――――――→
    基地外     イタタ    厨房     普通     大人    君子     聖人
                         情緒的成熟度

380 :デフォルトの名無しさん:2011/10/05(水) 04:20:53.29
>>377
動的型スキーだけど、バグだろうね。
ただ、環境のバグかプログラムのバグか、そこが問題だ。

381 :デフォルトの名無しさん:2011/10/05(水) 06:05:33.75
GCCに-Wextra -Werrorを付けてる奴ばかりなら少しは納得するw

382 :デフォルトの名無しさん:2011/10/05(水) 07:37:02.89
>>379
わろた

383 :デフォルトの名無しさん:2011/10/05(水) 20:42:48.53
やっぱり動的言語を使っている人って
コンパイルエラーをバグとして考えているんだね。

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

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


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

やはり、基本的には静的型付け言語の方向で進みながら、動的型付け言語の機能を取り込むのが
プログラム言語の未来への正しい道だと思うな。

384 :デフォルトの名無しさん:2011/10/05(水) 21:44:59.19
あのー、ドヤ顔してるところ申し訳ないんですが、
静的型言語派の俺もコンパイルエラーはバグだと思ってますよ、と。

385 :デフォルトの名無しさん:2011/10/05(水) 21:55:13.95
>>383
例えば未定義のメソッドを呼び出そうとしてエラーになったとすると
呼び出そうとしたのが悪いのか、定義していないのが悪いのか、自動的には判定できない
どっちが悪いかを考えるのは人間の仕事

386 :デフォルトの名無しさん:2011/10/05(水) 22:02:33.44
>>383
論点があいまいで読んでてイライラする文章

387 :デフォルトの名無しさん:2011/10/05(水) 22:05:20.83
コンパイル通らないのはバグ以前の問題で、バグとは思ってないな。

388 :デフォルトの名無しさん:2011/10/05(水) 22:07:48.97
ようわからんが俺も387と同じだな

389 :デフォルトの名無しさん:2011/10/05(水) 22:12:27.29
自分の書いたコードについては>>387と同じ
他人の書いたコードのコンパイルエラーはバグと感じる

390 :デフォルトの名無しさん:2011/10/05(水) 22:17:04.04
イライラするのは、決めつける言い方が多いから

変数の型を決めつける言語にイライラするのと似ている
自分で決めつけたことはイライラしない
他人が決めつけるとイライラする

391 :デフォルトの名無しさん:2011/10/05(水) 23:42:09.09
>>383
>プログラミング=設計であり、バグは設計上の問題。
>コンパイルエラーは、コンパイル=製造だから、製造上の問題と考える。

プログラミング=設計の段階でコンパイルエラーの原因が発生するんだから
製造の問題では無いよね。そこが間違ってるので以下全部おかしい

392 :デフォルトの名無しさん:2011/10/05(水) 23:51:05.25
>>391
設計は頭の中にあるんだよ(キリッ

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

実際経験を積んでいる人は、設計を考えるときに
言語のことはほとんど考えないでしょ?

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分野では半ば常識です

395 :デフォルトの名無しさん:2011/10/06(木) 00:14:50.22
昔はコーダーというものがあったらしいんだが、
コンパイルエラーはコーダーによるミスになるだろう。
直感的に考えて明らかにバグとは違うものだよ。

396 :デフォルトの名無しさん:2011/10/06(木) 00:41:51.02
>>394
貼ってあるリンクの続き。

>だから私は「プログラミングが製造だとするのは間違いである」と頭から信じ込んでいました。
>でも最近,この信念がゆらいできています。

397 :デフォルトの名無しさん:2011/10/06(木) 00:41:54.27
いまどきの日本の最底辺の下請けコーダーは
プログラミング言語と一対一対応するような仕様書を受け取って
それをコードに翻訳する仕事をしてるのかい?
いや、良く知らんのだが。

398 :デフォルトの名無しさん:2011/10/06(木) 00:44:08.40
>>396
それは、それを書いた人の考え。

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

自分が無知であると言ったようなものじゃないか。
その時点で自滅してるんだよ。

399 :デフォルトの名無しさん:2011/10/06(木) 00:46:15.20
>>397
良くない流れがあってね

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

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

本来下請けコーダーのやるような簡単なミスが、
なぜかプログラマのバグとして扱われ始めている。
良くない傾向。

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

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

この記事が書かれたのは2007年だが、あれほど騒がれたアジャイル熱も冷めているのが現実。

401 :デフォルトの名無しさん:2011/10/06(木) 01:02:35.88
どっちにしろ393は馬鹿ってことだな

402 :デフォルトの名無しさん:2011/10/06(木) 01:04:45.42
>>399
ずいぶん業界にお詳しいんですね

403 :デフォルトの名無しさん:2011/10/06(木) 01:07:02.55
どちらかというとマ板の議論が続いているな

ところで、その設計 vs. 製造の話が、なぜ動的片付け/静的型付けの結論になるのか、
>>383を何度読み返してもさっぱり意味不明なんだが....

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

プログラミングは設計だという考えに反対する人もいるだろうけど、
少なくとも、プログラミングは設計だという考えを知らない人は
モグリと言われてもしょうがないよ。

406 :デフォルトの名無しさん:2011/10/06(木) 01:30:23.27
>>403
静的型付け言語を使っている人はみんなそうだと思うけど、
コンパイルエラーはバグだとは思ってないんだよ。

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

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

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

じゃあ、バグとバグ以前のものはなにが違うを考えてみた所、
設計工程による不具合と製造工程の不具合の違いではないかと気づいたわけさ。


407 :デフォルトの名無しさん:2011/10/06(木) 01:34:31.27
動的型付け言語と動的言語、静的型付け言語と静的言語が
ごっちゃになってしまったな。
全部型付けの方だから訂正しておく。

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使う人がほとんどだから、普段プログラミングしてて
コンパイルエラーなんて意識しないだろ

それにしてもイライラする文章
少し前にさ、プログラミングは設計である!ってドヤ顔するのが流行ったよね
今さらドヤ顔してる奴を見るとは思わなかった


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されまくってると何処で定義されてるメソッドか分からねぇし、
くだらねぇタイポも実行時に初めて分かるし。
なにが生産性だよ。

415 :デフォルトの名無しさん:2011/10/06(木) 04:29:40.36
実行可能コードが生成された以降からバグが発生する。
従ってコンパイルエラーはバグとは考えていない。


416 :デフォルトの名無しさん:2011/10/06(木) 07:42:30.91
>>414
Rubyという言語が嫌なんじゃなくて、IDEのサポートが貧弱なのが嫌なんでしょ?

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は良く出来てる。
沢山書いても、実現してる事は少ないから頭を使わなくていい。

422 :デフォルトの名無しさん:2011/10/06(木) 12:25:45.79
土方でも読めるもんね、Javaすごい

423 :デフォルトの名無しさん:2011/10/06(木) 12:36:06.78
>>421
文系が数式よりも記述密度が低い自然言語での説明を好むように
低能は記述密度の低いJavaを好む

424 :デフォルトの名無しさん:2011/10/06(木) 15:01:12.24
いくらHaskellやPythonが仕事で使えるとしても、
お前らみたいな勘違いばかりなら確実に鬱になるな。

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
お前の中では面倒なんだろうけど、他の人がどう思うかはその人の自由。
自由にして生産性を上げるか、徹底的に管理して生産性を上げるかという話だな。

429 :デフォルトの名無しさん:2011/10/06(木) 19:43:56.19
そんな話なの?w
普通に同意できる内容だと思うけど。

430 :デフォルトの名無しさん:2011/10/06(木) 20:43:15.05
>>389が感覚的に近いかなあ。
共同作業だと各自のライブラリやらソースやらのバージョンの差で、
自分の手元でコンパイルできて他の人がコンパイルできないコミットする場合あるし。

まあ静的言語でパーサ通っても安心て訳じゃないのは当然だけど、
型チェックくらいはパーサに任せたい。


431 :デフォルトの名無しさん:2011/10/06(木) 21:07:10.08
パーザで型チェック

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
コンパイルするためにあるんじゃない!実行するためにあるんだ!
っていう主張なんでしょ。

437 :デフォルトの名無しさん:2011/10/07(金) 04:27:00.97
>>416
> Rubyという言語が嫌なんじゃなくて、IDEのサポートが貧弱なのが嫌なんでしょ?

IDEのサポートが貧弱なのは
Rubyという言語が原因。

438 :デフォルトの名無しさん:2011/10/07(金) 05:51:43.32
>>406
ハスケルの偉いひとも「コンパイルはテスト!」って言ってたお?

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で実用的なコードを書ける人員は非常に高くつくんで
利益/コストが高くなるようには思えない

443 :デフォルトの名無しさん:2011/10/07(金) 07:53:08.08
利益が出てるから、高額で雇える。

444 :デフォルトの名無しさん:2011/10/07(金) 08:43:16.98
利益は言語では決まらない。

445 :デフォルトの名無しさん:2011/10/07(金) 08:47:56.33
ミスは許されない。
でも、人間が失敗するのは人間だから仕方ない。

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

Haskellとか数学とかって、やっぱり自然科学とは違うのかね。

446 :デフォルトの名無しさん:2011/10/07(金) 08:58:30.92
なに言っちゃってんの?

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

450 :デフォルトの名無しさん:2011/10/07(金) 14:17:55.35
>>431-433
多分、>>431を書いた人は、パースは単なる構文解析ステージであって、
型チェックを行うのは「意味解析」ステージだ、と言いたかったの
だと思う。

451 :デフォルトの名無しさん:2011/10/07(金) 17:59:05.39
あ、はい、そのようにとらえております

452 :デフォルトの名無しさん:2011/10/07(金) 19:42:51.53
>450
おまえウケる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

457 :デフォルトの名無しさん:2011/10/07(金) 21:02:45.29
言葉遊びという茂木の本質が非常によくわかるわめきだ

458 :デフォルトの名無しさん:2011/10/07(金) 21:36:13.93
>>要約
オタクはCUIでの計算を好むけど、人の感性への働きかける計算も重要。

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

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

>>もっと要約
考えるんじゃない。感じろ。

459 :デフォルトの名無しさん:2011/10/07(金) 21:40:07.65
しょぼいPC画面やなぁ

460 :デフォルトの名無しさん:2011/10/07(金) 21:42:09.81
さらに要約

アップルはお洒落(そんなアップルを支持する俺もお洒落)

461 :デフォルトの名無しさん:2011/10/07(金) 22:34:03.05
アップルの威を借りるオタクが同類をコケにしてる

462 :デフォルトの名無しさん:2011/10/07(金) 23:02:33.60
Windows = Java
Mac = Ruby

463 :デフォルトの名無しさん:2011/10/07(金) 23:13:36.87
ああ、Ruby使ってる奴っていかにも茂木って感じするわ。
なんか自分だけ天啓を受けたような気がしてる、すっとこどっこいな感じ?
悦に入ってるけど、端から見ると普通に可読性低いよっていう。

464 :デフォルトの名無しさん:2011/10/08(土) 01:17:25.58
茂木のツイートは読みづらいわりに面白くないのがなぁ。

とりあえず俺はRubyの方がWindowsっぽい気がする。
洗練されてなさっぷりが。
けなしては無い。
パッと使う分には使いやすい。

465 :デフォルトの名無しさん:2011/10/08(土) 01:19:04.28
>>456
プログラマの立場から言わせてもらえば、コマンドラインアプリすら作れない奴にまともなGUIアプリは作れない


466 :デフォルトの名無しさん:2011/10/08(土) 01:22:18.81
Macが使いやすかったのはOS9までの話だな。OSX以降は普通にウンコというか、もうAppleはiOSの会社でMacはオマケ。

467 :デフォルトの名無しさん:2011/10/08(土) 01:37:31.01
さすがに釣りにしても無理あるというか

468 :デフォルトの名無しさん:2011/10/08(土) 01:43:46.48
>>466
言えてる
ジョブズの引退ら死去までが早過ぎたから、後継者が育ってるかも疑問
iPhone3G->3GSは劇的だったけど、iPhone4->4GSはジョブスのやり口なら5を持ってきてたはず

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

精神は引き継がれてない

byどざえもんw


469 :デフォルトの名無しさん:2011/10/08(土) 01:59:35.94
MBAにWindows7を入れて使うのが正解

470 :デフォルトの名無しさん:2011/10/08(土) 09:45:07.84
要約
・同じでしょ
・等価ではない
・「計算」という概念が、狭すぎる
・チューリング・マシンの枠内で理解できる「計算」と、異なる「計算」が、この世界にはある
・等価かもしれない
・全く違うんだ!

471 :デフォルトの名無しさん:2011/10/08(土) 11:15:48.55
脳がバグってる

472 :デフォルトの名無しさん:2011/10/08(土) 16:02:31.12
ここの人たちはJavaの悪名高い検査例外についてどう思う?
特に静的型付け派の人に聞きたい。

473 :デフォルトの名無しさん:2011/10/08(土) 17:48:30.03
http://thinkrelevance.com/blog/2007/05/12/static-typing-and-readable-code.html

474 :デフォルトの名無しさん:2011/10/08(土) 19:04:21.18
大半をExceptionにキャストしても
1個でも強い型が残れば実質的に静的型付けの勝利
0点じゃないなら1点でいいです

475 :デフォルトの名無しさん:2011/10/08(土) 20:02:38.69
>>472
考え無しに握り潰すアホは考えない前提で、
アジャイルでないプロジェクトにおいては有益。

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
意味が全くわからん。
検査例外の問題点がわかってないんじゃないのか?

479 :デフォルトの名無しさん:2011/10/08(土) 23:01:30.56
>>474
Exceptionにキャストしてどうやってまともな例外処理をするつもりなんだ?

480 :デフォルトの名無しさん:2011/10/08(土) 23:14:51.25
困った時は動的型に頼る
ほとぼりがさめたらまた動的型を排除する

481 :デフォルトの名無しさん:2011/10/08(土) 23:34:18.61
動的型 < 体(コード)だけが目当てだったのね!?


482 :デフォルトの名無しさん:2011/10/09(日) 14:49:59.06
実装の詳細を曝す
かといってあまりラップして一般的にしすぎるとthrows Exceptionと大差ない
そもそもその場で例外処理するべきでない場合は多い

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の型を示せ
話はそれからだ

487 :デフォルトの名無しさん:2011/10/09(日) 20:21:27.35
つうかサブタイプも知らずに検査例外がどうこう言うほどのキチガイはそう滅多にいないな


488 :デフォルトの名無しさん:2011/10/09(日) 20:24:44.46
>>486
お前が自由に決めていいよ。

489 :デフォルトの名無しさん:2011/10/09(日) 20:27:14.10
チェック例外はJavaにラムダを導入するのが難しい大きな理由の一つらしいけど
ガチな関数型の世界ではその辺うまくやる手法ってあるの?

490 :デフォルトの名無しさん:2011/10/09(日) 20:42:29.62
> チェック例外はJavaにラムダを導入するのが難しい大きな理由の一つ
なんで?

491 :デフォルトの名無しさん:2011/10/09(日) 20:52:23.85
例えばCallable#call throws Exceptionてあるでしょ
一般的すぎて何投げるかわかんないからExceptionにするしかないんだわ
ラムダが入るとそういうのが激増するから、そのままだとチェック例外が無意味になる

492 :デフォルトの名無しさん:2011/10/09(日) 22:11:47.81
>>488
引数の型がサブタイプで
返り値の型がスーパータイプで
例外の型がサブタイプなら
そのメソッドの型は元のメソッドのサブタイプだ、
という常識もわからないキチガイはホムセンでロープ買ってこい

493 :デフォルトの名無しさん:2011/10/09(日) 22:28:41.94
>>492
で、「メソッドをサブタイプする」ってのは
どうなったんだ?
お前が言ったんだぞ

494 :デフォルトの名無しさん:2011/10/10(月) 02:02:19.39
$ 打ちまくってる感触はどう?


495 :デフォルトの名無しさん:2011/10/10(月) 02:11:10.24
>>492
縛ってほしいのか??

496 :デフォルトの名無しさん:2011/10/10(月) 06:04:05.47
>>493
ばか死ねカス

497 :デフォルトの名無しさん:2011/10/10(月) 08:02:04.13
>>489
Scalaもチェック例外無いし、どうなのかね

498 :デフォルトの名無しさん:2011/10/10(月) 09:20:09.95
>>489
例外は副作用
副作用が発覚したらファンの人が幻滅する

499 :デフォルトの名無しさん:2011/10/10(月) 09:34:08.56
関数型言語の中では例外を直和型で扱うのがあるけど
検査例外よかまだ筋はいいと思うわ
というか検査例外はあれを目指してたんだろうな

500 :デフォルトの名無しさん:2011/10/10(月) 10:18:34.06
Either型を使えばいーさ

501 :デフォルトの名無しさん:2011/10/10(月) 12:26:56.29
審議拒否

502 :デフォルトの名無しさん:2011/10/10(月) 14:45:07.76
例外が副作用とか、頭おかしいんちゃう?

503 :デフォルトの名無しさん:2011/10/10(月) 14:58:44.63
Haskellで型付けされた継続とか使ってみればわかるよ

504 :デフォルトの名無しさん:2011/10/10(月) 16:01:10.81
Haskellで型付けされた例外を使ってみれば
例外が副作用とかプププってわかるよw

505 :デフォルトの名無しさん:2011/10/10(月) 22:22:29.52
a -> Either b Nullpo
これが世界の選択か……

506 :デフォルトの名無しさん:2011/10/11(火) 13:43:09.99
このスレ的にはDartはどうですか?

507 :デフォルトの名無しさん:2011/10/11(火) 14:07:16.94
Googleはちょっとした研究の成果物と実用目的のものを区別しないで大袈裟に発表するからなあ
信用無くすぞ

508 :デフォルトの名無しさん:2011/10/11(火) 15:08:33.06
Dartは静的に型付けできるよ

509 :デフォルトの名無しさん:2011/10/11(火) 16:11:14.05
でもあまりメリットない。

510 :デフォルトの名無しさん:2011/10/11(火) 16:54:01.23
型注釈構文とそれを元に警告を出すlintが標準で付いてくるだけで
動的型付け言語だよね

511 :デフォルトの名無しさん:2011/10/11(火) 16:56:52.34
まあActionScript程度のパフォーマンス向上はあるかもね。
でもその程度。

512 :デフォルトの名無しさん:2011/10/11(火) 17:10:58.59
結局JSになるんじゃ変わりようがないんじゃ?

513 :デフォルトの名無しさん:2011/10/11(火) 19:50:30.02
CoffeeScriptの後だからもうちょっと面白いの期待したがダメだったな
っていうかCoffeeScriptに型アノテーションと名前空間ついた言語を

514 :デフォルトの名無しさん:2011/10/11(火) 19:51:35.36
$ 打ちまくってる感触はどう?

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、型指定できるじゃん。

518 :デフォルトの名無しさん:2011/10/11(火) 21:47:08.28
ほんとに見るところのない言語だな
あくまでリサーチプロジェクトとしても目的がよくわからん
Googleが言ってるJavaScriptは中間言語だというのを実践してみたかっただけ?

519 :デフォルトの名無しさん:2011/10/11(火) 21:51:20.56
>>517
静的に型チェックするけど、間違ってる可能性があっても警告出さない場合があるってさ
どうせなら型推論にしろよ誰得だよ、と思った

520 :デフォルトの名無しさん:2011/10/11(火) 22:37:22.58
なるほど。静的型付けベースで
動的型付けも許容するって位置づけなのか。

521 :デフォルトの名無しさん:2011/10/11(火) 22:54:45.44
Dart使うくらいならGWTだろJK

522 :デフォルトの名無しさん:2011/10/11(火) 22:58:05.12
C#のdynamicキーワードはそんな感じだけどね。Dartは動的型ベースだと思う。

例えるなら、Pythonにはpylintってチェッカーがあって
簡単な型エラーを静的に見つけられるけど、それの強化版って感じ。

523 :デフォルトの名無しさん:2011/10/11(火) 23:34:04.04
Dartの仕様からは「静的厨はIDEで補完できてスペルミスが見つかりゃ満足だろ?」
「動的厨は型を省略できりゃいいんだろ?」的な意図を感じるw

524 :デフォルトの名無しさん:2011/10/11(火) 23:38:42.63
なるほど。静的型に絡んでるやつは変態ということで。

525 :デフォルトの名無しさん:2011/10/11(火) 23:43:09.84
素人考えだけど、DartはC#で言うdynamicとautoをわければよかったのに
なんでもvarじゃ型推論されるケースとダック型になるケースが分かりにくくない?

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にコンパイルすればいいから関係ない。


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は大規模なウェブアプリケーションの記述に非常に適したものになるとわれわれは考えている。


やっぱりそうか。大規模=型か。

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;;

531 :デフォルトの名無しさん:2011/10/12(水) 00:32:57.96
わかりにくい時は型をちゃんと書けばいいわけで、
型推論は難しく考えず、たんなる型を省略した書き方をしても
型を書いたのと同じ効果があると考えればいいのではないかな。

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;;

533 :デフォルトの名無しさん:2011/10/12(水) 00:56:21.16
>>527
ここ読んでみろよ。マジで動的型言語にlint付けただけって
分かってガッカリするぞ
http://www.dartlang.org/articles/optional-types/

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だけで書くよか、はるかに苦痛が和らぐから

538 :デフォルトの名無しさん:2011/10/12(水) 02:14:01.43
Google「DartはJava土方にも理解出来る構文にしました」

539 :デフォルトの名無しさん:2011/10/12(水) 03:17:57.30
GoogleってJava使ってるらしいけど、
Googleよりもお前のほうが土方じゃね?w

540 :デフォルトの名無しさん:2011/10/12(水) 03:34:55.82
静的型付けなら安全化と言うとそうでもない訳で

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よりも
圧倒的に上の言語だという評価はする

545 :デフォルトの名無しさん:2011/10/12(水) 07:27:04.34
静的型検査なんてオプションでいいし、不完全でもいいと判断したわけだよね、Googleは。
どうせ実行してテストするからね。

546 :デフォルトの名無しさん:2011/10/12(水) 07:44:16.63
>>544
varはDynamic型(どんな値を入れても静的型チェッカーが警告を出さない型)になるだけで
型推論するとは書いてない。

547 :デフォルトの名無しさん:2011/10/12(水) 07:54:14.08
型検査を遅延評価

548 :デフォルトの名無しさん:2011/10/12(水) 07:59:58.97
それただの動的型

549 :デフォルトの名無しさん:2011/10/12(水) 08:41:36.35
Dartが静的型付けをサポートしたんで
動的型付け厨房が焦ってるなw

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の型推論もイケてないんだろう

553 :デフォルトの名無しさん:2011/10/12(水) 10:07:30.91
世にあるプログラムのほとんどがC/C++である現実

554 :デフォルトの名無しさん:2011/10/12(水) 10:13:44.11
C++11にはautoが入ったよ

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
 (_フ彡       /

557 :デフォルトの名無しさん:2011/10/12(水) 12:20:43.19
autoがなくても限定された型の中での型推論を式テンプレート使って行うテクニックは存在したよね

558 :デフォルトの名無しさん:2011/10/12(水) 12:32:19.24
C++の関数テンプレートの型推論は最初感動したわ

559 :デフォルトの名無しさん:2011/10/12(水) 12:46:23.74
gcc拡張文法OKならtypeof使でもいいし

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
小梨は圧倒的に人間的に上だという評価をユーロと米国がする

563 :デフォルトの名無しさん:2011/10/12(水) 17:25:20.87
動的型付けでもいまどき型推論で最適化ぐらいはするだろう

564 :デフォルトの名無しさん:2011/10/12(水) 18:11:27.45
最適化しても大して速くならないか、もしくは最適化に途方もない時間がかかるか
好きな方選べ

565 :デフォルトの名無しさん:2011/10/12(水) 18:27:57.48
型を書かなくても静的型チェックできるコード解析ツールすらあるのに、
optional typing で型チェック可能とか言われてもなぁ……

566 :デフォルトの名無しさん:2011/10/12(水) 18:40:03.56
実用的じゃないツールを例にだされてもなぁ……

567 :デフォルトの名無しさん:2011/10/12(水) 19:06:39.40
Pythonはマジでその辺が充実してる

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は何でもはっきりきっちり書く文化だもんな
大規模なプロジェクトだと静的型で書いてるのと変わらんようなのが多い

572 :デフォルトの名無しさん:2011/10/12(水) 20:13:26.87
Dartのoptional typingって、Pythonのtype annotationと比べて何が優れているの?

573 :デフォルトの名無しさん:2011/10/12(水) 20:18:43.03
大体似たようなもんだろ

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イラネ派が
ツール作れないという理由で隅に追いやられてる

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に関しても同じ、型がなくても動くから
ない方が楽に実装できる
つまりまともに設計せずに実装しながら適当に仕様を決めたら
今のメジャーなスクリプト言語の出来上がり
インタプリタにとって型は動作に必要ないコメントだが
型はプログラムに意味を与える最重要なコメントでもある
それを省略してすばらしいなんてなるわけがない
人や開発ツールのために型は強制すべきだった

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使えばいい
高速化を目的としてテンプレート使ってる人は考え直すべき
時代が変わった

584 :デフォルトの名無しさん:2011/10/13(木) 07:25:41.68
へー、型推論や多相型を無くすかわりに型付け弱くするのか?
明らかに安全性とは逆の方向性だなw

つーか、型注釈の有無は静的型/動的型と関係ねーだろ
馬鹿じゃないの?

585 :デフォルトの名無しさん:2011/10/13(木) 07:53:47.50
安全はツールで確保
ツールを作りやすくするための型
つまり安全性を後付で拡張できる言語仕様を超えた安全性

安全性には価値があるけど静的型や動的型の区別なんてどうでもいいよ
頭が固いんじゃないの
人格否定や挑発ばかりやってるとバカになるよ

586 :デフォルトの名無しさん:2011/10/13(木) 07:56:31.39
おまえをみてるとどうやらそれは正しいらしいな

587 :デフォルトの名無しさん:2011/10/13(木) 08:03:58.77
自分が書き込むスレのタイトルくらいは読んだほうが良い

588 :デフォルトの名無しさん:2011/10/13(木) 08:05:32.19
ツール使わずともアノテーションなりメタデータなりでいくらでも拡張可能だし
コンパイル時間を気にしなければTMPのような型計算で静的チェックは可能
そのほうがポータビリティもあるんじゃないか?
ツールで処理すべきなのはちょっと厳しい環境向けだと思うね
たとえばSTLのイテレータのトロさが問題になるケースとか

589 :デフォルトの名無しさん:2011/10/13(木) 09:01:45.32
>>583
時代が変わるというなら、自然言語を早くなんとかしないと。
自然言語は野放しにしているくせに、
プログラムの構文を「最悪のモンスター」という、そういう暴言をやめさせるのが先だ。

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の宣伝

594 :デフォルトの名無しさん:2011/10/13(木) 14:19:35.38
早くなんとかしないと。

595 :デフォルトの名無しさん:2011/10/13(木) 14:31:55.24
それが技術じゃなくてなんなんだ

596 :デフォルトの名無しさん:2011/10/13(木) 14:35:50.68
なんかMSの技術ってここ10年本質的に進歩してないような気がする
.Netに見るべきところがあるとすれば、部分信頼モデルくらいじゃない?

597 :デフォルトの名無しさん:2011/10/13(木) 14:37:23.76
と言って独身家事無能かつ無職で笑いを取ってた

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
本質を抽象する

もし「抽象」が無定義語でなければ
抽象するモノ (目的語) のことを本質と定義できる

602 :デフォルトの名無しさん:2011/10/13(木) 19:04:00.77
Dartに比べたら>>593のasyncの方がよっぽど先進的だわ

603 :デフォルトの名無しさん:2011/10/13(木) 19:15:41.98
快適にプログラミングできるなら
本質的な進歩でなくてもいい

604 :デフォルトの名無しさん:2011/10/13(木) 19:34:04.64
計算可能性だったらたいていのものはみんな同じだしな

605 :デフォルトの名無しさん:2011/10/13(木) 20:08:54.29
型を書くのを省略できるのは
快適なプログラミングへの第一歩

606 :デフォルトの名無しさん:2011/10/13(木) 21:20:35.72
型を省いてもIDEの補完がお馬鹿さんにならないのであれば考えても良い。

607 :デフォルトの名無しさん:2011/10/13(木) 21:23:20.75
(会社のPCの壁紙を見て)
早くなんとかしないと。

608 :デフォルトの名無しさん:2011/10/13(木) 21:32:42.63
変数の型とオブジェクトの型が二つあるのややこしいやん
静的型付けも構造的部分型が主流になればいいのに

609 :デフォルトの名無しさん:2011/10/13(木) 21:38:40.32
動的型付けはデメリットが大きすぎる

610 :デフォルトの名無しさん:2011/10/13(木) 22:02:46.07
>>576
> ていうか、型を二回書くのが嫌なんじゃなくて、型を書くのがいやなんです

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

所で聞きたいのだが、型を書かないで
どうやって特定の型のオブジェクトを生成するんだい?


611 :デフォルトの名無しさん:2011/10/13(木) 22:10:10.09
> auto a=f.create()

これは一度も型を書いてないよね

612 :デフォルトの名無しさん:2011/10/13(木) 22:34:51.28
でも、createの中で書いてるでしょ。

613 :デフォルトの名無しさん:2011/10/13(木) 22:43:50.63
型は値の範囲()
型はドキュメント()
型は仕様()

パラメトリシ(笑)

614 :デフォルトの名無しさん:2011/10/13(木) 22:50:01.67
>>612
createが返すのが例えばクロージャだったら?
中で型を書いてるとは限らんだろ

615 :デフォルトの名無しさん:2011/10/13(木) 22:52:42.04
ソフトウェアがクロージャだけで作れるのならそれでもいいが、
クロージャ以外だと型書いてるでしょ。

616 :デフォルトの名無しさん:2011/10/13(木) 22:53:04.96
つーか、クラスを定義しなくても直接オブジェクトを生成できる言語も在るじゃん

617 :デフォルトの名無しさん:2011/10/13(木) 23:11:26.99
>>608
完全に同意

618 :デフォルトの名無しさん:2011/10/13(木) 23:27:52.63
そこでconceptですよ

619 :デフォルトの名無しさん:2011/10/13(木) 23:56:35.14
型宣言厨はJava以外の言語も触った方がいい。マジで

620 :デフォルトの名無しさん:2011/10/14(金) 00:00:20.09
diamond operatorとかセンスなさすぎてもう

621 :デフォルトの名無しさん:2011/10/14(金) 00:29:03.83
(笑)

622 :デフォルトの名無しさん:2011/10/14(金) 07:50:40.80
簡潔なコードと冗長なコードの例
http://queue.acm.org/detail.cfm?id=2038036

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
> 型推論は重い。

何が重いの?コンパイル?時間計って比較したの?

627 :デフォルトの名無しさん:2011/10/14(金) 18:15:54.48
(一行いくらで単価計算される土方仕事では行数が稼げるから)メリットも大きいし、(型を)書いたほうがいい。

628 :デフォルトの名無しさん:2011/10/14(金) 18:49:06.43
ドカタ仕事だとロリロリなようじょの顔見れるからドカタ仕事のほうがいいよ。


629 :デフォルトの名無しさん:2011/10/14(金) 19:24:31.61
>>626
動的言語の最適化時の型推論と
束縛時やマッチング時の型推論じゃまったく意味が違うからな
どっちの話してるのかよくわからんが一般に前者は軽くて後者は重いだろうな

630 :デフォルトの名無しさん:2011/10/14(金) 19:30:07.91
何言ってんだろこいつ
型書かない方が文字数少なくて済んで、行数稼げるだろ

631 :デフォルトの名無しさん:2011/10/14(金) 19:35:22.36
型オンリーで50行とか普通にあるよ。

632 :デフォルトの名無しさん:2011/10/14(金) 19:44:22.10
強い静的型を持つ言語では型レベルプログラミングが熱い

633 :デフォルトの名無しさん:2011/10/14(金) 19:51:37.86
強い動的型を持つ言語では何が熱いの?

634 :デフォルトの名無しさん:2011/10/14(金) 20:00:58.12
対応するとすればrubyでmethod_missingにフックをかけて滅茶苦茶な事する手法かな
確かsmalltalkでも似たようなものがあったと思う

635 :デフォルトの名無しさん:2011/10/14(金) 20:02:21.85
コンパイラをインタプリタにしちゃうんだよ

636 :デフォルトの名無しさん:2011/10/14(金) 20:15:24.37
>>632
強力なチェックをかいくぐる抜け道を作ってるだけだったりして。
そんな政治的なプログラミングは嫌だ。

637 :デフォルトの名無しさん:2011/10/14(金) 20:27:04.02
型は宇宙

638 :デフォルトの名無しさん:2011/10/14(金) 21:05:45.25
>>636
自分が理解出来ないことイコール危険なこと、ですか?
プライドばかり高くて頭悪い人に多いタイプですね。

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土方(笑)だから。

説得力ある答えを求む。

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

642 :デフォルトの名無しさん:2011/10/14(金) 23:08:49.97
チーフに鼻フックをかけて鬼畜眼鏡で滅茶苦茶な事するかな

643 :デフォルトの名無しさん:2011/10/14(金) 23:10:31.52
>>641
頭のアンダーバーは本質的なところじゃないよ。
両方共文字列扱い。

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

header関数の中では両方共文字列として渡される。

644 :デフォルトの名無しさん:2011/10/14(金) 23:11:05.76
ってか、つられてアンダーバーって書いたけど
ハイフンなw

645 :デフォルトの名無しさん:2011/10/14(金) 23:25:58.81
>>640
固定で決まっているって、なんでわかるの
じつは固定ではない可能性を想定するほうが安全じゃないの

646 :デフォルトの名無しさん:2011/10/14(金) 23:27:50.55
Perlにはキーワード引数が無いからハッシュで真似してるだけじゃね

647 :デフォルトの名無しさん:2011/10/14(金) 23:32:44.28
>>645
> 固定で決まっているって、なんでわかるの
ソースコード見たから。

ソースコードにもご丁寧に、”文字列で”書いてあるよw

648 :デフォルトの名無しさん:2011/10/14(金) 23:35:37.85
wwww

649 :デフォルトの名無しさん:2011/10/14(金) 23:37:39.67
キーワード引数やオプション引数そのものを批判してるのか、
上記の機能をハッシュでエミュレートしてるのを批判してるのか、
ハッシュのキーにmutableオブジェクトを使ってるのを批判してるのか、
あるいはそれ以外なのかが分からない

650 :デフォルトの名無しさん:2011/10/14(金) 23:39:06.39
>>646
じゃあ、他の動的型付け言語なら大丈夫なんですかね。
ハッシュばかり使ってある糞コードながめて、
おいおい、このハッシュ、どんなキーが入ることがあるんだよって、
うんざりすることはないんですかね。

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

だから本質的な作業ではないところ(コーディング)で発生するミス、
つまりスペルミスも検出できないようなコーディングスタイルは
大嫌いなんだよね。

651 :デフォルトの名無しさん:2011/10/14(金) 23:39:53.89
>>649

>>650で書いたとおり

652 :デフォルトの名無しさん:2011/10/14(金) 23:42:00.27
Pythonはキーワード引数がある
Rubyはキーワード引数は無くてハッシュ
PHPは知らない

653 :デフォルトの名無しさん:2011/10/14(金) 23:43:38.91
Rubyオワタ\(^o^)/

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パターンみたいな
手間が必要なのも何とも。

656 :デフォルトの名無しさん:2011/10/14(金) 23:52:27.18
>>640なコードをJavaで書く場合、キーワード引数やデフォルト引数が無いかわりに

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

のようなインターフェースを用意するのが一部で流行と聞いた

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();

こっちも大差ないでしょ?
くだらないミスで時間を取られることもない。


659 :デフォルトの名無しさん:2011/10/15(土) 00:00:15.35
>プライドばかり高くて頭悪い人に多いタイプですね。
反論できなくなったら人格攻撃に走るのは
敗北を認めたことになりますよ
プライドばかり高くて頭悪い人に多いタイプですね。

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のコードも何年かしたら同じように非難されるんだろう




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な引数の多いメソッドごとに用意する
必要があるわけでこれはこれで面倒。

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
でそうやって、高度な機能を追い求めると
静的型付け言語に分があるんだよな。

実行しないでも分かる=コードを書いているときに分かる だから。

667 :デフォルトの名無しさん:2011/10/15(土) 00:38:21.95
もしかしてコーディング=製造の人か

668 :デフォルトの名無しさん:2011/10/15(土) 00:38:44.79
Perlでモダンに書くなら、Mooseを使う。MooseはPerl6のOOP機構をPerl5に導入するもので、静的に型を指定する事が可能になる。
ただ、Mooseは重いんで、そこまでの高機能でなくて良いなら、Smart::Argsとかの引数バリデーションモジュールを使う。この手のモジュール使うと、やっぱり型指定出来るようになる。

669 :デフォルトの名無しさん:2011/10/15(土) 00:40:01.69
ただ、名前付き引数は欲しい機能だよね。Perl6にはある。

670 :661:2011/10/15(土) 00:41:21.59
>>662
うん、Perlに置き換えたらの話。

一応Class::Structモジュールが古くから標準で入ってる。
モダンにやるならMooseだろうね。

671 :デフォルトの名無しさん:2011/10/15(土) 00:53:56.09
>>641
>>643
先頭にー(ハイフン)を付けるのは、連想配列のキーが文字列であることを表すため。
Perlは関数の()を省略出来て、連想配列のキーは文字列であっても引用符でくるまなくてもよいので、fooだと関数なのか文字列なのか分からない。
use strictは変数宣言を強制するのに使う。別の話。

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

だからこそコーディングの手間は極力減らすという考えにたどり着く。
そのための静的型付け言語。

673 :デフォルトの名無しさん:2011/10/15(土) 00:59:09.26
コーディングに高度な機能を求めるのは、
コーディングが大好きだからじゃなくて
コーディングを極力無くしたいからなんだよ。
勘違いしないでよね。

674 :デフォルトの名無しさん:2011/10/15(土) 00:59:50.27
ああやっぱりプログラミング=設計という考え方を盛大に勘違いしている人か

675 :デフォルトの名無しさん:2011/10/15(土) 01:22:28.74
>>672-674
俺が書くのもなんだけど
40秒でレス返すってどんだけ張り付いてるんだよ

676 :デフォルトの名無しさん:2011/10/15(土) 01:26:02.25
>>674
へぇ、なにか意見があるのかい?
なら言ってみたら。

677 :デフォルトの名無しさん:2011/10/15(土) 07:02:19.05
>>672
コーディングの手間を減らしたいなら
名前付き引数を持ってる言語を使うべきじゃないか?
言語組み込みの機能は良くテストされてるが、
>>658のような方法は手間がかかるだけでなく
そこにバグが潜む可能性がある

678 :デフォルトの名無しさん:2011/10/15(土) 07:38:35.65
>>677
良くテストされたライブラリのAPIとしては>>658の方法も十分にOK。
というか山ほどある。

コーディングの手間だけで使う言語を選べるのであればどれほど楽か。

679 :デフォルトの名無しさん:2011/10/15(土) 07:47:15.37
つまり自分では名前付き引数を持つメソッドを書かず、
他所様の書いたライブラリを使うのみってこと?

> コーディングの手間だけで使う言語を選べるのであればどれほど楽か。
静的型検査の有無だけで使う言語を選べるのであればどれほど楽か。

680 :デフォルトの名無しさん:2011/10/15(土) 09:26:48.65
ああやっぱり勘違いしている人か

681 :デフォルトの名無しさん:2011/10/15(土) 09:33:38.95
ていうか、理論上は「変数」に型がなくても「文字列リテラル」は静的に解析できる。
リテラルは変数よりも情報が多いので、変数ばかり解析しているのは勿体ない。

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

そりゃそうだろうw
だから静的型付け言語を使うべきになるんだよ。

683 :デフォルトの名無しさん:2011/10/15(土) 10:51:59.51
理論上は、というか普通のまともな処理系なら文字列リテラルも変数の名前もハッシュ値になるでしょ

684 :デフォルトの名無しさん:2011/10/15(土) 10:58:35.16
メタプログラミングを実行時にばっかりに頼る傾向にあるのが間違い。
Perlのコンパイルフェーズに処理を実行できる仕組みをみなすべき。

コンパイル時メタプログラミングを採用すれば、
実行時メタプログラミングの必要性は9割減ると思っている。

685 :デフォルトの名無しさん:2011/10/15(土) 11:00:46.53
弟の部屋以外に視野角固定できますよーに

686 :デフォルトの名無しさん:2011/10/15(土) 11:01:15.48
動的型言語にも名前付き引数あるし…

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

688 :デフォルトの名無しさん:2011/10/15(土) 11:05:24.90
>>687
ただし、それらは実行時にならないとわからないのが問題。

実行時にならないとわからないのと
実行前にわかるのとでは、大きな差がある。

689 :デフォルトの名無しさん:2011/10/15(土) 11:10:11.57
まぁこのスレは敷居が高いから底辺x高さ÷2がないと無理

690 :デフォルトの名無しさん:2011/10/15(土) 11:11:10.82
ようするにjson投げてるようなもんだろ

691 :デフォルトの名無しさん:2011/10/15(土) 11:13:03.74
ハッシュで渡す場合省略可能な引数でなおかつその引数名をタイポで間違えたら
実行時にもエラーでなくて動かして想定と違う動きして初めて分かるとかあるんじゃ?

692 :デフォルトの名無しさん:2011/10/15(土) 11:57:15.73
>>688
一度も実行されてないコードをリリースするの?

693 :デフォルトの名無しさん:2011/10/15(土) 11:59:10.09
>>692
なんでいきなりそんな話になるの?

アメリカにつくのであれば、
早くても遅くても交通手段は関係ないという発想の人?

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
リグレッションテスト?なにそれおいしいの?みたいな会話でちょっと怖いぞ。


701 :デフォルトの名無しさん:2011/10/15(土) 12:11:15.84
>>697
早さに差が出ると思ったのではなく
実際に早さに差が出ている。

競争してみるか?
20行ぐらいのコードを書いて、書いてる途中にわざとタイポいれて
(わざとタイポ入れるが、入れたことに気づかないふりをする)

お前は実行してから分かる方法、
俺は書きながらリアルタイムにタイポを検出してくれる方法

どちらが早く修正できるか。

702 :デフォルトの名無しさん:2011/10/15(土) 12:11:27.92
さあ、ここで静的チェッカーで名前付き引数のエラーが分かる動的型言語Pythonさんの参上

703 :デフォルトの名無しさん:2011/10/15(土) 12:12:48.52
>>701
Javaで20行なら動的型言語では5行くらいになるが……

704 :デフォルトの名無しさん:2011/10/15(土) 12:15:24.03
>>699
> え?ユニットテストって一部だけ実行できるんだぜ?知らないの?

できないよ。

まずそれなりのスケールがあるプロジェクトではな、
ユニットテストを実行できる最小限のクラス、その中に複数のテストコードが含まれる。
数が大きければ、テストにも時間がかかる。そしてその中の一部を実行することはできない。
だいたい何個もあるのに、その中の一つを選ぶとかめんどくさすぎるw

そしてそれら実行した所で、エラーになったことはわかるが、
なにが原因でエラーになったかは教えてくれない。

ユニットテストを使うにしろ、その問題を解決するのは大変なんだよ。
ユニットテストよりも先に解決できるなら、そっちの方が時間がかからない。

705 :デフォルトの名無しさん:2011/10/15(土) 12:17:04.97
>>703
> Javaで20行なら動的型言語では5行くらいになるが……
それもならない。

Javaだとオーバーヘッドの分、つまりクラス定義だとか
そんなコードが+αされるが、実際関数の中身なんて大差ない。

706 :デフォルトの名無しさん:2011/10/15(土) 12:17:18.72
>>704
え?お前んとこのユニットテストはモックやスタブを使ってないの?

707 :デフォルトの名無しさん:2011/10/15(土) 12:18:27.02
>>706
話理解できてる?w

クラスを単体でテストするという話じゃなくて
テストの一部を実行するって話だろw

あぁ、一つのクラスのテストに
大量にテストコードがあるという
規模を想定できないかw

708 :デフォルトの名無しさん:2011/10/15(土) 12:20:54.58
>>707
ある特定のクラスの特定のメソッドをテストする特定のテストメソッドだけを
呼び出す事も簡単に出来るが……?

709 :デフォルトの名無しさん:2011/10/15(土) 12:20:54.81
動的型付け言語だとインタプリタな言語多いからな
テストがお手軽なのは動的型付け言語という事になってしまうな

710 :デフォルトの名無しさん:2011/10/15(土) 12:23:41.21
>>708
だから、発想ができる(アメリカにつく)のなら
それまでにかかる時間を無視してるとw

競争してみるか?
20行ぐらいのコードを書いて、書いてる途中にわざとタイポいれて
(わざとタイポ入れるが、入れたことに気づかないふりをする)

お前は実行してから分かる方法、
俺は書きながらリアルタイムにタイポを検出してくれる方法

どちらが早く修正できるか。


711 :デフォルトの名無しさん:2011/10/15(土) 12:28:15.61
>>710
え?動的型言語ではIDE/エディタ禁止?

712 :デフォルトの名無しさん:2011/10/15(土) 12:29:08.51
つーか、競争ってどうやんの?w

713 :デフォルトの名無しさん:2011/10/15(土) 12:33:42.78
20行ぐらいのコードなら、ちょうどここ>>271にあるじゃない

714 :デフォルトの名無しさん:2011/10/15(土) 12:40:15.22
静的型付けで一応の型推論がありDbCのサポートがありユニットテストが言語組み込みの
Dが最強ということでよろしいか

715 :デフォルトの名無しさん:2011/10/15(土) 12:52:32.51
なんか「アメリカ、アメリカ」言ってる奴から
ほのかなウォーターフォールオンリー臭を感じる。

716 :デフォルトの名無しさん:2011/10/15(土) 13:26:20.68
>>676
このスレとは関係無いけど
ネット上でよく見るプログラミング=設計という主張は普通はコーディングを含めてプログラミングと言ってるからな
「プログラミングとは設計書をコードに起こす作業であって誰でも出来る」っていう考え方への反論みたいなもんだから

717 :デフォルトの名無しさん:2011/10/15(土) 16:30:14.27
>>710
おまえま>>367を百回音読しろ

718 :デフォルトの名無しさん:2011/10/15(土) 16:40:43.96
動的型言語はアノテーションてんこ盛りで強いテストすればいいし
静的型言語は型計算と静的解析ツールとアサーションだな俺の場合は
型うんぬんより、用件に対してふさわしくない言語や処理系使うのが一番危険だ

719 :デフォルトの名無しさん:2011/10/15(土) 18:30:09.37
動的型付け・・・小規模開発向け
静的型付け・・・大規模開発向け

720 :デフォルトの名無しさん:2011/10/15(土) 18:40:13.68
テストしこしこ作ってるとき、これ静的言語に書き直したほうが早いんじゃないのと思ったら負け

721 :デフォルトの名無しさん:2011/10/15(土) 19:02:59.36
つーか、女子と競争ってどうやんの?wwwwwwwwwwwwww

722 :デフォルトの名無しさん:2011/10/15(土) 19:25:35.53
>>720
ここは静的型付け言語だからってテスト書かないようなプログラマの来るスレじゃないよ
テストの無いプログラムが安全なんて言えないからね

テストは書く前提で、それでも両者のどちらが安全性/生産性が高いかで論争してる

723 :デフォルトの名無しさん:2011/10/15(土) 19:31:24.64
動的型付け・・・若者向け
静的型付け・・・高齢者向け

いや寄る年波には勝てずメソッド名とかも頻繁に忘れがちになったし
長いキー入力もしんどいのでIDEがより的確にメソッド名一覧を表示
したり補完したり出来る静的型の方がなんというか、優しい。


724 :デフォルトの名無しさん:2011/10/15(土) 19:35:50.15
wikipediを見ると、

>安全でない弱い静的型付け
>宣言型の安全でない強い静的型付け

みたいな表記があるんだけど、
安全であるないとか、強い弱いとかってどういうこと?

725 :デフォルトの名無しさん:2011/10/15(土) 19:58:57.63
>>723
そりゃなぁw

メソッドを覚えるとか、キーを入力するとか
そんなのはコーダーの仕事であって
プログラマの仕事じゃねぇからな。

コンピュータでできることを
人間が努力してやるなんて流行らないよ。

726 :デフォルトの名無しさん:2011/10/15(土) 20:01:22.88
>>722
> テストは書く前提で、それでも両者のどちらが安全性/生産性が高いかで論争してる

テストは書く前提というけどさ、
そのテストは完璧であるという前提なの?

今まで人生で完璧なテストなんて見たこと無いんだけど。
(もしそんなのがあれば、バグがないソフトがあるということになる)


727 :デフォルトの名無しさん:2011/10/15(土) 20:05:54.55
>>726
そういう前提を置いたつもりは無いよ
だからテストでカバーしきれない静的型検査の安全性を主張してもいいと思う
というか、俺は静的型言語の方が好きだし

でもテスト自体は書くだろと

728 :デフォルトの名無しさん:2011/10/15(土) 20:17:02.35
ttp://livedoor.2.blogimg.jp/hatima/imgs/6/a/6ab0f506.jpg

729 :デフォルトの名無しさん:2011/10/15(土) 21:07:53.78
> コンピュータでできることを
> 人間が努力してやるなんて流行らないよ。

だから型推論のある言語が良いってことじゃん
コンピュータが推論できるのに人間が型書くなんてアホすぎ
型情報が必要ならコンパイラにでも出力させとけ

730 :デフォルトの名無しさん:2011/10/15(土) 21:17:03.88
>>729
型推論って、静的型付け言語の機能だってわかってる?

変数に型がない言語だと実行時の型を
使うだけだから推論する必要ないよね。

731 :デフォルトの名無しさん:2011/10/15(土) 21:18:01.30
Haskellが最強ってことだよ言わせんな恥ずかしい

732 :デフォルトの名無しさん:2011/10/15(土) 21:18:32.35
おっと型推論もない巷の諸々の動的型付け言語をDisるのはそこまでだ。

733 :デフォルトの名無しさん:2011/10/15(土) 21:19:09.60
型があるのが嫌なのと、
型はあって欲しいが、書くのが面倒だってのは
全く別の話。

書くのは面倒だが、型が欲しい。 なら推論だ!
これが型推論の本質。

734 :デフォルトの名無しさん:2011/10/15(土) 21:50:43.87
ま、HaskellやOCamlが使えるなら
大規模なプログラムを動的型言語で組む理由は無いな

735 :デフォルトの名無しさん:2011/10/15(土) 22:52:44.68
つまりC#最強って事か。

736 :デフォルトの名無しさん:2011/10/15(土) 22:56:02.26
それは無い

737 :デフォルトの名無しさん:2011/10/15(土) 23:10:30.32
   ./            ,,,,;;::''''' ヽ
  /    ,,,,;;:::::::::::::::       __   ヽ
  |   .  __       '<'●,   |
  |.   '"-ゞ,●> .::            |
  |           ::: :⌒ 、      |
  ヽ.      ;ゝ( ,-、 ,:‐、)      |  
   l..            |  |      |  じゃかまっしゃ!深夜騒音
   |        __,-'ニ|  |ヽ_     |   クズおんなが女子刑務所行く
    ヽ:        ヾニ|  |ン"    /__  までやるで!
    .ヽ:        |  l, へ      ::::ヽ,
     l.:`.         / /  , \  /ヽ  ::\
     `、:::::       |    ̄ ̄\/ ノ    :::ヽ
      |::::::      |      ー‐/ /  

738 :    にしむら ひろゆき(38)   :2011/10/15(土) 23:13:15.52
 









 

739 :デフォルトの名無しさん:2011/10/16(日) 00:50:13.25
Java とか C++ とか, ダイナミックキャスト的な機能を
持ってるだけで静的型言語と言えなくなる気がするんだ


740 :デフォルトの名無しさん:2011/10/16(日) 01:01:38.21
>>739
そうだよ。今はもう静的言語なんて存在しない。
静的型付け言語はあるけどね。

741 :デフォルトの名無しさん:2011/10/16(日) 01:33:30.89
つまりgo最強ってことか

742 :デフォルトの名無しさん:2011/10/16(日) 08:56:07.44
ま、Javaでデザインパターンとかすると圧倒的に冗長なので、
それで静的型付けに悪い印象をもっちゃうんだろうけど
静的型付け = Java じゃないからな

743 :デフォルトの名無しさん:2011/10/16(日) 09:16:06.07
>>739
オブジェクトの型はキャストするが、メソッドの型をキャストする事はない。
型推論なら関数の型は自動的に決まるが、データコンストラクタは手で書く。
つまりデータは動的にしてアルゴリズムは静的にすればよさそうだ。

744 :デフォルトの名無しさん:2011/10/16(日) 09:18:33.41
>>742
弱い静的型付け or ナンチャッテ静的型付け = Java/C++

745 :デフォルトの名無しさん:2011/10/16(日) 09:22:33.33
parametric polymorphism で良かったりしない? > データは動的にしてアルゴリズムは静的

746 :デフォルトの名無しさん:2011/10/16(日) 09:40:44.28
最近、オブジェクト指向というモノについて懐疑的になりつつあるんだけど、
継承(inheritance)を含む型システムについて明解な解はあるのかな?
自分なりにあれこれ調べてるけど、MLやHaskellの型推論の基礎になっている
型システムでは、いわゆるSmalltalkから始まる
「オブジェクト指向を形式的に定義」
できていないのが現実じゃないかと思っている。

# だからOCamlのO(Object-oriented)の部分は歪んでいるし、
# JavaではNullPointerExceptionでC++ではSegmentation faultが起きる。
# かといってHaskellの純粋関数型パラダイムは(一般人には)とうてい受け入れがたい。

もし知っているヤシがいたら教えてくれ、いや教えておくんなさいまし、お願い!!
# キーワードやヒントだけでもいい、あとは自分で調べるから....

747 :デフォルトの名無しさん:2011/10/16(日) 09:45:31.87
継承なんてただの型と型の間に成り立つ半順序関係だけど何か?

748 :デフォルトの名無しさん:2011/10/16(日) 09:47:05.33
OCamlのOは(特に見た目的に)他の機能と浮いてるし、
モジュールがあるから殆ど使わないけど、
型システム(構造的部分型、列多相)は悪くないんじゃないの?

749 :デフォルトの名無しさん:2011/10/16(日) 09:50:04.77
>>747
つうか、包含関係だな。

750 :デフォルトの名無しさん:2011/10/16(日) 09:54:19.03
多重継承を許すなら、メソッドの探索順序をどうするかは考えなきゃいかん
メタクラスで探索順序をユーザ定義できるようにするか否かも

751 :デフォルトの名無しさん:2011/10/16(日) 09:54:47.21
>>749
こういう言い回しのジョークがあるんだよ
有名なのはWadlerの「モナドなんてただの自己関手の圏におけるモノイド対象ですが何か?」

752 :デフォルトの名無しさん:2011/10/16(日) 10:05:52.26
>>746
ヒント
class Left<a> implements Either<a,b>
class Right<b> implements Either<a,b>

753 :デフォルトの名無しさん:2011/10/16(日) 10:29:23.43
>>747,749
それは理解していますけど(理解しているつもりだけど)、self.any_message という式で
selfのデータ型を推論できる型システムはあるのか?という疑問です

>>748
オリジナルのMLを引き継いだ型システムには何ら問題は無い、と見ています。
問題は後付けのOの部分で、これが「OOな関数型言語の設計」として破綻している、
言い換えると、OCamlの存在自身がOOと関数型の相性の悪さ(?)を証明している、という指摘です

>>750
単一継承ですら、形式的に定義されていないんじゃないかと(少なくとの自分の知る範囲では....)

754 :デフォルトの名無しさん:2011/10/16(日) 10:40:37.67
>selfのデータ型を推論
単に型クラス、型インスタンスでできるように思えるけど

755 :デフォルトの名無しさん:2011/10/16(日) 11:09:18.82
>>753
ちょっと興味があるから、どのように破綻してるのか説明して
例があると分かりやすいかも

あと単一継承の場合スーパークラスの方向へ遡って探索するだけじゃないの?

756 :デフォルトの名無しさん:2011/10/16(日) 11:16:29.18
多重継承のように順序付けできないことがあるっての半順序たる所以なんだよな
十分形式化できてるじゃん

757 :デフォルトの名無しさん:2011/10/16(日) 11:33:53.48
>>754
たぶん(自分を含めて)推論なんてできて当たり前だろって思うのが普通なんでしょうけど、
少なくともOCamlのOOPはメソッドを動的結合をするので、いわゆる method missing 例外が多発します。
だからそれがOCamlコミュニティでも(OCamlの)Oは敬遠されている理由のようです。(ここは推測ですが....)

自分としても、強い静的型付け言語であることを自称しているOCamlなんだから、
メソッド未定義みたいなミスは、コンパイル時に型エラーとして検出されるのが当然だと考えていました。
それが、現実には(現実のOCamlでは)型検査されない、言い換えると「型システムの破綻」という残念な現実があります。

そこから、OOと関数型の相性の悪さとか、OOPそのものへの疑念が始まっています。

758 :デフォルトの名無しさん:2011/10/16(日) 11:37:03.60
>>757
どうやったらOCamlの型システムでmethod missing例外出せるの?
Objモジュール使うのは無しで

759 :デフォルトの名無しさん:2011/10/16(日) 11:44:43.53
>>755
OCamlのOOPは(Smalltalkのように)メソッドを実行時に動的束縛します
でもこれって静的型付け言語としては違反じゃないの?という単純な疑問です
OOの型システムが形式に定義できているのなら、こんなことは起こりえないんじゃないかと思います

# OCamlはかじった程度なんで、初心者ゆえの誤解があるかもしれません
# もしもOCamlでOOPしても型検査は保証できるよ!という指摘があれば嬉しいです

760 :デフォルトの名無しさん:2011/10/16(日) 11:45:45.03
なんでこう頭が硬いんだろうな。

100%完璧じゃないから使い物にならんとかさ。
別に完璧じゃなくても使えるだろ。よく考えてみろよ。

ちょっとぐらい、型付けがない部分があったからといって
型システムの破綻とまで大袈裟なことになるわけねーだろ。

別に俺らは、物理法則を定義する完璧な統一理論とか
目指しているわけじゃねーよ。

761 :デフォルトの名無しさん:2011/10/16(日) 11:48:56.98
OCamlでOOPしても静的型検査されるよ
動的束縛だけど型が一致しないものは許されない
そこが duck typing と structural subtyping の違いだね

762 :デフォルトの名無しさん:2011/10/16(日) 11:50:46.49
あと、動的に束縛するからといって、
型がないということにはならんからな。

動的に束縛された時、そこに絶対メソッドがあると保証される。
つまり変数に入れたときに、その型であることがちゃんと保証されてるなら

「動的に束縛される静的型付け言語」だ。

763 :デフォルトの名無しさん:2011/10/16(日) 11:53:39.28
Class obj = getHogeHoge()

obj.foo()

例えばこれ、動的に束縛される。
つまりこれは動的言語だ。

だが、getHogeHogeはClass型、もしくはそれと互換性がある型を
返さないとコンパイルエラーになるのであれば、それは静的型付け言語だ。
(そうなっていないのであれば、動的型付け言語。)

動的に束縛されるからといって、動的型付けとは限らない。


764 :デフォルトの名無しさん:2011/10/16(日) 11:55:54.48
というか、最近では静的言語なんてマイナーな分野。
現在使われてるほとんどの言語が動的言語だろう。

静的言語といえばCOBOLとかFORTRANとか古いBASICぐらいなもんだろ。


765 :デフォルトの名無しさん:2011/10/16(日) 11:59:57.27
継承の関係に下限、つまりすべてのクラスを継承したものがいて
定義上そいつはあらゆるメソッドを持ってる
そのメソッドがmethod_missing例外を投げるという実装になってるだけ
型システムの上では全て上手いこといってる、ただそれが要求に沿うかってのは別問題だけども
そいつの名前は大抵NullとかBottomとか言うんだけど
で、こいつがいないとメソッドの解決が停止しないつまり存在しないメソッドを呼んだ時点で無限ループだ
そう考えると例外の方が幾分かマシじゃね?w

766 :デフォルトの名無しさん:2011/10/16(日) 12:51:08.16
>なんでこう頭が硬いんだろうな。

にぎにぎ

767 :デフォルトの名無しさん:2011/10/16(日) 13:02:38.34
>>762
>「動的に束縛される静的型付け言語」だ。
意味不明

768 :デフォルトの名無しさん:2011/10/16(日) 13:13:20.25
>>767
型は静的に束縛されて、値(メソッド)は動的に束縛される。
JavaでもC++のvirtualでもそうだろ。

769 :デフォルトの名無しさん:2011/10/16(日) 13:41:04.64
> 少なくともOCamlのOOPはメソッドを動的結合をするので、いわゆる method missing 例外が多発します。

恐ろしいデマだな……信じるやつがいたらどうするんだ

770 :デフォルトの名無しさん:2011/10/16(日) 13:44:32.44
>>768
言い換えると、
「型宣言はコンパイル時に検査できるけど、値(の型)は実行時にならないと検査されない」
ということですね。
スレタイに沿って考えるに、そんなレベルで「静的型付け言語であれば安全なソフトを作れる」と主張するには
あまりに無理がありすぎじゃないかと....
いったい「動的に束縛される静的型付け言語」と「動的型付け言語」のどこに差があるのでせうか?

静的型付け言語に期待されるのは、(OOPを含めて)型エラーはコンパイル時(=実行前)にすべて検出できる、
というのが底辺プログラマの一般認識じゃないかと思っていますけど....

771 :デフォルトの名無しさん:2011/10/16(日) 13:46:39.70
>>770
だから型エラーは静的に検出できるっていってるじゃん

772 :デフォルトの名無しさん:2011/10/16(日) 13:58:10.70
値の型は実行時にしか決まらないけど、
その値の型はすべて静的に決まる変数型の部分型になってる
(だから型エラーは発生しない)というのが継承

773 :772:2011/10/16(日) 14:02:16.40
あ、構造的部分型なら継承の必要は無いから、上のは
静的型OOPの性質ってことに訂正

774 :デフォルトの名無しさん:2011/10/16(日) 14:07:28.68
>>770
> 静的型付け言語に期待されるのは、(OOPを含めて)型エラーはコンパイル時(=実行前)にすべて検出できる、
> というのが底辺プログラマの一般認識じゃないかと思っていますけど....

底辺プログラマってのはお前のことを指すのか?w

775 :デフォルトの名無しさん:2011/10/16(日) 14:11:49.51
>>770
> 「型宣言はコンパイル時に検査できるけど、値(の型)は実行時にならないと検査されない」
> ということですね。
違う。

値の型は静的に検査できる。これは単純に型が決まるという意味ではなく
”互換性がある”型に決まるという意味。

Interface i = getHogeHoge()

この場合、iの中に入る型は実行時に決まるが、
iという型と互換性がある型であることは決まる。
これもまた、静的型付け言語において、静的に型付けされた状態。

そして、型は静的に型付けされているが、
そこに値が入るのは実行時であるため動的言語。

776 :デフォルトの名無しさん:2011/10/16(日) 16:29:44.68
>>764
え、c/c++とjavaは。。。


777 :デフォルトの名無しさん:2011/10/16(日) 16:45:11.91
>>776
動的な静的型付け言語ですが?

778 :デフォルトの名無しさん:2011/10/16(日) 19:55:18.37
C++だって仮想メンバ関数(Java的に言うとメソッド)は実際にオブジェクト(Java的に言うとインスタンス)が生成されるまでどのクラスのメンバ関数を呼ぶのか不定だしなぁ

779 :デフォルトの名無しさん:2011/10/16(日) 20:28:03.03
ただしC++やJavaの静的型チェックはうんこですけどね

780 :デフォルトの名無しさん:2011/10/16(日) 21:11:30.56
JavaやC#の参照型が全てnullを許容する仕様は頂けないな

CやC++に関しては、用途を考えると仕方ないんじゃないの
メモリには(少なくとも一般には)型を示すタグやラベルなんてついてないし
ただのバイト列と見做せる空間に過ぎない
メモリを直接相手にするようなプログラムを書くのに使われる言語がCなわけだから
void *, union, キャストなどでお嬢様から見ればド汚いtype punningや
絶対番地アクセスみたいなことができないようではむしろ不自由する
C++はCと違って上品ぶって型安全性を喧伝してるけど、所詮もとはCだからな



781 :デフォルトの名無しさん:2011/10/16(日) 22:08:00.15
ぬるぽ

782 :デフォルトの名無しさん:2011/10/16(日) 22:15:05.45
>>780
Haskellでも、リスト型は全て空リストを許容する仕様になっている。
無限リストなら空リストは不要なのに。

無限リスト専用の型を定義することは一応できるけど
車輪の再発明と言われたくないのでみんな制約の弱いデータ構造を再利用している。

783 :デフォルトの名無しさん:2011/10/16(日) 22:39:44.13
>>782
>>780
>無限リストなら空リストは不要なのに。

「集合」ベースだって事を忘れないように。

784 :デフォルトの名無しさん:2011/10/16(日) 22:46:23.75
空リストなんかより⊥をなんとかしてくれ

785 :デフォルトの名無しさん:2011/10/17(月) 06:12:04.19
空リストの先頭要素へのアクセスは
現状のようにランタイムエラーで止まるのがいいか、
無限リストに永遠に待たされるのがいいか、
選択するがいい。

786 :デフォルトの名無しさん:2011/10/17(月) 07:40:50.08
空リストの先頭要素へのアクセスなんて
パターンマッチ使ってたら書くこと無いだろ

787 :デフォルトの名無しさん:2011/10/17(月) 08:38:54.12
定理証明系みたいな網羅することが強制されるような類の言語ならそういえるかもしれんが
少なくともCamlやHaskellじゃそれはない

788 :デフォルトの名無しさん:2011/10/17(月) 08:42:56.30
パターンマッチが網羅的じゃなかったら警告出るから、
意図的に警告を無視しなければねーよ

789 :デフォルトの名無しさん:2011/10/17(月) 12:04:15.94
JavaがRuby並みにランタイムエラーが出る言語だからって
HaskellやOCamlまで一緒にすんなよw

790 :デフォルトの名無しさん:2011/10/17(月) 17:28:33.93
リスト使うなら空っぽかどうかのチェックしようぜ。
空っぽを許容しないならそういうデータ型を自前で用意しようぜ。

791 :デフォルトの名無しさん:2011/10/17(月) 23:23:37.49
このスレはもうこれで 終わりにしよう。
次は
動的言語 VS 静的言語 バトルロイヤル
くらいにして 見たらいいよ。 LLバトルロイヤルはあるけど
煽り屋さんにはフレームスレは必要だろうよ。:p

792 :デフォルトの名無しさん:2011/10/17(月) 23:36:08.85
いや、ここは元々が隔離スレなんだけど....

793 :デフォルトの名無しさん:2011/10/17(月) 23:39:41.71
ここまでの流れ、Javaer/C#reが自分の無知をさらけだして
自滅しただけだし....

794 :デフォルトの名無しさん:2011/10/18(火) 00:51:18.01
ということにしたいんですねw

795 :デフォルトの名無しさん:2011/10/18(火) 01:05:25.83
俺、リアルではIT土方と接点無いから
土方の知識レベルが分かるこのスレは面白かった

796 :デフォルトの名無しさん:2011/10/18(火) 01:11:32.76
まあ、小規模なプログラムとか個人開発なら型のないスクリプト言語もいいんじゃない?Googleもそういってる事だし。

797 :デフォルトの名無しさん:2011/10/18(火) 01:18:36.31
MSWORDの話はもうこれで 終わりにしよう。

798 :井の中の蛙:2011/10/18(火) 01:22:06.07
>>795
そっか、2ちゃんねるで世界を知ることができたんだねw



799 :デフォルトの名無しさん:2011/10/18(火) 01:32:56.97
まぁ素直でカワイイんじゃないかなw

800 :デフォルトの名無しさん:2011/10/18(火) 07:40:55.47
うん。底辺ってどんなもんか知りたかったから
大変ためになった。ありがとうw

801 :uy:2011/10/18(火) 11:13:47.34
2chは土方の本音が見えるしな

普段コミュ障の連中だから
リアルじゃ話しかけてもきょどってて話にならん

普段こいつらゴミが何を考えて生きているのか
それはネットをみないとわからない

802 :デフォルトの名無しさん:2011/10/18(火) 11:46:53.39
>>221
> 2chは土方の本音が見えるしな
ほんとだ

> 221 名前:uy[sage] 投稿日:2011/10/01(土) 18:39:59.51
> 死ね 

ttp://hibari.2ch.net/test/read.cgi/tech/1248205502/829+834
> 829 名前:デフォルトの名無しさん[] 投稿日:2011/10/02(日) 08:44:21.80
>   法律でC言語の使用利用流通教育販売製造を禁じるべき時期にあると考える。
>
> 834 名前:uy[] 投稿日:2011/10/18(火) 11:16:09.93
>   >>829
>   同意
>  (C言語なんかを使う) ゴミグラマは死ね  死ねゴミグラマ


803 :デフォルトの名無しさん:2011/10/18(火) 11:52:53.07
タチの悪いコテハンってこのスレで引き取っておいてくれよ。
そのほうがほかは幸せだわ。

804 :デフォルトの名無しさん:2011/10/18(火) 12:24:39.42
つーか、名指しされたわけでもないのに
土方と言われて反応するのってどうよ?
自覚症状あるのかよ

805 :デフォルトの名無しさん:2011/10/18(火) 14:12:29.08
土方以下だという自覚もなく土方を叩くクズを野放しにするってどうよ

806 :デフォルトの名無しさん:2011/10/18(火) 14:12:55.06
まだ放射能が足りないってか

807 :デフォルトの名無しさん:2011/10/18(火) 15:40:24.04
電波を出す能力のこと

808 :デフォルトの名無しさん:2011/10/18(火) 17:10:29.53
case res of
>>803-807 -> Nothing
_ -> undefined


809 :デフォルトの名無しさん:2011/10/18(火) 18:32:46.22
煽りじゃない動的型付けへの不満

・関数、メソッドの引数が型に応じた補完を受け付けない(以下例)
def f(self, x):
    self.foobar() # これは補完できるし、
    y = T()
    y.foobar()    # こっちも補完できるけど、
    x.foobar()    # これは補完できない

・カリー化の扱いが難しい
(引数の数を間違えたときに、予想外の場所でエラーが出て酷い事になる)


個人的にタイプミス補正は型の問題じゃないと思ってる(>>367に同意)

810 :デフォルトの名無しさん:2011/10/18(火) 20:24:05.17
>>809
>・関数、メソッドの引数が型に応じた補完を受け付けない(以下例)

補完はもしもメソッド定義の仮引数に型宣言ができる構文があれば実現できるんじゃないかな?
たとえば Python 3系の関数アノーテーションみたいな構文。

# ただし現状のPython 3処理系が補完機能を実装しているか否かは別の話(言語の仕様と実装は別という意味)

>・カリー化の扱いが難しい

カリー化を基本とする関数型言語であればその主張は正しいと思うけど、
非カリー化な言語ではそもそもカリー化を前提としたプログラミング技法はほとんど使われない。
もちろんCの関数ポインタやSmalltalk/ObjC/Ruby等のブロックはあるけど、これらはカリー化されていない。
だからカリー化の扱いの難しさで比較するのは不公平に感じる。

811 :デフォルトの名無しさん:2011/10/18(火) 23:09:20.92
>>810
たしかに、OOPではカリー化は問題にならず、逆に関数型では補完は殆ど問題にならない
だから、ひとつ目はOOPで書くときの、ふたつ目は関数型で書くときの不満と思って欲しい

そして指摘の通り、Python3やDartみたいなアノテーション構文で補完の問題は
原理的に解決できるけど、現時点では対応してないので不満がありますよ、と

812 :デフォルトの名無しさん:2011/10/18(火) 23:36:42.51
Pythonみたいなダックタイプ言語で、型アノテーションをその手の用途に活用しようと
思ったら、実際どうするんだろ

たとえば
def add(x, y): return x + y
という関数があったとして、xやyの型をどう記述するかということなんだけど
xやyはたとえばintでもfloatでもcomplexでもstrでもlistでもいいよね
ダックタイピングだからそれらは特定の型やインタフェースを継承・実装したりも
してない

Addableみたいなannotation目的のダミークラスを捏造してそれを使うのか
それともある程度幅がある場合は何も書かないのか

813 :デフォルトの名無しさん:2011/10/18(火) 23:53:14.44
必要なメソッド名のリストを書くとか?(dir関数の戻り値と同じ形式)

def add(x:['__add__'], y:['__add__']):
    return x + y

814 :デフォルトの名無しさん:2011/10/19(水) 00:02:10.02
なるほど
毎回そういうの書けって言われたら嫌そうだけど
目的は達成できてるね

815 :デフォルトの名無しさん:2011/10/19(水) 02:38:44.46
普通に静的型付け言語使った方がいいわ

816 :デフォルトの名無しさん:2011/10/19(水) 02:44:00.21
ただし「動的に束縛される静的型付け言語(>>777)」を除く


817 :デフォルトの名無しさん:2011/10/19(水) 06:58:12.09
動的型付けの言語って、IDEの補完あることはあるけど、関数の引数で型情報がないのもそうだし、
リストとか配列に入れた変数は型情報が消えるとか、メンバーフィールドに入れた変数は型情報が消えるとか、やっぱ無理がある。
それに型なんて意識しないでプログラムが書かれるんで、
function foo() {
 if (flag) {
  return 0;
 } else {
  return 'abc';
 }
}
↑こういうのが大量にある。そうすると、f = foo();で、fの型をIDEが推測出来るわけがない。

818 :デフォルトの名無しさん:2011/10/19(水) 08:41:50.85
>>817
無能なIDEは処刑するしかない。

819 :デフォルトの名無しさん:2011/10/19(水) 11:13:00.63
>>817
S式やJSON考えれば分かるけど、「何でもリスト」みたいなのは動的型だと普通だわな
ただJavaなんかもGenericsが導入される前は事実上何でもリストであるObjectコンテナと
キャストが多用されていたわけで

つまりそういう場合もキャストやパターンマッチみたいに型を確定させ明示する
方法があれば補完を機能させられるんじゃね
引数アノテーションだけでは足りないってことだな

820 :デフォルトの名無しさん:2011/10/19(水) 12:45:07.28
ttp://www.fujitv.co.jp/anabang/photo/message_ph.jpg

821 :デフォルトの名無しさん:2011/10/19(水) 13:00:20.85
なまものはちょっと。。。

822 :デフォルトの名無しさん:2011/10/19(水) 17:44:05.53
>>817
行儀良く書いてれば、それらの補完は原理的に可能ではある(MLで型推論できるのと同じで)けど
実際に補完できるIDEが在るのかどうか……
メンバの型情報を使った補完だけなら可能なIDEはあるが

823 :デフォルトの名無しさん:2011/10/19(水) 18:00:44.83
>>817の f = foo() の型は <int>|<str> であると考えられるので
<int>と<str>が共通で持つメソッドを補完できれば良い

824 :デフォルトの名無しさん:2011/10/19(水) 18:06:09.90
>>819
JSON自体が、データが型情報を持っていると言う意味で、動的型だし。

825 :uy:2011/10/19(水) 18:11:49.79
>>818
こういう
「できること」と「できないこと」の区別すらつかねー奴って何?


お前が処刑されろよゴミカス

826 :デフォルトの名無しさん:2011/10/19(水) 18:21:03.16
>>822
よくわからんけど、補完とMLの型推論って逆向きなのでは?

+使ってる→intだな、::使ってる→リストだな、みたいに
操作から対象の型をボトムアップに推論しているというか

補完って、逆に、ある対象に対してどういう操作が可能か
知りたいというトップダウンだと思うので、まず対象の型が何であるかを
確定させないとだめなんじゃね?

同じことなんだろうか?

827 :デフォルトの名無しさん:2011/10/19(水) 18:27:00.74
>>826
関数引数に対して補完が働かないのはそのとおり
でも関数の戻り値に対しては型が確定する

828 :デフォルトの名無しさん:2011/10/19(水) 19:06:54.55
型にはまり毎日のように挿入されたわけだ。


829 :デフォルトの名無しさん:2011/10/19(水) 19:37:20.71
>>827
んなわきゃねえ
返り値が多相だったらどう確定させんだよ?

830 :デフォルトの名無しさん:2011/10/19(水) 19:38:43.18
>>829
そうだね。確かに言い過ぎたw

831 :デフォルトの名無しさん:2011/10/19(水) 20:03:25.96
動的型言語に型推論を追加して補完するなら
ついでに静的型チェックもしてくれ(完璧じゃなくて良いから)

832 :デフォルトの名無しさん:2011/10/19(水) 21:25:58.80
足なんて飾りですといって、足がない状態で完璧を目指している人もいる
そう考えると、完璧じゃなくていいから足がある方が良いというのは残酷だね

833 :デフォルトの名無しさん:2011/10/19(水) 21:28:50.82
例えがよくわからん。

泥棒対策で例えてくれないか?

834 :デフォルトの名無しさん:2011/10/19(水) 21:33:19.05
鍵なんて飾りですといって、鍵がない状態で泥棒対策を目指している人もいる
そう考えると、泥棒対策にならなくてもいいから鍵がある方が良いというのは残酷だね

オレなら鍵を使いつつ完璧を目指すが・・・。

835 :デフォルトの名無しさん:2011/10/19(水) 21:39:28.08
完璧を目指す?AqdaやCoqを使ってるのかい?

836 :デフォルトの名無しさん:2011/10/19(水) 21:46:15.92
>>833
鈍感なやつが安全を語るな

837 :デフォルトの名無しさん:2011/10/19(水) 21:50:14.27
>>835
もしかして定理証明器に夢見ちゃってる人?

838 :デフォルトの名無しさん:2011/10/19(水) 22:01:06.10
OCamlの型推論部分は自明じゃないアルゴリズムを使ってて複雑なので
Coqで書き直したいという議論もあるそうな

839 :デフォルトの名無しさん:2011/10/19(水) 22:07:00.57
型推論ってなんか、技術に走り過ぎな気がする。
そんな推論の限界を追求しなくても、
2回書く所を1回ですめば良い程度のもんでいいんじゃね?

840 :デフォルトの名無しさん:2011/10/19(水) 22:15:47.58
>>839にとって型推論は 酸っぱいブドウ らすい....

841 :デフォルトの名無しさん:2011/10/19(水) 22:33:42.21
なんだ。反論じゃないのか

842 :デフォルトの名無しさん:2011/10/19(水) 22:53:57.59
> 2回書く所を1回ですめば良い程度

Java7のダイヤモンドオペレータの型推論がそんな感じ

843 :デフォルトの名無しさん:2011/10/19(水) 22:57:26.32
>>839は(技術論じゃなくて)単なる感情論だからなぁ
本人がそれで良ければそんなもんでいいんじゃね?

844 :デフォルトの名無しさん:2011/10/19(水) 22:58:36.48
>>842
Javaに無い機能はいらんってことか
>>840の言う通りじゃねーか

845 :デフォルトの名無しさん:2011/10/19(水) 23:37:44.87
そんなのはどうでもよくて
反論が聞きたいんだが

846 :デフォルトの名無しさん:2011/10/19(水) 23:45:27.51
いわゆる「IDEなんて要らない」と同じ話だろ?
そいつにとっては事実なんだろうからそれでいいよ

847 :デフォルトの名無しさん:2011/10/19(水) 23:57:35.04
IDEはいらないと言っている人に、
IDEの機能単体をどう思うかを聞くと、
いらないなんて一言も言わないんだよな。

848 :デフォルトの名無しさん:2011/10/20(木) 01:01:00.14
ソースコードなんて中学で一通り書いたし。

849 :デフォルトの名無しさん:2011/10/20(木) 03:26:46.32
そうだね。ソの字が一番書くの難しいよね。
ちょっと油断すると、リになったりンになったり。

850 :デフォルトの名無しさん:2011/10/20(木) 06:41:50.23
自分でIDEのようなツールを作ってみればいい
エディタからプロセス呼び出して位置とファイル名を渡して
それを解析してパラメータヒントやリファレンス結果をチップ表示するだけ
それを考え出すと型がない不便さがよくわかる、型推論に殺意が沸く
そして無理難題を突きつけられるIDEに同情するようになる
俺のIDEたんをいじめるなくそ言語開発者どもめ
こういう思想に染まる人が増えても不思議ではない
プログラマはIDEなしでは生きられないのよ

851 :デフォルトの名無しさん:2011/10/20(木) 07:13:26.20
>>850
別にIDE作る仕事をしてるわけじゃないから問題ない

852 :デフォルトの名無しさん:2011/10/20(木) 08:08:26.12
IDEを好む -> 土方
型推論を好む -> ハッカー

853 :デフォルトの名無しさん:2011/10/20(木) 08:22:35.37
C++系の言語が梯子を外しそうなのが問題なので
もともと型推論してた言語は関係ない

854 :デフォルトの名無しさん:2011/10/20(木) 08:44:51.24
型推論ってむしろIDE使ってる人の方が
メリットあると思うけど。
型省略しても、コード補完できるしね。

テキストエディタを使っていれば、
単に書くのを省略出来るだけでしょ?
省略した結果、コード追わないと型がわからなくなることもあるし。

それにしてもIDEを嫌う人って普段なにを使ってるんだろうね。
メモ帳?w 高機能なテキストエディタを使っているとしたら
そのテキストエディタの機能とIDEって同じものなのにね。
ただIDEの方がより正確で便利なだけであって、

855 :デフォルトの名無しさん:2011/10/20(木) 08:45:44.90
>>847
確かにな。
お前が要らないとしても、お前を構成するのと同じ元素が宇宙から消えたら困るのと一緒だな。

856 :デフォルトの名無しさん:2011/10/20(木) 08:46:01.01
>>853
型推論(静的に推論する)と実行時の型をみるのとでは意味が違うぞ

857 :デフォルトの名無しさん:2011/10/20(木) 09:00:04.71
>>855
それって、特定のIDEが嫌いなだけで、IDEが嫌いとは言わないんじゃ
俺もXCodeやEclipseは嫌いだがVisualStudioは好きだぞ

858 :デフォルトの名無しさん:2011/10/20(木) 09:13:53.87
仕事退職して風俗嬢とおまんこしまくってきた。


859 :デフォルトの名無しさん:2011/10/20(木) 13:41:26.10
挑発的だな
Visialなんちゃらが一番嫌われてるの

860 :デフォルトの名無しさん:2011/10/20(木) 13:41:49.35
おっとVisualなんちゃらな

861 :デフォルトの名無しさん:2011/10/20(木) 15:42:03.66
MS教徒なら、IDEは理解できるが。(あれのコンソールは・・・)
コンソールがもともと充実しているOSにはIDEってあまり重要ではないわな。
むしろ、起動のかったるさのほうが敬遠される原因じゃないかな。
メモリ食いというのもあるけど、そちらは今あまり影響がないしな。
動的言語でsnippetを書く程度でIDEを立ち上げたとしたら、それは仰々しい
だろうしな。もともとREPLがある言語対応がいまいちなものが多いし、
大抵本家じゃなくて第三者がプラグインを作ってる。Javaならいいのかも
しれんが、HaskellやOcamlでもEclipseプラグインはあるけどな。
lisp系+slime+emacsの域に達してるものはない印象かな。せいぜいR+ESS+emacs
程度の完成度があれば違うかもしれんが。あまりに小さくて1行にならない程度
のsnipet程度なら
$ cat > foo.rb
で済ませてしまう人も多そうなんだがな。IDEがいらない場合ってIDEが使いにく
いん言語を使ってる人が多いと思うよ。>>847
よく知らんのだけど、IDEの補完って、slimeのファジー補完みたいなのあるの?
型が型がと言う話は出てるけど、関数の引数情報などはslimeは出てきてるよ。
だから変数の名前を慣例に乗っ取って書いてる限り型を間違えることもないん
だよ。リストや配列、ハッシュなどの情報も含まれるので。
haskellの場合はghciで:eとすればエディタが起動するけどデフォルトでvimだ
からな。replとの組み合わせで考えてると思ったらいいんだけど、いわゆる土方
さんにそれが伝わるのか?わからん。replすら知らんかもしれんし。会話の接点
すら見つけられるかどうかわからんのよ。


862 :デフォルトの名無しさん:2011/10/20(木) 15:48:07.33
CUI的な使い方を好む人なら
vim+screen+repl(ipython/irb/ghciなど)というパターンじゃないかな。
clojureでも同じような使い方ができるけど。あれはjavaの文化の言語だから
新規作成はleiningenというものを使ってプロジェクトを作成させてる。
IDEが不要だという考えの一つの解決法を示してると思うよ。scalaのsbtは
詳しくは知らないけど、同じようにIDE不要の解決方法なんだろうな。leiningen
はわかりやすかったけどsbtはleiningenほどではなかったように思う。こん
なことを書くとscalaの怖い兄ちゃんたちが暴れるかもしれんが。

863 :デフォルトの名無しさん:2011/10/20(木) 15:53:15.72
ファジー補完:たとえば
m-v-b と打ってタブを押せっば、multiple-value-bind と補完してくれる。


864 :デフォルトの名無しさん:2011/10/20(木) 15:54:52.70
ファジー補完:たとえば
m-v-b と打ってタブを押せっば、multiple-value-bind と補完してくれる。


865 :デフォルトの名無しさん:2011/10/20(木) 15:56:13.55
ファジー補完:たとえば
m-v-b と打ってタブを押せっば、multiple-value-bind と補完してくれる。
このときemacsの下には(multiple-value-bind VARLIST VALUE-FORM &BODY BODY)
とでるの。これで必要な引数の型情報がわかってしまう仕組み

866 :デフォルトの名無しさん:2011/10/20(木) 16:20:54.41
三回も書くとは余程大事なんだなw

867 :uy:2011/10/20(木) 17:11:18.41
>>865
ずいぶん時代錯誤なことをいっているようにしか見えない

ハッシュ引数ってわかりますか?

とっくのとっくに言語側で解決してる問題はIDE・エディタが介入しにこなくていいよ
言語側のダメさを補うのが役割なんだから


2011年に未だC・JAVAなんて使ってるゴミグラマーは知らん

868 :デフォルトの名無しさん:2011/10/20(木) 17:12:51.20
>>867
さっさと刑務所に帰れ

869 :デフォルトの名無しさん:2011/10/20(木) 17:18:21.04
名前付き引数があろうがそこにどんな名前が使えるかを教えてくれる環境がある方が便利だろう

870 :デフォルトの名無しさん:2011/10/20(木) 17:45:45.78
>>861
今時のいわゆるIDEって基本的にOOPL向きに特化してるし、上の流れで
念頭に置かれているのも、おそらくそうしたもの

この手のIDEでは、変数xがあるとき、
x.
とか打ち込むと、xのメンバがずらずら一覧で出てきたりするわけ
(メソッドの引数型とかは見れてあたりまえ)
これが出来るためには当然xのクラスなり型なりが静的に確定してなきゃいけなくて、
だから上のような話になっているんだろ

どうやらそんなことも分かっていなかったようだけど、
分かった上で俺はそんなものは要らないという話なら
チラシの裏にでも書いてくれないか

871 :デフォルトの名無しさん:2011/10/20(木) 17:56:09.33
>>870
ここはチラシの裏だって。もっと高級なものだと勘違いしてたのか?
謎だな。Framerスレだけに、丁寧に不要なタイプの人の事情を書いて
”やった”のにな。

口だけ将軍さんよ。

872 :デフォルトの名無しさん:2011/10/20(木) 18:01:26.71
話の流れも理解せずに的外れなこと言い出したと思ったら捨てゼリフかよ
さすがREPLとかSLIMEなんて言っても今の子わかんないよねーフフンとかLisperなだけで
大威張りな老害は一味違うわ


873 :デフォルトの名無しさん:2011/10/20(木) 18:07:06.14
eclimみたいなのもあるんだから、IDEとエディタで
補完機能その他に差があるとは一概に言えない

874 :デフォルトの名無しさん:2011/10/20(木) 18:31:04.24
インスタンスから型を手繰り寄せてメンバを補完する式のやり方は
(マルチメソッドでない、Javaみたいな)OOPL向きのやりかたなので、
使ってるのがその手の言語でなければあまり意味はないし役には立たんわな

まあCとかでも構造体に関しては変数からメンバを取れるので、一応この形式の
補完は使えるけど、有用性というか使用頻度はOOPLより低くなる

あとMSVCで言うとCtrl+Space打つとその時点で可視な名前(関数とか定数とか)の
リストが出て、名前の先頭数文字打って適切なところで確定、みたいなのは一応
出来るが、これは型情報関係ない補完だ


875 :デフォルトの名無しさん:2011/10/20(木) 18:44:40.86
安全という観点では
IDEがないとコンパイラを動かせないとか、言語仕様に問題があってIDEが作れないとか
どこか一箇所に問題があるだけで全体が止まってしまうような仕組みは
あまり安全とは言えないように思える。

876 :uy:2011/10/20(木) 18:49:19.93
>>868
お前も一緒にくるんだよ

877 :デフォルトの名無しさん:2011/10/20(木) 18:52:15.39
http://ja.wikipedia.org/wiki/Phalanger

878 :デフォルトの名無しさん:2011/10/20(木) 18:54:37.10
>>875
>IDEがないとコンパイラを動かせない
こういう製品は見たことがないな

879 :デフォルトの名無しさん:2011/10/20(木) 19:00:58.94
>>859-860
msの開発者も使ってるだけ有って使い勝手良いのに?
(mfcは糞だが)



880 :デフォルトの名無しさん:2011/10/20(木) 19:01:12.97
IDEがないとコンパイルする方法が分からないプログラマはいるだろうけど、
そういう話かな?
それをIDEの所為にするのは酷い話だが。

881 :デフォルトの名無しさん:2011/10/20(木) 19:44:49.72
無責任だな
まあ後で無責任になるよりは最初から無責任なほうが良いね

882 :デフォルトの名無しさん:2011/10/20(木) 19:47:21.70
入力や編集に特殊な環境が必要なテキストファイル、というのは珍しいものじゃない。
たとえば日本語テキストとかw

だがプログラマならCUI使えません、というのはちょっと困るよな、最低限の
コンピュータの知識として。

883 :デフォルトの名無しさん:2011/10/20(木) 19:56:56.98
>>882
同意だが、流れと何か関係あるのかと


884 :デフォルトの名無しさん:2011/10/20(木) 20:10:25.69
よくわからんがとにかく責任論は100%か0%の二択で考えるとトラブルが少なくなる。
つまり動的型付け言語もある意味合理的なんだよ。

885 :デフォルトの名無しさん:2011/10/20(木) 20:21:12.09
なんだそのJohn Major's Equalityみたいな

886 :デフォルトの名無しさん:2011/10/20(木) 20:32:04.59
試行錯誤しながらコード書くときの
REPLの便利さは異常

887 :デフォルトの名無しさん:2011/10/20(木) 20:53:03.97
Eclipse 使えばスクラップブックがあるし

888 :デフォルトの名無しさん:2011/10/20(木) 21:01:45.08
キーバインドが違うとか、自分が作った開発環境が良い、というのは好みの問題
メモリが足りないとか、CUIで動かないとか言うのは環境の問題
これらを省くとすればIDEを嫌う理由はないはずなんだが。

テキストエディタ+αがIDEであって
テキストエディタに比べて何かが
できなくなってるわけじゃないんだからさ。

IDEに反対している人ってのは、IDEを使うまでもないというだけで
IDEがダメなんて言ってないしね。


IDEばっかり使ってると、コンパイラの仕組みがわからなくなる。
こういう意見もあるか。これは教育の問題。

889 :デフォルトの名無しさん:2011/10/20(木) 21:25:50.49
一般的にIDEが開発に便利な機能を提供しているように思われてる。
それは間違ってない。

でももう一歩突き進むと、IDEの機能を実装するための
情報をプログラム言語は提供している。

プログラム言語がIDEに情報を提供する

IDEがその情報から機能を作り出し開発者に提供する

開発者

つまり、これは、プログラム言語によってIDEが提供できる機能に差があることを意味している。
実はこのことに気づいていない人が結構いるのではないだろうか?
IDEや静的型付け言語での解決経験が少ない人ほどそんな気がする。

890 :デフォルトの名無しさん:2011/10/20(木) 21:47:31.15
>>874
しかし多重ディスパッチと単一ディスパッチ、世の普及度から言うと、

>(マルチメソッドでない、Javaみたいな)OOPL向きのやりかたなので、
>使ってるのがその手の言語でなければあまり意味はないし役には立たんわな



>単一ディスパッチでない、Common Lispみたいな言語には不向きなやり方だけど
>使ってるのがその手の言語でなければ大いに意味があるし役に立つわな

の方がより適切なのではないかw (いや意味的には一緒なんだけれどもさ)

891 :デフォルトの名無しさん:2011/10/20(木) 22:13:34.39
>>850
え?今時ファイルベースのIDEでご満悦?
頭わるそw

892 :デフォルトの名無しさん:2011/10/20(木) 22:31:33.55
C++とIDEはピンチの時に自分だけ逃げるタイプ
残るのは単なるCとテキストエディタ

893 :デフォルトの名無しさん:2011/10/20(木) 22:56:27.33
>>890
どのようなアシストツールが便利かは言語によるという、それだけの話だな

894 :デフォルトの名無しさん:2011/10/20(木) 23:00:43.29
IDE大好きなんだ
理解出来んがMSに帰依するとそんなもんかね
タイプ減らす意味でdabbrev程度で十分かな

895 :デフォルトの名無しさん:2011/10/20(木) 23:09:18.63
10年前から全く議論が進んでねぇw

896 :デフォルトの名無しさん:2011/10/20(木) 23:17:39.24
IDEはLISPとSmalltalkで育ってひろまっていったのだが、
どっちも動的型言語だなあw

897 :デフォルトの名無しさん:2011/10/20(木) 23:31:25.27
動的型言語のIDEなんて広まってないのだが

898 :デフォルトの名無しさん:2011/10/20(木) 23:41:12.25
squeak

899 :デフォルトの名無しさん:2011/10/20(木) 23:56:36.50
ここで話しているのはIDE全般の話ではなく、その中でもcontent assistとか
auto completeとかいった入力を補完する機能の事でしょ。

型の宣言だろうが型推測だろうが、実行前にレキシカルに型を判定できる言語と
そうでない言語で補完の打率が異なるのは仕方がない。
静的に判定できる言語では打率は基本的に100%で、適用可能な候補はもれなく
列挙されるし使えない候補は基本的に表示されない。
候補の表示にしても代入先の型を見て表示順に優先度をつけたりも出来るし。

これが動的型付けになって実行前の型判定が難しくなったり補完機能の実装が
お馬鹿になるにつれて打率が下がって欲しい候補を取りこぼしたり空気読めて
いない候補を表示したりするようになる。

900 :デフォルトの名無しさん:2011/10/20(木) 23:57:30.89
>>894
IDEでなんで「MSに帰依」とか出てくるのやら
MSとか別に関係ねーだろ

言語と環境が一体になってるIDEの典型例つーとSmalltalkだろ
Java方面ではEclipseが勿論有名だし
WindowsでもWin32の初期ではBorlandのDelphiが完成度の高さでメジャーだったし
勿論AppleもXcodeとか提供してるし、Think C/Symantec CとかCodeWarriorとか
サードパーティ製も以前から色々あった

901 :デフォルトの名無しさん:2011/10/20(木) 23:57:47.89
emacs+elisp

902 :デフォルトの名無しさん:2011/10/20(木) 23:59:30.17
> 言語と環境が一体になってるIDEの典型例つーとSmalltalkだろ

普通IDEといえば、言語と環境ではなく
言語とテキストエディタが一体となっているもの
(連携しているもの)なんだが。


903 :デフォルトの名無しさん:2011/10/20(木) 23:59:56.09
>>897
Eclipseは元々はSmalltalkだけど何か?

904 :デフォルトの名無しさん:2011/10/21(金) 00:01:18.53
なぜEclipseはSmalltalkを捨てたのか。

そこに見えるのは動的型付け言語の
限界なんだろうね。

905 :デフォルトの名無しさん:2011/10/21(金) 00:01:57.00
>>902
適当に書いたが、確かにIDEは環境というよりはもっと狭いなw
ただ、「普通は」というのなら、普通はソースレベルデバッガ、クロスリファレンサ
なんかも含んでいると思う


906 :デフォルトの名無しさん:2011/10/21(金) 00:02:57.20
>>899
コンプリーションこそXeroxで生まれて広まった技術じゃないか。
当然、源流はLISPとSmalltalk。どっちも動的言語のIDEだ。
Eclipseもそうだが、静的言語のIDEはしょせん派生にすぎないことをわきまえろw

907 :デフォルトの名無しさん:2011/10/21(金) 00:03:23.11
Smalltalk時代のIDEの機能が知りたいね。
たぶん今と違ってすごく貧弱なものなんだろうけど。

908 :デフォルトの名無しさん:2011/10/21(金) 00:04:04.52
>>902
IDEが何の略か知らないのか?EはEditorのEじゃねえぞww

909 :デフォルトの名無しさん:2011/10/21(金) 00:04:24.16
>>906
いや、はじめにIDEが使われたからといって
だからなんなんだ?

その頃のIDEと今のIDEは別物だろう。
昔のはIDEというより、ただの実行環境ではないのか?

910 :デフォルトの名無しさん:2011/10/21(金) 00:04:45.92
>>904
Java厨にもいじれるようにするためだろw
恥かしいこと書かせてんじゃねえよww

911 :デフォルトの名無しさん:2011/10/21(金) 00:04:47.48
>>908
開発環境のEだよな?
実行環境ではなく。

912 :デフォルトの名無しさん:2011/10/21(金) 00:05:24.64
>>910
意味がわからん。

それはJavaを採用した理由であって
Smalltalkを捨てた理由じゃないだろ。

913 :デフォルトの名無しさん:2011/10/21(金) 00:09:26.48
>>907
いちいち全部挙げても仕方ないが、このスレで出てきた機能だけでも
コンプリーション
ソースの自動整形
文法でハイライト
自動コンパイル
マウスを使ったGUI
コンテキストメニューによるコピー&ペーストおよびコード実行
ソースレベルデバッガ
はSmalltalk-80に実装されていたわけだが?

914 :デフォルトの名無しさん:2011/10/21(金) 00:10:24.35
>>912
は?SmalltalkのままじゃJava厨はいじれねえだろ?

915 :デフォルトの名無しさん:2011/10/21(金) 00:11:24.27
>>913
じゃあ、違いは質かな。

916 :デフォルトの名無しさん:2011/10/21(金) 00:12:18.17
しかし、Smalltalkの名が出ても
IDEを否定する動的型付け言語厨ってどうなの?
裏切り者?w

917 :デフォルトの名無しさん:2011/10/21(金) 00:13:20.01
というかIDEを否定するLisperが一番分からん
お前が使ってるソレはIDEと何が違うのだ……

918 :デフォルトの名無しさん:2011/10/21(金) 00:14:53.60
>>915
質がどう違うかも説明できねえくせにwww

919 :デフォルトの名無しさん:2011/10/21(金) 00:18:56.73
静的型言語のドカタ共が方眼紙にソースを手書きしていた時代から
動的型言語のハッカー達はコンプリーションやシンタックスハイライトする統合環境を作り上げていた。
それを今頃「静的型言語にはIDEがある(キリリッ」とか、知らないって恥ずかしいねw

920 :デフォルトの名無しさん:2011/10/21(金) 00:21:36.21
そしてその進化は静的型付け言語を選んだ。

みろよ、今の動的型付け言語のIDE対応。
貧弱と言わざるを得ないじゃないか。

921 :デフォルトの名無しさん:2011/10/21(金) 00:21:47.09
今どんだけ活用されているかが問題なのだが。
元祖を誇ったところでメシの種にもならん。

922 :デフォルトの名無しさん:2011/10/21(金) 00:23:57.68
http://www002.upp.so-net.ne.jp/feedc0de/diary/nikki0106b.html
malltalk-80はブームになったけど、でも結局遅いとかリソース食うとかいろいろ問題があって、
商業的には成功しなかった。 今動かしてみると、当時としては革新的だったGUIやIDEも
今となってはむしろ見劣りがする。 なんか、小さいころ遊んだ公園に20年後訪れてみたら、
こんなに小さかったんだー、みたいな。

923 :デフォルトの名無しさん:2011/10/21(金) 00:27:29.13
ハッカーは面白がる。
信者は恩に着せようとする。

924 :デフォルトの名無しさん:2011/10/21(金) 00:29:11.55
Smalltalkの例からもわかるように、
本来はIDEは便利なツールとして
誰からも理解されて当たり前なのに、
なぜIDEを否定するのか。



925 :デフォルトの名無しさん:2011/10/21(金) 00:29:37.92
ハッカーはIDEを使う。

926 :デフォルトの名無しさん:2011/10/21(金) 00:31:21.31
Lispの環境が大昔から充実してたってのは、ソースコードが構文木そのもので
S式だけの世界なので、非常にパースしやすく扱いやすかったからかねぇ
一方Cはviとctagsでどうにかしていたって感じか


927 :デフォルトの名無しさん:2011/10/21(金) 00:34:36.81
ハッカーはIDEを使う。

928 :デフォルトの名無しさん:2011/10/21(金) 00:37:05.04
XamarinはMonoTouchの最新版となる「MonoTouch 5.0」を公開した。

MonoTouchはクロスコンパイラ、ライブラリ、ツール、Xcodeインテグレーション、デバッガ、デバイス経由
デバッガなどが含まれたアプリケーション開発キット。
C#などの.NET対応プログラミング言語を使ってiPadやiPhone向けアプリケーションを開発できるという特徴がある。

「MonoTouch 5.0」の最大の特徴は、リリースされたばかりのiOS 5に対応した点にある。
説明によれば、MonoTouch 5.0を利用することでiCloud経由のクラウドストレージの利用、
Twitterの活用(メッセージ、URL短縮化、写真アップロード、位置情報利用など)、AirPlayを経由したストリーミングの実施、
Bluetooth経由による外部デバイスとの通信、Newsstandの活用などを実現できるという。

MonoTouch 5.0の発表段階ではまだドラフト版とされているが、MonoTouchを使ってiOS 5の機能を利用するための
サンプルコードを解説が「Introduction to iOS 5」にまとまっている。
具体的にどのような機能が利用できるのか参考になる。

http://journal.mycom.co.jp/news/2011/10/20/017/index.html




929 :デフォルトの名無しさん:2011/10/21(金) 05:48:17.64
>>920
> みろよ、今の動的型付け言語のIDE対応。
> 貧弱と言わざるを得ないじゃないか。

やっぱり使いもせずに評論家気取りのドカタか♪

930 :デフォルトの名無しさん:2011/10/21(金) 06:04:08.93
JavaScriptでビシバシ補完してくれるIDEって無いかしら。

931 :デフォルトの名無しさん:2011/10/21(金) 08:07:55.23
>>929
使ってやるから、最低限これぐらいは
サポートした動的型付け言語用IDEを教えてくれ。
Smalltalk以外で。

コンプリーション
ソースの自動整形
文法でハイライト
自動コンパイル
マウスを使ったGUI
コンテキストメニューによるコピー&ペーストおよびコード実行
ソースレベルデバッガ


932 :デフォルトの名無しさん:2011/10/21(金) 08:12:38.39
netbeansのrubyサポートはそこそこだったな

933 :デフォルトの名無しさん:2011/10/21(金) 12:34:33.21
>>931
例えばpythonあたりなら、
emacsのpython-modeや他のいろんなコードを寄せ集めたら
その程度の機能は揃わないか?

934 :uy:2011/10/21(金) 12:40:01.60
>>933
そんなことは  誰  で  も  わかってんだよ

お前がそれを正確にここにソースのせる必要がある
「技術」というのは、その情報のありかを知っているか?すぐ探せるか?
そこにかかっている

IDEの話題でEmacsを取り上げるのは逃げ。
あいつは何でもある

少し前にemacsの本たくさんでたからなぁ
そこでちょっと手をつけたタイプの奴か

935 :デフォルトの名無しさん:2011/10/21(金) 14:58:40.16
>>933
EmacsでGladeやQT DesignerみたいなUIデザイナ系の機能が実現可能なわけないし、
標準のpython.elには補完機能とかないっぽいぞ
色々入れると補完ぐらいはできるようにはなるみたいだな

ただEmacsである以上、外部にPython立ち上げてプロセス間通信という方法なわけで
emacs.pyというEmacs側の付属品の置き場をPython側のsys.pathに入れてやるだとか、
gud.elからpdb使うにしてもpdbってただのPythonスクリプトだから
pdb.pyのパスを設定したりとか、Windowsならshebang使えないから
更にもう一手間いるとか、くだらなくて無駄な手間が色々ある

色々四苦八苦して設定してようやく標準でついてくるidleで当然できてることが
できるようになるんじゃ、何が何でもEmacsでやりたいって変人以外には
メリットゼロだろ

936 :デフォルトの名無しさん:2011/10/21(金) 15:24:05.62
動的型付け言語では安全なソフトは作れない

からどんどん離れていってるな
なぜGoogleのDartが静的型付け「も」できるように作られてるのか考えれば、業腹かもしれんが結論は出るだろうに

937 :デフォルトの名無しさん:2011/10/21(金) 16:07:54.78
結論が欲しいなら実行しよう
実行しないなら安全ではあるがその代わり結論は出ない

938 :デフォルトの名無しさん:2011/10/21(金) 17:24:21.59
windowsなんて誰も相手してないだろ
おとなしくVSと秀丸でも使ってなさいってこった

939 :デフォルトの名無しさん:2011/10/21(金) 17:39:22.68
vimだと、Python有効でビルドされている場合はPythonのsoやdllを
直接読み込むので、プロセス間通信しかないEmacsより「原理的には」
Pythonと相性がいい

ただし当然vimビルド時に対象となるPythonのバージョンが固定されてしまうし
標準のGUDでpdbデバッグサポートしているEmacsと違って
そっち方面の機能が標準ではないはず

940 :デフォルトの名無しさん:2011/10/21(金) 17:51:51.17
vimでPython書いてるけど、デバッガはpudb使ってる
あとWindows限定だけど、PyScripterってIDEが補完精度も高く動作も軽快で良い

941 :デフォルトの名無しさん:2011/10/21(金) 20:35:09.93
>>936
> なぜGoogleのDartが静的型付け「も」できるように作られてるのか考えれば

動的型付け「も」だろ。


基本設計として静的型付けとして作っていなければ
後付で静的型付けを付け加えるのは不可能だよ。

情報を無視することは可能だけど、
情報がない所から作り出すことは不可能だからね。

942 :デフォルトの名無しさん:2011/10/21(金) 21:38:28.25
>>941
だからDartは静的型付けを基本設計としたわけだろ
そういう需要が大きかったから、そうした

動的型付けでは困ることが多い(大規模プロジェクト)から、新たに言語を作ってまで静的型付けにしたわけだ
小さいプロジェクト用に「一応動的型付けもできるように」というフォローもしながらね

Googleがすべてではないが、少なくともGoogleは「静的型付けの方が優れているし、それを得るために新言語までをも作ろう」としてるわけだよ

943 :デフォルトの名無しさん:2011/10/21(金) 21:47:25.11
スコープとかも整理したかったんだろ
dartは静的に見えても動的な型だから
気をつけないと簡単にゴミ作れる

944 :デフォルトの名無しさん:2011/10/21(金) 22:13:06.57
ちゃんと計算されてるんですね、大規模プロジェクトとか

945 :デフォルトの名無しさん:2011/10/21(金) 22:19:26.49
>>942が本当なら、Dartは「本当の」静的型付け言語として生まれただろうに。
ベースが動的型付けで、「オプショナルに」型アノテーション「も」つけてもいい、というのが実態だろ。

946 :デフォルトの名無しさん:2011/10/21(金) 22:27:03.97
なんで、型もつけられるようにしたのか、

型をつけることにメリットがあるから?

947 :デフォルトの名無しさん:2011/10/21(金) 22:28:51.51
>>941
> 基本設計として静的型付けとして作っていなければ
> 後付で静的型付けを付け加えるのは不可能だよ。

Common Lisp とか Strongtalk とかしらんのか?

948 :デフォルトの名無しさん:2011/10/21(金) 22:30:04.41
>>947
それらも、型が便利だからって
あとから追加したの?

949 :デフォルトの名無しさん:2011/10/21(金) 22:30:48.04
>>945
逆だ逆
ベースが静的型付けだよ

動的型付けがベースなら、JSっていう普及しきってる言語があるだろうがw
今からJS並になるのは心底大変なのに、あえて新言語作らなきゃならんほど静的が欲しかったんだよ

950 :デフォルトの名無しさん:2011/10/21(金) 22:32:52.10
うん。たぶんDart開発の動機の大きな一つは
型をつけることにあったんだと思う。

951 :デフォルトの名無しさん:2011/10/21(金) 22:33:46.91
もしDartに型が無かったら、ちょっと記述量が少ない
JavaScriptってだけで何の特徴もなかっただろうな。

952 :デフォルトの名無しさん:2011/10/21(金) 22:33:54.96
実際ぐぐる自体がそう発表してるしな

953 :デフォルトの名無しさん:2011/10/21(金) 22:37:47.34
Googleほどの規模が大きいシステムってまず無いからね。
その規模の大きさに耐えられないとJavaScriptが判断され、
耐えるための機能がJavaScriptにはないDartの機能なわけだ。

954 :デフォルトの名無しさん:2011/10/21(金) 22:41:29.46
>>953
Googleほどの規模が大きいシステム
ってなんだよw
まさか検索エンジンをDartで書くとか勘違いしてんの?

それともGoogleがちょくちょく出してるサービスが、とてつもなくでかい規模だとでも勘違いしてんの?

955 :デフォルトの名無しさん:2011/10/21(金) 22:43:04.49
じゃあ自分の会社名乗ってみてよ

956 :デフォルトの名無しさん:2011/10/21(金) 22:43:58.72
Dartはブラウザで動かす言語だろ。
どうしてサーバーで動かす検索エンジンをDartで
作るとかいう間抜けな発想が出てくるのか。

957 :デフォルトの名無しさん:2011/10/21(金) 22:46:41.83
>>956
Googleほどの規模が大きいシステム
なんていうから、まさかそのレベル(間抜けな発想)で勘違いしてるのか?
って聞いたんだが

958 :デフォルトの名無しさん:2011/10/21(金) 22:49:16.39
Javascriptのプログラムをてっとりばやく移植できるように
動的型付けでも動くようにしただけだろ

959 :デフォルトの名無しさん:2011/10/21(金) 22:50:01.48
>>957
じゃあ、Google Docsを作ってみてくれよw

960 :デフォルトの名無しさん:2011/10/21(金) 22:53:34.24
>>959
GoogleDocsも、JSが担っている部分は「(Google以外の会社のサービスでは)まず無い」なんて言われるほどでかくないが・・・?

Google並の規模は稀
だからDartはGoogle以外の会社が使う利点がない
だから静的型付け言語いらない
動的マンセー

なんていう論法が間抜けすぎるってだけの話

961 :デフォルトの名無しさん:2011/10/21(金) 22:55:52.80
あんまいじめてやんなよ
テキストエディタで作るレベルのJavascriptしか触ったことない人間は少なくないんだから

962 :デフォルトの名無しさん:2011/10/21(金) 23:01:23.59
GoogleがJavaScriptの今後どうにもならない欠点として、動的型付けをあげたのは事実だからなあ……
規模がある程度以上になるとJavaScriptじゃ大変すぎる
PHPとかも同じ
最初は小規模用だったからあいまいでよかったけど、規模がでかくなると曖昧じゃ困る

963 :デフォルトの名無しさん:2011/10/21(金) 23:02:27.28
>>960
サーバーなくても動くんだが?

Google Docs、HTML5 を使ったオフライン版開発中
http://www.excite.co.jp/News/net_clm/20110617/Slashdot_11_06_17_0128232.html

964 :デフォルトの名無しさん:2011/10/21(金) 23:04:13.93
>>960
つまりGoogleが並だとすると、
そのGoogleでも動的言語はだめと判断したということは
Googleよりもでかい多くの会社は
動的言語に見切りをつけるべきですね。

965 :デフォルトの名無しさん:2011/10/21(金) 23:05:47.84
>>963のドヤ顔が痛々しい……
どんだけGoogleの規模がでかいことをアピールしても、
Googleほどの規模に達しない程度の規模であっても、静的型付けは有用ってことを覆すことにはならんのだぞ……?

966 :デフォルトの名無しさん:2011/10/21(金) 23:06:54.56
Googleに達しない規模ってどんだけ小さい会社なんだw
ついさっき、GoogleのJavaScriptは大規模ではないと
言ったばかりではないか。

967 :デフォルトの名無しさん:2011/10/21(金) 23:08:12.87
お前ら話題が逸れすぎ
ぐぐるの話は、静的のほうが優れている一面をもっていることの証明であって、それが全てじゃないだろ
動的マンセー派は、動的のほうが優れている部分をアピールしろよ

968 :デフォルトの名無しさん:2011/10/21(金) 23:08:36.28
Googleが大規模じゃないと思うか思わないかは
個人の勝手だからどうでもいいよ。


ただ言えることは、Googleの規模では動的言語では
だめだと判断されたということ。

あとは、自分はGoogleと比べて○○だから・・・で
個々の人が判断すればいい。

969 :デフォルトの名無しさん:2011/10/21(金) 23:12:22.08
規模が小さければ小さいほど、動的「でも」いいやと思うのは確か
だが規模が大きくなればなるほど、動的は絶対嫌だ

970 :デフォルトの名無しさん:2011/10/21(金) 23:17:28.66
俺は小さければ小さいほど静的のほうがさらに良いと思う派だな
小さいやつは、コンパイルエラーではじけるレベルのミスしかしえないから
当然規模が大きければ大きいほど静的がさらに良い

971 :デフォルトの名無しさん:2011/10/21(金) 23:23:46.86
動的なのヤツの手軽さと生産性の高さは実証済みだし
静的な方が大規模開発に向くのも同じ
使い分ければいいだけだろさ
でなけりゃjvmとかでスクリプト動かすやつなんておらんわな

972 :デフォルトの名無しさん:2011/10/21(金) 23:24:23.60
動的のほうがタイプ量が少なくていいだろ
そんなこともわかんねーのかよ
プロはスピード勝負なんだから、タイプ量の少なくて済む動的のほうが圧勝

973 :デフォルトの名無しさん:2011/10/21(金) 23:27:31.95
>>972
^^;

974 :デフォルトの名無しさん:2011/10/21(金) 23:28:02.02
>>979
作り話すんなよw どうせお前はそうは思ってないくせに

小さいスクリプトで、定義とか初期化でコードを長くすることが
いいと思っている奴なんていない。

975 :デフォルトの名無しさん:2011/10/21(金) 23:31:16.89
>>974
そう言いきっちゃうのが良くないと思うよ?俺は

小さいスクリプトって何行くらい?
30行くらいまでだったら同意してもいいかな

976 :デフォルトの名無しさん:2011/10/21(金) 23:36:07.16
Dartが静的型?笑わせんな。
ちゃんと型注釈付けて、それで型エラーがあっても「あえて」無視するような仕様だぞ。
そんないい加減な型検査でいいなら、巷の動的型言語の全てに静的型検査を導入出来るぞw

977 :デフォルトの名無しさん:2011/10/21(金) 23:39:09.87
当たり前の話だが、大きいプログラムになればなるほど、
全体を把握するのが大変になるし、時間的に全体を把握することが不可能な場合もある。
だから書くことよりも読みやすさが重要になる。

小さいプログラムは、コードが少ないから全体を把握するのは簡単。
だから書きやすさが重要になる。

書きやすさにこだわっている事自体が、
動的言語の限界は、全体を把握するのが簡単といえる
レベルまでだということがわかる。

978 :デフォルトの名無しさん:2011/10/21(金) 23:39:35.09
>>976
あえて無視するのは実行時な。どうせならちゃんと調べろよ

979 :デフォルトの名無しさん:2011/10/21(金) 23:40:37.58
>>976
静的型じゃなくて静的型付けな。笑わせんなはお前。

作者が静的型付け言語だといっているのだから間違いない。
実行前に静的型付け検査が行えるのなら、それは静的型付け言語

980 :デフォルトの名無しさん:2011/10/21(金) 23:43:56.48
>>976
実行時に「あえて」無視しなくてどうすんだ?クラッシュしろと?

981 :デフォルトの名無しさん:2011/10/21(金) 23:44:45.28
お前等、下のサイトの"The static checker"くらい読んでから発言しろよ
http://www.dartlang.org/articles/optional-types

982 :デフォルトの名無しさん:2011/10/21(金) 23:46:36.71
お前等、下のサイトの"The static checker"くらい読んでから発言しろよ
http://www.dartlang.org/articles/optional-types

983 :デフォルトの名無しさん:2011/10/21(金) 23:47:08.95
よし、全部読破した。かかってこい。

Error: Not Found

The requested URL /articles/optional-types was not found on this server.

984 :デフォルトの名無しさん:2011/10/21(金) 23:52:25.04
http://www.dartlang.org/articles/optional-types/

じゃないとアクセスできないぞ

985 :デフォルトの名無しさん:2011/10/22(土) 00:11:21.42
Googleの判断にたてつける奴はさすがに居なかったか・・・

986 :デフォルトの名無しさん:2011/10/22(土) 00:13:02.11
>>978-980
おいおい、まさかDartのサイトすら読まずに語ってたのか?
恥ずかしい奴らだな

987 :デフォルトの名無しさん:2011/10/22(土) 00:14:21.31
読んだぞ。それでなんなんだ?

お前がなにか言いたいことがあるんだろ?
それ言えよw

988 :デフォルトの名無しさん:2011/10/22(土) 00:21:11.82
>>987
本当に読んだか?型エラーの可能性があっても無視する場合があるって書いてるだろ。
この例では、lookup('Frankenstein')の返り値がStringである保証は無い
(戻り値の型はObject)が型チェッカーはスルーするとさ。


> However, unlike a classic mandatory type system, code like this

> Object lookup(String key) {...} // a lookup method in a heterogenous table
> String s = lookup('Frankenstein');

> will not cause any complaints from the checker. That’s because there is a 
> very good chance that the code is correct, despite the lack of type information. 
> You, the programmer, often have semantic knowledge that a typechecker does not. 
> You know that the value stored in the table under 'Frankenstein' is a string, 
> even though the lookup method is declared to return Object.

989 :デフォルトの名無しさん:2011/10/22(土) 00:23:57.43
>>988
いや、だからそれがどうかしたのか?
中途半端にこっちに解釈させると、お前が語りたいことを誤解される可能性があるぞ

990 :デフォルトの名無しさん:2011/10/22(土) 00:25:03.18
戻り値がObjectと定義されてるんだから
当然じゃね?

991 :デフォルトの名無しさん:2011/10/22(土) 00:29:43.23
lookup()がintを返すかもしれないのに?

992 :デフォルトの名無しさん:2011/10/22(土) 00:32:43.50
なにを返すかわからんから、基底型のObjectを戻り値の型にしてるんだろ。で?

993 :デフォルトの名無しさん:2011/10/22(土) 00:35:04.00
intかもしれない(もちろん他の可能性もある)値を
String型の変数に代入してるのが問題なんだろ。

994 :デフォルトの名無しさん:2011/10/22(土) 00:35:46.58
programmerのknowledgeがtypecheckerよりも優れているって書いてあるじゃん

995 :デフォルトの名無しさん:2011/10/22(土) 00:36:47.71
結局988が何を言いたいのかわからん
書くなら自分が988だと主張した上で頼む

996 :デフォルトの名無しさん:2011/10/22(土) 00:37:10.04
なるほど。programmerのknowledgeがtypecheckerよりも優れているなら
動的型付けでいいな。

997 :デフォルトの名無しさん:2011/10/22(土) 00:37:26.13
>>988のコードは、Javaなら
String s = (String)lookup("Frankenstein");
と書かれるわけで、要はDartはダウンキャストの構文省いてるだけだろう
Javaの場合、Stringじゃないものが返って来たら、実行時エラーで
ClassCastExceptionになるわけだ

ArrayListみたいなコンテナが全部Objectを格納し
こういうダウンキャストが頻発してたGenerics導入前のJavaも
型付け弱くて萎えるけど、静的型付け言語ではある

998 :デフォルトの名無しさん:2011/10/22(土) 00:39:33.76
互換性の無い(サブタイプじゃない)型の値を変数に代入できる以上、
Dartの静的型検査は型エラーを防がない。

999 :デフォルトの名無しさん:2011/10/22(土) 00:41:57.67
>>997
ダウンキャストすらせずに代入できてどうする。
そこの差は大きいぞ。

1000 :デフォルトの名無しさん:2011/10/22(土) 00:43:03.39
>>999
小さすぎるがなw お前はドアホ

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

260 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)