静的型付け言語の潜在開発生産性は今の100倍 ×5

**デフォルトの名無しさん** · 2013/11/24(日) 15:06:08.63

int a = 1;
a = "a"; ← エラーになる。
型がない言語ではできない芸当です。（爆笑）

人間がやっていたことを、コンピュータにやらせる。
これが生産性を上げる最大の方法。
コンピュータは間違わない、同じ事を何度も高速に行える。

その為に、コンピュータがコードの意味を正確に
認識できる方法が必要。実行しないとわからないことは
コンピュータは認識できない。

すなわち静的型付け言語であれば、実行しなくてもわかるので
コンピュータが理解できる。そうすれば様々な
コンピュータの高度な情報支援が得られる。

コンピュータのバックアップを受け、人間の生産性は
限りなく向上する。

前スレ
静的型付け言語の潜在開発生産性は今の100倍 ×4
http://toro.2ch.net/test/read.cgi/tech/1383572174/

**デフォルトの名無しさん** · 2013/11/30(土) 19:54:16.61

引数にどんな型が渡されるかわからない言語とか怖くて使えない
C#やJavaで言えば常にObject型の引数が来てリフレクションでメソッド呼び出すようなもんでしょ

**デフォルトの名無しさん** · 2013/11/30(土) 20:00:26.55

>>308
全然違うよ、馬鹿すぎる

**デフォルトの名無しさん** · 2013/11/30(土) 20:02:13.99

ぜんぜん違うよ！

（じゃあ何が違うのだろう・・・）

ぜ、ぜんぜん違うんだよ！

（あぁ、答えられないのね）

**デフォルトの名無しさん** · 2013/11/30(土) 20:14:59.40

型が推論できるかとコードの近さとは関係ないよ
静的型付関数型言語で、遠い場所のコードは推論できないとか聞いた事ある？

**デフォルトの名無しさん** · 2013/11/30(土) 20:20:38.49

遠い場所のコードの型が推論できないのは
動的型付け言語の話でしょ。
静的なら当然遠くの場所でも型わかるさ。

**デフォルトの名無しさん** · 2013/11/30(土) 20:22:52.62

動的な機能を使えば遠くても推論できない
使わなければ遠くても推論できる

結論：近さは関係ない

**デフォルトの名無しさん** · 2013/11/30(土) 20:23:56.27

> 動的な機能を使えば遠くても推論できない

動的な機能を使えば近くても推論できない、の間違い

**デフォルトの名無しさん** · 2013/11/30(土) 20:24:13.56

> 静的型付関数型言語で、遠い場所のコードは推論できないとか聞いた事ある？

遠い場所が発生しないように、クラスのパブリックメソッドには
きちんと型を書かないといけないって話なら聞いたことあるな。
推論できるのは近くの場所だけだからね。

**デフォルトの名無しさん** · 2013/11/30(土) 20:24:45.89

A<B> x = y.foo(z.bar());

型情報で候補を絞り込むのは foo と bar だけ
A と B と y と z は型情報を使わずに補完
x は補完できない

**デフォルトの名無しさん** · 2013/11/30(土) 20:26:08.49

>>317
それってSMLとかOCamlとかHaskellにも当てはまるの？

**デフォルトの名無しさん** · 2013/11/30(土) 20:26:18.94

型推論って、静的型付け言語ならでわの
機能だって知ってるかな？

型がない言語では、推論したくても推論できない。
推論できるのは、そもそも型が存在するから。

**デフォルトの名無しさん** · 2013/11/30(土) 20:28:39.63

>>319
> それってSMLとかOCamlとかHaskellにも当てはまるの？
当てはまるんじゃね？

その言語の汎用ライブラリでも調べればわかるでしょ？
使い方を限定することが出来ないライブラリだと
そのシグネチャに型を書いていないと当然推論さえも出来ない。

**デフォルトの名無しさん** · 2013/11/30(土) 20:29:21.51

今書いた関数をその場で自分で呼び出すなら型は無くても良いよ。
ワンライナーとか掻き捨ての小さなスクリプトとかは断然動的型の方が書きやすい。

ただ他の人も使うものとか、あと今日はともかく明日の自分は他人と思っておいた
方が無難だから、今後再利用する可能性のあるものに関してははドキュメントを
書くし、それには引数の期待する型の情報も含まれるよね。となると、

/**
* @param str {String} an input
* @returns {Number} a nice output
**/
function func(str){ ... }

と

/**
* @param str an input
* @returns a nice output
**/
int func(String str){ ... }

にどれほどの違いがあるのかと。
逆にどうしても型情報を「つけたくない」(つけるのが面倒、では無く)場面というのは
案外限られるし、そういう場面では静的型でもJavaのObject渡しでリフレクションとか
Cで生ポインタ渡しでキャストとかそれなりに回避策もある。

だから結論としては静的には動的にも書けるGroovyは節操なくて便利だと。

**デフォルトの名無しさん** · 2013/11/30(土) 20:30:22.11

>>321
残念、当てはまりません

**デフォルトの名無しさん** · 2013/11/30(土) 20:31:16.84

>>322
いや、動的型付けは小さいものじゃないと
使いものにならないという言い方をしてくれよ。

小さいもので作りやすいとか言われても興味ないんだよね。
小さいものなら適当でも全体見渡せるからいいよ。

でも大きい物はどうなのさ？
こっちのほうが何倍も大変だ。

**デフォルトの名無しさん** · 2013/11/30(土) 20:31:48.99

>>323
そうか

で、説明はないんだね。

（やっぱりな苦笑）

**デフォルトの名無しさん** · 2013/11/30(土) 20:32:36.69

動的型で、コードの場所が遠いという理由で推論できない例をあげてみてよ

**デフォルトの名無しさん** · 2013/11/30(土) 20:33:32.31

>>326
JavaScriptでいえば、

function foo(a) {
　　aが持ってるメソッドは？型推論できない。
}

**デフォルトの名無しさん** · 2013/11/30(土) 20:34:55.44

>>325
OCamlはシグニチャ付けてコンパイル通るコードは、
シグニチャ無しでも型推論でコンパイル通るって話だよ

**デフォルトの名無しさん** · 2013/11/30(土) 20:35:58.32

>>328
それはシグニチャなしでも通るだけ。
型推論はしていない。型を捨ててるだけ。

**デフォルトの名無しさん** · 2013/11/30(土) 20:36:20.71

>>327
そのfooを呼び出してる側のコードも読み込んで
解析するのが普通なので、fooを使ってる側のコードも必要

**デフォルトの名無しさん** · 2013/11/30(土) 20:36:51.82

>>329
知らないのに絡むヤツだなぁ
OCamlが型捨てる訳ないだろ

**デフォルトの名無しさん** · 2013/11/30(土) 20:39:39.32

>>330
> fooを使ってる側のコードも必要
ほらな。遠くになったからわからなくなった。
近くじゃないとわからないから
その情報をほしいわけだろ。

**デフォルトの名無しさん** · 2013/11/30(土) 20:40:02.31

>>324
いや、だからちゃんと結論を読んでくださいって。
結局静的動的関係なく単にGroovy節操なくて良いよと言いたいだけなんでw

という冗談はともかく、結局動的でもメンテナンス可能な大きなものを書くには
型とか含めてゴリゴリドキュメントを書くし、トータルな手間としては結局静的
言語と大差なくなってくる。小さなもの相手には出来た手抜きは通用しない。

ただ動的言語でもきっちり手間をかけて書かれた大きなプロダクトはいくらでも
あると思う。

**デフォルトの名無しさん** · 2013/11/30(土) 20:40:41.97

>>330
> そのfooを呼び出してる側のコードも読み込んで
> 解析するのが普通なので、fooを使ってる側のコードも必要

fooを使っているかどうかは、
静的型付け言語ならコンピュータが判断してくれるよ？

動的型付けではできないよね。

**デフォルトの名無しさん** · 2013/11/30(土) 20:42:23.74

>>332
> ほらな。遠くになったからわからなくなった。

なんで遠くにあるコードも解析に使うって話からこの結論になるの？

**デフォルトの名無しさん** · 2013/11/30(土) 20:43:49.21

>>334
動的型だと、出来る場合と出来ない場合がある

**デフォルトの名無しさん** · 2013/11/30(土) 20:48:30.69

>>327
Javascriptって、次のような関数がある場合でも

function bar() { foo(1); }

fooの中でaのメソッドを補完できないほど
しょぼいIDEしか無いの？

**デフォルトの名無しさん** · 2013/11/30(土) 20:54:53.89

>>337
それに加えてfoo("hoge")みたいな呼び出しもあったらどう補完されるの？

**デフォルトの名無しさん** · 2013/11/30(土) 20:56:40.84

遠くにあるコードを解析する言語は、全体が完成するまで解析できない

つまり、全体が完成する前に実行できる言語があれば
静的に解析するより早い時期にデバッグできるんだよ

**デフォルトの名無しさん** · 2013/11/30(土) 21:02:09.63

静的な型付けの言語は別に型の推測に遠くのコードを解析する必要なんて無いけど。
そのコードを書いた時点で型が確定しているのだから当然。

**デフォルトの名無しさん** · 2013/11/30(土) 21:02:55.68

>>338
両方が共通に持ってるメソッドだけ補完するか、
どちらか一方が持ってるメソッドを補完するか、
好きな方を設定で選ぶ

**デフォルトの名無しさん** · 2013/11/30(土) 21:08:55.09

>>341
JSでそういう上等な補完を行ってくれるIDEってあれば知りたい。

動的言語のIDEの補完は影響範囲がローカルでレキシカルに型を特定できたり
ドキュメントに型情報がある場合はその型を、そうでない場合は諦めモードで
基本クラスやDOMやjQuery等のメジャーなAPIをずらずら並べるのが多い気がする。

**デフォルトの名無しさん** · 2013/11/30(土) 21:11:09.53

>>339
Haskell等でも、未完成の関数をundefinedにしておいて
未完成の状態で実行したりするらしいよ

**デフォルトの名無しさん** · 2013/11/30(土) 21:24:41.50

JSとLispの差にくらべてJavaとHaskellの差が大きすぎる
静的型付け言語は多様性が100倍

**デフォルトの名無しさん** · 2013/11/30(土) 21:30:53.47

JavaとHaskellの差は手続き型か純粋関数型かの違いだと思うけど。
動的静的、関係なくない?

**デフォルトの名無しさん** · 2013/11/30(土) 21:48:34.09

Javaはオブジェクト指向です

**デフォルトの名無しさん** · 2013/12/01(日) 00:13:53.45

>>343
するかボケ
評価の順序試す時ぐらいだろ

**デフォルトの名無しさん** · 2013/12/01(日) 01:11:10.71

>>322みたいにドキュメントを用意して引数の型を丁寧に書くなら型を動的にするメリットがない
じゃあドキュメントを用意しない場合はどうか。

function func(attr){ ... }

int func(File.Attributes attr){ ... }

こんな関数があったら前者は怖くて使えないよね。
何を渡していいのかわからない。何が渡されるのかわからない。
後者なら型情報が全てを物語ってる

**デフォルトの名無しさん** · 2013/12/01(日) 01:13:33.60

>>348
実装見たらええやん。3行程度だし。

**デフォルトの名無しさん** · 2013/12/01(日) 01:19:41.54

>>349
補完そのものを全否定かい

**デフォルトの名無しさん** · 2013/12/01(日) 01:19:44.84

>>349
実装見ても理解できる気がしない
https://github.com/jquery/jquery/blob/1.8-stable/src/core.js#L772

**デフォルトの名無しさん** · 2013/12/01(日) 01:24:07.19

動的型付け言語を好む動的人間と静的型付け言語を好む静的人間とが居るかもしれない。

**デフォルトの名無しさん** · 2013/12/01(日) 01:25:22.24

>>349
実装見ようとしたのですがファイル名末尾がmin.jsでファイルの中身をのぞいても
全部一行にかたまっていて何が何だがよくわかりません。

**デフォルトの名無しさん** · 2013/12/01(日) 01:31:46.41

>>352
まあでもどちらも比較的変種で普通種は動的言語も静的言語も両方使うと思う。

**デフォルトの名無しさん** · 2013/12/01(日) 01:47:08.21

>>348
全くそのとおりだな。

型というのは、コンパイラと人間の両方が
理解して処理可能なコメントだと思えばいい。

短いコードならコメントなしでもいいが
規模が大きくなるにつれて、コメントがあるといいよ。
しかもそれが、早くて正確なコンパイラが理解可能なコメントなら
矛盾を指摘してくれたり、コメントをもとに適切な
アドバイスをしてくれるんだよ。

**デフォルトの名無しさん** · 2013/12/01(日) 02:05:12.90

型とコメントは別のものだと思うんですよね。

**デフォルトの名無しさん** · 2013/12/01(日) 02:12:47.43

型に関してもコメントを残すなら書く手間は動的も静的もそう変わらんということ。

**デフォルトの名無しさん** · 2013/12/01(日) 02:15:02.72

別のものだと思うんですよね。

**デフォルトの名無しさん** · 2013/12/01(日) 02:18:36.37

別なんじゃない。
静的型付け言語の型情報にはコメント的な御利益もあるというだけであって。

**デフォルトの名無しさん** · 2013/12/01(日) 02:19:35.15

>>356
コメントがなくてもわかるような
コードを書けってきかない？

型を含めたコード全てが
コメントのように分かりやすくあるべきなんだよ。

コードに必要な情報を埋め込められる言語
ようするに型もその情報の一つなわけだけど、
そういう言語だとコードが分かりやすくなるんだよ。

（コンパイラが理解できない）コメントは
コードに情報を埋められない言語の逃げでしかない。

**デフォルトの名無しさん** · 2013/12/01(日) 02:22:12.37

コメントにはなぜそうしたのか？という理由を書く
コードにはそうなっているという事実を書く。

型は、そうした理由ではなく事実。
この変数・引数には○○型を採用しているという事実。
事実だからコードで書く。

○○型を採用した理由を書く必要があるならば
それをコメントに書く。

**デフォルトの名無しさん** · 2013/12/01(日) 02:55:44.19

他の動的言語はともかくJSerはツンデレだからね。

変数スコープがウンコと言われてそんなことないもん! と強がる一方でletを導入したり
辞書型はオブジェクトリテラルで十分なんだからねっ! と言いながらMapを準備したり
functionぐらい面倒くさがらずに書きなさいよ! となじる一方で密かにアロー記号用意したり
型情報なんか必要だなんて思っていないんだからっ! と表向きは突き放しつつ陰ではいそいそ
JSDocに型情報を書いてみたりガードが使えるようになる未来を夢想してこっそりデれたり。
で、そのことを指摘しても「ガードは・・・そういうのとは違うのよっ」と否定してみたり。

**デフォルトの名無しさん** · 2013/12/01(日) 03:14:17.32

JS利用者が導入したわけじゃないしね。
必要ないのに勝手に誰かが導入しただけだしね。

**デフォルトの名無しさん** · 2013/12/01(日) 03:22:20.17

>>360
たいていのアルゴリズムはコメントどころか書籍程度の説明が必要。
書籍一冊で理解させるのが困難な場合も多く、直接的な指導が必要な場合も多い。

コメントを書かなくても理解させられるコードというのは、単に手続きを
羅列したものであり、そのような手続きの羅列を強要させられることこそが
糞言語のあかしなのである。
コメントを書く必要がないのではなく、コメントを書かなくていいような
手続きの羅列を書かされている。
こういった認識を持てないのは、糞言語に調教された証左である。
つまり、君は我々人類と対等に話せる場所に既に居ない。
機械に調教された悲しき奴隷、それが今の君の姿なのである。

**デフォルトの名無しさん** · 2013/12/01(日) 03:25:46.68

コメントを書こう、メモを残そう、テストを完璧に行おう、デバッガを捨てよう。

**デフォルトの名無しさん** · 2013/12/01(日) 05:11:23.08

>>364
'コメントを書かなくても理解させられるコードというのは、単に手続きを
羅列したものであり、そのような手続きの羅列を強要させられることこそが
糞言語のあかしなのである。'
という宣言が論理式に変換されればよいというだけの話ではないか。
>>364の言っていることは。

**366** · 2013/12/01(日) 05:12:17.82

>>360の言っていることは。だね。

**デフォルトの名無しさん** · 2013/12/01(日) 06:02:23.28

>>364
くだらね。極端な例はいらん。

**デフォルトの名無しさん** · 2013/12/01(日) 06:03:00.15

> 'コメントを書かなくても理解させられるコードというのは、単に手続きを
> 羅列したものであり

間違い。

**デフォルトの名無しさん** · 2013/12/01(日) 06:52:56.51

間違いもそうだが、そもそもレスが論理的におかしい

自分で「コメントを書かずとも理解させるコード」と、
コメントが理解の助けになる前提で語ってる時点で
最良はコメントのように書いてあるコードしかないだろうに

**デフォルトの名無しさん** · 2013/12/01(日) 06:54:50.42

そもそも、型情報は
コメントとして書くものではなく
コードで書くものだという話。

**デフォルトの名無しさん** · 2013/12/01(日) 06:55:33.92

というか>>349実装見たら良いとか>>360コメントいらずのコードとか謎。

使う人が知る必要があるのは仕様。ドキュメントやコメントに書いてあるのは
そういうこと。
コードに書いてあるのは実装。読んで理解すれば時には役にはたつがはじめから
使う人間に実装の中身の理解を求めるのは普通に変。

自動車運転する人にオットーサイクルの理解を求めるの?

**デフォルトの名無しさん** · 2013/12/01(日) 07:03:35.70

>>372
エンジンを使って何かをつくろうとしてる人なら
理解していたほうが良いだろうね

**デフォルトの名無しさん** · 2013/12/01(日) 07:19:25.63

>>373
自動車運転する人の話を聞いているんだけど。
GoogleやFBが提供するAPIを使って何かを作る人はそのバックエンド処理の仕組みを知る
必要があるの?
gzipを使う人はgzipのコードを読んでからで無いとダメ?
HTMLにマイクロフォーマットを埋め込む人はRDF Semanticsの仕様を読んで理解してから?
String.indexOfを使う人はそれがどのアルゴリズムで書かれているか知ってからでないと
使っちゃダメかな?

理解「した方がよい」のと使うのにまずコード読んで中身の理解を求めるのは全く別。

**デフォルトの名無しさん** · 2013/12/01(日) 07:19:29.74

>>372
お前は自分でコード書かないのかよｗ
関数の中身を書く人、修正する人の話だろ。
プログラム板なんだから。

**デフォルトの名無しさん** · 2013/12/01(日) 07:30:28.94

>>375
コードは書くし他の人が読んで理解しやすいように書くけどコードを提供する側としては
自分が書いたコードを使うならまず読んで理解しろとは全く考えないね。

自分で書いたコードをいろいろな人に使ってもらった経験って、ある?

**デフォルトの名無しさん** · 2013/12/01(日) 08:13:20.34

>>360
>>364 >>374
http://nojiriko.asia/prolog/takeshi_san.html

**デフォルトの名無しさん** · 2013/12/01(日) 11:42:22.02

型を宣言してもコメントはなくならないし、テストもなくならない
グローバルスタンダードになるつもりは最初からない
ガラパゴスの多様性を擁護する側の勢力がどんな戦い方をするのかという実験なんだよ

**デフォルトの名無しさん** · 2013/12/01(日) 12:32:35.07

>>374
駄目と入ってないが、どれも知っていたほうが理解が早い
特にWen関連APIなんてそのベンダーの仕様知ってると相当に早い
それにマイクロコードなんてSEO考えてるならまず仕様から入るし
gzやindexOfの実装にしたって
パラメタ指定が速度に関わる系なら知ってて損はない

概要すらいらないなんて考えはさすがに同意しかねるよ

**デフォルトの名無しさん** · 2013/12/01(日) 13:06:30.06

>>379
知っていた方が理解が早い
で、実装の詳細を知るために要する時間はドキュメントのコメントを読むのに要する時間よりも遥かに長い

# だから経験者の即戦力が求められるってことでもあるんだけどね

**デフォルトの名無しさん** · 2013/12/01(日) 13:09:32.04

>>376
> 自分が書いたコードを使うならまず読んで理解しろとは全く考えないね。

やっぱりお前アホだ。

誰も「コードを使うならまず読んで理解しろ」なんて一言も言ってない。

お前日本語読めないだろ。

**デフォルトの名無しさん** · 2013/12/01(日) 13:20:35.67

あれでしょ？なんだかんだ言って
関数を自分で作ったことがない人なんでしょ。
使うだけの人。

プログラマなら普通、自分が書いているコードの
中身の話をするもんだけどねぇ

**デフォルトの名無しさん** · 2013/12/01(日) 15:44:13.87

コメントやドキュメントに書いてある事だけ知っていれば良かったらどんなに楽だろうか

**デフォルトの名無しさん** · 2013/12/01(日) 15:45:54.12

>>383
コメントやドキュメントが整備されていれば実装まで調べる必要ないけど

**デフォルトの名無しさん** · 2013/12/01(日) 15:50:08.51

>>348
それ型が解るだけで結局何する関数なのかさっぱり解らないと思うんだが
その型情報で何を想像するかは人よって見解が分かれそう

**デフォルトの名無しさん** · 2013/12/01(日) 16:08:55.34

ドキュメントに具体例がないと苦労する
具体例とは、仕様書でもソースコードでもない

**デフォルトの名無しさん** · 2013/12/01(日) 16:18:54.90

>>386
たしかに例が載ってると助かるよね

**デフォルトの名無しさん** · 2013/12/01(日) 17:19:30.39

ここでＤ使いが参上

「Ｄならunittestのコードを直に埋め込めるし
　ドキュメントに使用例として吐出されるよ」

ｼｭﾀｯミ

**デフォルトの名無しさん** · 2013/12/01(日) 17:56:08.53

>>384
なんでまだ、使う人の話してるの？

使うコードを書だろ？
そのコードの話をしてるんだが。

コメント見なくてもわかりやく書けよ。
誰もコメントなくなと入ってねーよ。

**デフォルトの名無しさん** · 2013/12/01(日) 18:02:55.11

>>382
誰かと一緒に作業したり他の人にコードを提供するプログラマなら中身同様にドキュメント
等を含めたコードの外面をとことん気にすると思うけれども、違うの?
ドキュメンテーションをちゃんと行うなら静的も動的も記述量はたいしたことが無いんじゃ
ないのという例を挙げたのは自分だけど、そこからドキュメントを用意しない場合という話
が出てきて実装読めば良いとかコメント無くてもわかるコードという話になったので「謎」
と言ったわけ。

いやそこ頑張るとこじゃ無いというか、頑張っても良いけどまずメソッドのシグネチャや
付随するコメントが十分に説明的になってからでないと単に効率悪いだけだから。
function func(attr)もint func(File.Attributes attr)も中身の書き方云々する前にまず
コメントから書こうよw メソッド名も書き直す。

**デフォルトの名無しさん** · 2013/12/01(日) 18:13:51.40

>>389
>なんでまだ、使う人の話してるの？

使われるコードを書く人の話をしています。

**デフォルトの名無しさん** · 2013/12/01(日) 18:23:17.12

>>391
勝手に話をすり替えないように。

**デフォルトの名無しさん** · 2013/12/01(日) 18:23:48.97

話を戻そうね

360 名前：デフォルトの名無しさん[sage] 投稿日：2013/12/01(日) 02:19:35.15
>>356
コメントがなくてもわかるような
コードを書けってきかない？

型を含めたコード全てが
コメントのように分かりやすくあるべきなんだよ。

コードに必要な情報を埋め込められる言語
ようするに型もその情報の一つなわけだけど、
そういう言語だとコードが分かりやすくなるんだよ。

（コンパイラが理解できない）コメントは
コードに情報を埋められない言語の逃げでしかない。

**デフォルトの名無しさん** · 2013/12/01(日) 18:28:50.95

使うだけにしても実装を追うにしてもコメントのあるなしで大分違うからまずコメント書けってのには同意だけど
コメントが書いてあれば実装を追わなくても理解できる、とか言われると「はぁ？」って感じ

**デフォルトの名無しさん** · 2013/12/01(日) 18:32:04.04

経験上、コメントがないとわかりづらい部分とコメントを書きづらい部分というのがかぶっているわけで

**デフォルトの名無しさん** · 2013/12/01(日) 18:45:11.41

同じ手間でコードでかけることならば、コードで書いていれば良い。
引数の型とかそういうのはコードで書くべき情報。

**デフォルトの名無しさん** · 2013/12/01(日) 18:49:35.92

服着てる現代人と裸の原始人とどっちが優秀かって問題だと思う。
原始人は体が鍛えられてて個体としては優秀だが、狩猟ができず食える草が生えてない東京で絶望することだろう。

**デフォルトの名無しさん** · 2013/12/01(日) 18:50:28.76

>>393
自分が好都合なリビジョンに話をロールバックするなw
エラー発生時点まできっちり巻き戻そう。

>>348
>function func(attr){ ... }
>int func(File.Attributes attr){ ... }
>こんな関数があったら前者は怖くて使えないよね。

後者だって怖くて使えね～w
要するに、そういうことだよ。型が合った方が良いという例としてはイマイチ無茶。

仮に実装の中身にしても同様。

int i = 0;
var index = 0 // 0..(users.length -1)

どっちが説明的?

int index = 0; // 0..(users.length -1)

と大差ある?

「コメント無くてもわかるようなコード」というのは型情報だけでは無くメソッド
名や変数名にも配慮して初めて書けるもの。型情報なんてその中の一つに過ぎない。
で、その程度は少しのコメントで補えるもの。この点で動的型が不利とは思わない。

さらに言えば「コメント無くてもわかるようなコード」の書きやすさではJava等
よりもPythonなどを押すかな。これは静的型動的型の違いと言うよりもコード中の
ノイズの多さの違い。

**デフォルトの名無しさん** · 2013/12/01(日) 18:56:38.16

>>394
コメントが書いてあれば実装を追わなくても理解できる、とまではさすがに求めない。
まずは実装を追わなくても使えるべきで、そのためにコメントやドキュメントは必要と
言っているだけ。

ドキュメントを書いたのにドキュメントだけでは使い方がわからなかったとか言われた
場合はそれなりに悔しいw

**デフォルトの名無しさん** · 2013/12/01(日) 18:56:46.51

> 後者だって怖くて使えね～w
> 要するに、そういうことだよ。

どういうこと？（笑）

ほらね、理由を全く言ってない。
これなんだよ。卑怯な人はね。

> var index = 0 // 0..(users.length -1)
>
> どっちが説明的?
>
> int index = 0; // 0..(users.length -1)

下じゃねーの？

上に書いてあるint i = 0; がなんのことだかわからんけど、
誤記入だろう？型がない言語でにはint iなんて物は存在しないからね。

**デフォルトの名無しさん** · 2013/12/01(日) 18:57:58.20

比べるなら

> var index = 0;
> int index = 0;

この二つで比べるべき話だね。
>>398は変な人だね。

**デフォルトの名無しさん** · 2013/12/01(日) 18:58:58.72

>>348
型がないとコードを読めない初心者さん、おつかれ。
早く補助輪なしで自転車に乗れるようになれたらいいね。

**デフォルトの名無しさん** · 2013/12/01(日) 19:01:00.31

>>401
この二つは明らかに下のほうがわかりやすいね。

上はindexって書いているけど、これが何型かわからない。
もしかしたら本の索引って意味かもしれんし。
その場合は、1.1 （一章一節）なんて数値が入るかもしれない。

後者だと整数であることが明確である。

**デフォルトの名無しさん** · 2013/12/01(日) 19:02:51.27

もっと具体的な型だったら
さらに意味がわかりやすいよね。

BookIndex index = 0;

**デフォルトの名無しさん** · 2013/12/01(日) 19:03:29.40

>>401
でもHaskellのコードとか、
関数がポイントフリーになっていて引数名すら存在しない、
その関数の引数の型ぐらいしかヒントがない、
なんてことがあるし。

傾向として
静的型プログラマは型に頼って変数名はテキトー、
動的型プログラマは変数名に拘るのが多いんじゃね？

**デフォルトの名無しさん** · 2013/12/01(日) 19:04:19.46

>>403
おまえは本を0章から書き始めるのか？
RMSみたいな奴だなw

**デフォルトの名無しさん** · 2013/12/01(日) 19:04:48.65

> 静的型プログラマは型に頼って変数名はテキトー、
> 動的型プログラマは変数名に拘るのが多いんじゃね？

全然違うし。変数名が適当であるという根拠は何一つ出てない。

静的型プログラマは型も変数名にもこだわってる。
動的型プログラマは変数名に拘るが型は適当。

これが事実だろ。

**デフォルトの名無しさん** · 2013/12/01(日) 19:05:57.33

コメントは基本ドキュメンテーションコメントだけでいいんだよ

**デフォルトの名無しさん** · 2013/12/01(日) 19:07:28.59

>>407
ハスケラとか1文字変数平気で使うし、
ポイントフリーで0文字なんてのもザラだし、
それどころか0文字変数名を推奨してるしw

Javaのコードだって大抵は変数名はクラス名より短いしw

**デフォルトの名無しさん** · 2013/12/01(日) 19:07:47.65

>>406
0というのは、どこも指していないって意味ですよｗ
ほらね。型がないとこういうことになる。

>>407
だな。静的言語のほうが変数名は長くて具体的な傾向がある。

動的言語の場合は、適当に短い名前をつける。
で、これで許されるのは、結局プログラムの規模が小さいから。
プログラムの規模が小さいから、適当な名前でもどうにかなる。

だから大規模になると動的言語は破綻する。
ずっと前から出てる結論じゃないか。