動的言語の問題点、大規模開発でテスト工数が増大
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2012/04/24(火) 05:02:52.54非常に遅いため、Rubyで作成したアプリケーションの納品をためらったことがあります。
Rubyはプロトタイプ作成用に使い、納品用にJavaで作りなおさなければなりませんでした。
RubyとRailsのプロジェクトが数千行の規模を超え、チームに新しいメンバーを追加したときに、
動的言語の問題が明らかになって来ました。私たちは、コーディングの時間の半分をテスト作成の
費やさなければならなかったのです。Railsによって得られた生産性の向上は、テスト作成の作業に
失われてしまいました。作成したテストの多くは、Javaであれば不必要なものでした。テストの大半は、
リファクタリングによってメソッド名やパラメータの数を変更した際に、呼び出し元が
正しく変更されているかを確認するためのものでした。
また、Rubyでもチームメンバーが2名から4名であれば、メンバー間のコミュニケーションは
非常にスムーズでした。しかし新しいメンバーをチームに参加せせようとすると、
これまでチームで培ってきたノウハウを新しいメンバーにうまく伝えることが出来なかったのです。
0002デフォルトの名無しさん
2012/04/24(火) 05:32:46.72Javaで作ったプログラムをRubyで書き直し
プロジェクトが大きくなりメンテナンス不能のなって
結局またJavaで書き直し
0003デフォルトの名無しさん
2012/04/24(火) 07:36:01.190004デフォルトの名無しさん
2012/04/24(火) 08:42:09.250005デフォルトの名無しさん
2012/04/24(火) 09:11:54.61これは「Scalaプログラミング入門」3ページからの引用ですが、
RubyがJavaに比べて一方的に劣っていると誤解させる恣意的な引用ですね。
筆者はScalaがJavaとRubyの長所を併せ持つとしか主張していません。
そしてScalaが関数型言語でもある事を最も重要な事としています。
筆者の考えがより正確に伝わるように前後を引用します。
直前の記述：
1996年、Javaとの初めての出会いは、まさにお告げでした。
メモリの解放について悩まなくても済みます。Javaにはまともな例外処理機構があります。
一夜にして、私が作ってきたプログラムで発生した欠陥のうち、70%がすべて解決されたのです。
それから長い間、私はJavaを使いつづけ、愛してきました。
（中略：JVMはどんどん速くなった）
JVMが成熟してきたのに対し、Java言語は長年にわたり、成熟することができませんでした。
Javaの文法は停滞し、JavaのWebアプリケーションフレームワークは、どんどん肥大化してきました。
フィールドの定義や、フィールドをもとにHTMLフォームを生成するなどの単純なことを実現するだけでも、
JavaやXML、その他の設定ファイルに書かなければならない量はどんどん増えてきています。
ほとんどのプロジェクトでJavaを使っていましたが、Javaに対しての失望感は募っていくばかりでした。
（中略：ジェネリクス導入により、補完機能のあるIDEでないとコーディングできなくなった）
自分の中にあるアイデアを、よりシンプルに、より直接的に表現できるもっと良い方法がないだろうか？
私は答えを探し始めました。そして、RubyとRailsを見つけました。これこそ自由です。
Rubyでは、はるかに少ないコードで自分の考えを表現できます。
RailsはSpringMVCや、Hibernateなどその他の
「効率的な」Webフレームワークよりも、ずっとずっと簡単です。
RubyとRailsを使うことで、頭の中のコンセプトを、より短い時間でより多く実現できます。
C++からJavaへと乗り換えたときに似た、開放感を覚えました。
0006デフォルトの名無しさん
2012/04/24(火) 09:12:25.96私は、新しい言語と開発環境を探し始めました。
Rubyの豊かな表現力と、Javaの高いパフォーマンスを併せ持つ言語を探していました。
そして2006年11月、出会ったのがScalaです。
Scalaは表現力とパフォーマンス両方を兼ねそなえているだけでなく、
それ以上の可能性を感じさせてくれたのです。
（中略：Scalaは高速でJavaと互換性がある）
最も重要な事は、Scalaはこれまでと違ったプログラムの方法や考え方を教えてくれたことです。
Scalaを知ったおかげで、バッファーや構造体、オブジェクトの割り当てや、
これらのメモリ操作について考えるのをやめました。
その代わり、私の作るプログラムのほとんどは、
インプットからアウトプットへの変換ととらえられることを学びました。
Scalaは、簡潔でモジュール化されたコードを、
メンテナンス可能な形でまとめられるツールを与えてくれました。
しかも、JavaやRubyを使う場合よりも、はるかに複雑なロジックを記述できます。
2年以上Scalaを使いつづけ、愛し続けた結果、後悔していることが1つだけあります。
それは大学時代にLispを学ばなかったことです。
大学院時代にプログラミング言語理論についてのコースをとっておくべきでした。
0007デフォルトの名無しさん
2012/04/24(火) 10:28:20.920008デフォルトの名無しさん
2012/04/24(火) 10:36:03.49筆者の考えがより正確に伝わるように引用します。
「テストの大半は、リファクタリング」
0009デフォルトの名無しさん
2012/04/24(火) 11:05:54.590010デフォルトの名無しさん
2012/04/24(火) 11:41:28.29数千→数万になったって意味じゃね？
0011デフォルトの名無しさん
2012/04/24(火) 12:11:30.690012デフォルトの名無しさん
2012/04/24(火) 12:17:36.92移行とかに慣れないうちはよくある
0013デフォルトの名無しさん
2012/04/24(火) 12:18:57.450014デフォルトの名無しさん
2012/04/24(火) 13:54:02.92Javaに対するEclipseのような修正漏れが限られているリファクタリングツールが
Railsにないからテスト工数が増大したという事ですね。
Ruby+Railsだと修正漏れの少ないリファクタリングツールを作るのは難しいですが、
今後ツールが自動的に修正できる範囲が増えれば必要なテストは減るでしょう。
つまり、Rails用リファクタリングツールの性能向上で解決できる問題だと思います。
0015デフォルトの名無しさん
2012/04/24(火) 15:38:29.21オブジェクト指向で何か修正したい場合
メンバーの継承と追加はできるが削除はできないというのが基本です
これはツールではなくパラダイムです
メソッド名やパラメータの数を変更するのも、ツールではなくパラダイムの問題です
0016デフォルトの名無しさん
2012/04/24(火) 15:47:07.32そんなにrubyが憎いか。
0017デフォルトの名無しさん
2012/04/24(火) 18:30:56.15リファクタリングについて何も知らないのに「パラダイムの問題」と断言するのはどうかと思います。
内部構造を整理するために既存のクラスを修正するのがリファクタリングです。
メソッド名やパラメータ数を修正した時に呼出側も漏れなく修正されるかどうかはツールの問題です。
リファクタリング (プログラミング)
http://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0_%28%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%29
0018デフォルトの名無しさん
2012/04/24(火) 21:20:58.20いつの時代の人間だ
0019デフォルトの名無しさん
2012/04/24(火) 22:01:04.01> メソッド名やパラメータ数を修正した時に呼出側も漏れなく修正されるかどうかはツールの問題です。
言語の問題であることも多いよ。
RubyわからんのでPerlの例でいうけど、
たとえばPerlだと
{
package Class1;
sub new { ... }
sub foo { ... }
}
↑このfooというメソッド名を修正した時、
my $c = $flag ? Class1->new() : Class2->new();
$c->foo();
↑ 呼び出し側のfooを変更していいかどうかなんて判別不可能だしね。
Rubyも変数に型がないから、同じじゃない？
0020デフォルトの名無しさん
2012/04/24(火) 22:14:19.08YARVはRailsの性能問題を解決しませんでした。
http://ja.wikipedia.org/wiki/YARV
> 2006年12月31日にRubyリポジトリにマージされ、
> 2007年12月25日にリリースされたRuby 1.9.0から、正式に組み込まれた。
http://www.rubyist.net/~matz/20070707.html
>じゃあ、速度の問題はこれで解決かというとそんなことはない。
>YARVになってもRailsの性能は改善されないからだ。
http://it.slashdot.jp/story/09/04/10/0421223/
>Twitter、Ruby on RailsからScalaへ
> Twitter ではフロントエンド、バックエンド共に Ruby on Rails が使われていたが、
> 最近では大量のメッセージを処理できず「Fail Whale」出現の原因となったりしていた。
0021デフォルトの名無しさん
2012/04/24(火) 22:26:51.29断言が気に入らないようだが、宣言的なパラダイムをどう思う？
そもそも「修正する」というのは手続き的だよな
0022デフォルトの名無しさん
2012/04/24(火) 22:29:28.47静的型付言語のJavaが静的コード解析で修正箇所を特定できるのに対し、
動的型付言語でダックタイピングを採用したRubyと
黒魔術レベルの動的プログラミングを実現したRailsの組み合わせに対して
必要な修正を網羅するリファクタリングツールを非常に作りにくいのは確かですね。
それでもRailsのバージョン別のツールにするとか
ホワイトボックステストで実行フローを枝刈りするとか
ツールのアルゴリズムを工夫する余地はあると思います。
0023デフォルトの名無しさん
2012/04/24(火) 22:47:34.46手続き的か宣言的かオブジェクト指向かというのはプログラムの設計の話です。
リファクタリングは無駄に複雑でわかりにくいコードを全体的に整理するという話です。
あなたは全然関係ない話をごちゃまぜにしています。
0024デフォルトの名無しさん
2012/04/24(火) 23:08:13.23あなたは「設計と全然関係ないことをするのがリファクタリングだ」と言っています
0025デフォルトの名無しさん
2012/04/25(水) 00:08:13.79余地があるのは、今のRubyのリファクタリングツールが貧弱なだけ。
少しはまともになるかもしれないが、まあ期待するだけ無駄でしょう。
Scalaのおかげで、コードを短く書くのに、動的言語である必要性はないのが証明されました。
これからは静的言語かつコードを短く書けるScalaのような言語が
主流になっていくでしょう。
プログラマだというのに、プログラミングを楽にするためにコンピュータの力を
生かせる言語を作ろうと発想が出てこないのが不思議でなりません。
Scalaは理想の言語ですね。
0026デフォルトの名無しさん
2012/04/25(水) 02:29:57.05やりたいことが頭の中から逃げてしまう。簡潔さは力なのです」
http://toro.2ch.net/test/read.cgi/tech/1326687331/57
0027デフォルトの名無しさん
2012/04/25(水) 08:20:42.68誰も読めないようなperlの魔法的変態記述の反省でもあるのに
なぜ性懲りもなく繰り返すのか
perl知らない素人じゃあるまいに
0028デフォルトの名無しさん
2012/04/25(水) 08:44:28.00ScalaでHello World
↓
println("Hello, world!")
これだけ。
public static void mainなどいらないのです。
0029デフォルトの名無しさん
2012/04/25(水) 09:02:33.82Perlはものすごく読み書きに詳しい
では、読み書きに詳しくない人に読ませるという立場はどこから出てきたのか
0030デフォルトの名無しさん
2012/04/25(水) 10:45:09.16Rubyが遅いのは動的だからって短絡はほんといいかげんやめてほしい。
Rubyが遅いのは単純にまつもとやささだの技量不足ってだけの話しで、
やつらが作れば静的言語だって遅くなる。LuaやV8の実装者に申しわけなさ過ぎる。
0031デフォルトの名無しさん
2012/04/25(水) 17:51:45.56LuaやV8はRuby処理系ではないのに、速度差の原因は
言語仕様の違いではなく技量の差とどうやって判断したのですか？
Groovy++で@Typedをつけると型推論を行い静的型に基づいて最適化されます。
@Typedをつけない部分はGroovyと同じく動的ディスパッチや動的型付ができます。
@Typedをつけたかどうかで実行速度が数十倍違います。
コンパイラは同じだから、コンパイラ作者の技量の差などありません。
@Typedをつけると最適化しにくい言語仕様を切り捨てるのが速度差の原因です。
Groovy++
http://d.hatena.ne.jp/uehaj/20100225/1267106256
Groovy++、来襲
http://www.slideshare.net/touchezdubois/groovypp-attack-6229953
0032デフォルトの名無しさん
2012/04/25(水) 22:19:47.39> 技量の差とどうやって
動的という観点に絞れば、LuaやJavaScriptはRubyよりはるかに動的だからでＦＡ
> コンパイラは同じだから、コンパイラ作者の技量の差などありません。
それは１行目の話。型情報を使って最適化できる静的型が有利なのは当たり前。
0033デフォルトの名無しさん
2012/04/25(水) 22:39:32.260034デフォルトの名無しさん
2012/04/25(水) 22:58:32.280035デフォルトの名無しさん
2012/04/25(水) 23:02:56.10さて、次の三つのうち実行時間が一番遅いのはどれでしょう？
１．コンパイル処理を実行開始前に完了しておく
２．コンパイル処理を実行開始時に行う
３．コンパイル処理を実行されるたびに行う
0036デフォルトの名無しさん
2012/04/26(木) 00:07:49.48もっと一般的なスレタイの方が良かったのでは？
●過去スレ
やっぱり動的言語では安全なソフトは作れない
http://hibari.2ch.net/test/read.cgi/tech/1306002146/
やっぱり動的言語では安全なソフトは作れない 2
http://hibari.2ch.net/test/read.cgi/tech/1306571666/
やっぱり動的言語では安全なソフトは作れない 3
http://hibari.2ch.net/test/read.cgi/tech/1308499587/
やっぱり動的言語では安全なソフトは作れない 4
http://hibari.2ch.net/test/read.cgi/tech/1316016777/
やっぱり動的型付け言語では安全なソフトは作れない
http://hibari.2ch.net/test/read.cgi/tech/1316887046/
やっぱり動的型付け言語は大規模開発で効率が悪い 2
http://hibari.2ch.net/test/read.cgi/tech/1319212872/
やっぱり動的型付け言語は大規模開発で効率が悪い 3
http://hibari.2ch.net/test/read.cgi/tech/1320832914/
やっぱり動的型付け言語は大規模開発で効率が悪い 4
http://hibari.2ch.net/test/read.cgi/tech/1321843683/
やっぱり動的型付け言語は大規模開発で効率が悪い 4
http://toro.2ch.net/test/read.cgi/tech/1321972779/
0037デフォルトの名無しさん
2012/04/26(木) 06:41:08.61どっちもウンコ言語だから良い勝負だな
0038デフォルトの名無しさん
2012/04/26(木) 07:44:44.20Lua 50.5
LuaJit 6.8
http://attractivechaos.github.com/plb/
0039デフォルトの名無しさん
2012/04/26(木) 08:21:31.03>実行時間が一番遅い
日本語で頼む。
0040デフォルトの名無しさん
2012/04/26(木) 08:54:57.97３
0041デフォルトの名無しさん
2012/04/26(木) 08:57:31.13すどおりしたようにみえる
0042デフォルトの名無しさん
2012/04/26(木) 15:40:35.66初めて見たときは衝撃だよな
0043デフォルトの名無しさん
2012/04/26(木) 22:39:04.82BASICだ。
0044デフォルトの名無しさん
2012/04/27(金) 09:00:10.900045デフォルトの名無しさん
2012/04/27(金) 14:05:19.47それに気づかなかったり、rubyでendをうっかりendifって書いていて、ミスしたのはコードの
最初のほうなのに表示されるエラーの行番号はコードの最終行でミスを見つけるのが困難だったり
ほんと動的言語はダメだわ。
0046デフォルトの名無しさん
2012/04/27(金) 14:27:31.49あとlint的なものを使えば、その手の間違いを検出できる場合もある。
0047デフォルトの名無しさん
2012/04/27(金) 14:28:27.24アホ
0048デフォルトの名無しさん
2012/04/27(金) 14:31:38.72動的かどうか全く無関係に区別は不可能
っていうか着色とキーワード改行インデントするエディタ使え
0049デフォルトの名無しさん
2012/04/27(金) 14:32:05.33静的型付け言語だと、変数の宣言が必須でコンパイルエラーになるから検出が容易
0050デフォルトの名無しさん
2012/04/27(金) 14:40:24.940051デフォルトの名無しさん
2012/04/27(金) 14:43:14.370052デフォルトの名無しさん
2012/04/27(金) 14:48:18.950053デフォルトの名無しさん
2012/04/27(金) 14:52:53.05時間潰しでレス欲しいだけならVIPやニュー速や嫌儲へどうぞ
0054デフォルトの名無しさん
2012/04/27(金) 15:04:55.53IDEがサポートしてる静的言語ならエディタで入力した時点でそんな変数ないって指摘してくれる。
0055デフォルトの名無しさん
2012/04/27(金) 15:08:27.68頑張れば大部分は検知できそうな気もするが、流行らないのはなんでだろう
0056デフォルトの名無しさん
2012/04/27(金) 15:21:41.140057デフォルトの名無しさん
2012/04/27(金) 15:22:19.68"loginＩd = param"のつもりで"loginid = param"と書いてしまったときの話だよ？
0058デフォルトの名無しさん
2012/04/27(金) 19:00:40.63グローバル変数の使用状況を見れば、頑張らなくてもチェックできるんだが
グローバル変数が無い言語が流行っている
0059デフォルトの名無しさん
2012/04/27(金) 21:20:25.70全然違う視点を持つと結果は変わってくるが
クラスベースOOとかJavaに近い動的言語はダメになる
0060デフォルトの名無しさん
2012/04/27(金) 21:32:22.92動的言語を使うなという話。
0061デフォルトの名無しさん
2012/04/28(土) 00:56:52.290062デフォルトの名無しさん
2012/04/28(土) 02:18:16.52ただしGCが改良される度にソースの互換性がなくなる気がする
0063デフォルトの名無しさん
2012/04/29(日) 14:27:24.66使い物にならない言語という結論
0064デフォルトの名無しさん
2012/04/30(月) 04:14:56.56現行のほとんどの言語がやれちゃうのでどうしようもない
あきらめてスクリプト言語で作ろうぜ
俺は絶対にやらないけど
0065デフォルトの名無しさん
2012/04/30(月) 10:28:42.94名前をつけても何も解決しないな
0066デフォルトの名無しさん
2012/04/30(月) 11:00:31.68l i! l , ＿,.ﾍ V ＼ {ヾー- _',___Ｖ | l| |
il __.ｨﾁ "| i!￣ ﾊ '., ＼ ' , ヾー __i! i| |
.!￣ | ,ｨ≦三ﾐ､ ', ＼ i｀,ｨfゞ三ミ､ ',.| , | |
! i|. ,'/ ,'´}:｀ヽ. ＼ | .,'´}:｀ヽ ヾ., ',! / i| |
,. ! {{' {´:::::::::}. ヽ. i! {;´:::::::::} }} } / i| |
, i i! ゞ ゝ;;;;;ソ, ヽ! ゝ;;;;;ソ ﾘ' ,' / .i| |
, l､ ', / ,ｲ .i| |
, i! ヾ. ///////// /////// /／ .l| |
ﾍ! .{ .｀ ! /'/ ;i i| |
ﾊ , ｀∧ / ノ,' | |
ﾊ ', ヽ __ __ / / ./ | |
ﾍ V ヽ. ,´ ＿＿ ヽ .ｲ /／ i|! .| |
ﾍ V .i! ヽ. ´ ｀ ィ /´ i! l| i| |
ヽ ', i! | ＞ ＜ | | i! .i! |
0067デフォルトの名無しさん
2012/05/07(月) 01:15:39.07静的型付けのC++なら、この程度の関数は何も気にせずに使えるけど、
http://ideone.com/xcxjC
動的型付けのJavaScriptだと、この程度の関数でも気をつけて使わないと駄目な代物になる事。
http://ideone.com/lbcaB
0068デフォルトの名無しさん
2012/05/11(金) 21:54:23.230069デフォルトの名無しさん
2012/05/11(金) 23:29:18.34現実には型付けがなくて片付けられないんだよ
0070デフォルトの名無しさん
2012/05/12(土) 00:14:38.090071uy
2012/05/12(土) 12:20:05.59でっていう
ライブラリ側は全て静的言語でやって（速度も速いし）
その速度の速いライブラリを動的言語から呼び出したり、
型情報とかいちいちつける意味のない
実装コードは動的言語でさっさとやるんだよ
0072デフォルトの名無しさん
2012/05/12(土) 15:20:43.380073デフォルトの名無しさん
2012/05/12(土) 17:28:00.830074デフォルトの名無しさん
2012/05/13(日) 12:32:23.01もう動的型付け言語ではやっちゃいけないってことなんだよ。
この変数は○○型です。なんて
コメントをつけ出したら末期。
0075デフォルトの名無しさん
2012/05/13(日) 21:35:36.32と言うかシステムハンガリアンが活きるのって
CやJavaやC#じゃなくて動的言語だよなあ
0076デフォルトの名無しさん
2012/05/15(火) 23:53:16.430077デフォルトの名無しさん
2012/05/16(水) 01:05:53.130078デフォルトの名無しさん
2012/05/16(水) 04:46:45.01いれても正常に処理しますってのは無いんだから。
0079デフォルトの名無しさん
2012/05/16(水) 07:26:51.79つまり、コード自体のミスよりも
悪いコードに罰を与えようとする側の判断ミスの方が深刻な問題になる
0080デフォルトの名無しさん
2012/05/16(水) 18:15:57.100081デフォルトの名無しさん
2012/05/17(木) 00:58:48.26予想通りで笑った
0082デフォルトの名無しさん
2012/05/21(月) 23:43:56.65動的型付けだからシステムハンガリアンが必要になるんじゃないの？
違う型突っ込んでもシステムがエラーを拾うわけじゃないんだろうけどさ
0083デフォルトの名無しさん
2012/05/22(火) 14:17:06.25> ライブラリ側は全て静的言語でやって（速度も速いし）
> その速度の速いライブラリを動的言語から呼び出したり、
> 型情報とかいちいちつける意味のない
> 実装コードは動的言語でさっさとやるんだよ
ブラウザだと逆になってしまいそうだな。
ライブラリは速いJavaScript、それを使うユーザーは静的型言語から変換。
どうしてこうなった
0084デフォルトの名無しさん
2012/05/22(火) 14:27:55.050085uy
2012/05/22(火) 16:13:17.91動的言語はダメだ ってふうに勘違いされやすいけど
そうじゃなくて
今まで静的言語でプログラム開発していた部分に
やっと動的言語が1歩踏み込んだけど、まだ色々と足りなくてダメだったね
ってだけだからね
いずれにしよ、小規模なプログラム開発では動的言語に静的言語が勝てるわけないから
そのうち大規模開発でも動的言語は使い物になると思うよ
今は、「え？別に動的言語で大規模開発できるでしょ？」って無理して発言する事ではなく
「なぜ出来ないのか？」「どうすればいいのか？」 それを考える時期
0086デフォルトの名無しさん
2012/05/22(火) 16:35:06.090087デフォルトの名無しさん
2012/05/22(火) 17:55:35.84からどうして
「大規模開発でも動的言語は使い物になると思うよ」
につながるのかが、さっぱりワカラン。
0088デフォルトの名無しさん
2012/05/22(火) 18:38:01.21世界が滅びる兆しのようだ。
0089デフォルトの名無しさん
2012/05/22(火) 19:13:26.080090デフォルトの名無しさん
2012/05/22(火) 22:05:50.12動的言語に近い簡潔さで型安全なプログラムが書ける。
動的言語：小規模書き捨てスクリプト
関数型言語：中規模少数精鋭
静的手続き型言語：大規模ドカタ開発
こんな感じで棲み分けされるよ。
0091uy
2012/05/23(水) 18:12:53.30概念が中途半端
0092デフォルトの名無しさん
2012/05/23(水) 20:25:04.68その軸の両端には何の概念が来るんだ？
中途半端さが理由で流行らないってことは
中途半端でない概念をベースにした言語は流行ってるのか？
ってここまで書いて気付いたがuyかよ
0093デフォルトの名無しさん
2012/05/23(水) 21:00:33.910094デフォルトの名無しさん
2012/05/23(水) 22:35:46.89やっかいだな。
0095デフォルトの名無しさん
2012/05/23(水) 23:06:52.490096デフォルトの名無しさん
2012/05/24(木) 09:08:30.06だが、その醜い身体の中には正義の血が隠されているのだ。
0097uy
2012/05/25(金) 00:17:48.590098デフォルトの名無しさん
2012/05/25(金) 00:27:25.800099デフォルトの名無しさん
2012/05/25(金) 04:38:11.86本当に実行時じゃないと決まらないことって少ないんだよね。
実はコードジェネレータでコンパイル時に定義ファイルなどから
コードを動的に生成するだけで十分ってことが多い。
0100uy
2012/05/25(金) 13:43:17.47普通にかいてればバグとかはいる箇所って全然少ない気がする
バグが存在しないとわかってるコードを利用する分には、問題はなくて
動的言語で困るのは、自分でソースコードを大量に書かなきゃいけない時か
それでも
a = nil
a.push 2
とかかいてて、こういうののせいで誰かリアルで死んだら
声高らかに動的言語は間違ってる！とか言われるから
やっぱり型チェックは存在していないとまずい
もしや動的言語からevalがいらないんじゃね
evalさえなければコンパイラも作れる可能性は高い気がする
0101デフォルトの名無しさん
2012/05/25(金) 21:51:15.36まで読んだ
■ このスレッドは過去ログ倉庫に格納されています