やっぱり動的型付け言語は大規模開発で効率が悪い 4

1 ：11/11/21 〜 最終レス ：11/12/09

大規模と書いてドカタと読む。
やっぱり動的型付け言語は大規模開発で効率が悪い 3
http://hibari.2ch.net/test/read.cgi/tech/1320832914/

2 ：

スレタイで興味持った新規さん向けの要約
> 163 ：デフォルトの名無しさん：2011/11/12(土) 00:37:41.74
> 　つーか日本の標準的な組織でどうかって話じゃないと意味なくね？
> 　ファウラーの環境を引用してどうすんの？
> 　君らファウラーに匹敵するスキルを持っていて、周りもそういうレベルの奴に囲まれた環境で仕事してんのか？
>
> 165 ：デフォルトの名無しさん：2011/11/12(土) 00:42:56.66
> 　>>163
> 　つまり日本の底辺ドカタに動的型は使いこなせるか？を議論すればいいのか
> 　じゃあスレタイも「動的型付け言語ではドカタは大規模開発できない」に変更しなきゃな
仕事で活用できないとあんま意味ないよ派
仕事でプログラミング学んだので他は知らね派
家でも趣味やOSSでプログラミングしてるよ派
仕事なんてしてませんが何か派
ﾌｧｲｯ

3 ：

PHPの動的型付け嫌だけどね
$a = "100";
これが文字列ではなく整数とみなされたりね

4 ：

整数でいいと思うけど。

5 ：

だからPHPは「HTMLを構築して出力する」という特化目的に於いて許容される仕様（とどう煮ても焼いても許されざる仕様）が山ほどあると何度
PHPは汎用プログラミング言語ではない

6 ：

"100" + 1 とか 1 + "100" が
エラーにならない言語は

7 ：

あのさ、俺思うんだ。
PHPは知能を持っている。
「10:12」こんなメモを渡されたとする。
これなんだろう？
10対12？10時12分？
これ人間だったら状況に応じて意味をくみ取るわけ。
たとえばさ、秘書に「10:12に集合するよう徹底してください」こんなメモ
渡すでしょ。
ここで秘書が「10対12ってなんですか？ちゃんとわかるように書いてください」
とか言い出したら、この娘アホの子なのか？って思うよね。
結局、JavaとかCってアホの子なんだよね。
っていうか無能なの、知能がないの。
まああたりまえだけど。
でもね、PHPにはこれができる。
やっぱりPHPには知能があるんだよ。

8 ：

$a = "百";
と書けばいいだけ

9 ：

perlとかDみたいに文字列連結と足し算を区別してないのが問題だな

10 ：

awkをdisってんのか？

11 ：

JavaとJavascriptも？

12 ：

個々の言語仕様ごとに意味が違うのに表層しか見えない >>9 の脳みそが問題

13 ：

awkは数の加算と文字列結合は分かれてる
1 1と並べて書けば文字列結合と解釈されて11になるし、1 + 1は2だ

14 ：

というか、どの言語もきちんと区別はしている（じゃないと処理できない）
人間が判断する見た目または他の言語と乖離していることがあるというだけに過ぎない

15 ：

エラーにもならず、人間が判断する見た目でも区別が付き難かったら
ミスに気付かず意図しないデータ型で動かしてしまう可能性が高まる
処理系が区別してるなんて話はそもそもしてない（んなもん当たり前）

16 ：

ポリモーフィズム全否定来ましたw
ハードディスクを交換したらファイル操作のコマンドが全部別のものになるのが正義なんだそうですw

17 ：

ポリモーフィズムじゃなくて、オーバーロードや暗黙の型変換の話ですが

18 ：

同じ見た目でも、対象によって異なった動作をする、ということが気にくわないのでしょ？

19 ：

"1" + "1" => "11" で 1 + 1 => 2 のときに
"1" + 1 => ? をどうするかという問題だから
"1" + 1 => 11 なら数値が文字列に、
"1" + 1 => 2 なら文字列が数値に型変換されてる
こういう暗黙の型変換は分かり難い
"1" + "1" や 1 + 1 は否定してないので、
ポリモーフィズム全否定ではない

20 ：

>>18
同じ見た目なら常に同じ動作だ
1+"1"が文脈やランダム性によって2になったり11になったりすることはない

21 ：

…まあ、あれだ、 x + 1 が x の「型」によって結果が違う、みたいな話にしないと
リテラルで話をしていても微妙に埒があかない

22 ：

なんでいつもの人が反論してるんだろう...と思ったら
Javaも批判の対象だからかwww

23 ：

だれがいつもの人なんだろう

24 ：

>>17
じゃあ暗黙の型パラメータとか型クラスのメソッドの名前解決とかも全否定ですね。

25 ：

あ、それは全否定でいいや
両方持ってるScalaはRuby並みにキタネーし

26 ：

>>9
Perlは文字列の連結と足し算を演算子で区別すると思うが…

27 ：

型がないと型ごとに演算子が増えるよね。
+ 数値足し算
. 文字連結
== 数値比較
eq 文字比較
みたいに。

28 ：

>>27
おまえ正気か？

29 ：

変数に型がある/ない
値に型がある/ない
まずこれを区別するところからはじめようか

30 ：

その程度も区別できないからこそ
ドカタなわけですよ

31 ：

数値の足し算と文字列連結の両方+にしたいと言ってる人は
足し算を意図している所で連結が起こる可能性を無視したバグプログラマと
文字列連結にされたくないってときに必ず
Number(a) + Number(b) とか書くような作業が大好きな人だけだろ

32 ：

記号が増え過ぎる、って主張も解らんでもない
Haskell で ++ とか初めて見た時は「…それ、なんか無理してね？」と思ったし

33 ：

・内部形式が数値か文字列かによって、足し算か連結か変わるのは良くない
・文字列の内容が数値かによって、足し算か連結か変わるのは良くない
・記号が増えすぎるのは良くない
・既存の記号に違う意味を与えるのは良くない
だれかこの堂堂巡をどうにかしてくれ

34 ：

静的型付なら問題にならないでしょ

35 ：

暗黙の変換がやたらあるのはよくない
静的なものではC、動的なものではJavaScriptの==演算子

36 ：

ていうか、Goを触ってみろ。
Cを作った奴等の次の次の言語、だけあって、Cのいいところを残して、
ダメな所がよく潰されている。

37 ：

>>34
静的型で暗黙コアージョンしまくりな言語がいいのか？

38 ：

>>36
Dartもそんな感じがするな。JavaScriptのスコープとトホホな点とかは
きっちり潰している。

39 ：

stやrubyみたいな規則だとわかりやすい
phpが場当たりなだけ
jsの==はある意味必然だろ

40 ：

goいいよね
スクリプト的にも書けるし
ちょい面倒なとこもあるけどさ

41 ：

もう結論出てるだろ
大規模開発ドカタは静的型付け言語すらちゃんと使えない
動的型付け云々を言う前に
せめてcaseの網羅性を静的検査可能な形で記述できるようになれ

42 ：

パターンマッチの網羅性を検査できる言語はあるが、
だからと言って仕様で定められた分岐を網羅してるか否かまでは検査出来ないぞ
そこは分かって書いてるの？

43 ：

仕様で定められた分岐が、可能な状態を網羅しているかどうか検証すればいいだろ

44 ：

テストで？

45 ：

>>41「必須条件だ」
>>42「十分条件ではない」

46 ：

>>41
大規模開発ドカタ限定で答えだすなｗ
静的型付け言語をちゃんと使えるプログラマ前提の話、
（お前はもちろん使えるんだよな？ｗ）
そういう前提だと、静的型付け言語が優れてるってのは
言うまでもない話だ。
ま、静的言語と静的型付け言語をごっちゃにしているお前の
いうことなんか誰も耳をかさないだろうけどなｗ

47 ：

変数の型と、値の型とを区別出来ない言語を使っていた時は.動的型付けの意味が判っていなかった。
尤も、世間の9割以上は単純な事務処理だから、区別出来なくても当面困る事は無いだろう。

48 ：

それはアセンブラでも頑張れば出来る理論だなｗ

49 ：

単純な事務処理なんてドカタ＆Javaで十分
ぬるぽはうざいけど、ドカタはJavaくらいしか書けねーしな

50 ：

またドカタが口癖にお前かｗ

51 ：

>>33
よし、数値といってもintとかfloatとかがあるから、それぞれの足し算の記号を別のものに……。

52 ：

>>46
> ま、静的言語と静的型付け言語をごっちゃにしているお前の
> いうことなんか誰も耳をかさないだろうけどなｗ
理解できていないのはお前だろｗ
>>41は「静的型付け言語」「caseの網羅性を静的検査」に言及しているが
静的言語なんて言及してねえぞｗ
で、caseの網羅性を静的検査する場合、
静的型付けとの関係が深いことは言うまでもないことだよな？な？

53 ：

>>52
なんかさ、すべての問題を解決してくれないなら
意味が無いと思ってないか？
ユニットテストは仕様上のバグを解決してくれないから
意味が無いみたいな。
caseだって網羅性とか完璧に解決してくれないなら意味が無いと
言おうとしてるんだろうけど、caseと静的型付けはほとんど関係ないから。
まあ、caseっていうかswitchの引数に指定できない型を検出してくれるという意味で
少しは意味があるけどね。

54 ：

C#かJavaか知らないけど、言語によっては、
switchにenum型変数を入れてcaseではそのenum型の
値でしかチェックできないってのもあったはず。

55 ：

網羅性の静的検査があると嬉しいのは事実
直和型のパターンマッチとかでは、型さえ仕様と合ってれば
仕様で定められた分岐の網羅性を検査できるわけだし

56 ：

>>55
それって動的型付け言語じゃできないものなのかな？
この変数に入る値は○○ですって
あらかじめ定義しておけば、
動的型付け言語でも可能だと思うんだけど。

57 ：

>>56
直和型について言えば、定義した型を
実行時に変更できないようにすれば可能かもしれない

58 ：

>>57
> 定義した型を実行時に変更できないようにすれば
それって静的型付け言語って言うんじゃ…

59 ：

実行時に変更できない時点で動的型付け言語じゃなくなってるけどなｗ
やっぱり静的に型付けできないと、静的にチェックは難しくなるね。
もし静的型付け言語にコンパイルフェーズってのがあって
その時にコードでいろいろ変更できるようにすれば
動的型付け言語を完全に超えられると思う。

60 ：

でもさ、動的型付け言語で優れたIDEが作れる、と言っても
実例としてはSmalltalkにしか存在しないように、
静的型付け言語なら分岐の網羅性を静的検査できる、と言っても
実例としては一部の関数型言語しか存在しないじゃん
このスレにいる静的型付け言語派の人はみな関数型言語使いなの？

61 ：

またわけのわからんのが来たよ

62 ：

>>59
コンパイル後の変更に対応できないから動的型付け言語を超えられない。

63 ：

>>53は型の基本がわかっていない...

64 ：

前スレで分かったこと
- 大規模開発にはドカタ動員が必須
- ドカタは静的型チェックやIDEの補完の助けなしではFizzBuzzも書けない。
- 逆にコンパイラとIDEの助けを借りれば、なんとか動くコードは書ける。
- 動的言語には現状まともなIDEがない（Smalltalkerはこっちくるな。Emacs？笑えんな）
- よって大規模開発で動的言語を使うと炎上する

65 ：

>>64
> - 逆にコンパイラとIDEの助けを借りれば、なんとか動くコードは書ける。
だうと

66 ：

>>62
> コンパイル後の変更に対応できないから動的型付け言語を超えられない。
コンパイル時に変更できれば、あらかたの問題は解決するでしょ？
どうしてもコンパイル時にやらないといけないことってなに？

67 ：

>>66
実行時拡張

68 ：

>>67
それは言葉を言い換え得ただけ。
どうしても実行時拡張をしないといけないことってなに？

69 ：

たいていの問題はコンパイル時拡張が出来れば
実行時拡張を使う必要がない。
俺が作ろうと思っている言語は静的型付け言語だが、
コンパイル時拡張を備えている。

70 ：

むしろ実行時拡張しなくてもいいアプリのほうがよほどドカタ・・・

71 ：

だから、どんなときに実行時拡張が必須なのか
言えってｗ

72 ：

言えないから、ドカタって煽って逃げてるんだろ・・・
察しろよ！

73 ：

あ、なるｗ　ｗｗ

74 ：

Smalltalkは原則として実行時の拡張しかできない。

75 ：

実行時拡張というのは、万能関数 eval を使ったメタプログラミングのことだろ？
（他にはリフレクティブプログラミングと呼ぶ事もある）
LISP系言語やRubyでは必須というか、煽るまでもなくごく当たり前に使われているな

76 ：

使われてるかどうかじゃなくて、
どういう時に使うのかって話なんだけどなｗ

77 ：

コンパイル時拡張があれば、動的拡張はいらないって話なんで
そこんところを勘違いしないように。

78 ：

>>74
Smalltalkの場合、クラスブラウザ上でクラスを新規定義すると、
ブラウザの中の人がClassインスタンスを生成して
それをシステム辞書に登録するんだったよね

79 ：

Smalltalkなんかはそうなってるってだけで、
どうしても実行時に拡張しなければいけないことなんてないでしょ。
特にコンパイル時に拡張できればほとんどの問題が解決する。
で残りの問題はあると思うから「ほとんど」と書いたが、俺は思いつかない。
どうしても実行時に拡張しなければならないことなんてあるの？

80 ：

とりあえずこれでも読んでみるとか。
「ソフトウェア工学」は矛盾語法か？-アラン・ケイ
http://metatoys.org/oxymoron/oxymoron.html

81 ：

>>76
たとえばActiveRecorrdというRubyで書かれたORM(Object-Rerational Mapper)では、
データベースに接続した時にデータベースのスキーマ情報から各テーブルに対応する
クラスが動的に定義される。この時、テーブル内の各フィールドはクラスに所属する
インスタンスメソッドとしてこれまた動的に定義される
JavaやC++のような実行時拡張の欠落した言語には、こんな芸当ができるかな？

82 ：

>>80
要約すると、コンパイル時拡張では最初からやり直しになりがちだしデータも作り直しになるから
例えばSmalltalkみたいに３０年間動き続けるとか長期運用に耐えるソフトウエアは作れない。

83 ：

最初からやり直しになるとかデータも作り直しとか
どこの世界の話だよ

84 ：

>>81
でもさ、それって obj.setField(F1, 'abc') こう書くのとなにも変わらないよね？

85 ：

>>81
データベースに接続した時点でのクラスが作られるってことは言い換えると、
コードに書いてあるクラスとは違うオブジェクトができてしまうこともあるってことで、
データベース定義が変わってしまうと、コードが動かなくなってしまうってことじゃないの？
それよりか、データベース定義からコンパイル時にクラスを作ってくれたほうがいいんだが。

86 ：

> それよりか、データベース定義からコンパイル時にクラスを作ってくれたほうがいいんだが。
ようするに、その言語のクラスの定義の仕方は、
class HOGE {
　　public foo()
}
みたいなのだけど、
yamlで書いたテーブル定義からも
クラスを定義できるってこと？
yamlからSQL文も生成できるようにしておけば、
単一の定義からクラスとcreate table文が出来るわけか。
一種のジェネレータみたいだけど、実際にコードを生成しなくても別の定義ファイルから
コンパイル時に直接クラスを作れるわけか、それってかなり良くない？

87 ：

コンパイル時拡張が出来れば、コンパイル時に
データベースに接続して、クラス生成なんてことも可能だろうね。
これだと、しっかり型チェックができるから
更に優れているのではないか。

88 ：

これからはやるだろうな。コンパイル時拡張。

89 ：

>>84
Rubyだと、obj.f1 = 'abc' あるいは obj.f1! abc と書けるよ
JavaよりもRubyのほうが簡潔なコードが書けることは一目瞭然じゃないのかな？

90 ：

データベースのフィールドなんか、コード補完できないところだけど、
コンパイル時拡張があれば、コード補完できるようになるかもしれないな。

91 ：

>>89
でも、シンタックスシュガーでしかないでしょ？
ちょっと書き方が変わった程度。
C＃ならプロパティがあるから、
obj.fields(f1) = 'abc'なんてかけるしね。
もしそれでデータベース定義に従って
コンパイルエラーが出るなら、まだ意味があるけど無理でしょ？
もしコンパイル時拡張があれば、obj.f1 = 'abc'って書いてコンパイルしたら
データベースにそのようなフィールドはありません。ってエラーを出せるようになるかもね。

92 ：

>>91
>でも、シンタックスシュガーでしかないでしょ？
>ちょっと書き方が変わった程度。
いや、単なる構文糖とは全然違うよ
JavaやC#じゃ obj.set_f1('abc') あるいは obj.f1 = 'abc' と書けないだろ？

93 ：

>>85
>データベース定義が変わってしまうと、コードが動かなくなってしまうってことじゃないの？
それはJavaでも同じだろ？ActiveRecord固有の問題じゃないよ
>>85,86
>それよりか、データベース定義からコンパイル時にクラスを作ってくれたほうがいいんだが。
そういったクラスジェネレータは、ActiveRecordの登場以前にもいくつか存在していた。
その代表例が、AppleのWebObjectsというWebフレームワークの一部である
EnterpriseObjectと呼ばれる技術。WebObjectsでは、Modelerというツールを
利用する事でデータベースのスキーマ情報からクラス定義を自動生成できる。
さらにはModelerは、IDEであるProjectBuilder(今のXCode)と統合されている。
一言で言えば「過去に通った道」だね

94 ：

>>86
>yamlで書いたテーブル定義からもクラスを定義できるってこと？
そのアイデアも過去に通った道
・Rubyist Magazine - プログラマーのための YAML 入門 (実践編)
　　http://jp.rubyist.net/magazine/?0011-YAML

95 ：

ドメインモデル貧血症を地でいく展開だね☆

96 ：

むしろRubyの場合、IDE側がRubyそのものを動かせば案外上手く行くんじゃ？
あの言語、実行途中でクラス作成や追加や修正できて
インスタンスも同じく作成追加修正できるし
あるオブジェクトが現在持っているメソッドの一覧とかも出せるんじゃん

97 ：

実行時拡張の議論でわかったことは、
ORマッパーやダイナミックローダを使うだけのドカタは、
それらの機構を実現する基礎となっている実行時拡張を不要と言い切る。
天に唾するとは、このことだなｗ

98 ：

だからドカタに動的言語を使わせるのは自行為だと何度言えば

99 ：

>>95
ドメインモデル貧血症 ＝ トランザクションスクリプトで
特に日本でよく使われる、優れた方法の一つなんだが・・・

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
・　次のスレ
4: スレ立てるまでもない質問はここで 115匹目 (321)
5: 【Google】Androidアプリ作成part10 (759)
6: Androidプログラミング質問スレ Part15 (667)
7: 【誰か】jQueryのここがわからない 2【助けて】 (22)