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

1 ：11/11/22 〜 最終レス ：12/01/26

静的型付け言語は最強
Java → 冗長すぎる → Scala（静的型付け言語）
のコンボで行きましょう
前スレ
http://hibari.2ch.net/test/read.cgi/tech/1320832914/

2 ：

Clojureも型付け指定すれば柔軟な動的言語としての機能をローカル関数で使って、インターフェースとして外界にさらす関数を型指定で組むことで使いがってが非常に良くなるので検討してちょ

3 ：

重複スレ誘導
http://hibari.2ch.net/test/read.cgi/tech/1321843683/l50

4 ：

このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

5 ：

まさかSmalltalkのメッセージパターンが英語との親和性が非常に高いことも知らずに
メソッドの英語としての読みやすさ云々を言う香具師がいるとはねw

6 ：

Smalltalkのメッセージの英語っぽさなど笑止
メソッド名に英語の文章をだらだら書くJava方式こそ至高

7 ：

Java言語+Eclipseのタッグが最強だろ…誰がなんと言おうとな、ハ。
Scalaなんぞつかっとる厨など俺のEclipse捌きの前では瞬だは。
いうなればGoogle Mapsを駆使してる俺 vs 紙の地図でｳｵｰｻｵｰしてる厨みたいなもんだは。
ショートカットキーぽんぽんぽんでコーディングが完了する様を指でもくわえてみてろよｗ

8 ：

魚竿？

9 ：

しつこすぎ
いい加減にしろ

10 ：

なんか静的型付け言語だと
Javaだけじゃなくて、C#、C++、Scalaが代表例として出てくるけど、
動的型付け言語はSmalltalkしかないみたいじゃない
Smalltalk（現場では殆ど使われてない）しか
誇れるものがないの？ｗ

11 ：

SmalltalkとLISPが極北にあってある意味理想型だけど、
強力すぎるので制限されたSmalltalkやLISPとして他の言語を使っているわけだ。

12 ：

いや静的型付け言語は実際に使っている言語の話をしてる。
動的型付け言語だけだろ。実際に使ってない言語の話をしてるのは

13 ：

ScalaとSmalltalkでは、どう考えてもSmalltalkのほうが事例は多そうだがなｗ

14 ：

動的型付け言語って、静的型付け言語ならソースコードだけで完結することをわざわざドキュメントとテストにまで散らかして仕事増やしてるだけだよね。
ドキュメントもテストも適当でいい、または採算度外視のプロジェクトでしか使えない。

15 ：

しつこすぎ
いい加減にしろ

16 ：

ここそういうスレだから、ウザイと思うならスレ見なきゃいいじゃん。

17 ：

COBOLやFlex/as3プログラマーが定時退社で月給150万円以上もらってるという事実すら知らず、
Flashはオワコン、Webサイコー、Javaサイコー、Rubyサイコー、動的だ、静的だ、
とか言ってるアホが多い
挙げ句の果てにはドカタがドカタを見下すアホっぷり

まあアホだからこそ中卒リアル土方以下の月収40万円無保障使い捨てでもこき使えるんだが
言語云々よりも客先業界を選ぶ能力を身に付け、潤ってる業界が好む言語を使え

動的だの静的だの、そんな見当違いのところに頭つかってるからドカタなんだよｗ
　

18 ：

IDEの話をすると動的型言語使い（Smalltalk除く）は黙る
コードを書く御題が出るとJava使いは黙る

19 ：

つかもっと実践的な長いコードで比べてみたいんだが。
500行以上でライブラリを使いこなしたコード。
そうすれば大差ないってことが分かるんだがね。

20 ：

うむ。オイラは2kステップ以内ではやりかたの優劣なんか大して出ないと思っている。
実際の現場では一人5kから15k書いて1小隊が30kから50kくらいになるよな？
でさらにそれらを結合していく訳で。
ジャンボジェットつくるときに昆虫の飛行理論出すのはイクナイ、と思うことが、よくある。

21 ：

smalltalkで英語の文みたいに書けるて話、もう25年前だろ？
あれで一体、オレらが生きてる現実世界の何を解決出来たのかと、小一時間問い詰めたい。
夢見て裏切られると、信者から超アンチになるよ

22 ：

>>17
>COBOLやFlex/as3プログラマーが定時退社で月給150万円以上もらってるという事実すら知らず、
と、妄想を語る無職元ドカタ乙

23 ：

>>22
COBOLは知らんがFlexは150どころか200、300なんて話も聞くな
技術者がいないのもそうだが、仕事を取ってくる発注側（企画会社、広告代理店）で金が唸っているのが一番の理由っぽい
まず発注者がNTTデータやNECなどの既存ベンダーではないってのもあるかも
完全に一過性のバブルだろうけど

24 ：

COBOLは年功序列的な要因だろ
20世紀はCもVBもインフラ屋さんそのくらいが相場だったし

25 ：

Smalltalkのキーワードメッセージパターンは
メソッドの意味、各パラメータがどのように使われるのかという用法など、
コードとドキュメンテーションの一体化にすごく貢献している。
その工学的な有効性を理解できずにアンチになる人はどのみち大したこと
できないだろうから、放置でいいんじゃね？

26 ：

>>19>>20
違うちがう。Javaドカタはライブラリのメソッドを順番に呼び出す
簡単なコードしか書けないってことだよ。
ちょっと制御構造が入ったら10行程度の簡単なプログラムも書けない。
まさにドカタ。

27 ：

Smalltalk って 1 + 2 * 3 が 9 を返すんでしょ？

28 ：

演算子の優先順位とか考えなくていいからそれはそれで便利だけどな

29 ：

>>23-24
> Flexは150どころか200、300なんて話も聞くな
> 20世紀はCもVBもインフラ屋さんそのくらいが相場だったし
ソースプリーズ
脳内の妄想なら、自分の日記に書いとけ。

30 ：

>>27
電卓dis乙

31 ：

>>29
ブラック案件じゃあるまいし公募なんてしてるわけねーだろ
常識的に考えて
学生かよ

32 ：

はい、脳内確定です。

33 ：

>>1-1000
おまえら一盛り10円
http://kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

34 ：

ドカタ言語があるのではなくドカタドメインがあるってことに気付け
どれだけ多くの言語を覚えたところで
ドカタドメインのアプリしか書けないならドカタ
特定のドメインでしか使われない言語がある
その言語を使いこなして仕事をする奴は単価が高い
だからといってドカタがその言語を覚えても単価は上がらない
単価が高いのは、その言語を使いこなせるからではなく
そのドメインに精通しているからだよ
このことを勘違いしているドカタは本当に痛い

35 ：

>>27
電卓でも珠算でも９だね。で、何？

36 ：

>>29
シリコンバレーでFlashプログラマの給与が急騰中
http://www.publickey1.jp/blog/10/flash_2.html
DeNAの初任給1000万円、グリー1500万円
http://news.livedoor.com/article/detail/6111164/
バブルor不人気では当たり前の結果だわな。
ゴミ収集のおっさんが給料高いのと一緒。

37 ：

500個のタブを開いたSafariをFLASHでクラッシュさせられたときの絶望感

38 ：

>>35
> 電卓でも
関数電卓だと 7 になる奴もあるよ。
> で、何？
無知露呈しちゃったね。

39 ：

世の中には「色を決める職業」というのがある。
主に高級ブランドサイトや大手企業サイトが客。
お値段、A4の紙切れ2枚で500万円。
当然、それを受け取ってWebサイトを作る人も高給取り。
完全に属しているコミュニティーの問題だよ。

40 ：

>>38
うーん。それで Smalltalk の弱点を指摘しているつもりなら違うなあ。
System.out.println(BigInteger.valueOf(1).add(BigInteger.valueOf(2)).multiply(BigInteger.valueOf(3)).intValue());
Java でも 9 だ。
数学的には + は T * T -> T に定義される関数であって、
これを T 型オブジェクトのメソッドとするという発想に無理がある。
関数は関数。何でもメッセージにすりゃいいってものじゃないだろうと。

41 ：

>>1-1000
おまえら一盛り10円
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

42 ：

>>40
>うーん。それで Smalltalk の弱点を指摘しているつもり
まず、日本語の理解から始めたほうがいいんじゃね？

43 ：

>>42
当たり前だが >>27 を含めてレスしている。

44 ：

>>38
> 関数電卓だと 7 になる奴もあるよ。
で、何？
1+2*3という表現式の評価結果を9とする
正当な環境があるという事実には
何の変わりもないよ。

45 ：

しょぼい電卓 or Smalltalk： 1 + 2 * 3 = 9
数式、関数電卓、普通の高級言語：1 + 2 * 3 = 7

46 ：

かってにきめんな！まず演算子の優先度をだな…
といった定義厨御用達言語。

47 ：

smalltalkって決めうちの優先度を持っていたり自分で優先度を定義する
仕組みって無いの?

48 ：

だまSmalltalkの話しかしてないのか？
そんなに動的型付け言語は駄目なのか？

49 ：

>>45
へー、あんた、数学での掛け算をアスタリスクで書いてるのかｗ

50 ：

>>49
お前は何で書いてるの？

51 ：

\times

52 ：

>>49
そんなことでしか反論できなくなったのか (w
ROM ってりゃいいのにね。

53 ：

ROMるべきは、動的型付言語の本当の問題点を何一つ指摘できずに
動的型付言語発祥の技術を「静的型付だからできる（ｷﾘｯ」とか言ったり
動的型付けとは関係ないアサッテな事で腐すしか脳がない静的ドカタでは？

54 ：

>>45
そんなことでしか反論できなくなったのか (w
ROM ってりゃいいのにね。

55 ：

lispだとcobolの10分の1程度のタイプ数になったりするから
行数ベースで見積もりたててると効率が悪いって話になるんだろうな

56 ：

そうだね、俺も >>53 は ROM るべきだと思う。

57 ：

1 + 2 * 3 => 7
----- 演算子の優先順位の壁 -----
1 + 2 * 3 => 9
----- 演算子定義の壁 -----
BigInteger.valueOf(1).add(BigInteger.valueOf(2)).multiply(BigInteger.valueOf(3)).intValue() => 9

58 ：

>>45
関数電卓ならRPNでしょ。

59 ：

型推論最強のHaskellさんでFA。
動的言語なんて使い捨て目的以外で使おうなんて思わない。
evalなんてスパゲティの元だ。

60 ：

Haskellが流行ったら困るのは
mapやfoldlすら殆ど使ったことのないJavaドカタだけどな

61 ：

そのままそうして燻っておけ。そのほうが助かるわ。

62 ：

> mapやfoldl
動的言語のlispがもとだろ

63 ：

>>62
細かいこと気にしすぎじゃね？
なら型推論使ってる動的言語をどう思うの？

64 ：

実行時に型を判断するから動的型付け言語なのであって、
型推論（静的に型を推論する機能）は動的型付け言語とは
真逆の発想だ。

65 ：

動的型付け言語が型推論欲しいのって
やっぱり静的型付け言語は羨ましいなぁ。
静的にチェックしたいよ。という要求から来るのではないのか？

66 ：

Javaにブザマな型推論が入ったときは、
やっぱドカタも簡潔な言語が羨ましいんだなって思ったわw

67 ：

よく知らずに想像で書くけど、
コンパイルのときに型推論できるところは最適化できるとかかなあ。

68 ：

最適化できるという話はあるが最適化したという実績は知らないから想像で書くけど、
コンパイラの価値は最適化ではなくポータビリティにある。
しかしJavaの型とHaskellの型は全然違うので全然ポータブルでない。

69 ：

静的型付け言語が型推論欲しいのって
やっぱり動的型付け言語は羨ましいなぁ。
型なんて書かずにプログラミングしたいよ。という要求から来るのではないのか？

70 ：

>>65,69
どちらの視点も正しい(少なくとも誤りではない)と思うね

71 ：

>>66
簡潔に書ける構文と
静的動的は別の概念だぞ。
静的でもScalaのように簡潔に書ける言語はあるし
動的でもJavaScript（DOM）のようの面倒な言語もある。

72 ：

>>67
> コンパイルのときに型推論できるところは最適化できるとかかなあ。
うん。型推論っていうのは
動的に型を判断するのではなくて
型を書いてないのに、型を書いたかのように
静的に型を判断してくれる機能。
実行時にならないと型がわからない場合（動的）は
型推論できない。

73 ：

型推論っていうのは、
変数から型情報をなくしましょうではなくて
型情報が推論で決まる所は省略できますってだけだからな。
実質型を書いているのと同じなんだよ。
冗長な記述をなくしただけ。シンタックスシュガーと同等のもの。
動的型付け言語は、変数から型情報をなくして
実行時の値で判断しましょうという考え。
だから根本的に違っている。

74 ：

まあ本当に型を書いてない多相ヴァリアントは型推論の中でも異端視されているんだよな

75 ：

静的型付け言語も、パターンマッチは実行時の値で判断する。
これって、実行時の値で判断しましょうという考えから来るのではないのか？
だから根本的には同じだ。

76 ：

>>73
動的型付け言語に後付けで型推論ベースの静的型チェックを
追加すること（例えばlint的なものとして）は不可能という主張？

77 ：

scalaが簡潔？scalaはinfoQ記事以後の流れを見てると完結しそうだが。複雑だろ？

78 ：

>>75
それはJava/C#のような「出来の悪い」静的型付け言語に限定される話
それだからcaseの網羅性をコンパイル時に(静的に)検査できないという欠陥がある
MLやHaskellのような「正しい」静的型付け言語であれば、
パターンマッチはコンパイル時に(静的)に決定される
>>だから根本的には同じだ。
したがって、他の人達が言うように静的型付けと動的型付けは根本的に違うよ

79 ：

つってもHaskellでさえ実行時束縛してる箇所あるし

80 ：

出来の悪い静的型付けと正しい静的型付け
なぜ潰し合うのか

81 ：

>>76
> 動的型付け言語に後付けで型推論ベースの静的型チェックを
> 追加すること（例えばlint的なものとして）は不可能という主張？
条件付きで可能。100%は不可能。
たとえばローカル変数の場合、他から変更されようがないから
その変数の型は判断可能。
その変数にオブジェクトを代入したとして、オブジェクトに
動的に追加されたメソッドまで分かるかと言ったら無理。

82 ：

ocamlでもメソッドを追加できるぞ
let add_bar x = object
method foo () = x#foo ()
method bar () = "bar"
end;;
let o = object method foo () = "foo" end
in add_bar o;;

83 ：

そもそもOCamlはオブジェクト作るのに
必ずしもクラスを定義する必要無いからね

84 ：

>>75
お前はBoostで地獄を見てこい。

85 ：

>>84
型付けとは関係ないけど
Cでできることが全てC++でもできることを証明することにより
Cで地獄を見ないならばC++でも地獄を見ない、ということを証明できる気がする

86 ：

Java, C#：出来の悪い静的型付け
Ruby, Python：静的型検査無し
Haskell, OCaml：ライブラリ不足
C++, Scala：セカンドシステム症候群
どれも決定打に欠けるので、いつまでも結論が出ない

87 ：

Haskell, OCamlがJVM, .NETに対応できない理由は、
出来の悪い中間言語より型のないネイティブコードを生成する方が良いと思ってるから。
ということはつまり、Java, C#の更に上に型のないレイヤーを乗せれば、
Haskell, OCamlがJVM, .NETに対応してライブラリが利用できる。

88 ：

なんだよ型のないネイティブコードって。

89 ：

コンパイル時に既にチェック済みなので実行時は一切チェックされなくなるコード。

90 ：

それはCOMとIDL(インターフェイス定義言語)のことかな？

91 ：

そう言えば、最近、ドカタキングことドカ太郎がいない。。。
polymorphism も universalとad-hocと２種類あるんだな。へぇーと思って本を読んでた。

92 ：

>>86
ぎんのたまはないってこと。
最も、問題に適切なパラダイムを持つ言語を使えるようにしておくのが一番い
いんだろうけどな。現実はそうやないから、むしろ言語選択する側のリテラ
シーによるよな。リテラシーのないやつほど、好きだから、みんな使ってるか
らみたいな情緒的な理由になりがち。

93 ：

>>90
機械語の事だろ。

94 ：

動的型付け言語はふつうの包丁
静的型付け言語は悪用を防ぐ装置がついた包丁

95 ：

>>94
ただし、肉を切ろうとすると悪用防止装置が発動して、肉を切れない包丁。

96 ：

そうやってまた変な例えをする…。
現実の包丁はCやasmの低水準だろ。

97 ：

パラダイムの違いなんだって。^^; data driven なプログラミングを
静的でやろうとおもえばかなりしんどいだろうけど、他のでやれば
何とかなるってこったろ？ただ、柔軟じゃないってこと。

98 ：

>>86
ぶっちゃけその中だとdynamic使えるC#が最強だと思う
DynamicJSON使って思った

99 ：

>>87
OCamlはF#があるだろ

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
・　次のスレ
65: C++相談室 part93 (689)
66: Visual Studio 2008 Part 21 (476)
68: Androidアプリ制作依頼スレ (287)
69: 【.cmd】 バッチファイルスクリプト %8 【.bat】 (460)