静的型付け言語の潜在開発生産性は今の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/29(金) 01:33:37.30
JSerがそこらじゅうに転移してるな。まるでヘルペスウイルスだ。
2013/11/29(金) 08:15:31.77
JavaScriptは用途が広がる一方で仕様拡張が追いついていない印象だな。
モジュールのインポート云々が好例。JSerは手作りできるから言語仕様としては不要と
強弁するけど、普通の開発者は単に当初の想定外の用途故の機能不足と解釈するよな。
2013/11/29(金) 10:19:17.30
>>1
"人間がやっていたことを、コンピュータにやらせる。"

人間がやらずに済んでいたことをわざわざコンビュータにやらせる。
2013/11/29(金) 16:23:48.03
やらずに済むと錯覚するのは単に未熟だからです
264自故レス
垢版 |
2013/11/29(金) 17:10:11.89
>>263
誰が偽りの説教をしろと？
2013/11/29(金) 23:51:28.82
zapzapzap
2013/11/30(土) 00:29:00.03
>>261
もうすぐES6が出るじゃん
2013/11/30(土) 01:36:44.94
>>266
ES6でインポート関連機能がサポートされるかよく知らないのだが、IE 含めて普通に
その機能を使えるようになるのっていつ頃？
2013/11/30(土) 08:34:02.73
>>267
IEは関係ないだろ
バカかこいつ
2013/11/30(土) 08:57:00.55
実行環境として普通に関係あるでしょ。
Androidの分断化問題と一緒。いくら規格が進んだところでランタイムの更新がある程度
進まないとプロダクションに投入できない。
270デフォルトの名無しさん
垢版 |
2013/11/30(土) 09:16:25.39
>>268
流石にこの発言ないわー
2013/11/30(土) 09:30:11.13
>>269-270
なんで商用が前提になってんの？
2013/11/30(土) 09:39:42.32
つまり商用の人はお断りですよと。

商用だろうが非営利だろうが趣味だろうが、ブラウザ上でいろいろな人に使ってもらうので
あればブラウザの対応見込みは気にすると思うけど。
273デフォルトの名無しさん
垢版 |
2013/11/30(土) 09:51:12.92
>>271
趣味の発言前提にしてんの？
2013/11/30(土) 09:54:10.84
>>272
なんでWebアプリ前提なの？

>>273
「商用では互換性が重要」って知らんがな。

「Javaで互換性重要だから7, 8の機能使いません」
↑
知らんがな

これと同じ
2013/11/30(土) 10:20:06.04
>>274
>なんでWebアプリ前提なの？

Webアプリを開発したい、する必要があるからだけど?
Webアプリ開発はJavaScriptの利用目的の中でも大きな分野だと思うけど、違うの?

JavaScriptは手段であって目的では無いのだが。
いくら新しい規格が出たところで目的の用途に使えなければ意味ないよ。
2013/11/30(土) 10:20:52.88
「PerlはCGIで使うものだ」ってのと同じ臭いがする
2013/11/30(土) 10:36:44.84
CGIをつくることを目的にしている人とっては使いたい機能がPerlにあったところで
CGIで使えなければ意味が無いだろうね。

・・・で使うものだ、という話じゃないよ。
・・・をしたいのだが、どうよ、という話。目的が主。言語は従。

クライアントサイドのUI開発にES6を使うとして、どうよ。いつになったら使えるの?
2013/11/30(土) 11:06:25.56
ていうか、ブラウザで動くという最大のメリットを除けば
JSなんて他言語に対して何のアドバンテージも無い
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
コメントがなくてもわかるような
コードを書けってきかない？

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

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

（コンパイラが理解できない）コメントは
コードに情報を埋められない言語の逃げでしかない。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況