静的型付け言語の潜在開発生産性は今の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/27(水) 01:53:09.78

【最も美しい言語 - 01スクリプト言語】

・0と1、二つの文字だけで書くことができる新しい種類の言語です
・現在の実装はトランスレータです
・コンパイラ、実行環境はお好きなものを選べます

【現在の実装】
・0と1だけから成り立つ入力文字列より8バイト消費し、それぞれ0のビット
　1のビットとして一バイトにおさめます
・選択されたコンパイラや実行環境の入力としてバイトを送ります
・文字列の終端に達していない場合、最初のステップに戻り、それ以外の場合
　終了します

**デフォルトの名無しさん** · 2013/11/27(水) 07:00:45.74

wとWで書けるのもあるしな

**デフォルトの名無しさん** · 2013/11/27(水) 07:04:02.82

(^q^)ｱｳｳｳｱｳｱｱｱｳｱｳｳｱ-

**デフォルトの名無しさん** · 2013/11/27(水) 09:25:08.74

↓美しい言語家

**デフォルトの名無しさん** · 2013/11/27(水) 10:59:28.39

>>220
そんな素晴らしいものでなんで全てのプラットホームで使えるようになってないのよ。お前ら信者の布教具合がたるんでるんじゃねえの？

**デフォルトの名無しさん** · 2013/11/27(水) 11:10:22.91

JavaScriptの関数読んだけど難しすぎてわけがわからん。
誰かこの関数の使い方を教えてくれないか？
どういう返り値を期待してどういう引数を渡せばいいのか。
https://github.com/jquery/jquery/blob/1.8-stable/src/core.js#L772

**デフォルトの名無しさん** · 2013/11/27(水) 11:24:57.45

>>232
糞JSerが頑なに正解だと言っていたbulkの再代入が直してあるな
まあ当然だよなあ

**デフォルトの名無しさん** · 2013/11/27(水) 11:57:12.38

型システムの起源って何の言語？

**デフォルトの名無しさん** · 2013/11/27(水) 12:08:11.75

型システムの定義によって答えは変わる

**デフォルトの名無しさん** · 2013/11/27(水) 15:37:11.26

だが静的脳の達人は質問者の追加入力を待ってノロノロ答えを計算するなどということはない

**デフォルトの名無しさん** · 2013/11/27(水) 15:42:48.31

>>234
データ型という概念そのものは、高級言語の登場に伴って自然発生的に生まれた
たとえば Fortran には整数型/実数型といった単純型や配列という複合型がある
また PL/I ではレコードやポインタといったデータ型が追加され、
Pascal でデータ型の体系が整理された後、モジュールや抽象データ型を経て
現在のオブジェクト指向が主流な現在に到る
したがって、型システムの起源として言語を特定する事に意味は無い

この自然発生的な型システムに遅れて、形式的な型システムが誕生した
そしてこれが最初に実装された言語が、ある定理証明器の記述言語として設計された ML になる
MLはその後、汎用的なプログラミング言語として開発が世界中で活発化し、
Standard ML(SML) と Objective-Caml(OCaml) に分かれて現在に到る
また ML は純粋関数型言語である Miranda にも強い影響与え、その後継が現在の Haskell
言い換えると、形式的な型システムの起源は ML と言える
ML については、Wikipedia にも簡単な解説があるので、そちらも参照のこと

**デフォルトの名無しさん** · 2013/11/27(水) 16:01:41.85

このスレ勉強になるわ

**デフォルトの名無しさん** · 2013/11/27(水) 16:16:31.63

見事だ

**デフォルトの名無しさん** · 2013/11/27(水) 16:46:05.27

自演臭すぎる

**デフォルトの名無しさん** · 2013/11/27(水) 18:36:30.31

JSはCの二倍速い。

**デフォルトの名無しさん** · 2013/11/27(水) 19:40:41.78

そんなわけあるか。CのがJSの二倍遅い。

**デフォルトの名無しさん** · 2013/11/27(水) 19:59:49.13

JSも速いけど今の流行はPOMですよ。

**デフォルトの名無しさん** · 2013/11/28(木) 01:36:51.13

でもさ、やっぱりさ、Java書いた後、PHPでコード書くと
この糞言語って思わない？？
少なくともこの比較だったらやっぱりJavaの方が色々楽だよね？

よく使うので言うとMapあるし、型エラー、メソッド有る無しのエラー、
変数定義のエラーなどなどEclipseの恩恵含めていいとこあるし
テストもクラス内の特定メソッド指定して実行できるし、
カバレッジ出るのも早いし、メトリクス測定も早いし

PHPでも出来るもの、代用品はもちろんあるけど面倒いし遅いし
曖昧な関数多いし

PHPでやるメリットってお遊びアプリ作る程度に
留めないと無いような気もしてくる

**デフォルトの名無しさん** · 2013/11/28(木) 04:24:55.41

JavsScriptで関連クラスやユーティリティ群を束ねたモジュールを書く必要があるので
昨今はどういう体裁で書くのがよいのか調べるも、AMDとかCommonJSとか色々書き方の
流儀があるみたいで唖然とした。ベストな書き方はいったい何なの。

**デフォルトの名無しさん** · 2013/11/28(木) 04:34:28.76

ベストな書き方は、自分の作ったライブラリ部分と
AMDなどの書き方をするべき所を明確に分離することだ。
そうすれば、簡単なプロキシコードでどのようなものにも対応できる。

**デフォルトの名無しさん** · 2013/11/28(木) 05:13:04.47

モジュール一つ書くのに色々書き方がある上に要プロキシコードとか生産性以前の問題。
きっとその「簡単なプロキシコードでどのようなものにも対応できる」自分の作った
ライブラリ部分の書き方も色々あるんでしょ。
単純にメンテナンス性が悪くなる。

**デフォルトの名無しさん** · 2013/11/28(木) 09:14:39.14

>>247
プロキシコードでどんな用も対応できるというのは、
結局のところ、特定の書き方に依存しないってことだ。

特定の書き方に依存させるなというだけの話。
特定の書き方を考慮せずに普通に書けばいい。

だからメンテナンス性は高くなる。

**デフォルトの名無しさん** · 2013/11/28(木) 16:24:33.10

プロキシーコードが必要な時点で変だと疑わないと。

**デフォルトの名無しさん** · 2013/11/28(木) 17:36:38.45

プロキシじゃなくてアダプターじゃね？

**デフォルトの名無しさん** · 2013/11/28(木) 20:17:17.12

JSはどんな書き方してもCの二倍速いよ。

**デフォルトの名無しさん** · 2013/11/28(木) 20:58:35.53

>>251
わーすごいですねー(´･_･`)

**デフォルトの名無しさん** · 2013/11/28(木) 21:10:24.35

>>252さんが仰るようにJSはすごいんですよ。

**デフォルトの名無しさん** · 2013/11/28(木) 21:14:09.66

【>>252も認めるJSの実力】

剃り残しなし！

**デフォルトの名無しさん** · 2013/11/28(木) 21:51:50.58

あの、馬鹿にするのやめてもらえますか？
C言語はちゃんと速度出ますよ
JSが速すぎるだけなんです

**デフォルトの名無しさん** · 2013/11/28(木) 21:54:32.51

確かにCはJavaの100倍速いです。

**デフォルトの名無しさん** · 2013/11/28(木) 21:59:35.69

ところでApacheってなんであんなに遅いの？

**デフォルトの名無しさん** · 2013/11/28(木) 22:59:41.26

>>257
遅くねえよ
ちょっと個々の設定ファイルの解析と適用に時間かかったり
アクセス元のホストを逆引きしたり
CGIを丁寧に毎回forkしたりしてるだけだよ

**デフォルトの名無しさん** · 2013/11/29(金) 01:04:13.53

ApacheはCの100倍遅い。

**デフォルトの名無しさん** · 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

やらずに済むと錯覚するのは単に未熟だからです

**自故レス** · 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の分断化問題と一緒。いくら規格が進んだところでランタイムの更新がある程度
進まないとプロダクションに投入できない。

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

>>268
流石にこの発言ないわー

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

>>269-270
なんで商用が前提になってんの？

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

つまり商用の人はお断りですよと。

商用だろうが非営利だろうが趣味だろうが、ブラウザ上でいろいろな人に使ってもらうので
あればブラウザの対応見込みは気にすると思うけど。

**デフォルトの名無しさん** · 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

どこが？
低能なプログラマの人数？

**デフォルトの名無しさん** · 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

神が言ったから「神の見えざる手」なんだろ

◆QZaw55cn4c · 2013/11/30(土) 13:47:52.09

アダム・スミスがいったんじゃなかったっけ

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

アダム・スミスが「神の見えざる手」といったのは明らかなのにｗ
それを聞いて、神が言ったと勘違いするマヌケｗ

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

「見えざる手」の持ち主は明記されていない

**デフォルトの名無しさん** · 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が持ってるメソッドは？型推論できない。
}