静的型付け言語の潜在開発生産性は今の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/12/04(水) 23:25:38.85
>>546
その理屈で言うと、間違ってる日本語でもいいってことになるよ
548デフォルトの名無しさん
垢版 |
2013/12/04(水) 23:29:05.02
すべて絵にしてリンクを書いておけ
2013/12/04(水) 23:50:11.15
英語もどきを翻訳して正しく訳せることはない。
一体誰が読めるコメントなのだろうか。
2013/12/05(木) 00:08:21.99
自分も同じ間違いをしたことがあれば読める
間違ったことがない奴は何も読めない
551デフォルトの名無しさん
垢版 |
2013/12/05(木) 06:44:30.35
英語でコミュニケーションできない奴にプログラマの資格なし。
2013/12/05(木) 13:43:22.23
No, you aren't.
2013/12/05(木) 21:41:04.23
音楽でも資格のない者が演奏することは禁止されてるっぽいからね
そういう風潮なんだな
2013/12/06(金) 09:39:40.23
動的型言語でプログラムを書く資格のないものが
仕方なく静的型言語を使う
2013/12/06(金) 09:46:06.78
最近はマスを描くにも資格がいるそうだ。
2013/12/06(金) 10:40:38.25
マスかき1級
2013/12/06(金) 13:43:13.42
ね、猫く....
か、描く....
558デフォルトの名無しさん
垢版 |
2013/12/06(金) 14:06:47.25
>>554
ピスト野郎と同じこと言ってんな
559デフォルトの名無しさん
垢版 |
2013/12/06(金) 18:14:08.57
Javaのような静的言語に比べてJSやPHPのような動的言語は習得コストが高い。
しかし、習得後の生産性は動的言語のほうがはるかに高い。
また製品の速度や品質も非常に高い。
つまり、一般的に動的言語を使うべき。
しかし頭が悪い人は習得が難しいので静的言語で我慢するしかない。
2013/12/06(金) 18:21:38.46
だから技術的には合法だって
コンパイラのお墨付きをもらうのは簡単
難しいのは、コンパイラと無関係なやつらが口を出してくること
2013/12/06(金) 18:29:04.60
>>559
などとチグハグで噛み合わない内容を並べて平気なプログラマもどきに愛される動的言語をどうぞよろしくお願いします
562デフォルトの名無しさん
垢版 |
2013/12/06(金) 18:45:22.68
静的言語は初心者用。
2013/12/06(金) 18:46:15.87
静的言語は悪くないよ
機械に仕事を任せたものの不安になって結局人間がああだこうだ言ってる状況が悪い
564デフォルトの名無しさん
垢版 |
2013/12/06(金) 18:54:40.37
何言ってんだかわかんないんだけど？
静的言語が社会悪だってことは学問的に証明されてるでそ。
2013/12/06(金) 18:55:49.02
学問的ｗｗｗ

「学術的」だろ高卒クンｗ
2013/12/06(金) 18:56:57.36
中卒に高卒というのはちょっと‥
2013/12/06(金) 18:57:35.84
まあ一般論としては動的はよりライトな応用分野の方が多いような。
大規模処理やミッションクリティカルな分野にはなかなか食い込めていないのも事実。
568デフォルトの名無しさん
垢版 |
2013/12/06(金) 18:58:37.03
rev.2.

何言ってんだかわかんないんだけど？
静的言語が社会悪だってことは学術的に証明されてるでそ。
569デフォルトの名無しさん
垢版 |
2013/12/06(金) 18:59:39.77
スパコンに投入するジョブはJSが増えてるけどね。
2013/12/06(金) 19:34:32.59
rev.3.

I don't see what you argue.
It's been scholarly manifested that static-typed languages are social evils,
hasn't it?
571デフォルトの名無しさん
垢版 |
2013/12/06(金) 19:37:15.81
オープンソースじゃないのでやめてください！
著作隣接権を主張します！
2013/12/06(金) 19:39:12.69
まあTIOBEをみれば歴然だがな
573デフォルトの名無しさん
垢版 |
2013/12/06(金) 19:52:58.02
JSの圧勝だった。
2013/12/06(金) 19:55:42.88
hoge たたきの次は JS ステマか
2013/12/06(金) 20:11:37.37
ステマというよりはヨタだけどw
576デフォルトの名無しさん
垢版 |
2013/12/06(金) 20:13:44.40
JSは実行時に最適化するので速いのです。
Cの約二倍速い。
2013/12/06(金) 22:47:21.50
実行前に最適化したほうが速いよ。
実行時の最適化は毎回やるしね。
2013/12/06(金) 23:14:03.00
>>577
ネタだろwマジメに答えんなってw
さて、動的押してるフリしてる釣り師諸君に問題です！
V8, Rhino, SpiderMonkyはどの言語で実装されているでしょう？！
perl, rubyはどの言語で実装されているでしょう？
どんな答えがかえってくるかオラわくわくしてきたぞ！
2013/12/06(金) 23:15:49.37
>>578
Perl 6はHaskellで実装されたね
2013/12/06(金) 23:22:41.88
>>578
Smalltalk は Smalltalk で実装されてたね
2013/12/06(金) 23:45:41.21
まあ、javascriptは後方互換性を捨てた方がいいよね
2013/12/07(土) 01:58:09.04
後方互換性を捨てることで
得られるものを具体的に述べよ。
それをお前は欲しいと思っているはずなんだよね？
2013/12/07(土) 01:58:50.21
> 後方互換性を捨てることで
> 得られるものを具体的に述べよ。

訂正

後方互換性を捨てないと
得られないものを具体的に述べよ。
2013/12/07(土) 10:01:09.81
世間の混乱
2013/12/07(土) 11:52:20.82
無駄なコストを捨てようとしたら
コストとは何かが客観的にわからないということがわかった
2013/12/07(土) 16:46:56.72
静的型＝コスト

ここ大事ですよ。テストに出ます。
2013/12/07(土) 19:55:54.02
どうせES6以降のコードはES5の実行環境では動かないのだから、use "ES6"とか
オプションつけたら変数スコープも常識的なブロックスコープになる機能が欲しい。

let導入で二種類の変数スコープが併存とか無意味すぎ。
もう今のvar相当はobsoluteで使ったらログに警告吐くぐらいの勢いで良い。
588デフォルトの名無しさん
垢版 |
2013/12/07(土) 20:16:20.87
JSは互換性にも配慮されているので問題ありません。
2013/12/08(日) 15:40:27.33
低級言語の仕様を変えさせないという目的もある
高級言語を気が済むまで改変させることで低級言語が守られている
2013/12/08(日) 16:01:49.94
？
2013/12/08(日) 16:07:17.43
>>587
移行というのは前のをバッサリ切り捨てるやり方じゃダメなんだよ。
いきなり全てを変えるなんて出来やしない

両方共存出来る状態を作って少しずつ変化させていく。
こうやらないとだめ。

> どうせES6以降のコードはES5の実行環境では動かないのだから、
動く。Polyfill系なんかがそう。
動かないのはletなどを使ったES6専用のコードだけ（コンパイルエラーになる）

こうやって、部分的にES6対応コードに置き換えていく。
varに関してもletに単純に置き換えれるように
コードを整理することは可能。これでES6でもES5でも動くコードになる。

これはES6に早い段階から対応していくという方針のやり方。
逆に将来ES6が十分に普及してしまった後にレガシーなES5を移行する。というような場合でも
varとletの両方が使えるならば、徐々にES6コードに置き換えるていくことが可能になる。
2013/12/08(日) 16:16:41.68
まるでpythonみたい
2013/12/08(日) 17:28:22.91
昔のことを覚えていなければ、いま新しいことをしているのかどうか分からない
2013/12/08(日) 17:32:10.28
letは別に新しくともなんともなく単に普通なのであって、varも古い云々以前に単に変なだけ。
特に覚えておく必要も無い。

なのでuse strictの強化版のようなばっさり切り捨てる機能があって良い。
2013/12/08(日) 19:25:18.31
オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
http://engawa.2ch.net/test/read.cgi/poverty/1386476617/
2013/12/12(木) 22:08:17.68
最強のPythonが動的型言語なので
動的型言語の方が生産性が高い
2013/12/14(土) 00:49:28.23
普通は文字列は一次元で絵は二次元だけど
「実行しないとわからない」なら時間軸を追加して次元がひとつ増える

三次元は正確に認識できないことがあるので生産性が低い
それは時間軸が原因だともいえるし、絵が原因だともいえる
2013/12/17(火) 20:07:17.91
オメーらあんまりｇｄｇｄ言ってっと型に嵌めちまうぞッ
2013/12/18(水) 02:34:16.63
Pythonも微妙になってきたな。
CG方面でなぜかデファクトだから仕方なく使う感じだ。
600デフォルトの名無しさん
垢版 |
2013/12/18(水) 02:38:51.00
>>591
> 移行というのは前のをバッサリ切り捨てるやり方じゃダメなんだよ。
> いきなり全てを変えるなんて出来やしない

そうとは限らん。そういう場合もあるというだけだ。
破壊的変更と非破壊変更は相互補完の関係にあって、どっちを偏重してもいかんのだよ。
現にMozillaも新言語Rustを作ってるしな。

つかどう見てもES4のときに一度ばっさり互換を切るべきだった。
あれがWeb Platform最大の失敗だったことは、無数のaltJS乱立によって証明済み。
2013/12/18(水) 03:31:57.85
altJSって、2007年頃のLLブームに乗っかり、
いんぽqのに騙されたバカな魔法少女たちぐらいしか使わないんじゃねーの？
2013/12/18(水) 07:27:49.18
低能にはJSのウンコさが理解できない
2013/12/18(水) 17:45:29.98
>>600
> 現にMozillaも新言語Rustを作ってるしな。
Rustへの移行が成功してから言えよｗ

現時点では前（JavaScript？）のをバッサリ切り捨てて
Rustを作ったが、ほれみろやっぱり移行していないではないか。
という実例になってるぞｗ
2013/12/18(水) 17:47:42.68
> つかどう見てもES4のときに一度ばっさり互換を切るべきだった。

ECMAScript 4は互換を切ったよ。
だから仕様もまとまらなかったんだが。

それもまた、互換性をバッサリ切り捨てるやり方は
失敗するという、お前がいいたいのと正反対の実例だな。
2013/12/18(水) 20:09:07.21
JSは土管なんだから
後方互換性は何よりも大事だよ
2013/12/18(水) 20:28:41.19
処理系間の互換性が崩壊してる言語で後方互換性がどんな意味を持つんだろうか
2013/12/18(水) 21:11:41.22
ESがバッサリ互換切り捨てたらバージョン間互換すら出来なくなるよね
608デフォルトの名無しさん
垢版 |
2013/12/18(水) 22:07:24.13
コメントがなくてもわかるような
コードを書けってきかない？
コメント書くのは素人
2013/12/18(水) 22:13:07.62
>>608
よっぽどのその言葉気に入ったみたいだなｗ
2013/12/18(水) 22:20:56.13
コメントの9割は無駄！〜アンチプラクティスから学ぶ洗練されたコメントの書き方〜 #code #コード
https://codeiq.jp/magazine/2013/12/3700/

番外編　プログラムのコメントは少なければ少ないほど良い？
http://www.appresso.com/now/column/2010/09/0009-1.html

先日、日経ソフトウェアで「プログラムのソースコードは20%を切ることが望ましい」
という記事を書きました。また、8月のMIJSでのディスカッションでも議論の中で
同じように「詳細設計書やプログラムのコメントは多い方が良いか、少ない方が良いか」という議論がありました。

この話は、私が大学時代に教官から「以前は、コメント率(ソースコード中のコメントの割合)は
50%を超えていないと品質が低いとされた」という話を聞いて衝撃を受けたことが発端となっています。
私自身は、詳細設計書やコメントは少なければ少ないほど良いと思っていたのに、
「コメント率は50%を超えなければいけない」と言われ、驚いたわけです。その頃は、
自分はプログラムは小学生の頃から趣味で色々と書いていたとはいえ、まだプロとしての
経験がないので理解できていないだけかとも思ったものですが、大学を卒業してプロとしての
プログラマーの経験を10年強積んだ今、以前にも増して「ソースコードのコメント率は
低ければ低いほど良い」という考えが強まっています。


ソースコード中のコメントは多いほうがよいのか、少ないほうがよいのか？
http://d.hatena.ne.jp/eel3/20130815/1376529541
2013/12/19(木) 00:03:28.61
コメント率50%とか正気の沙汰ではないな
ソースコードに詳細設計書をそのまま書いてるようなもんじゃん
2013/12/19(木) 00:11:34.43
コメントを読む必要があるのはソースを読めないから。
つまり初心者。
2013/12/19(木) 00:16:27.16
テストを徹底すればコメントは必要ない
2013/12/19(木) 00:17:19.70
テストを徹底するのは不可能
まずこういう前提がある。
2013/12/19(木) 00:22:10.53
コメントを書く暇があったらコードを書こう
2013/12/19(木) 00:23:23.85
なぜテストを徹底するのが不可能かというと
その数が極めて膨大になるから。

例えば条件分岐が16個あるとする。
その組み合わせは2の16乗で65536になる。
条件分岐が32個であれば4294967296
1つ1ミリ秒で実行できたとしても50日かかる計算になる。
この全ての組み合わせをテストするのは不可能。

一つのアプリで条件分岐はいくつあるだろうか？
普通は32個よりはるかに大きな数であろう。

だからテストを徹底するのは不可能という結論になる。
テストはその一部しか出来ないのは当然の話。
だからその一部で十分とみなせるようにしないといけない。
そのためにはアプリの作り方と静的なチェックが重要になる。
2013/12/19(木) 00:26:43.45
Linuxならすべての組み合わせをチェックできる
2013/12/19(木) 00:53:24.75
>>616
ホワイトボックステストとブラックボックステストの違いくらい知っておこう
基礎知識がない人に限って断定口調で話す傾向があるね
2013/12/19(木) 00:58:38.89
>>618
ホワイトボックスとブラックボックスの違いを知らないと
思った理由は？

なんでさ、知らないと断定するの？

それに、ホワイトボックス（またはブラックボックス）
だったらなんなのさ？


知らないだろうといっただけで、
お前は意見を何も述べてなよ。
2013/12/19(木) 01:02:43.76
>>619
雑魚は素直にハイと言っておけば良い
2013/12/19(木) 01:03:35.09
>>619
テストにはホワイトボックステストとブラックボックステストの二種類がある。
>>616のレスはホワイトボックステストにしか当てはまらないが、
それなのにテスト全体について総括した意見を述べてしまっている。

よってブラックボックステストのことを知らないのだろうと判断できる。
2013/12/19(木) 01:10:49.95
>>621
ブラックボックステストにも当てはまるぞ。

条件分岐を、チェックボックスと置き換えればいい。
32個のチェックボックスが存在する検索フォーム

例えばこんなのな
http://www.chintai.net/tokyo/search/en_101001/

テストを徹底するというならば全ての組み合わせを実行しないといけない。
特定の組み合わせでのみエラーが起きるというのは普通に存在する。
2013/12/19(木) 01:11:50.88
Linuxならすべての組み合わせをテストできます
2013/12/19(木) 01:26:57.51
>>610
文芸的プログラミングが推奨された時代の話じゃねーの？
てか、サイレントボブみたいにコールグラフ描くツールの使い方おしえろよ
625デフォルトの名無しさん
垢版 |
2013/12/19(木) 02:17:02.59
コメントがなくてもわかるような
コードを書けってきかない？
コメントは
コードに情報を埋められない言語の逃げでしかない。
2013/12/19(木) 07:49:00.61
名前を変に省略形にしたり、変数がアルファベット1文字だったり、tmpだったり、
さらにそれを同じメソッド内で別用途に使いまわしたり、
１つのメソッドor関数で多くの機能を入れ込んで、さらに上流と下流のコードが混在していて、
どのブロックが上流の下流のどの工程なのか熟読しないと分からないとか、

まあ、「リーダブルコード」を読め、ってことだ。
2013/12/19(木) 08:00:32.37
まあ業務系は客観的に見て暇な仕事だからコメントをウダウダ書いて暇つぶしする余裕があるww
余裕がないとか言っている奴は隣人や就職希望の奴の仕事を奪って忙しがってる小山の大将(バカ)
2013/12/19(木) 10:44:02.91
>>616
テスト専門企業のHP見れば判るけど、今はテストケースをどうやって減らすかがノウハウだよ。
2013/12/19(木) 11:55:30.20
統合環境にはチェックボックスが32個ぐらいあるんだな
シェルだったらコマンドが32個あっても組み合わせた場合の責任はユーザーに転嫁される
2013/12/19(木) 12:29:13.88
そもそもCPUもディスクもメモリもOSもデバイスドライバもランタイムライブラリもそこまでの品質に達していないからPCごと窓から投げ捨てろ
631デフォルトの名無しさん
垢版 |
2013/12/19(木) 22:37:22.96
LinuxのようなOSSは品質が高い
2013/12/28(土) 01:17:06.39
Linuxの品質は高いが、OSSは総じて品質が低い
なぜだ？
2013/12/28(土) 13:55:07.64
ソースを公開する動機は品質向上というより、古いソフトの寿命を延ばすことだから
2013/12/28(土) 14:02:15.19
数の問題
2013/12/28(土) 16:50:28.30
おびただしいゴミの山から一握りの大成功だけをもってOSSと呼んでいる

流行に乗って何度もクソを取り上げてもてはやした過去は都合よく忘れている
2013/12/28(土) 16:55:58.94
業務アプリとかの方がクソっぷりは上だけどねー
いやホントに
2013/12/29(日) 00:06:12.98
いやいや捨てられて都合よく記憶からも消去されてしまうクソにはおよびませぬ
638デフォルトの名無しさん
垢版 |
2014/01/01(水) 10:16:24.21
今年はC++の1.5倍速いJSが馬のように勝つでしょう(^.^v)
2014/01/01(水) 10:18:04.91
1.5倍遅いの間違いです
2014/01/01(水) 10:23:30.46
Smalltalkも遅いしな。
動的言語が速い云々は特定ユースケースに絞った口先ばかりの話ばかりだ。
2014/01/01(水) 10:39:54.92
まあC#よりは速いんだからJSの速度は認めるしかないわな。
642デフォルトの名無しさん
垢版 |
2014/01/01(水) 11:35:39.56
実際C#と同等に動いてくれるならわざわざネイティブで作らんでもいいんだけどねぇ(´・ω・｀)
2014/01/01(水) 11:40:42.35
ちょっと話変わるけどC#とJSって近いよな
例えばUnityのJSはC#バインディングだし
同じ臭いがする
2014/01/01(水) 11:49:45.70
>>631-632
バイドゥのIME　Shimejiってオープンソースじゃなかったっけ？(w

そして、GoogleはIMEをオープンソースにしていない。
2014/01/01(水) 13:47:35.88
Googleは情報を集めることを公言してるし、
何と言っても検索で情報を提供してる
またWidevineみたいな情報を閉ざす方にも力を入れてる
Googleは情報の管理人として最も相応しい存在として世界中で認められているので
Baiduの件に比べて問題が少ない
2014/01/01(水) 14:05:46.10
×問題が少ない
○問題が大きすぎて思考停止している
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況