静的型付け言語の潜在開発生産性は今の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(土) 11:08:04.25
>>278
スレタイ読めますか？
ブラウザで動くという以外の部分で静的型付け言語を上回ってるという話ですが
2013/11/30(土) 11:13:08.21
どこが？
低能なプログラマの人数？
281デフォルトの名無しさん
垢版 |
2013/11/30(土) 11:48:20.17
使う人の妄想力でしょ。
JSは世界一だ。それを使う俺も世界一だって感じ？
2013/11/30(土) 11:58:58.78
>>1
「コンピュータは間違わない」と言ったのはコンピュータではない

なぜ、コンピュータが言ってないことを人間が言うのか？

人間が言った方が早いからでしょ
本当は人間の方が効率が良いって知ってるんだろ
2013/11/30(土) 12:13:24.26
>>282
意味不明。馬鹿なの？
2013/11/30(土) 12:28:21.89
「神の見えざる手は間違わない」と言ったのは神ではない。
神が言ってないことを、人間が言う。
2013/11/30(土) 12:32:37.94
>>282 みたいな意味不明な出力は
残念ながら静的型言語をもってしても除去することはできない
2013/11/30(土) 12:39:25.07
意味不明って偉そうに言う事じゃないでしょ
なんで意味分かってない奴が意味分かってる奴より偉そうなの？反知性主義なの？
2013/11/30(土) 12:52:43.23
>>282
むしろコンピューターがいったことってなんだよ
2013/11/30(土) 13:21:04.09
>>287
>>265
2013/11/30(土) 13:21:50.67
このように自分の誤りに対して寛容すぎる人々によって好まれるのが動的言語です
2013/11/30(土) 13:25:00.32
>>282
コンピュータは間違わないと人間言った。

うん、そう人間が言ったんだよ。

コンピュータは間違わないで人間よりも早く
同じことを何度もやれる。

と人間が言ったけど

これ間違いじゃないけど、君、反論してないよね？
2013/11/30(土) 13:26:16.35
>>284
むしろ「神の見えざる手は間違わない」と
神が言ったなんて誰が言ったんだ？

お前馬鹿じゃないのか？
2013/11/30(土) 13:41:07.23
神が言ったから「神の見えざる手」なんだろ
2013/11/30(土) 13:47:52.09
アダム・スミスがいったんじゃなかったっけ
2013/11/30(土) 13:48:58.00
アダム・スミスが「神の見えざる手」といったのは明らかなのにｗ
それを聞いて、神が言ったと勘違いするマヌケｗ
2013/11/30(土) 14:03:00.52
「見えざる手」の持ち主は明記されていない
296デフォルトの名無しさん
垢版 |
2013/11/30(土) 15:20:58.06
持ち主オブステルスハンド
2013/11/30(土) 16:17:54.67
静的型付け関数型言語を使ってみたけど
型検査が強力すぎて馴染めなかった
2013/11/30(土) 16:36:05.43
型検査が強力で嫌な理由って何？
2013/11/30(土) 17:16:11.20
小ミスで全体が死にしかもどこでコケてるかわからない状態
とエスパーしてみる
2013/11/30(土) 17:26:24.03
あぁ、型がないとそうだろうね
実行するまで問題に気づかない。
2013/11/30(土) 17:34:49.02
一行に含まれる情報が多すぎるとむつかしいんよ
2013/11/30(土) 18:03:21.03
>>298
型検査が強力でも動的言語のインタプリタを実装できるしコンパイルできる
コンパイラは文句を言わない

でも動的言語はだめだと人間が言う
コンパイラが文句を言わなくても人間に認められないとだめだって人間が言うんだよ
誰もコンピュータを信じてない
コンピュータは間違えないなんて言うけど、誰も信じてないんだよ
2013/11/30(土) 18:06:52.77
>>302
お前の妄想垂れ流すのやめたら？
意味ないしキモいだけだよ。
2013/11/30(土) 18:36:16.04
>>298
型とか細けぇ事はいいから結果が早く欲しい時くらいかな
2013/11/30(土) 18:38:41.67
静的言語のメリットとして入力補完などIDEの支援が受けやすいとは昔こそよく言われた
けれども今時のIDEだとその点のメリットは動的言語を扱う場合でも大差ないと思う。
今は動的言語であってもIDEが積極的にコード解析して、レキシカルに特定できる範囲で
正しいプロパティを色分けしたり型コメントを勝手につけたりする。
逆にこういうコード解析が出来ず色分け等されなかった部分は実際大抵ミスっている。

そうしたミスを直して、全体がコード解析されて色とりどりにデコレーションされた
書き上がったコードを見て一人満足するけれども、逆にあれ、こんなふうにコードの
大半が静的に解析してある程度検証できてしまうような場合、動的言語の出番って
何だろうね? とも思ってしまう。適当に型をつければそのまま静的言語でも動くような。

実際書かれているコードの多くは静的でも動的でもあまり大差ないのでは無いのか。
違いは言語の記法や機能、あとは関数型と手続き型というパラダイムの違いであって、
動的静的といった型付けの違いは案外些末なことでごく特定の場面でしか効いてこない
印象。
2013/11/30(土) 19:01:29.81
> けれども今時のIDEだとその点のメリットは動的言語を扱う場合でも大差ないと思う。

いや、思うじゃなくて、実際に使ってみろって。
動的言語では、その仕組み的に不可能なんだよ。

実行するまで（補完するための情報が）わからない言語で
どうやっって補完するっていうんだ？
2013/11/30(土) 19:42:36.36
分からない部分も在るが、分かる部分もある
で、意外と分かる部分が多い
2013/11/30(土) 19:48:19.35
分かる部分＝近くのコード
わからない部分＝遠くのコード

これが逆ならいいんだけどねぇ。
どれだけ影響範囲が広いか調べる必要があるのに
その遠くのコードがわからないんじゃ意味ないよ。
2013/11/30(土) 19:52:11.11
影響範囲を調べる必要が生じた時点で動的型を捨てよ
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){ ... }

こんな関数があったら前者は怖くて使えないよね。
何を渡していいのかわからない。何が渡されるのかわからない。
後者なら型情報が全てを物語ってる
349デフォルトの名無しさん
垢版 |
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
全くそのとおりだな。

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

短いコードならコメントなしでもいいが
規模が大きくなるにつれて、コメントがあるといいよ。
しかもそれが、早くて正確なコンパイラが理解可能なコメントなら
矛盾を指摘してくれたり、コメントをもとに適切な
アドバイスをしてくれるんだよ。
356デフォルトの名無しさん
垢版 |
2013/12/01(日) 02:05:12.90
型とコメントは別のものだと思うんですよね。
2013/12/01(日) 02:12:47.43
型に関してもコメントを残すなら書く手間は動的も静的もそう変わらんということ。
358デフォルトの名無しさん
垢版 |
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に型情報を書いてみたりガードが使えるようになる未来を夢想してこっそりデれたり。
で、そのことを指摘しても「ガードは・・・そういうのとは違うのよっ」と否定してみたり。
363デフォルトの名無しさん
垢版 |
2013/12/01(日) 03:14:17.32
JS利用者が導入したわけじゃないしね。
必要ないのに勝手に誰かが導入しただけだしね。
364デフォルトの名無しさん
垢版 |
2013/12/01(日) 03:22:20.17
>>360
たいていのアルゴリズムはコメントどころか書籍程度の説明が必要。
書籍一冊で理解させるのが困難な場合も多く、直接的な指導が必要な場合も多い。

コメントを書かなくても理解させられるコードというのは、単に手続きを
羅列したものであり、そのような手続きの羅列を強要させられることこそが
糞言語のあかしなのである。
コメントを書く必要がないのではなく、コメントを書かなくていいような
手続きの羅列を書かされている。
こういった認識を持てないのは、糞言語に調教された証左である。
つまり、君は我々人類と対等に話せる場所に既に居ない。
機械に調教された悲しき奴隷、それが今の君の姿なのである。
365デフォルトの名無しさん
垢版 |
2013/12/01(日) 03:25:46.68
コメントを書こう、メモを残そう、テストを完璧に行おう、デバッガを捨てよう。
2013/12/01(日) 05:11:23.08
>>364
'コメントを書かなくても理解させられるコードというのは、単に手続きを
羅列したものであり、そのような手続きの羅列を強要させられることこそが
糞言語のあかしなのである。'
という宣言が論理式に変換されればよいというだけの話ではないか。
>>364の言っていることは。
367366
垢版 |
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の実装にしたって
パラメタ指定が速度に関わる系なら知ってて損はない

概要すらいらないなんて考えはさすがに同意しかねるよ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況