静的型付け言語の潜在開発生産性は今の100倍 ×5
■ このスレッドは過去ログ倉庫に格納されています
int a = 1;
a = "a"; ← エラーになる。
型がない言語ではできない芸当です。（爆笑）
人間がやっていたことを、コンピュータにやらせる。
これが生産性を上げる最大の方法。
コンピュータは間違わない、同じ事を何度も高速に行える。
その為に、コンピュータがコードの意味を正確に
認識できる方法が必要。実行しないとわからないことは
コンピュータは認識できない。
すなわち静的型付け言語であれば、実行しなくてもわかるので
コンピュータが理解できる。そうすれば様々な
コンピュータの高度な情報支援が得られる。
コンピュータのバックアップを受け、人間の生産性は
限りなく向上する。
前スレ
静的型付け言語の潜在開発生産性は今の100倍 ×4
http://toro.2ch.net/test/read.cgi/tech/1383572174/ 実行前に最適化したほうが速いよ。
実行時の最適化は毎回やるしね。 >>577
ネタだろwマジメに答えんなってw
さて、動的押してるフリしてる釣り師諸君に問題です！
V8, Rhino, SpiderMonkyはどの言語で実装されているでしょう？！
perl, rubyはどの言語で実装されているでしょう？
どんな答えがかえってくるかオラわくわくしてきたぞ！ >>578
Perl 6はHaskellで実装されたね >>578
Smalltalk は Smalltalk で実装されてたね まあ、javascriptは後方互換性を捨てた方がいいよね 後方互換性を捨てることで
得られるものを具体的に述べよ。
それをお前は欲しいと思っているはずなんだよね？ > 後方互換性を捨てることで
> 得られるものを具体的に述べよ。
訂正
後方互換性を捨てないと
得られないものを具体的に述べよ。 無駄なコストを捨てようとしたら
コストとは何かが客観的にわからないということがわかった どうせES6以降のコードはES5の実行環境では動かないのだから、use "ES6"とか
オプションつけたら変数スコープも常識的なブロックスコープになる機能が欲しい。
let導入で二種類の変数スコープが併存とか無意味すぎ。
もう今のvar相当はobsoluteで使ったらログに警告吐くぐらいの勢いで良い。 JSは互換性にも配慮されているので問題ありません。 低級言語の仕様を変えさせないという目的もある
高級言語を気が済むまで改変させることで低級言語が守られている >>587
移行というのは前のをバッサリ切り捨てるやり方じゃダメなんだよ。
いきなり全てを変えるなんて出来やしない
両方共存出来る状態を作って少しずつ変化させていく。
こうやらないとだめ。
> どうせES6以降のコードはES5の実行環境では動かないのだから、
動く。Polyfill系なんかがそう。
動かないのはletなどを使ったES6専用のコードだけ（コンパイルエラーになる）
こうやって、部分的にES6対応コードに置き換えていく。
varに関してもletに単純に置き換えれるように
コードを整理することは可能。これでES6でもES5でも動くコードになる。
これはES6に早い段階から対応していくという方針のやり方。
逆に将来ES6が十分に普及してしまった後にレガシーなES5を移行する。というような場合でも
varとletの両方が使えるならば、徐々にES6コードに置き換えるていくことが可能になる。 昔のことを覚えていなければ、いま新しいことをしているのかどうか分からない letは別に新しくともなんともなく単に普通なのであって、varも古い云々以前に単に変なだけ。
特に覚えておく必要も無い。
なのでuse strictの強化版のようなばっさり切り捨てる機能があって良い。 最強のPythonが動的型言語なので
動的型言語の方が生産性が高い 普通は文字列は一次元で絵は二次元だけど
「実行しないとわからない」なら時間軸を追加して次元がひとつ増える
三次元は正確に認識できないことがあるので生産性が低い
それは時間軸が原因だともいえるし、絵が原因だともいえる オメーらあんまりｇｄｇｄ言ってっと型に嵌めちまうぞッ Pythonも微妙になってきたな。
CG方面でなぜかデファクトだから仕方なく使う感じだ。 >>591
> 移行というのは前のをバッサリ切り捨てるやり方じゃダメなんだよ。
> いきなり全てを変えるなんて出来やしない
そうとは限らん。そういう場合もあるというだけだ。
破壊的変更と非破壊変更は相互補完の関係にあって、どっちを偏重してもいかんのだよ。
現にMozillaも新言語Rustを作ってるしな。
つかどう見てもES4のときに一度ばっさり互換を切るべきだった。
あれがWeb Platform最大の失敗だったことは、無数のaltJS乱立によって証明済み。 altJSって、2007年頃のLLブームに乗っかり、
いんぽqのに騙されたバカな魔法少女たちぐらいしか使わないんじゃねーの？ >>600
> 現にMozillaも新言語Rustを作ってるしな。
Rustへの移行が成功してから言えよｗ
現時点では前（JavaScript？）のをバッサリ切り捨てて
Rustを作ったが、ほれみろやっぱり移行していないではないか。
という実例になってるぞｗ > つかどう見てもES4のときに一度ばっさり互換を切るべきだった。
ECMAScript 4は互換を切ったよ。
だから仕様もまとまらなかったんだが。
それもまた、互換性をバッサリ切り捨てるやり方は
失敗するという、お前がいいたいのと正反対の実例だな。 JSは土管なんだから
後方互換性は何よりも大事だよ 処理系間の互換性が崩壊してる言語で後方互換性がどんな意味を持つんだろうか ESがバッサリ互換切り捨てたらバージョン間互換すら出来なくなるよね コメントがなくてもわかるような
コードを書けってきかない？
コメント書くのは素人 >>608
よっぽどのその言葉気に入ったみたいだなｗ コメントの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 コメント率50%とか正気の沙汰ではないな
ソースコードに詳細設計書をそのまま書いてるようなもんじゃん コメントを読む必要があるのはソースを読めないから。
つまり初心者。 テストを徹底するのは不可能
まずこういう前提がある。 なぜテストを徹底するのが不可能かというと
その数が極めて膨大になるから。
例えば条件分岐が16個あるとする。
その組み合わせは2の16乗で65536になる。
条件分岐が32個であれば4294967296
1つ1ミリ秒で実行できたとしても50日かかる計算になる。
この全ての組み合わせをテストするのは不可能。
一つのアプリで条件分岐はいくつあるだろうか？
普通は32個よりはるかに大きな数であろう。
だからテストを徹底するのは不可能という結論になる。
テストはその一部しか出来ないのは当然の話。
だからその一部で十分とみなせるようにしないといけない。
そのためにはアプリの作り方と静的なチェックが重要になる。 >>616
ホワイトボックステストとブラックボックステストの違いくらい知っておこう
基礎知識がない人に限って断定口調で話す傾向があるね >>618
ホワイトボックスとブラックボックスの違いを知らないと
思った理由は？
なんでさ、知らないと断定するの？
それに、ホワイトボックス（またはブラックボックス）
だったらなんなのさ？
知らないだろうといっただけで、
お前は意見を何も述べてなよ。 >>619
テストにはホワイトボックステストとブラックボックステストの二種類がある。
>>616のレスはホワイトボックステストにしか当てはまらないが、
それなのにテスト全体について総括した意見を述べてしまっている。
よってブラックボックステストのことを知らないのだろうと判断できる。 >>621
ブラックボックステストにも当てはまるぞ。
条件分岐を、チェックボックスと置き換えればいい。
32個のチェックボックスが存在する検索フォーム
例えばこんなのな
http://www.chintai.net/tokyo/search/en_101001/
テストを徹底するというならば全ての組み合わせを実行しないといけない。
特定の組み合わせでのみエラーが起きるというのは普通に存在する。 >>610
文芸的プログラミングが推奨された時代の話じゃねーの？
てか、サイレントボブみたいにコールグラフ描くツールの使い方おしえろよ コメントがなくてもわかるような
コードを書けってきかない？
コメントは
コードに情報を埋められない言語の逃げでしかない。 名前を変に省略形にしたり、変数がアルファベット1文字だったり、tmpだったり、
さらにそれを同じメソッド内で別用途に使いまわしたり、
１つのメソッドor関数で多くの機能を入れ込んで、さらに上流と下流のコードが混在していて、
どのブロックが上流の下流のどの工程なのか熟読しないと分からないとか、
まあ、「リーダブルコード」を読め、ってことだ。 まあ業務系は客観的に見て暇な仕事だからコメントをウダウダ書いて暇つぶしする余裕があるww
余裕がないとか言っている奴は隣人や就職希望の奴の仕事を奪って忙しがってる小山の大将(バカ) >>616
テスト専門企業のHP見れば判るけど、今はテストケースをどうやって減らすかがノウハウだよ。 統合環境にはチェックボックスが32個ぐらいあるんだな
シェルだったらコマンドが32個あっても組み合わせた場合の責任はユーザーに転嫁される そもそもCPUもディスクもメモリもOSもデバイスドライバもランタイムライブラリもそこまでの品質に達していないからPCごと窓から投げ捨てろ Linuxの品質は高いが、OSSは総じて品質が低い
なぜだ？ ソースを公開する動機は品質向上というより、古いソフトの寿命を延ばすことだから おびただしいゴミの山から一握りの大成功だけをもってOSSと呼んでいる
流行に乗って何度もクソを取り上げてもてはやした過去は都合よく忘れている 業務アプリとかの方がクソっぷりは上だけどねー
いやホントに いやいや捨てられて都合よく記憶からも消去されてしまうクソにはおよびませぬ 今年はC++の1.5倍速いJSが馬のように勝つでしょう(^.^v) Smalltalkも遅いしな。
動的言語が速い云々は特定ユースケースに絞った口先ばかりの話ばかりだ。 まあC#よりは速いんだからJSの速度は認めるしかないわな。 実際C#と同等に動いてくれるならわざわざネイティブで作らんでもいいんだけどねぇ(´・ω・｀) ちょっと話変わるけどC#とJSって近いよな
例えばUnityのJSはC#バインディングだし
同じ臭いがする >>631-632
バイドゥのIME Shimejiってオープンソースじゃなかったっけ？(w
そして、GoogleはIMEをオープンソースにしていない。 Googleは情報を集めることを公言してるし、
何と言っても検索で情報を提供してる
またWidevineみたいな情報を閉ざす方にも力を入れてる
Googleは情報の管理人として最も相応しい存在として世界中で認められているので
Baiduの件に比べて問題が少ない ×問題が少ない
○問題が大きすぎて思考停止している 自動車の事故と同じ
多大なメリットを提供してくれるGoogle様にはさからえない >>641
ネイティブ吐けるC#ってあったっけ？
CLR上でC#を超えるようなJS実装ってあったっけ？
比較対象がおかしいよ C#もJSも最終的に機械語になって実行されるんだから何も変わらん 静的言語はキャストがめんどうなんだよな。
あんなもの苦痛でしかない。 >>650
MS社内にあるだけで門外不出なんだろ？ >>652
いやググれば出てくるでしょ
MonoはC#をネイティブ出力できるよ この世はC#を無条件でWindows+.NET+Formsへと脳内変換する視野狭窄なドカタで満ち満ちている
ネイティブなどとほざいても絵空事にしかならない >>651
関数型がデフォルトイミュータブルなのと一緒でそれを不自由と見るか保証と見るかはあなた次第。 >>1のコードだと、指摘したい内容に対して微妙に噛み合ってないような
実行前に（変数の）型が決まっているかどうかと
変数に型を持たせられるかどうかは、厳密には別の話だよね
大抵の動的言語は変数に型がないから、端的に示すには十分なんだろうけど >>657
「型体系(type system)」と「型付け(typing)」の違いだね
これらはの概念は組合せ(直積)で考える必要がある
型体系(type system)：
・単一型(型無し、とも言う)
・ただ一つの型しか存在しない、言い換えると型を区別しない
例：Tcl や Shell --> 文字列型のみで、1 と "1" はどちらも文字列
・素朴な型体系
・複数の原始型と僅かな複合型
例：Lisp、Prolog、JavaScript --> 数値や記号といった原始型(=アトム)と
リスト(Lispの場合)または項(Prologの場合)から構成される
・複雑な型体系
・複数の原始型と複合型
例：Pascal や C といった多くの手続き型言語、および
ML族のような初期の静的型付け関数型言語 -->
以下の３種類の基本構造から構成される
・直積：タプル、レコード(=構造体)
・直和：列挙型、合併型(=共用体)、代数型
・列：配列、リスト
・複雑で階層的な型体系
例：C++/Java/Smalltalk/Ruby といったクラスベースのオブジェクト指向言語、
および Haskell や Scala のようなアドホック型多相を基礎とする関数型言語など
型付け(typing)：
・静的型付け：Pascal/C/C++/Java/C#/OCaml/SML/Haskell/Scala
・動的型付け：Lisp/Prolog/JavaScript/Smalltalk/Ruby/Python
・ハイブリッド：Objective-C 現在プログラム板のID制導入の投票を実施中です
よろしくお願いします
プログラム板 強制ID制導入に関する投票スレ
http://kohada.2ch.net/test/read.cgi/vote/1394290844/ メインで使う言語が Ruby から入って今は専ら Java だけど、
Rubyに戻りたくないな
やっぱ静的型付けは曖昧さがないから安心感が高くていいよ
オーバーロードも出来るし
開発環境もいろいろサポートしてくれるし
まぁでも Ruby はそれなりに良い言語ではるけどね
クロージャが書きやすいし(Javaでも書けるけど)
ミックスインも強力だし……そういえば Java8 でインターフェースのデフォルト実装来るのだろうか？
クラスがオブジェクトとして扱えて、クラスメソッドでポリモーフィズムが使えたり
うーん、懐かしいわ NumOrString で何がやりたいの？ Genericで型を作る事（IntやDouble とStringだけに制限かけるとか）でもできるし 何もしないでAnyでも良いだろ
Swift で Int を取りだす例
func getInt(v: Any)->Int{
if v is String {
return (v as String).toInt() ?? 0
} else if v is Int {
return v as Int
}
return 0
}
var numOrStr: Any = "100" // 文字列代入
println( getInt( numOrStr )+2 ) //102
numOrStr = 200 // 整数代入
println( getInt( numOrStr )+2 ) //202 動的型言語が急激にオワコン化しつつある
まだどっちにもメリット・デメリットがあるだの中立を気取る穏健派気取りも多いが
明らかにそんな段階超えてるっしょ。英語圏でもこんな記事が人気だ。
The abject failure of weak typing（弱い型の惨めな失敗）
http://techblog.realestate.com.au/the-abject-failure-of-weak-typing/
あと、静的型の連中はテスト書かんのか的勘違いしてる動的派たまにいるけどさー
型チェックして、静的解析して、その上でさらにCIもするに決まってるだろｗ
バグを減らすためのあらゆる手段を各段階に投入するんだよ。
それから、動的型の方が気楽に書けるだの速く書けるだのは妄言というほかない。
コードを実行するよりも前に、テストを走らせるよりも前に一定のバグチェックが働いたほうが
明らかにイテレーションが高速だろうが。常識で考えろ。
プロジェクトの規模が膨らむほど顕著になる。
つかせいぜい数千行で明らかに静的型の方が採算が良くなる。
リファクタリング一つ取ってもどうするつもりなのか。
静的型言語だとガチャガチャ数百行一気に組み換えて
コンパイルエラー何十個か潰して実行したら何の問題もなく動作するというようなことがままあるわけだが
RubyだのJavaScriptだのがメインの連中、そういう快感を知らないし想像もできないのだろう。
静的型で優れたIDEの恩恵をきちんと受ければどれほどの高速コーディングができるかも知るまい。
まして、プログラマは怠惰であるべきだから動的型マンセーｗだの
Twitterでアホがツイートしてるのを見たときには
馬鹿じゃねえのかと思ったよ。本気で。 >>662
weak typing?
技術用語の使い方も間違えてるバカのいうことなんか放っておけばいいw 「静的型言語」と言ってる時点ですでに穏健派の思う壺だよね
不特定多数の言語を指してるから
一つに絞り込む必要性が全く感じられない
複数選択可なら動的型言語も選んでみたくなる TypeScriptみたいに、動的型言語なんだけど、
オプションで型を書いて静的型検査する言語は
どうなんだろう？ 言語について静的と言っているのか、型付けについて静的と言っているのか、曖昧な表現を使うな。
「静的言語」か「静的型付き言語」の、どっちかにしろ。 >>667 何を言ってるんだよ TypeScriptは単なるプリプロセッサ。
出てきたJavaScriptが動的言語と言うだけの事
そんな事を言ったら色んな言語がそうできる
C++他からJavaScriptとか（Emscripten）
或は各種動的プログラミング言語のコンパイル版 例えば Python のPypiとか 機械語レベルにまで変換したら、
すべての言語は型情報を持たない。 >>670
byte単位、word単位、dword単位のインストラクションを持つCPUを使う限り
機械語にも型情報がある。 >>672
それは型じゃないな。
ただのビットサイズ >>674
符号の有無もあるぞ。十分にデータ型の条件を満たしているが。 メモリ上のオブジェクトのビット幅と符号等のエンコーディングだけでは型じゃないというなら、
じゃあC言語の型は型じゃないのかよw ■ このスレッドは過去ログ倉庫に格納されています
