トップページ⇒tech
1001コメント270KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2013/10/06(日) 00:30:02.59
人間がやっていたことを、コンピュータにやらせる。
これが生産性を上げる最大の方法。
コンピュータは間違わない、同じ事を何度も高速に行える。

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

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

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

静的型付け言語の潜在開発生産性は今の100倍
http://toro.2ch.net/test/read.cgi/tech/1362302249/
0153デフォルトの名無しさん2013/10/09(水) 08:08:18.44
うわ、型チャックってなんだ。型チェックだ
0154デフォルトの名無しさん2013/10/09(水) 08:08:47.23
マトモな型推論ある言語を使った事あったら
TypeScriptに型推論があるなんて思うわけがない
上に出てた型推論とは全く関係ない指摘を型推論と思い込んじゃたってのがすぐ分かる
0155デフォルトの名無しさん2013/10/09(水) 08:10:44.24
>>152
型推論っていうのは宣言を明示的にしなくても
勝手に宣言してくれるような機能であってそういう明示的なのとは全く違う
0156デフォルトの名無しさん2013/10/09(水) 08:12:01.27
でもこれは型チェックできない、ワロス

function f(): number {return ((x) => x)("a")}
0157デフォルトの名無しさん2013/10/09(水) 08:12:46.05
>>155
xやyの型はいつ宣言しましたか？
0158デフォルトの名無しさん2013/10/09(水) 08:14:35.63
xやyの型でエラーが出てるんじゃなくて
関数の戻り値の型と合わないエラーでしょ
型推論っていうのはこういうの

var x = [];
x = 1; //error
0159デフォルトの名無しさん2013/10/09(水) 08:17:00.22
>>158
お前本当に何も分かってないな
宣言してないyの型を推論して、その推論した型と戻り値の型が合わないから
エラーを出してるんだろうが

で、>>158のそのxは何で型エラーが出てるの？www
0160デフォルトの名無しさん2013/10/09(水) 08:18:41.96
型推論っていうのは
型を推論することじゃなくて
どの型で宣言されればいいのか推論することです
いい加減恥ずかしいからやめてね
0161デフォルトの名無しさん2013/10/09(水) 08:22:38.27
これでも見て勉強しろ。
http://ja.wikipedia.org/wiki/%E5%9E%8B%E6%8E%A8%E8%AB%96
0162デフォルトの名無しさん2013/10/09(水) 08:28:30.40
>>160
いや、まさに型を推論してるんだけど

で、>>158は何でエラーになったの？答えてよ
あと>>157にもね
0163デフォルトの名無しさん2013/10/09(水) 11:11:27.33
function add_1(x){ return x + 1; }
function add_2(x){ return add_1(add_1(x)); }

add_2("22"); // compile error

こうだろ普通
戻り値型の注釈付けておいて型推論できましたって言われても
0164デフォルトの名無しさん2013/10/09(水) 11:41:27.36
それは何でコンパイルエラーなの？
0165デフォルトの名無しさん2013/10/09(水) 11:50:49.86
>>164
型推論が働くならコンパイルエラーという意味
0166デフォルトの名無しさん2013/10/09(水) 13:03:03.35
JSは文字列と数の加算が定義されてるんだから、
勝手にエラーにしたらダメだろ
0167デフォルトの名無しさん2013/10/09(水) 14:25:23.29
IE11、ES6対応といっても主要な機能だとletとconstへの新規対応だけなんだな。

ES6は凄い -> letとconstが使えます、って事か。実質。
そりゃ凄い。

言語の仕様拡張で夢は広がりんぐは結構だけど肝心の実装とランタイム環境の更新が
伴ってない。

ブラウザ向けは当面別の言語の模索も続くだろうね。Haxeってどうなん?
0168デフォルトの名無しさん2013/10/09(水) 14:40:57.26
>>166
それもまともに型推論働かない理由の一つだな
根本的におかしい機能に固執する
0169デフォルトの名無しさん2013/10/09(水) 15:43:45.77
varはスコープの先頭にまとめるというスタイルも変数巻き上げのトラブルを避けるための
ノウハウはいえ、客観的にみると単にウンコな変数宣言の仕様に巻き込まれて強制されて
いるだけで、見栄え的にも何時の時代のCよという感じではあるな。
0170デフォルトの名無しさん2013/10/09(水) 17:22:36.80
>>163
ローカル変数の型推論は型推論と呼ばない俺ルール発動ですか？
俺ルールじゃないなら信頼できるソースを頂けますか？
0171デフォルトの名無しさん2013/10/09(水) 18:11:14.52
>>170
俺ルール発動か？
そもそも型推論じゃないとは言ってないが
そんな貧弱なチェックであるとドヤ顔されても困ると言ってる
0172デフォルトの名無しさん2013/10/09(水) 19:49:32.66
型推論っていうのは変数の宣言される型を推測することであって
その変数がどんな型かを推論することじゃないだろ
TypeScriptの場合varで宣言したときはJSと同じ任意型であって
型推論で型が決定されているわけじゃない
0173デフォルトの名無しさん2013/10/09(水) 19:54:40.67
>>169
それはJSに慣れてない人のためのもので
知っていれば別になんでもないこと
0174デフォルトの名無しさん2013/10/09(水) 20:07:26.61
>>172広義では型を決め打ちすること全般でいいんじゃ？
0175デフォルトの名無しさん2013/10/09(水) 20:20:03.95
ほかの言語の欠陥はあげつらうのにJavaScriptの欠陥は「知っていればなんともない」
なんですね。巻き上げられて良いことなんて何もない、単なるバグの発生源なのに。
0176デフォルトの名無しさん2013/10/09(水) 20:24:41.48
つーかTSとかの型推論挙げずに素直に関数型言語や.NET系の型推論挙げとけよ
0177デフォルトの名無しさん2013/10/09(水) 20:32:15.72
>>172
いい加減なこと書くなよ
ちゃんと任意型を表すanyがあるし、varで宣言しても任意型にならない
第一任意型なら、>>152はエラーになったらダメだろうが

ここでも読んで出直してこい
TSの型推論ついても書いてあるから
http://phyzkit.net/typescript/
0178デフォルトの名無しさん2013/10/09(水) 20:41:08.15
anyとvarで吐かれるコードは同じ
そんないい加減なもの型推論とはいえない
0179デフォルトの名無しさん2013/10/09(水) 20:42:44.15
>>175
それでバグが起こったことや実際見たことなんて入門したての頃から１０年強一度もないな。
0180デフォルトの名無しさん2013/10/09(水) 20:46:08.43
>>178
型チェックの結果コンパイルエラーになるか否かが違う
0181デフォルトの名無しさん2013/10/09(水) 20:50:05.99
なって無いじゃん
そんなんコンパイラの気休めサービスで言語の機能じゃないだろ
0182デフォルトの名無しさん2013/10/09(水) 20:51:58.89
>>179
宣言を最初にまとめる方が異端な現状を見ると全く説得力がない
ただ気になる人もいるってだけでそりゃ人間の好みって言うもの
lintとかでも途中の宣言を認めないなんてものはないし
実際困ることもない

重複宣言にならないっていう便利なことはある
letなどならこれはエラーになってしまう
要は使い分けの問題
0183デフォルトの名無しさん2013/10/09(水) 20:53:55.14
これはコンパイルエラー

var x = 0
var n : string = x // Cannot convert 'number' to 'string'


こっちはコンパイルエラーじゃない

var x : any = 0
var n : string = x
0184デフォルトの名無しさん2013/10/09(水) 20:56:15.46
>>181
TSの仕様書にも型推論について書かれてるけど……

http://www.typescriptlang.org/Content/TypeScript%20Language%20Specification.pdf
0185デフォルトの名無しさん2013/10/09(水) 20:57:05.49
ES7のguardが導入されるのを待とう。
既に一部ES7候補の仕様を実装してきているFirefoxならそう遠くないはず。
0186デフォルトの名無しさん2013/10/09(水) 20:58:56.02
その通り動かない仕様書なんて便所の落書きと同じｗ
必死だなTS厨ｗｗｗ
0187デフォルトの名無しさん2013/10/09(水) 21:01:48.34
>>186
＞その通り動かない仕様書なんて便所の落書きと同じｗ

仕様書のどの辺りを読んで、仕様通りに動かないと思ったの？
仕様書のその箇所を引用してみて
0188デフォルトの名無しさん2013/10/09(水) 21:02:56.57
TypeScriptは言語じゃなくて「JavaScriptをよりよく書くためもの」だからこんなものだよ。
それで十分役目を果たしてるんだから問題ない。
0189デフォルトの名無しさん2013/10/09(水) 21:06:40.48
>>187その必要はないｗ
こちらにはちゃんとした型推論ではなく気休めサービスでしか無い証拠があるんだからｗ
そちらがちゃんと示してコンパイラの実装不備で今は便所の落書きになってるけれど
将来は期待してくださいお願いしますって弁解してみろよｗｗ出来るもんならｗｗｗｗｗ
0190デフォルトの名無しさん2013/10/09(水) 21:10:10.41
>>189
いや、型推論がゴミなのは仕様通りなので、
コンパイラの実装不備っていう結論はおかしい
そう言える証拠があるなら別だけど
0191デフォルトの名無しさん2013/10/09(水) 21:11:41.60
>>189
仕様書も読まずに仕様について語るなよ……
それでもプログラマかよ
0192デフォルトの名無しさん2013/10/09(水) 21:11:56.46
ゴミの型推論が仕様通りならちゃんと擬似型推論って言えよｗｗ
見え張ってんじゃねえよｗｗ
0193デフォルトの名無しさん2013/10/09(水) 21:13:30.92
>>191
馬鹿かｗ
こっちは型推論が仕様にあるって言葉を信用したんだよｗ
で、実際はゴミだったわけだｗ詐欺だわｗｗｗ
0194デフォルトの名無しさん2013/10/09(水) 21:15:06.78
>>193
うわぁ、仕事できなそう…
0195デフォルトの名無しさん2013/10/09(水) 21:17:30.63
遂にTS厨白旗かｗｗ
もう人格批判がやっとやっとｗｗ
0196デフォルトの名無しさん2013/10/09(水) 21:19:09.20
ていうか、一貫してTSの型推論はゴミだと書いてきたつもりだが…
どのレスを読んでTS厨だと思ったのだろうか
0197デフォルトの名無しさん2013/10/09(水) 21:24:51.87
型推論なんていらない
せっかくの動的型の優位性が失われる
自動変換も知らないやつが悪い
0198デフォルトの名無しさん2013/10/09(水) 21:26:21.49
自動変換？暗黙の型変換のこと？
0199デフォルトの名無しさん2013/10/09(水) 21:28:05.57
JavaScriptの暗黙の型変換や条件評価はものすごく複雑だぞ
まあ普段使う分にはその1/5くらいの知識で十分だろうが
0200デフォルトの名無しさん2013/10/09(水) 21:34:35.57
型推論で失われる動的型の優位性って何？
0201デフォルトの名無しさん2013/10/09(水) 21:38:22.80
型推論をパフォーマンス向上のために使うのなら結構だし、実際されてることだけど、
それを厳格さのために用意されて型エラーが出るようなことになると相性悪いってことじゃない？
やっぱりguardとか「型揃え」の方が考え方として相性いいんじゃないかな。
0202デフォルトの名無しさん2013/10/09(水) 21:39:12.25
連想配列に色んな型を含める
0203デフォルトの名無しさん2013/10/09(水) 21:41:38.17
オブジェクトに入れればいいんとちゃうん？
0204デフォルトの名無しさん2013/10/09(水) 21:46:20.12
連想配列はMapを使えばいい
0205デフォルトの名無しさん2013/10/09(水) 21:48:04.17
>>198 >>200
実を言うと釣りのつもりで書いたのに
擁護多すぎてドン引き中
0206デフォルトの名無しさん2013/10/09(水) 22:06:17.72
まあ本当にそこは言語の「柄」、そうじゃなくなったらその言語じゃないって部分だから
JavaScriptを使う限り前向きに受け入れて使うしか無いでしょう
どんな言語でもそう
0207デフォルトの名無しさん2013/10/09(水) 22:07:43.07
new xcomponent({width:200, height:100, visible: false})　// 使用

動的
xcomponent::constructor(xcis){...}

静的
xcomponentInitStruct {
　int width,
　int height,
　bool visible
}
xcomponent::constructor(xcomponentInitStruct xcis){...}
0208デフォルトの名無しさん2013/10/09(水) 22:15:29.31
既に「エラーの出ない型推論」をエンジンが暗黙的にやってくれてるんだから
JSはそれでいいじゃん
0209デフォルトの名無しさん2013/10/09(水) 22:17:35.88
scalaとかも静的型なんだが
0210デフォルトの名無しさん2013/10/09(水) 22:18:25.61
実行速度だけで言えばそうかもね
もっとも実行速度で比べたらJSも静的型言語に比べたら遅いけど
0211デフォルトの名無しさん2013/10/09(水) 22:20:32.41
まあ、TSの型推論をみれば、JSのエンジンがやってる型推論の程度も想像がつくな
本当に自明なところだけ推論してるんでしょう
0212デフォルトの名無しさん2013/10/09(水) 22:20:57.36
JSは変数使いまわしたら推論効かなくなるっちゅうの
0213デフォルトの名無しさん2013/10/09(水) 22:28:06.13
俺ならこうする
y &= ~(y >> 31);
0214デフォルトの名無しさん2013/10/09(水) 22:29:58.28
型推論というのは二種類あって、
一つは、静的型付け言語用の機能で型を書くのが
面倒だからそれを省略してかけるという機能

これはあくまで省略記法であり型情報は失われておらず
型を書いているのと全く変わりがない。

そのため静的型付け言語用であり、こっちの意味の型推論は
動的型付け言語には存在しない。
一般に言われる型推論というのはこっちの方。


もう一つは動的型付け用の機能で、明らかに特定の型しか
なりえないと判断した時に、動的な言語の遅さをカバーするために
特定の型用に最適化するための機能。

JSなんかの型推論というのはこっちの方。

コンパイラが頑張って型を推論できればいいのだが
現実にはそれが難しいために、型を明確にするために
特殊な書き方をすることがある。
0215デフォルトの名無しさん2013/10/09(水) 22:33:21.31
うーん。それだと実行時に統計情報を収集して
特定の型用の最適化コードを生成するのも含んでしまう感じだな
0216デフォルトの名無しさん2013/10/09(水) 22:33:56.84
HaskellとCoffeeScriptの組み合わせがトレンドなんだろ？
0217デフォルトの名無しさん2013/10/09(水) 22:34:15.28
>>211
プロファイル数に応じて投機度と最適化度を変えてるし、
Firefoxなんかは何個もエンジン積んで使い分けてる。
http://ledyba.org/2013/02/27181531.php
0218デフォルトの名無しさん2013/10/09(水) 22:38:37.67
asm.js使うとネイティブ超える場合もあるしなあ
0219デフォルトの名無しさん2013/10/09(水) 22:38:55.09
後者ってVMで有効になるやつのことでしょ
JSみたいに根幹にハッシュ使ってる言語で型推論で最適化とかいっても焼け石に水だと思うけどなあ
0220デフォルトの名無しさん2013/10/09(水) 22:41:20.55
最適化に邪魔な仕様は意図的に無視して
何らかの不具合が生じた場合にフォールバックするというのが
JS最適化の手法
0221デフォルトの名無しさん2013/10/09(水) 22:43:40.74
既にhotspotが通ってきた道だな
0222デフォルトの名無しさん2013/10/09(水) 22:45:13.22
だってV8の主流メンバって同じ人でしょ？
0223デフォルトの名無しさん2013/10/09(水) 22:47:12.54
>>217はv8じゃなくてmozillaだろ
0224デフォルトの名無しさん2013/10/09(水) 22:47:30.55
いくらJSでも型が途中で変わる方が稀だしな
JSerが型宣言を嫌うのは厳密性よりもむしろ面倒だから
だから型推論は嫌いじゃない
0225デフォルトの名無しさん2013/10/09(水) 22:49:39.11
>>223
>>220-221に対して言ったまでだしV8も基本は同じです
仮想クラスを仮定したり変数や配列なんかのタイプも仮定してる
0226デフォルトの名無しさん2013/10/09(水) 22:51:06.32
asm.jsみたいなのがJSのあるべき姿じゃね？
0227デフォルトの名無しさん2013/10/09(水) 22:51:09.63
そういう人は型推論付きの関数型言語やるとJSが嫌いになる
ソースは俺
0228デフォルトの名無しさん2013/10/09(水) 22:53:48.75
>>226
asm.js式の最適化方法は汎用化されてエンジンに採用されてきてるよ
まあでも要はこれguardだよね、ES7が入ればやっぱりこのへんは良くなるだろうね
0229デフォルトの名無しさん2013/10/09(水) 22:55:28.08
>>226
あんなの使うならVM作ればいいじゃんって思う
emscriptenのために犠牲になってるとしか思えない
0230デフォルトの名無しさん2013/10/09(水) 22:58:28.07
VM作っても型が動的でであるならば
結局遅いんだけどね。
0231デフォルトの名無しさん2013/10/09(水) 23:00:19.13
何回か書いたことあるけど
一番ダメなのはデバッガの表記が解決に繋がりにくいこと
今手で書くとして一番ダメなのはそこ
あとやっぱり形態がモジュール風というか、
ちょっとasm.js関数１つ作りたい時とかには厳かすぎるね
0232デフォルトの名無しさん2013/10/09(水) 23:02:25.13
asm.jsなんて手書きするもんじゃないと思う
0233デフォルトの名無しさん2013/10/09(水) 23:04:43.45
>>232
ぐう正論
0234デフォルトの名無しさん2013/10/09(水) 23:07:09.89
ES7のguardsって何？パターンマッチの出来損ないみたいなもの？
0235デフォルトの名無しさん2013/10/09(水) 23:08:24.66
>>232,233
それは好奇心を制限するものではないさ
自分はまだ手で各可能性を信じてるよ
ようはlintとデバッガさえまともになれば手で書けるんだからね
0236デフォルトの名無しさん2013/10/09(水) 23:11:08.48
>>234マルチ型付け
つまり変数の型を決定するのではなく、入ってくる型を宣言する仕組み
ようするにガード
0237デフォルトの名無しさん2013/10/09(水) 23:13:58.66
>>236
宣言した以外の型が入ってきたときはどうなるの？
0238デフォルトの名無しさん2013/10/09(水) 23:14:16.94
おれはすでにロジックはC++で書いてemscripten
0239デフォルトの名無しさん2013/10/09(水) 23:22:38.30
>>237当然エラー
多分こんな感じになるんじゃない？
let x :: Number | Boolean = value;
0240デフォルトの名無しさん2013/10/09(水) 23:34:12.80
ES7では特に数値型に関してはリテラルもたくさん入る。
それら同士の演算結果の型がどうなるか次第でだいぶイメージ変わる。
そもそもプリミティブ型になるのかvalue-object型になるのかが不明。
0241デフォルトの名無しさん2013/10/09(水) 23:42:16.48
演算子オーバーロードとValueProxyが入るから
ES7からはどんなものでも自由自在に暗黙の型変換できるし
いくつも新たに定義されるだろう
0242デフォルトの名無しさん2013/10/10(木) 00:56:36.30
Mozillaだけが突っ走ってその他のブラウザが実装し始めるのはずっと先だと思うけどね。
そんな未来は来ない可能性だってある。
0243デフォルトの名無しさん2013/10/10(木) 01:07:35.53
ValueObjectはES6に前身が入ったしES7途中経過報告でもう発表されてるし
ES7の３本柱になることが確実なものよ
ES6で実装する時に手間をかけるからES7への移行はスムーズに行くはず

そこんとこプリミティブ型になったらやっぱり厄介だろうね
だから実装負荷も考えてValueObjectで行くことになると思う
Parallelsも他の仕様と絡みにくいWorkerの糖衣APIみたいなものだから実装は容易
ガードもただ実装するだけなら型チェックの変形版だから容易
0244デフォルトの名無しさん2013/10/10(木) 01:24:19.40
ValueObjectってどのブラウザで使えるの？
0245デフォルトの名無しさん2013/10/10(木) 01:44:20.08
FirefoxでValueObjectのコンストラクタ（？）の前身が使える
int8(123)とかfloat32(123)

今これはただint8やfloat32に揃えられたdouble
Numberプリミティブ型が帰ってくるだけで、
ES6ではStructType({ x: uint32, y: uint32 })
とかして構造体っぽいのを作るために専ら使われるものだけど

ES7ではこれが増えて
int64(123)
bignum(123)
decimal(123)
とかしたときはValueObjectというものが帰ってくる予定

そしてそれらを演算子オーバーロードやValueProxyの技術と合わせることによって
オブジェクト間の演算が可能になって、JSに型を増やせるねってこと
0246デフォルトの名無しさん2013/10/10(木) 01:57:16.84
Haskellの先進性に比べると
JSに追加される機能は
時代遅れのウンコと言わざるをえない
0247デフォルトの名無しさん2013/10/10(木) 01:59:49.12
先進過ぎて誰も付いてこれないんじゃないか？
例えるなら鳩山由紀夫みたいなもんだろう
0248デフォルトの名無しさん2013/10/10(木) 02:08:53.50
そりゃあだって今までは単なるブラウザの上で
ちょこちょこっとHTMLを動かすだけのスクリプトだったんだからね

でもこれからは低レベル、高レベル、スクリプト言語として、大規模開発用言語として
幅広く、深く進化していくよ
ES5移行は本当に多くの言語を参考にして作られてる
確かHaskellもどこかの仕様で見たし、議論でも見たよ
遅いかもしれないけど失敗や出戻りが少なくて済む、
馴染み深いものが入ると思えばいい

特にパフォーマンスに関しては貪欲だよ
初めて言語仕様で最適化を明言しようとしてるし、
マルチスレッド化やSIMD系の型も入る

他にもイベントループとそれを扱う仕組みが言語に組み込まれたり
とにかく見てて毎日飽きない
そこがJavaScriptの一番の良さだと思ってる
完成されきっちゃったら話すこと無くてつまんないじゃん
0249デフォルトの名無しさん2013/10/10(木) 03:08:09.06
平和だなあ
0250デフォルトの名無しさん2013/10/10(木) 03:11:24.08
>>182
>宣言を最初にまとめる方が異端な現状を見ると全く説得力がない

これはそうかなぁ。

function(){
var a = ... ,
　　i = 0, ...

......

for(; i < x; i++)

的なのはよく見るでしょ。書き方のスタイルとして。
0251デフォルトの名無しさん2013/10/10(木) 04:06:30.16
おいおいｗ
それは２０００％ないわｗ
ループ複数書く時詰むだろそれｗ
これの間違いだろ……
（書き慣れてないのがすぐ分かるなオイ（笑））

function(){
var i

......
for(i = 0; i < x; i++)
0252デフォルトの名無しさん2013/10/10(木) 05:44:13.14
2000%無いって、jQueryそのものや関連プラグインはこの書き方多いやん・・・

カウンタの類の初期化まで先頭でまとめてやるのは極端にしても関数の初めの方に
変数宣言をまとめる傾向はJavaScriptでは結構目立つと思う。
■ このスレッドは過去ログ倉庫に格納されています