やっぱり動的言語では安全なソフトは作れない

型をしっかり明記してこそ
安全で堅牢、バグのないソフトは作れる

せめて、そう思う根拠ぐらいを書こうよ、自分の主張に説得力をもたせるためにさ。

俺は天才だ。って言って、誰が信じると思うの？

そんなこともわからないぐらいに>>1は池沼なのかな？

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

>>1 はMLかHaskell使ってればいいじゃない。
まさかC言語で「安全」とか思ってないよね？

どうして、京都大学霊長類研究所は、アイちゃんの、
スレ乱立を見過ごしてるの？

独自の板立ててそっちで実験するとかできないの？
いまどき、主婦だって専用の板ぐらい立てられるぞ。

「関係者以外は書きこまないで下さい。」とか、何
お前らがエラソーに仕切ってんだよ、ハゲ！

糞スレをあちこちにポンポン乱立されちゃ迷惑なんだよ。
ったく、京都大学霊長類研究所は能無しの集まりかよ！

Haskellだって本当に安全ってわけじゃないぜ？
unsafeな関数がゴロゴロしてる

せやな

関数型が開発効率上がるならもっと普及してる

>>4
むしろC言語って実質的には型がない言語じゃね？

静的に型チェックすることが重要ってことだろ

静的言語でも動的言語っぽい書き方はできる。
単にそういう書き方を許さない空気があるだけで、空気読まずに書こうと思えば書ける。
つまり、安全を機械的にチェックしているというのは半分嘘で、
実は人間のモラルに頼っている部分が大きい。

面倒なことはやらない

型推論をうまくやってくれて色々省略可能にした静的言語がつおい、でFA

　　　　 /: : : : : __: :/: : ::/: : :／/: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ　　　　＿＿＿
　　 　 /;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::､　 ／　　　　 ヽ
　　　 /ヽヽ: ://: :!:,X~::|: /;,,;,/: :／　 ﾘ!: ::/ﾉ　 l｀ヽl !: : |: : : :l: :l: ﾘ /　そ　そ　お　＼
　　　/: : ヽヾ/: : l/::l |／|||llllヾ,､　　/ |: :/ , -==､　l＼:::|: : : :|i: |　/ 　 う　う　 前　　|
.　　 /: : : //ヾ ; :|!: ｲ､||ll|||||::||　　　 ﾉノ　 ｲ|||||||ヾ､ |: ::|!: : ｲ: ::|/　 　な　思　が
　　 /: : ://: : :ヽｿ::ヽl |{ i||ll"ﾝ　　　 ´　　　i| l|||l"l　｀|: /|: : /'!/l 　 　 ん　う
　∠: : : ~: : : : : : : :丶ゝ-―-　　　　　 , 　ｰ=z_ｿ　　 |/ ﾊﾒ;, :: ::|.　　　だ　ん
　　 i|::ﾊ: : : : : : : : : : : ､ﾍﾍﾍﾍ　　　　 ､　　ﾍﾍﾍﾍﾍ /: : : : : ＼,|.　　　ろ　な
　　 |!l　|: : : : : : : : :､: ::＼　　　　､-―-,　　　　　　/ : : :丶;,,;,:ミヽ　　 う　 ら
　　　　　丶: :ﾊ､lヽ: :ヽ: : ::＼__　　｀~　"　　　　　 /: : ﾄ; lヽ）　　　ゝ
　　　　　　 ﾚ　｀|　｀､l｀､＞=ﾆ´　　　　　　　 ,　　_´ : :}　｀　　　／
　　　　　　　　 ,,､r"^~´"''''"t-｀r､ _　　-､　´ヽノ　＼ﾉ　　　／　　　　お ・
　　　　　　　,;'~　　_r-- ､__　　　　　~f､_>'､_　　　　　　　　 |　　で　　前 ・
　　　　　　f~　　,;"　　　　　~"t___　　　　ﾐ､ ^'t　 　 　 　 　|　　は　　ん ・
　　　　　 ,"　　,~　　　　　　　　　ヾ~'-､__　ﾐ_ξ丶　　　　　|　　な　　中 ・
　　　　　;'　　,ｲ　.. 　　　　　　　　　ヽ_　　 ヾ､0ヽ丶　　　　l　　　　　　　　　/
　　　　 （　;":: |:　:: ..　　　　　　　　　 .｀,　　 ヾ　丶 !　　　　＼＿＿＿＿／
　　　　　;;;; :: 入:: :: :: 　 　　　l｀ｰ-､　　 ）l　　 ヾ　丶
　　　　　"~､ｿ:: :い:: :　　　　　＼_　　ノ　,　　　 ヾ　丶

C++に型推論が必要だと思えない

C++に型推論は必要。templateやlambdaを書いてみれば分かる。
C++自体必要無いという意見は認める。

templateには必要ないしそもそもlambdaとか必要ない。
マルチパラダイムを存続させたいならCとC++の間にもうひとつ言語用意すべき。

Cを拡張した言語なんてこれ以上いらん

Objective-C最高

C++とかごった煮過ぎてプロジェクトで使えない

Objective-CとかCベースである必要性がない

静的 vs. 動的の話題が C++ vs. ObjC になるとかw

そんなにおかしくないじゃん

EclipseでPHP開発しようとしてがっかりした俺が来ました。

スペルミスしても動いてしまうからなぁ。

C言語もポインタ経由したりすると型無視されたりしてしまうし
C++もテンプレート使いまくると動的型みたいな状態になるな

え？え？

>>26
ならんが？ｗ

それに使い方の問題は関係ない。
静的言語であっても動的言語みたいなことはできる。
だが逆に動的言語では静的言語みたいなことはできない。

せやな

>>28
できるよ。

うそつきました

>>28
オプションを両建てできてもあんまり嬉しくない

動的な言語ならメタな機能を使って、
関数の引数や返り値の型だとか変数の型をアノテーションで宣言できるし、
モジュールロード時に型検査することもできる。

で、動的言語だと何ができないの？

静的チェック・メモリの自前管理

どこかで Ruby 「で」GC を実装する話を読んだ事がある希ガス

>>34
どうして>>33を読んで静的チェックが可能だと理解できないの？

>>33
それができるのはなんて言語だよｗ

つーか実行時にできてもしょうがないんだよな。
実行前に検査できるのが重要であって。

既にあるのかどうかは知らんが、たぶんpythonのアノテーションなら可能だと思うが。

>>38
どうして>>33を読んで実行前にチェックが可能だと理解できないの？ 馬鹿だから？

静的チェックができる動的言語ってC++のことじゃん

動的言語のメリットは記述が簡潔になる事なのに、
簡潔じゃない言語で動的な仕組みが使えても嬉しくないなあ

静的に決めないから動的なんであって。

記述の簡潔さのために可読性や保守性や静的なエラーチェックを下げるのか。

>>40
だからなんて言語か言えって（爆笑）
怖いのか？　お前の脳内言語か？

可読性は下がらない

メンバ変数が追加できる言語は宣言の概念がないか複雑なので可読性が下がってる。

>>45
書いてあるのが読めないの？気が狂ってるの？
さっさと病院いけやキチガイ

Objective-Cなんて昔は注目もされなかった言語だが。


それよりOS/9とかまだあるの？

静的言語だと、よく使われる単語であるget()というメソッドをfetch()に
変えようと思ったとき使用箇所が何百とあったとしても、
すべてを安全に変更できるし、エディタの力を借りればほんの数秒で終わる作業だが
動的言語ではそれができない。

最近はPythonのように、もともと動的言語だった物を
静的言語にしようという流れがある。

やっぱりそれは動的言語では安全なソフトを作れないからなのだろう。

>>50
そのコードを使うのがお前一人なら、という前提が抜けてるぞ。

ま、ホビーストならそれでいいんじゃないか？
しかしチームで開発するようになったら、そんなナイーブな発想じゃだめだ。
ましてや分散レポジトリを使うような開発になったら、そんな変更を勝手にやるカスは追い出されるぞ。

ActionScriptでもその流れ。
浸透すればするほど大規模に使おうとして静的になっていく。

>>51
違うよ。
動的言語はメタ機能が充実していることが多いから、
その気になれば静的言語の機能を取り入れることが可能なだけ。

>>52
50じゃないが大規模で動的言語自体危険なんだが。
変更の必要性を否定したら硬直化して一定規模以上で破綻するし
変更に安全性が保証されなかったらこれまた破綻する。

その気になればｗ

>>52
勝手にやるわけ無いだろ？
それは許可を得るというチーム開発の
マナーの話であって、

メソッド名を簡単に変えるという技術的な話とは一切関係ない

>>54
> 動的言語はメタ機能が充実していることが多いから、

動的言語のメタ機能っていうのは、実行時にしかわからんメタ機能だ。

実行前に分かるメタ機能 ＝ 静的言語が備えている機能

決して愛用の動的言語名は明かさない。

>>53
安全は規模に反比例する
大規模に使おうとする流れは危険だ

動的言語だと、このメソッドがどこで使われてるか？の判断に
grep使うしか無いからな。

だから、英単語一つのメソッドは作らないとか
メソッドの頭にはクラス名を付けるのような
コード規約がよく使われている。

たとえば、obj.get_customer や obj.custmer_getだと
grepで関係ないものまで引っかかったりしないでしょ？

>>60
おまえは最新OSもGNUも使うな

Javaが安全すぎる
異論は認めない

やはり、Javaか

ちか、動的言語と動的型付けって意味が違うよね。>>1はバカなの？

×ちか、
○つか、

>>61
あるメソッドがどこで使われてるか実行時にしか分からないのは、
静的言語でもポリモーフィズムとかを使ったら一緒
変数の型付けの問題じゃない

>>67
> あるメソッドがどこで使われてるか実行時にしか分からないのは、
> 静的言語でもポリモーフィズムとかを使ったら一緒

お前が言っている「分からない」ってのは一つに絞れないって意味だろ？

俺がいってるのは、一つに絞りたいということではなく
関係がある物を知りたいってことだよ。

ポリモーフィズムを使った場合、実装された関数だけを知りたいとは限らない。
インターフェースも知りたいし、そのインターフェースを使ってる関数も知りたい。
静的言語ならそれが見つかる。

だから、お前がいってるのは何の問題にもなってないよ。

>69
へー、じゃあ動的言語で何が問題なの？

間違えた
>>68で

検索すればわかるじゃん

>>69
たとえばgetでgrepしたとき
全く無関係のgetまで見つかって、
コードを修正するとき、どれが影響あるものなのか
調べるのに時間がかかる。

>>72
基本的に同意なんだけど、
動的言語でも名前空間使ったりして読む範囲を減らす努力はしてる

>>72
interface型でgetメソッドを宣言していて、
継承関係のない複数のclassがそのinterfaceを実装していたら、
結局同じことになるぜ？

こんなこともわからずに静的型マンセーしてるの？
恥ずかしいねえ

Pythonが静的型になったとか、このスレの静的型厨は頭がおかしいの？

>>74
ならないよ。少なくとも、
「interfaceを実装している複数のクラス」だけを見ればいい
これらはそもそも無関係のクラスではない。

>>73
名前空間使っても参照使われたらアウトだね。

インスタンス変数->メソッド ってなったとき
名前空間は役に立たないものになる。

>>76
「interfaceを実装している複数のクラス」が相互依存してると考えるの？
interfaceってそういうのじゃないぜ

>>78
interfaceに依存してるだろ。

例えばあるクラスのgetをfetchに変えようとしたとき、
静的言語なら、このクラスを変えただけでは駄目だ！
interfaceも変えなければ駄目だ！と分かるし

interfaceを変えただけではでだめだ！
このinterfaceを使っているすべてのクラスでも変えないと駄目だ！
ってわかるだろ？

これでも関係ないって言える？

しかし、そんなことで困る状況って、そんなにあるもんなの？
そもそもがスパゲッティな作りじゃない限り、それで困ることってある？
探すときも、まずクラス名やインターフェース名で探してからメソッド名で
絞り込めばいいわけだし。

>>80
そりゃ、個人で作っていたり
小さいプログラムなら、
時間はかからないだろうさ。

>>77
Pythonだとクラスじゃなく関数使うことも多い

>>79
ユニットテストクラスつくっとけや！

>>83
ユニットテストを作る時間がかかる

できるできないの話をしてるんじゃないんだよ。
時間がかかるかどうかの話。

ユニットテストを使わないでも分かることを
ユニットテストを使ってからじゃないとわからなければ、
それは時間がかかるということ。

ユニットテストを使っていても
結局は「ユニットテストで使っているgetを手動で書き換える」という
作業が増えてるだけなんだけどな。

動的言語の生産性 - テスト書く手間 > 静的言語の生産性

なら動的言語を使えばいいさ

テストも書いたらメンテしなきゃいけないからな。

書かずに同じ効果が得られるのなら
書かないほうがいい。

動的言語の生産性 は
静的言語より劣るよ。

つーか動的言語が生産性高いって
何を根拠にそう思ってるんだろうな。

そんなら、Webサービスも、バッチ処理も、コマンドラインツールも、全部C/C++でつくればいいじゃん。

>>89
だからC/C++は別の問題、文字列が扱いにくいのと
メモリ管理が手間がかかるんで、Javaで作ってるよ。

つーか静的言語だろうが何だろうがテストは書けよ

誰がテストを書かないっていったんだ？
それにテストを書く前に分かる方が優れてるだろ？

>>88
静的言語で総称型使って頑張ってるのを見ると
動的言語は楽なんだなって思う

総称型しかないから総称型で頑張ってるのは
動的言語の方だろう？

>>90
テキストファイルの処理とか、正規表現使ったりとか、置換処理とか、パース処理とか、日付の処理とか、
これ全部Javaでやるの？　面倒くさくない？

Javaがウンコだからといって
静的言語全部がウンコってわけじゃない

>>95
全部普通にできるし。

Perlで一行でできることが、Javaだと普通に10行ぐらいかかるな。

>>97
できる出来ないの話はしてないんじゃね？
だって動的言語でもテスト書けば安全なプログラムは書ける

良スレ

>>98
かからねーよｗ

>>99
だから、テストは実行しなければわからないんだから
そもそもレイヤーが違うもんだってば。

Javaは、Webとモバイルアプリ用途だろ。

動的言語を使うやつって、
どうも「関数を作る」という発想が少ないらしい。

だから毎回同じようなコードを書くやつが多い。

>>76
へー、そのcloneableを実装しているクラスなんて世の中に何個あるかもわからないのに
全てのクラスを見れるんだー(棒読み

>>79
うわー、シロウトだー

>>101
「動的言語で安全なソフトが作れるかどうか」を議論してるんじゃないの？
テストでバグ潰せるならいいじゃん

>>104
お前は何をいってるんだ？

自分が今やってるプロジェクトで
使っているところを知れば十分だろ。

お前はなぜ世の中すべてを見たいという話をしてるのか？

>>105
うわー、反論したいけど、こいつ何も言ってない。うわー

どう読んでも、静的厨のほうがチーム開発経験ないとしか思えんw

関数やメソッドのシグネチャ変える時に、手元のコードの型が辻褄あえばいいって発想からして
多数での分散開発の経験がないとしか言いようがない。

>>106
テストでバグ潰せるならどうでもいいという理屈なら
ユニットテストは不要という結論になるぞ。

完成品をブラウザで動かして全部手動でテストすればいいよな？


バグって言うものは、なるべく早い段階で見つけるものだ。
早い段階で見つかるものほど、修正にかかる手間は少ない。

統合テストよりも単体テストで見つけるほうが修正は楽だし、
単体テストを動かす前に見つかるテスト（構文チェックなど）で
見つけるほうが修正は更に楽。

>>107
じゃあ、おまえが勝手に変更したインターフェースを使っている他のプロジェクトの連中はどうする？
おまえが勝手に変更したクラス参照している他のプロジェクトの連中はどうする？

おまえ、チーム開発やったことないだろ

なんだ、結局、Java厨のLL叩きスレだったか．．．
こいつら、何言っても聞く耳もたねーぞ、
一生オブジェクトを生成し続けてろよw

>>110
だから自動化テストを書くっていってんだよwww
なんで手動でテストすることになってんだ
あと動的言語でも構文チェックはテスト書かなくてもするわい

静的検査で洗える部分なんて、ほんの一部だ。
セマンティックな部分はほとんどノーチェック。
結局は安全はテストに大きく依存していることを自覚しろっての。

>>109
だから手元のコードの方のつじつまだけじゃなくて、
そのコードと関連している部分をすべて見つけなきゃいかんのだよ。
だからinterfaceを使っていると関連コードが全て見つかるじゃないか。

見つけるべきものが見つけられず、
見つからなくていいものが、じゃまをする。
それが動的言語なんだよ。

>>111
> じゃあ、おまえが勝手に変更したインターフェースを使っている他のプロジェクトの連中はどうする？
> おまえが勝手に変更したクラス参照している他のプロジェクトの連中はどうする？

コンパイルエラーが出るからすぐに分かる。

>>113
お前前半部分しか読んでねーだろ？

自動テストを書くよりも前に先にわかるようが、
修正も楽だということだよ。

>>117
とりあえずテストは書くんだよね？
だったら一度テスト書いたら、修正のたびに再度テスト走らせるだけだが？

>>114
ほんの一部だろうが、スペルチェックの間違いのような
簡単なケアミスを、いちいちユニットテストを実行して調べるなんて
時間がかかることをしてられるか。

>>118
テストを走らせるなんて時間がかかるじゃない。
テストを走らせないほうが時間は短いよね。

>>119>>120
でもコンパイラは走らせるんでしょう？

Java厨の言ってることは、わからんでもないが、
生産性を左右するものってそれだけじゃないだろ？
お前んとこでは、メソッド名の変更ばっかりやってんのかよ。

関数名を変えたら、テストコードを実行してバグがあるということがわかるが、
実際はテストコードが間違っているわけで、テストを修正する必要がある。

その時、テストが間違っているのかコードが間違っているのか
調べるのは大変なことだ。だから動的言語ではリファクタリングに時間がかかる。

>>121
スクリプト言語だってインタプリタを走らせるのだから
何の反論にもなってないぞ。

>>122
スペルミスなどのケアミスを甘く見てはいけない。

そんな下らないことで大きなバグを引き起こしたり
修正するのに時間がかかることはよくあること。

Java厨房の仕事が、メソッド名の変更担当だということは分った。

スペルミス等のほとんどのケアレスミスは、動的言語でも構文の厳密化パラメータの使用でチェックできるけどな。

>>123
だから（テスト/コンパイラ/インタプリタ)走らせる手間なんて
安全なソフトを書く上ではどうでも良いって言ってんの
テスト走らせるの面倒って言ってんのJava厨だろ

>>127
面倒なんて言ってねーだろ。
時間がかかるって言ってるんだよ。

>>116
おまえ馬鹿だろw
「コンパイルエラーでるからわかるだろ」で済むかよカス

動的言語で書く時間 + テスト走らせる時間 < 静的言語を書く時間 + コンパイル時間

なら動的言語を使えば良いさ

>>129
馬鹿はお前だ。

コンパイルエラーでわかるのと
全くわからないのと、

この二つを比べて言ったセリフかそれは？

テストケース書くのは時間がかかるとか言ってる奴は、ユニットテストを理解してないだろ。つか、実際使ってないだろ。

>>115
> そのコードと関連している部分をすべて見つけなきゃいかんのだよ。

全て見つけるなんてできるわけねえだろカス
おまえが使ってるインターフェースを使ってるプロジェクトなんて
世界中そこら中にあるんだよ

静的厨ってみんなこんな馬鹿なの？
自分さえコンパイルエラーが出なければ
世界中に迷惑をふりまいても平気なの？

いいんだよ、メソッド名をきままに変えてまわるのが仕事なんだから。

>>113
だから、なんで世界中の話してるの？

作っている側が、使っている側をすべて把握するとか
なんでそんな話になってるの？

Linuxカーネル開発者が、すべてアプリを把握するとか
そういう話をしたいの？

静的言語の方が型情報の補助がある分コードが読みやすい、
ってことなら部分的に同意するが、コンパイルでバグ見つかるってのを
そんなに重要視されてもなぁ……

>>131
ヴァーカ、
だから動的言語では合意を重視しながら
元のセマンティクスを残して拡張するんだよ

メソッド名かえましたー
コンパイラがエラー吐きましたー
だからインターフェース定義を勝手にかえましたー

そうやってオレオレインターフェースつくって安全だとか言ってる時点で
おまえは本当の大規模開発の経験がないことを晒してんだよ

>>132
えとさ、静的言語でもユニットテストってあるんだよ。

ユニットテストがブームになったのはJUnit、すなわち静的言語のJavaじゃん。

その静的言語で
ユニットテストをしなくても分かるのと
ユニットテストを実行しないとわからないのでは
明らかに後者のほうが時間がかかるよね。

実行時間の話じゃないよ。
書いてからミスが発覚するまでの時間だ。

>>135
おまえはオレオレインターフェースしか使わないのか？
JDKで定義されているインターフェースを使わないのか？
おまえはそこまで馬鹿なのか？

>>137
全てに伝えられるわけなんてねえだろカス
おまえが使ってるインターフェースを使ってるプロジェクトなんて
世界中そこら中にあるんだよ

世界中から合意を得ないと変えられないとか
どんだけ不便なんだよ

Java厨が、スペルミスを極端に恐れていることは分った。
何かとんでもないミスをやらかして、トラウマにでもなったんだろうか。

>>138
> ユニットテストがブームになったのはJUnit、すなわち静的言語のJavaじゃん。

JUnit書いたのはケント ベックで、
彼は動的言語Smalltalkのプロで、
静的言語でのテスト環境があまりにアレなんで
業を煮やしてJUnit書いた、

ってのが真相なのだが、知らなかったの?
Unit testが動的言語の習慣が由来だったことも知らずに
JUnit自慢してたの？

動的言語は、インターフェース名を変えるとき
世界中の人から合意をとってるのか？

プロジェクト内での話なら
プロジェクトで合意をとればいいだけの話。

世界中で使われてるライブラリなら、
どうぞ世界中に合意をとってくださいなｗ

つーか、メソッド名を変えるときには
それを使っているところ全て自分の責任で
変えるもんだけどな。

Java厨が、メソッド名の変更に情熱をかけていることは分った。
一体、一日の何時間をメソッド名の変更に費やしているのだろう。

スペルミスは怖いよ
だから動的言語はレキシカルスコープと変数宣言の関係が超重要

>>142
話を勘違いするな。

静的言語でもユニットテストは行われるというだけのことだ。

動的言語が実用に耐えないことはわかった

>>140
やっぱりJava習いたての高校生か。
結局、おまえの言う大規模だの整合性だのは、
手元にあるコードの範囲内の話だ。

不特定多数の開発者が参加するプロジェクトでは
到底通用しないよ。

>>148
その理由は？

>>143
> つーか、メソッド名を変えるときには
> それを使っているところ全て自分の責任で
> 変えるもんだけどな。

つまり君はその程度の規模の開発しか経験ない

ってことだね。よーくわかったよ。

>>150
お前も経験浅そうだなｗ

>>145
そういうのは殆どはテストで刈り取れるんじゃないの

>>149
自分が扱っているコードの範囲内にしか考えが及んでいないから。

>>151
その理由は？(棒読み

名前解決の不整合がコンパイルでわかるのと
全てのフローを通るテストを書かなきゃわからない。
この差が決定的だと思えない奴が動的マンセーってことだな。

テストがあるから変化を恐れないってのが
ブームなくせに

なぜか関数名を変えることを恐れるのは
なぜなんだろう？ｗ

公開されてるインターフェースを変更するのにかかるコストの大部分は
折衝とかのコミュニケーションとかそういう部分であって
静的言語のコンパイルエラー云々なんて誤差
大規模開発ならね

なぜグーグル様はgwtなんて作ったんだろうね

>>157
そんなの、ドキュメントに書いていれば済む話。

少なくとも大規模ライブラリの開発者から
ユーザーの俺にドキュメントに書く以外の方法で
連絡が来たことはない。

Java厨は、コンパイルエラーさえが出なけりゃ、問題無しと思ってそうで怖いな。

動的厨は支離滅裂だな

>>160
アホかｗ

コンパイルエラーが出れば、
「明らかにそこに変化があった」と分かるだろ
それが重要なんだよ。

これも一種のテストだ。

ここのJava厨は、コンパイル通れば、スペルミス防げるとか思ってるみたいだけど、
多分、リフレクションとか使ったことないんだろうなと思う。つか、使ってたら怖いし。

>>159
でも勝手にインターフェース変えられたらムカつくでしょう？
場合によってはライブラリの使用を止めるくらいにさ

静的言語のメリットはあるけど、それはインターフェースを手元で
簡単に変更できるとかそういうことじゃない

どっちが安全かって話と１００％安全かの話にすり替えてる時点で終了

>>163
だから、コンパイルエラーでわからないものは
ユニットテストで捕まえればいいのよ。

要はコードを書いてからバグが発覚するまでの
時間は短いほうがいいってこと。

Java厨は、ほんと、コンパイルエラーさまさまなんだな。

どっちが安全かって話を１００％安全かの話にすり替えてる時点で終了

>>164
お前は勘違いしてる。

静的言語のメリットはインターフェースを簡単に変更することではなく、
インターフェースを変更したときに簡単にそれが検出できるってことだ。

C++最強の結論

そうか、構文チェックも
一種の「テスト」と考えればいいんだね。

型を明記するっていうのは、
こういう型でなければならないというテスト

引数を明記するのは
こういう引数でなければならないというテスト

そうか、これもテストなんだ。

ホワイトボックステストで判明するような不具合は、結局はブラックボックステストで判明するよ。

しねーよ・・・

>>170
宇宙がビッグバンからやり直しても、その結論には達しないなw

実際に運用時に不具合が発覚したとき
それと同じことをブラックボックステストしてれば
見つかったはずでしょ？

運用時に起きたバグが
ブラックボックステストで
見つからないなんてことあるのか？

>>174
これだもん

テストケース漏れだな。

>>175
おまえ責任なくていいな・・・

>>178
なんで話をすり替えるの？

>>159
そのライブラリ、具体的にどれよ？

俺は静的言語でも動的言語でもオプソなライブラリを公開してきたし、
プロプラなライブラリも提供してきた。
もちろん他所のオプソなライブラリやプロプラなライブラリを使ってきた。

今までAPIを変更する時には必ず、
(1) 変更の提案
(2) 時間を区切った議論
(3) 変更の決定
(4) ソースコードおよびドキュメントでのobsolete宣言をコミット
(4) 変更の周知期間(少なくとも次のメジャーバージョンまで)
(5) 旧インターフェース削除
という段階を踏むし、
もちろん他所のライブラリのインターフェースが変更された時も
上記のプロセスを無視するプロジェクトなんて見たことない。

これは静的型だろうが動的型だろうがかわらんし、
コンパイラのエラーだとか、そんなスウィーツな話とはレベルが違う。

さあ、ドキュメントで事後通告するだけの大型ライブラリの名称を晒せ。

>>180
お前が先に名称を晒せよ

難癖だけになった

>>169
簡単に検出できたからって何？
だからインターフェースころころ変えても良いっての？

もし滅多にインターフェース変更しないなら、簡単に検出できるメリットがあっても
そのメリットは開発全体のコストからみたら誤差だ

>>180
そのライブラリの中で使われてる
privateメソッドの変更でさえ、
わざわざそういう手順をとってるのか？

>>171
型のテストなんて、テスト全体から比べて、ほんの極一部だよ。

それに、近頃の動的型言語の開発環境のなかには、
「この変数で叩いてるこれらのメソッドを全て実装したクラスはありませんが、何か？」
みたいな警告をするものもあるぞ。

>>183
検出できて、かえたらいけないと判断したものは勝手に変えるなと伝えればいいだろ。
変わってるのに検出できないことの問題を考えたことがあるのか？

>>184
APIって書いてあるの、読めない？馬鹿？文盲？

どっちが難癖かはっきりした

>>185
極一部なのがなんか関係あるのか？
すべてのメソッド、変数、が極一部だとは思えないが。

>>176
あ、ゴメン。ネタで言ってるのかと思った。

>>186
> 検出できて、かえたらいけないと判断したものは勝手に変えるなと伝えればいいだろ。

だーかーらー、元々APIを変更するってのは、そんなチャチな話じゃないの。まだわかんない？

>>184
privateメソッドの名称変更ならスコープが限定されてるから
変更の影響がどこまで及ぶか分からない、とか無いよ

>>187
だから結局合意が取るのはAPIだけだろ？

内部を複数の人が作るという状況だってあるわけだし、
お前のコミュニケーションというのは、
プロジェクト全体の極一部の話しかしてないわけだよ。

>>192
動的言語はprivateなんて無いものが多いじゃん。

>>189
型に関する部分だけでは、全体のほんの一部だよ。
あんたが書いた通り、構文チェックもテストの一種だ。これは動的型でも行なわれる。
また、実行によるテストも当然、テストの一種だ。これも動的型でも行なわれる。

型だけで判定でき、かつ、型でしか判定できないバグは、全体の一部でしかない。

こんな話ですら合意とれないのが日本の現状

公開されたインターフェースは簡単に変えられない
公開しないインターフェースの名称変更の影響範囲が分からないってなら
それはモジュール化とかそういうのが壊れてる

>>193
もちろん、privateメソッドでも開発メンバー内で議論するよ。当然だろ。

え、やったことないの？あんた、本当に大規模開発の経験あるの？

>>192
なら内部だけで使っているpublicメソッドは？

>>198
さっきと正反対のことを言ってるぞｗ

Java厨が、異常なほどのスペルミス恐怖症だということは分った。

だめだ、静的厨のレベルが低すぎる。誰か、代わってやれ。

>>195
だから、全体の一部だからってなんなの？

>>202
どうぞどうぞ

>>200
はあ？あんたマジで頭おかしいんじゃね？
福島にいってバケツで床の水を汲み出す簡単な仕事やってくれば？

>>198
そして、議論されずに変えたものは
コンパイルエラーで見つかるから
静的言語のほうが安全という流れになるわけですね。

>>203
ほんの一部しかカバーできてない検査で「安全になる」なんて妄想は持たないほうがいい。

>>206
その議論の持っていき方は「Java厨=低能」になるからやめて

>>206
privateなメソッド名を勝手にかえたら、
C0カバレッジが確保されている単体テストで確実に見つかるよ。

そんなことも知らずにJUnitとかわめいてたの？馬鹿？

いや、メソッドごと消えたなら、C0カバレッジすら必要ないだろw

>>207
すべてをカバーできる検査なんて存在しない。

常識じゃん。はぁ全く。呆れるよ。

テストっていうのはね。バグは早く見つけるほうが
修正は早いという考えで、なるべく早く見つかる方法を
使うんだよ。

>>167
実際そうだよ
文法上のバグを取り除けたと言う保証は大きい

>>209
> privateなメソッド名を勝手にかえたら、
> C0カバレッジが確保されている単体テストで確実に見つかるよ。

遅い。

変えた時点で見つからなければ修正に時間がかかる。

まぁ、ある程度の規模のあるWeb開発はJavaかC#でいいよ。
だって、兵隊がこの程度の土方の集団なんだぜ。
そりゃコンパイルエラーの有難味も一層増すってもんだろうぜ。

大規模開発で起こりうる問題に根差す一番の原因はスペルミスとか
じゃないんだけどな。でもま、土方の集団にとっては、コンパイルエラー
の助けが、地獄を照らす希望の光に見えるのもわからなくもない。

どんだけメソッド名変更したいんだよJava厨はwww

単体テストもねぇ。
たしかにテストに失敗しましたって画面に表示されるんだけど、

いざそのテストを修正しようと思ったら、
コードを見て調べないといけないわけで。

たくさんの単体テストコードを書いていれば
たくさん失敗しましたってでるわけで。

たくさんの失敗の中から根本的な問題を捜す時間がかかるのを考えると
コンパイル時にわかるなら、そっちの方が、時間がかからずに済むんだよ。

単体テストフェーズ以前で検出できるようなものを
単体テストフェーズまで持っていけるってのがおかしい。

>>214
一番の原因じゃなければ、無視してもいいのか？

しかし、どんだけスペルミス恐怖症なんだよ、Java厨はw

え？スペルミスしないの？
スペルミスをわざわざユニットテスト実行して直してるの？

スペルミスを検出するのに
ユニットテストを実行するのは
すごくめんどくさいんだが、

プログラマの美徳「怠慢」を備えてないんじゃない？ｗ

実際すべての分岐を通るテストかいてるの？

パブリックなメソッドの名前を変更するなら、それに依存するクラスへ影響があるから、
関係者へも通知が必要だろうし、設計書への反映も必要だし、修正後の動作確認も
いるだろうから、動的言語だろうが、静的言語だろうが、手間はあまり変わらなくね？
コンパイルが通ったから、万事おっけーって訳にいもいかないだろ。
他のモジュールからクラスを動的にロードしたりとか、継承元とメソッド名がかぶって
しまって意図せずオーバーライドしてたなんて可能性もあるわけだから。

プライベートなメソッドなら、局所的なものだから、自分の判断で直してもいいかもしれ
ないけど、それは影響範囲が限られたものだから、動的言語で、ソース検索して探し
ても、そんなに手間がかかるもんじゃないだろ。

「変化を抱擁せよ」って言葉が懐かしい。
結局は関数名一つ変えるのに
まだこんなに恐れているんだな。

>>221
> パブリックなメソッドの名前を変更するなら、それに依存するクラスへ影響があるから、

その依存するクラスを見つけるのが簡単なのが
静的言語なんだよ。

依存するクラスはどれだー！って探さなきゃならないのは
いやだよね。だから変化するのが怖いってなっちゃう。

静的がjava,C++を指してることはわかるが動的か何を指してるか不明

>>214
コンパイルエラーは、希望の光と言うより、一里塚だな
文法上のバグは無い事が保証されたから、ロジック上のバグか、ライブラリのバグかに絞られる

スペルミス心配してる人が居るみたいだけど、ここでは、文法のスペルミスは文法上のバグに
変数名やクラス名のスペルミスはロジック上のバグになる

>>223
検索すればすぐわかるじゃん。
最近は、ソースからクラス図を吐いてくれるツールとかもある。
そんなに時間かかんないよ。

>>226
あぁ、静的言語じゃないと
使い物にならないあれねｗ

ま、最近のIDEとか、エディタはかしこいから、変数や関数のスペルミスなんかは、
間違ったそばから、色付けて教えてくれるけどね。

　なにこのスレw　低レベル杉、ワロタw

動的言語とIDEの相性がわるいのは
やっぱり静的言語にある情報が抜けてるからだろうな。

JavaとEclipseの相性は最高。
リファクタリングの機能を知らない人は
使ってみたほうが良い。

でここでの使える動的言語はなにさしてるの？

>>229
立場を明示せよ

実際、IDEと静的言語の相性は良い

つまり、Objective-CとXCodeの組み合わせが最高ということか。

ようやくIDEで一段階進んだ。

大規模開発に向いてる動的言語教えて

動的言語でIDEが流行らないのは色付けぐらいしか、
コード書いているときにやれることがないからなんだろうな。

コード書いているときにバックグラウンドで
今書いているコードのユニットテストを常に
走らせ続けているなんてIDEぐらいなら
作れると思うんだが。

>>236
Common Lisp

Objective-C　まじお勧め。　静的言語と動的言語のよいとこどりだぜ。
まぁ、Web開発にはオヌヌメしないが。

要らないとこ取りの間違いないだろｗ

>>237
>今書いているコードのユニットテストを常に
>走らせ続けているなんてIDEぐらいなら

そんなウザったい機能いらねーよ！

>>223
だから、人様に使ってもらえるようなコードは書かない
カスPGだって自己紹介はもういいよ

>>241
なぜウザったいと思うんだ？

決して具体的な言語名を挙げない動的言語派

>>242
ようカスPGｗ

結局人を罵倒するだけしかできなくなったなｗ

>>243
コード書いてる途中のテストに何の意味があるんだよw
そんなこともわかんねーのかよw

>>245
>>221を読んで、それでもまだコンパイルチェックで
減らせる手間が全体の手間と比べて誤差だって分からないなら
ちょっと頭が残念すぎるだろ

>>247
誤差って言い切るお前の頭が残念すぎる

勘違いしないで
ここで暴れてるのはJava厨だよ
決して静的型付け言語ユーザが皆こんなアホだと思わないでね

ここのJava厨は、クロージャとか使ったこともなさそうだな。
つか、クロージャの用途とか便利さとかも分らないだろ。
クロージャこそ、動的言語の特徴のひとつといってもいいだろう。
最近のJavaでも使えるんだが、毎日、毎日、スペルミスの修正
にやっきになってるお前らに使えるわけもなく。

>>246
そうだね。
それこそ、ユニットテストと
文法テストの大きな違いじゃね？

ユニットテストは文法テストに比べれば
あとの段階にならないとテストとしての意味を持たない。

逆に言えば文法テストはユニットテストよりも先にわかる
早いテストは修正も早い。

根本的にテストの種類が違っているわけで
ユニットテストで一緒に文法テストの代わりをしようっていうのは
ビッグバンテストでユニットテストの代わりをしようというのと同じこと

すごく間抜けな考え。

>>250
最近のJavaでも使えるので
クロージャは動的言語の特徴ではありませんよ

クロージャが便利だと思ったことない。
Javascriptでクラスのメンバ変数隠蔽のために使ってるけど
素直にクラスが欲しい。

てかhtml組み込みでJavaとJavascript両方使えるならJavaだよね？
この条件でJavaより便利な動的言語ってなにが考えられるの？

>>250
haskellは。。。

JavaScriptの良さがわかってない時点で、Java厨はダメだ
Prototype型とクラス型の違いとか、ホントにわかってんのか？

ああ真性なのね・・・

CoffeeScript最強
Javaはウンコ

文法テストなんて、テストがあるとは始めて知った。
Java土方の世界では、当たり前の用語なのか？

>>259
つまらないから黙ってて

すげー盛り上がってるなｗ

文法テストは、プログラマ向けじゃなくて、コーダー向けじゃないかな。

文法テストがない言語では文法ミスが
ロジックエラーにまで悪化してしまう。

おれはタイプミスしないプログラマーです！
・・・レベル低っ・・・

タイプミスぐらい誰でもするだろ。

えーと、動的型付け言語でも構文チェックは行われるけど
Java厨のいう文法テストってのはそれとは違うの？

動的言語野郎が嫌ってるのは静的言語じゃなくてC++とJavaなんじゃないか？

静的言語のC#(3.0以上)、scala、Haskellは素晴らしいぞ

実用的な動的言語の例が一向に上がらないんだが

関数型は黙ってて

>>266
構文チェックと識別子のチェックは別だろ？
そんなこともわかんねーの？

>>267
嫌ってないよ
公開インターフェースを簡単に変更するとか
アホなことばかり言ってるので突っ込んでる
静的言語使いがアホに見えるので止めていただきたい

>>266
構文チェックというよりか、
このクラスはこのメソッドを持っている。
このメソッド以外は持ってない。

この変数にはこの型と互換性があるものだけ入る。
それ以外は入らないというテストだな。


もしユニットテストとして書くなら
ASSERT(instanceof 変数 is MyClass)
を書いているようなもんだよ。

で実用的な動的言語って具体的に何？

>>269
クロージャとかの本家がコンパイラが多いから都合が悪いんじゃろか。。。

>>271
> 公開インターフェースを簡単に変更するとか

誰もそんな事言ってないと思うが？

言ってるのは、interface型を変更するって話だろ。
抽象クラス、クラス、インターフェースのインターフェースだよ。

private/public関係なく、オープンソースかどうか
ライブラリかどうかも関係ない話。

もしかして今まで勘違いして書き込んでたの？

静的言語は関数型の力を取り込んで年々強力になっていく
一方、動的言語は10年前からほとんど変わっていない
(ライブラリは色々と良い物が出てきたが、言語仕様に大きな進歩は無い)

静的言語と動的言語、どうして差がついたのか…慢心、環境の違い

動的言語って実際何を指してるの？

>>275
都合が悪くなったら言ってなかったことにするとかwww
>>159とか何なんだよ
アホすぎる

>>276
やっとLispに追いついてきただけ

で動的言語って実際何を指してるの？

>>280
lispじゃね？

>>278
いや、公開インターフェースと言い出したのはお前だろ？
今まで付き合ってやっていたが、通りは話がずれていると思った。

え？Lispなの？

Objective-C も動的型付け言語だけど、何か問題があるんだっけ?

>>282
付き合ってやってただけwww
なら最初から違うって言ってれば良かったのに
分が悪くなってから言い出すとかw
やっぱJava厨はアホだな

静的がJava,C++なのはいいと思うけど(原理主義者はJavaもだめだろうが)
動的はなにを念頭においてるのかわからないとそもそも議論にならないだろ

コンパイラチェックの恩恵がうけられないから、動的言語は嫌だと
敬遠しているようなプログラマは、まだまだひょっこだよ。

>>284
話にならない

静的言語の代表がJava,C++とか止めてよね

Objective-Cは最強だな。もう言語は、Objective-Cだけでいいと思う。

>>287
曲芸プログラムに興味はない

>>288
話出来ないなら別に良いけど・・

>>289
そういう時は代案言ってね

>>292
smalltalk由来のオブジェクト指向なのに問題点もわからない時点で終了

>>287
敬遠してないけど、大規模開発に動的言語は嫌だな
デバッグで最後の最後まで文法上のバグを捨てきれないとか嫌すぎる
デバッグが大変になるほど、切り分けは重要だもんよ

>>293
>>267

しかし、こいつらスペルミスがそんなに怖いのかね。
ちょっと異常すぎないか..

>>294
君が終了する分には何も困らんけど?

>>296
なんだつまらん

>>297
一人なら良いんだよ
大人数になるとスペルミスも笑えない

Smalltalkが普及しましたか？
Objective-Cがなぜ他の処理系に普及しないのか考えたこともないんだな

あぁ、そうか土方の集団が相手なんだったな。

Smalltalkと関数型は同じにおいがする

>>301
答えが見つかったら教えてくれ

>>304
使いたいと思わないから以外にあるの？

>>300
それは「動的言語では安全なソフトは作れない」が真になるほど
問題だと思うの？
そうじゃなければスレ違いの話をしていることになるよ

>>305
ホラ、もっとよく考えて良いんだぜ

Java厨はJavaマンセーの持論を展開したいだけで
スレタイとかどうでもいいのかも

JavaはGNUがさっさと作って普及したのにね
SmalltalkやObjective-Cがそのレベルで使われてるとでもいうつもりなのかな

>>302
あながち間違っても無い
大規模って事は、レベルも色んな人が関わるから

それでも動的言語使いますか？と聞かれたら、答えは絶対に、ノー

>>309
>JavaはGNUがさっさと作って普及したのにね

どういう意味か、誰か解説キボンヌ

集団開発はJavaでしょうがないかなと思うけど、個人でやるにはJavaは嫌だな。
何が嫌かって、まず開発環境と実行環境を整えるのが面倒臭すぎる。

動的言語のメリット語るときは具体的な言語も添えてください。
現在、Lisp、Smalltalk、Objective-C。

>>313
Common Lisp

普及してる言語じゃないじゃんｗ

>>313
JavaScript（ついでにCoffeeScript）も出てたよ

>>313
主要なLLは含めていいよ。
Perl, Ruby, Python, PHP

>>315
Dylan

>>313
PythonとPerlも出てたよ

>>313
Lua

え、Perl, Ruby, Python, PHP,JavaScriptが大規模開発で使えるって話してたの？

>>321
Io

Pythonは、プロトタイプがちゃっちゃっと作れるのがいいな。

キチガイだろｗ

>>313
Scheme

>>321
そりゃプログラマ次第だろ
少なくとも勝手にメソッド名変更したりする馬鹿が居れば
どんな言語使ってても大規模開発は困難だわ

>>285
じゃあ、今から違うという前提で話をしよう。
それだけの話だ。

結局動的言語はプロトタイピング専用言語ってことでいい？

JavaScript もプロトタイプを作るのに最適

言語名が出てきたとたんに終戦ムードｗ

自分の作りたい物をサクッと実装出来るのが良いね
後はテストケースを増やしながら熟成

Java厨の想定は、大勢の土方でWeb開発をしているという想定だから。
それに沿って話をしてあげて。　コンパイルエラーのメッセージが何より
もありがたい人達の集まりだから。

>>297
> しかし、こいつらスペルミスがそんなに怖いのかね。

ロジックエラーが怖いといえばいいのか？

動的言語に置いてスペルミスは
ロジックエラーになるんだよ。
スペルミスしていたとしても動くからね。

大きくなったらJavaかC++で書き直すだろ普通

安全なソフトが作れるか否かが論点だろ？

動的言語派はテストをちゃんと書けば作れると主張しているが、
静的言語派はテストは面倒としか言ってないので、動的言語派の主張を否定できてない

>>334
速度が必要な所だけね

>>335
＞静的言語派はテストは面倒としか言ってない
要らないテストコードを書く手間が省けるな

俺の最近の流行りは、Drupal(PHP製のCMSね)でWeb開発。
これ最強。　たぶん生産効率はJavaの5倍〜10倍ぐらい。

バインディングとか面倒だしロジック整理できるし動的のまま残す理由がない

>>338
こういうこと想定してるのとJava/C++派の想定しているものは前提が違いすぎる。

スペルミスが見つけられるということは
このクラスがどんなメソッドを持っているのが分かるということを意味する。
このクラスが持っているメソッドが分かるということは
適切なドキュメントを素早く表示できる。

大規模プロジェクトでpublic/private関係なくすべての関数を
把握出るわけがないんだから、素早くドキュメントを見れる仕組みは必要。

このようにたかがスペルミスだと思うかもしれないが、
その技術の応用は計り知れず、それが積み重なって
生産性の向上につながる

>>339
沢山のサイトが普通に PHP のままリリースされてるじゃん

>>342
だってレンタルサーバーでJava動かないんだから
仕方ないじゃない。

>>343
みんなはそれで納得していると言う事

>>306
個人的には思う

みんなが諦めているの間違いだろｗ

てかレンタルサーバーってｗ
小規模すぎ。

>>342
PHPが必要とされてるドメインとJava派が言ってる大規模開発は異なる

しかし、メソッド名を変えたくなることって、そんなにあることなの？

>>341
静的型付けじゃなくても、インターフェイスの定義をコンパイラが参照出来れば良いだけでしょ
Objective-C みたいに

>>341
動的言語でも全てのスペルミスが見つからないわけじゃないし
静的言語でも全てのスペルミスが見つかるわけじゃない

Scala等ならともかく、Javaなんて生産性高くないだろ

>>347
Facebook は PHP じゃなかったっけ?

高速化の為に PHP to C++ のトランスレータがあるらしいけど・・

>>348
Java厨はメソッド名を変えて廻るのがお仕事です

PHPってシステムの中の定型的なカスタマイズ部分用だろ。
最近はネットワーク上のマッシュアップ的なシステムも主流だから
動的言語の役割もわかる。
OS見たいな単一的なシステムはC/C++みたいな静的な言語になるでしょう。

>>347
PHPでいう大規模ってのは
個人・小規模開発者が自分でサーバーに入れて使う
そういう人が”たくさんいる”という意味での大規模で

Javaの場合の大規模ってのは、一つのシステムを
たくさんの人で作る、開発費も膨大でそれを
支払ってくれる大会社が顧客としている
という意味の大規模だよな

＞Scala等ならともかく
こいつ絶対大規模開発やったことない

Java開発って、結局Web開発でしょ？　大規模とはいえ、ただ画面が多いだけじゃん。
どうせ、ちゃんとクラス設計とかしてないでしょ？　マンパワーでごり押しでしょ？
ユースケースからロバネスト分析やったりとか、シーケンス図書いたりとかしてないでしょ？
そりゃ、コンパイラのエラーメッセージに藁をもすがる思いになるのもなんとなくわかるわ。

>>355
大規模開発経験者は簡単にメソッド名変えるんですよね？www

>>356
画面程度ならPHPだろ・・・

>>356
お前が思っていることを並べただけじゃ
何の意味もない

テストが面倒とか言ってるアホが大規模開発してるわけないじゃん

>>356
>ロバネスト分析

robustness?

>>357
簡単には変えないぞ？

ちゃんと影響箇所を調べて関係者を洗い出してから
変えるメリットとデメリットを考慮する。

その影響箇所を調べる手間が
かからないのが静的言語なわけ。

お前が言ってるほど単純な話じゃないんだよ。
ここらへん、実践経験がものをいうよね。

あ、ロバストネスだった。恥ずかしいorz...

１００万行レベルのコンシューマーゲーム開発者としては静的言語一択というかC/C++

>>313
Erlang

っていうか、文法チェックも一種のテストだって
わからんものかね。

「この変数はこの型である」
ユニットテストみたいだろ？

いやー、静的言語の方が大規模開発に向いてると思うけど、
このスレにいるJava厨が面子にいたら地獄だわ

ニコニコ動画は大規模になる？

ユーザーが大規模なのと
システムが大規模なのは
話が違う。

>>368
Java派はノー
動的言語はイエス
ということみたい

>>364だけどドメインによるよね
ネットゲー開発やったらここの動的言語派のいいたいこともわかるようになってきた
でも関数型はわからん。

このリストには文字列と文字と数字と配列が入りますよー

みたいなのは動的言語＋テストじゃないと面倒いよな・・

じゃそろそろ結論

大規模開発には、土方も大勢いるから、静的型チェックやスペルミスのチェックをコンパイル時にしてくれる、静的言語が望ましい。
それ以下の規模の開発で、スキルの高い人達が開発する場合は、動的言語の方がむしろ生産効率が高い。

で、おk？

俺くらいになるとstd::stringも排除する

>>356
静的言語と動的言語は重要視してるモノが違うだけでしょ
システムの信頼性重視なら静的言語
多少運用中に問題が出ても構わないシステムは開発効率の高い動的言語

静的言語で作ったシステムでも運用中に問題が出るのも有るだろうけど、その時の損失は動的言語のそれとは訳が違う

>>362
実務経験豊富だと、メソッド名変えたときにコンパイルエラーが出るのが
静的言語のメリットとか言っちゃうの？www

こんなの３年も前に結論でてるだろｗ

http://www.infoq.com/jp/news/2008/03/liftweb
> しかし、私は気が付いてしまいました。Ruby の動的型付けは多くのエラーを引きおこ
> すことに。そして、安心してデプロイするためには 95% ものテストカバレッジを達成
> しなければいけないことに。95% のテストカバレッジを得ることの代償として、私の
> 書いたコードは(テストコードも含めて) Java で書いたものと同等のサイズにまでふ
> くれあがってしまいました。その上、Rails では動的なコードの変更が可能なため、
> 開発・テスト・デプロイ中にトラブルが続出するようになりました。高いテストカバ
> レッジを確保しているにも関わらずです。これらの問題にくわえて、MRI(Matz Ruby
> Implementation: まつもとゆきひろ氏による Rubyの実装)は速度が遅く、言語仕様も
> 安定していません。それなのに開発コミュニティはそのことに見向きもしません。

>>377
真性からかってたのに何してくれるんだ

Mixiって Perlじゃなかったっけ？　LivedoorのいろんなサービスもPerlだったような。
Ruby on Rails　製のWebサービスもいっぱああるよね。 Twitter って最初RoRだった？
GreeはPHPだったよね。

大規模システムでも、ハードで負荷分散すれは、動的言語でも十分でしょ。
最近じゃクラウドでリソースをどんどん追加できるし。

動的言語が大規模に向かないってことは全然ないと思う。

>>367
実際、javaしか使えない奴と一緒になると地獄を見る可能性大だったりするから困る

>>377
Rubyは動的言語でも極めつけに大規模開発に向かないと思う

>>379
問題領域が違うんだって

>>381
具体的なちがいに言及できないの？

>>383
遅く、言語仕様が安定していなく（これは改善されつつある）、
オープンクラスとか活用するのが普通だから

Javaは、マンパワー重視。いけいけどんどん。体育会系言語。
ただしミスは断じて許さねぇ。

LLは、効率重視。気軽にいきましょ。文系言語。
ミスしてもすぐにやり直せるよぉ。

って感じ？

>>372

> このリストには文字列と文字と数字と配列が入りますよー
>
> みたいなのは動的言語＋テストじゃないと面倒いよな・・

そんなリストをあちこちで使うたびに、同じテストを書いていたら効率が悪い。
やるとしたら、文字列と文字と数字と配列が入るクラスを作って
このクラスのユニットテストを行う。

あとはこのクラス専用のリストを作ればいい。（JavaならGenericsでもいい）

そうすればユニットテストは一箇所だけでよくなる。
このリストをどこで使おうがあとはコンパイラがチェックしてくれる。

>>379
大規模の意味が違う
基幹業務とか、宇宙開発とか、予算の規模の事だボケ

Pythonは、NASAで使われてるけどね。

>>384
まったく的外れ

使われてるっていうだけなら、どんな言語だってNASAで使われてるだろうさ。

>>389
>>383

CでさえDJBにかかれば安全なプログラムが書ける
動的言語で書けないなんて甘え

数学科は関数型
物理学科はOOPL
おれはOOPL

ただひとつ言えることは、

Javaの開発は楽しくない （・∀・）　

ということ。

>>394
めちゃ楽しいじゃん

このスレにいるJava厨みたいなのと一緒に仕事とか
どう考えても楽しくない

昔はJavaなんてVM上で動くおもちゃじゃんなんて思ったもんだな

土方相手が楽しいとか、マゾだろ

>>386
> そんなリストをあちこちで使うたびに、同じテストを書いていたら効率が悪い。
> やるとしたら、文字列と文字と数字と配列が入るクラスを作って
> このクラスのユニットテストを行う。

静的言語だと、そのユニットテストすら不要になるとおもう。

このクラスのsetterとして
文字列のsetter、文字のsetter、数字のsetter、配列のsetter
を用意すればいい。

そうすればこのクラスは、文字列と文字と数字と配列だけが入るということを
保証するテストと同等の信頼性と言うことができる。

>>386
静的型付け言語で複数の型が入るリストのクラスを作るの面倒でしょ
動的型付け言語なら組み込みのリストを使うだけ

土方にすら相手にされないのにｗ

そういえば、エンタメ系のWebサービスで、Javaで作りましたっての聞いたことないな。

>>400
std::stringすら排除する俺には理解できない

>>399
>そのユニットテストすら不要になるとおもう。

医者で言ったらブラックジャック級のプログラマが揃っていて
そのクラスの実装に絶対にバグが出ないならね

>>399
お前、ユニットテストのこと理解してないだろ？

>>400
> 静的型付け言語で複数の型が入るリストのクラスを作るの面倒でしょ
> 動的型付け言語なら組み込みのリストを使うだけ

組み込みのリストは、指定された複数の型 ”以外”も入るから
使うだけって事にはならないだろ。

動的型付け言語でも、そんな手抜き実装でいいなら
JavaならObject型を使うだけだって。

それが危険だから「文字列と文字と数字と配列が入る」という
制約をつけたいわけ。

>>406
その危険はテストで刈り取れば良いじゃん

>>404
>>405
リストの実装なら、特定の型用のListをGenericsで生成して使えばいいじゃん。

ここで作る必要があるのは「特定の型だけ入れられるクラス」だよ。
Javaならね。

>>407
うん。だからテストを書かないといけないわけでしょ？

>>407
>>377

>>408
特定の型が入るリストじゃなくて
複数の型が同時に入るリストの話だよ?

大規模開発ならなおさらテストも書くだろ

ここの動的言語派が必要なテストを書いてるとはとても思えないわけだが

>>409
こっちで一緒にテスト書こうぜ

しかし、そんなに広範囲に渡って影響を及ぼすようなスペルミスを
Java厨の人たちってそんなにしょっちゅうやらかしていまうものなの？

>>415
わかってないなら黙ってて

>>410
だからRubyを動的言語の代表にするなよ

>>411
違うよ。

> このリストには文字列と文字と数字と配列が入りますよー

って書いてあるだろ。例えば日付型は入らない。

だから作る必要があるのは、文字列と文字と数字と配列の
setterを持った新しいクラスだけ。
あとはこの新しいクラス用のListを使えばいい。

>>413
Java厨と一緒にすんなよ

>>417
じゃあどの動的言語ならこの問題が起こらないかいってみ？

>>419
暇なんだね

>>418
そんな面倒な事しないで、こっち来て一緒にテスト書こうぜ

今の時間に忙しい人は仕事してんの？

>>400
> 動的型付け言語なら組み込みのリストを使うだけ
その程度ならobject型のリストを使えばいいだけ

型安全な共用体と相称型をサポートしている言語なら、
特定の複数の型以外でコンパイルエラーになるリストだって作れる

>>420
PythonとObjective-Cでは問題になったことが無いな

>>422
その甘い言葉に誘われた人の末路


> しかし、私は気が付いてしまいました。Ruby の動的型付けは多くのエラーを引きおこ
> すことに。そして、安心してデプロイするためには 95% ものテストカバレッジを達成
> しなければいけないことに。95% のテストカバレッジを得ることの代償として、私の
> 書いたコードは(テストコードも含めて) Java で書いたものと同等のサイズにまでふ
> くれあがってしまいました。その上、Rails では動的なコードの変更が可能なため、
> 開発・テスト・デプロイ中にトラブルが続出するようになりました。高いテストカバ
> レッジを確保しているにも関わらずです。これらの問題にくわえて、MRI(Matz Ruby
> Implementation: まつもとゆきひろ氏による Rubyの実装)は速度が遅く、言語仕様も
> 安定していません。それなのに開発コミュニティはそのことに見向きもしません。

>>425
>>377が理解できてないと判明

なんでJava厨はテスト書くの嫌がんの？
テスト書いたら死ぬの？

>>424
そんな面倒な物をわざわざ実装しないで、こっちに来てテストの続きを書こうぜ

>>411
だったら、要素がTupleのリストを使えばいいだけだろ

しかし、Javaの開発現場で、ユニットテストのクラス書いてるとこってあるのか？
未だかつてみたことも聞いたこともないんだが。
未だに昔ながらの、テスト仕様書かいて、マンパワーでひたすら人力テストというパターンでしょ。

>>428
お前がうそつきだから。
静的言語レベルで保証してくれる安全性を全部手書きのテストかいてる奴見たことない。

>>430
それ分かりにくくない?

>>428
え？ コストがかかるからに決まってるじゃん。
テストはなんでも書けばいいってもんじゃない。
効率良く書かなければ時間は無限にかかる。

遊びでやってるんじゃないよ。

>>400
代数データ型やdiscriminated unionのようなキーワードでぐぐるとよい
以下はF#の例
type Foo =
　| Int of int
　| Char of char
　| String of str

let xs = [ Int 1; Char 'c'; String "xyz ] # Fooのリスト

関数型言語では、このような型をパターンマッチとともに用いる
パターン漏れに対してはコンパイラが警告を出してくれるので
isinstanceのようなもので泥臭く分岐するより楽な上に安全

>>427
Rubyは(RORは)ものすごく動的だけど、
Pythonとかはそこまで動的なコード変更なんてしないからね
変数に型が無いからって何でも一緒にすんなよ

>>436
そこまでって問題じゃないんだが・・・

>>437
高いテストカバレッジを保っててもエラーがでちゃうのは、
まさに「そこまで」って問題なんだが・・・

>>438
＞そこまで動的なコード変更なんてしないから
動的言語のメリット否定してるのに気づかないの？

だから繰り返し言ってるじゃん
静的言語の方が大規模開発に向いてるけど、
Java厨と一緒なら地獄だって

>>435
ああ、そういうのは良いね
欲を言えば、そのシグネチャみたいなのを書かないで済むともっと良いんだけど・・

>>439
必要なとこだけ使えばいいじゃん
静的言語でも、動的な変更がしたければクロージャとか使うだろ
どっちかでしか安全に開発できないとかアホすぎ

>>442
どうやって動的言語で必要なとこだけ、
静的言語特有のことをやれっていうんだよｗ

静的言語で動的言語っぽいことならできるけどさ。

1.要求分析

2.ユースケース書く（できれば客も交えて）

3.ユーザレビュー

3.クラス図書く

4.シーケンス図書く

5.場合よっちゃ、コラボレーション図やステート図書く

6.暫く2〜5を行ったり来たり

7.ユニットテストクラス書く

8.テストエラーがなくなるまで、ひたすら実装

9.ユースケースに照らしながら、結合テスト、総合テスト

10.受入テスト、納品

11.ボーナスもらって長期休暇

>>433
どうせドキュメントに面倒な事を書くんだろ？
だったら、コードにしてコンパイラにチェックさせた方がいい

そもそも、　>>372 の説明では
tupleを使うべき場面なのかunionを使うべきなのかすら曖昧なので
ドキュメントを作ったところで役に立たない

静的言語で書けば、屑ドキュメントなんかよりよっぽどわかりやすい説明になる

>>443
静的言語特有のことをやるなんて書いてないよ？
「動的なコード変更」を必要なだけやるって書いたの？
おわかり？

>>446
大規模開発はお前が思う「おばかな」開発者とともにやるんだけどな

>>445
だから静的言語の方が向いてるのは皆認めてる
ただJava厨と一緒に仕事したくないだけで

>>466
必要なときだけやるのなら、
必要なときだけやれる言語の方がいいじゃんｗ

>>445
ああ、そういうのはいいや

>>448
いやこのスレ真性がいるぞ

なぜ必要なときだけ動的なコード変更を使って、
そうでないときは動的なコード変更を使わないのかというと
やっぱり、危険だからなんだろうな。

急に止まったw

>>373
生産効率の話に変わったのか？ｗ

だってもう投了レベルじゃん

静的言語を見直した動的言語派がF#でもインストールしてるんじゃねーの？

じゃあ関数型の是非でもやる？
純粋関数型は実用性ない。

じゃあ、動的言語側の圧勝ということで、今日の所はひとまずお開きにしますか。

新喜劇かよｗ

>>458
さすが勝利宣言だけはしとかないと気が済まないんだなｗｗ

動的言語のほうが開発効率がいいと
勘違いされたことの方が興味があるな。

>>453
急に止まったのは、
暴れてるのが一人しかいなかったってことじゃね？

明日朝から仕事だからじゃないの

動的な関数型か、静的なオブジェクト指向が良い
HaskellとRubyは駄目だ

>>461
むしろこのスレタイから開発効率の話をしてると
勘違いしてる馬鹿が多い方が驚き

つーか、開発効率の話したら
圧倒的に静的言語のほうがいいでしょ。

>>1-466
ケースバイケース

>>466
ちょっとしたプロトタイプとかスクリプトなら動的言語がいい
規模が大きくなったら静的言語のが楽

動的言語のメリットが感じられない。
インタプリタやブラウザ組み込み言語のメリットはわかるけど。

>>469
巷に喧伝されているメリットで納得出来ないなら、君にはメリットが無いって事じゃないの
簡単な話

動的言語のメリットなんて
みんな眉唾ものじゃないか。

>>471
>>470

>>470
動的言語のメリットなんて
みんな眉唾ものじゃないか。

ちなみに巷に喧伝されているメリットってなに？

>>474
ググリんしゃい

世の中には動的型付けの恩恵に預かれる人もいれば、そうじゃない人もいるんだな

知らないのかｗ

お前が考える「巷に喧伝されているメリット」を聞きたいんだが

スレ立てるまでもない質問はここで 111匹目
http://hibari.2ch.net/test/read.cgi/tech/1302963535/

決して答えることはなかったｗ

PerlとかRuby、Pythonの一番のメリットはお手軽ってところでしょ。
思い立ったときに、ちゃっちゃっとコーディングして試せる。

いちいちクソ重いEclipse立ち上げて、フロジェクトつくってとかしなくても
すぐにできる。ちゃっちゃっとできる。

Pythonとか、Rubyは、標準で対話型のインタプリタがついてるから、トライ&エラー
ですぐに試せる。すぐに。あれ、構文これでいいんだっけ？って時もちゃっと試せる。
外部ライブラリもお手軽に使えて、PythonのBeautifulSoupとか、便利すぎて涙が
出てくる。

Perlは、コマンドラインオプションの機能が強力だから、ちょっとしたテキスト加工とか、
サイトのコンテンツを取得して加工とか解析とか、エディタを開くまでもなくできたりする。

ワンライナーで、ほんと、Javaなら何行も書かないとできないようなこともパッと試せる。

このお手軽さは、コンパイル言語にはない気楽さであり、楽しさでもある。

ライブラリのインストールも超お手軽。PerlならCPAN、RubyならGems、PythonならPyPI
しゅっと入れて、しゅっと試せる。ちょーお手軽。

とにかく、思い立った時に、しゅっと書けて、しゅっと試せるのが便利。なれたら、脊髄反射
で、手が勝手に動いてる。

Javaだとこうわいかない。さぁコーディングするぞという心構えが必要。ちょっと汗かく。

それってコマンドラインツールってだけでは？
ライブラリインストール以外はJDKなら差がない。
構文のチェックはコンパイラのほうが優しいし。
ワンライナーはそうだろうね。
そういうメリットは大規模になるとなくなる。
ちなみにワンライナー以上のプロトタイプならブラウザでJavascriptのほうが楽しい。
この話は動的とは直接関係ないな。

動的言語と性的言語の違いがわかんないんです(´・ω・｀)

>>481
ワンライナーにユニットテスト書くかい？

ユニットテストが必要となるようなものは
もとから気軽に作っていいものじゃない。

今話しているのはそういう大規模なアプリだ。

>>481
動的言語だから気楽にできるというのではなく
気楽に作っていい程度の物は動的言語でいいってだけの話。

ソフトウェアを作るときは言語を先に決めるもんじゃない。

Java厨ってなんでこんなに必死なの？
何やるにもJavaじゃないと気が済まないの？
Javaしか知らないんじゃないかしらと勘ぐってしまうわ。

大規模は静的じゃないと実質無理って言ってるのになんでJavaを眼の敵にするんだろうね

動的言語と静的言語が合体したものとか、中間のものはないの？

JavaScriptはPrototype型のOOPだから、Javaプロジェクトの
プロトタイプ作りとしてはあまり約にたたないわな。

ActionScript3.0とかそんな感じ。
おれはもっと動的な機能削除して欲しいけど。

>>489
クラス型風にかけるよ。プロトタイピングなら十分。
そのまま最後まで書こうとは思わないけど。

>>487
大規模開発ってのを、土方率いて開発しろって意味だというなら
まったくもってその通りだわ。

>>492
土方と書けば自分が優位に立った気分なんだろうけど
実際おまえも土方レベルだよ。そしてお前のレスは正しい。

なんだ、クソつまらん業務系アプリ限定の話だったのかよ。
そりゃJava土方の独壇場だもんな。技術的優位性という意味ではなくて。

>>494
じゃあ、お前にとってつまらなくないアプリは何だ？

>>488
Java。

つーか最近の静的言語は
動的言語の機能を取り入れてるんだよ。

ケンカはやめて（＞＜）

わざわざJavaScriptとか使ってプロトタイプ作るなよw
設計レベルのレビューなら、PlantUMLで十分だろ。ちゃっちゃっとできるよ。

業務用アプリ以外で大規模アプリ作ってる奴が少ないだけ。
業務用以外で大規模アプリ作ってから粋がってね。
オープンソースでももちろんいいよ。

>>498
コード書かずに設計する人間を信用しろといわれましても・

>>495
業務系アプリ以外ならなんでも楽しいよ。

>>501
なんだって聞いてるだろ。

言っとくがな、ほとんどのアプリは
業務アプリとしても作られてるんだぞ。

>>500
お前まさか、DBアクセスのプロトもJavaScript使ってんの？　すごいね。執念だね。

>>503
つまんね

Java土方でも土方って呼ばれると怒るんだねwww

>>505
いや別にお前も土方だし

じゃあお前の使ってる言語に
土方って付けてやろう。
で、お前は何の動的言語を使ってるんだ？

動的言語土方

土方と言われると悔しいので
何の言語を使っているかは言いません。

>>506>>507
顔真っ赤すぎるwww

>>509
鏡見たの？

業務系アプリの開発者がなぜ、土方と呼ばれているか。
それは、既存のルールに縛られざるを得ないからだよ。

ルールの作成者こそが絶対神であり、そのルールの施行者
が神の下僕であり。その施行者のために、虐げられながら
神がつくったルールに背くことなく、尽くさなければなら
ないからだよ。

創造力とか、工夫とか、人間としての好奇心とか、そんな
ものがはなから否定されてる世界だからだよ。

神の理不尽なお告げにひたすらしたがわなければならない
からだよ。

>>511
いや、別に業務系じゃなくても
Java使ってるし。

何を勘違いしてるんだ？
恥ずかしいぞ。

>>511
で想像力溢れるお前の作ったプログラムはなんですか？

>>511
業務系じゃなくても
大規模で、大人数でやってるなら
ルールは必要なもんだ。

そのルールを作るのが創意工夫ってもんだ。

お前は使われる人間の器だから
ルールは誰かが作る物って発想しか出てこないんだよ。

Googleがアンドロイドの開発言語にJavaを採用した時には驚いたね。
Googleさえも、大衆に迎合したかと。
ま、でも、掴みだけ抑えて、そのうちGo言語に移行するだろうけどね。

>>515
おまえ薄っぺらさがにじみ出てるぞ

Javaが楽しいとか言ってる奴は、人生の半分ぐらいを損してると思う。
まさに、丼の中のトンカツ

Javaで楽しめない奴は人生も楽しんでないと思う。
まさに、丼の中のトンカツ

>>516
それは、つまらないことを、
一行しか書いてないお前よりもか？ｗ

つか、楽しくやりたいなら、開発は一人でやってろよ感じだな。
そしたら自分のルールで好き勝手やれるんだからさ。

ただそいういうやつはチーム開発に向かない。
ちっさな人生で終わっとけ。

Mixiも、Greeも、Googleも、Yahooも、MSも、Twitterも、Facebookも、Evernoteも
世の中のイノベーションは、個人の力で始まるんだぜ。

始まるのは個人の力ってだけで結局は多数の人で開発が進む
そうなるとルールは絶対に必要になる。
ルールという言い方が嫌なら、アーキテクチャと言い換えてもいい。
何にせよ、それに従った開発が求められる。

プロタイピングにがちがちの静的言語使えって誰か言ったの？

業務アプリは、どこのバカがつくったかわからんビジネスルールに縛られるから嫌い。つか、性に合わない。俺には無理。つうことで寝る。

>>524
それはお前が偉くないからだ。

悔しかったら力をつけろ。

土方以下の雑魚の愚痴スレだったな

いや別に悔しくないからw

土方が自分の土方っぷりを自慢してるのを
周りが憐れむだけのスレでしたね

>>527
涙目でそんなこと言われてもなーｗ

結局、延長戦も、動的言語側の圧勝だったな。
Java厨の負け惜しみが心地よいわ。ふぅ..

いいか、動的言語側の勝ちだからな
絶対だぞ。

面白いほどの
負け犬の遠吠えだなｗ

【今日の格言】

Java厨は丼の中のトンカツ

はいはい、また遠吠えｗ

>>50のJava厨が静的言語ならメソッド名を簡単に変更できるとか
アホなこと言い出してスレが伸びただけ。
勝敗をつけるなら静的言語の勝ちだけど、恥をさらしたのはJava厨。

結局お前はわからなかったんだｗ

うん、どうやらメソッド名が簡単に変更できるということは
他にどんなことが可能になるかって考える発想力がなかったんだな。

>>536>>537
具体的なことを書くと突っ込まれるから
そうやってトボケることをやっと覚えたんだねwww

そんな告白しなくていいから

>>538
具体的なことを言わなかったのは
お前も一緒じゃね？

結論から言えば、設計も実装もしっかり作り込めば動的型言語でも大規模開発は出来ると思うよ
ただ、テストやコンパイルも含めて、その保証が出来るか。信用して貰えるかの問題

静的型言語でさえ、バグが潜んでるのに、コンパイラ通さない動的型言語がお偉いさんに信用して貰えるか？
ココだけだな。問題は

人間はミスをするもの
テストの想定外のケースも有る

それを念頭に置かないとな

まともにテスト書いてないのに
テストをやってれば大丈夫っていうのは
一体何の冗談なのかね？ｗ

>>541
そもそもの話にしてしまうと、既に話は決まってる
どちらも等質で、不合理が起こったときに「いつ」「誰が」不便を被るかの違いに過ぎない
夜寝ない人の暇潰しに付き合う義理はないよ

>>542
テストを書かないどころか実行することさえ
面倒って書いてたのはJava土方だけwww
まったく恥ずかしくないのかねw

なんだ、またただの言いがかりかｗ
テスト書かないのはお前だけ。
お前は土方だからな。

真面目な話、動的言語でテストを書かないと
言ってた奴はひとりもいない

>>543がそのまんまなんだよな
最初にファイル作ってからアプリケーションを公開してしばらくデバグするまでの総合時間及び手間の総計は、
よっぽどどっちかの言語に特化した尖ったプログラムでもない限り、どっちもだいたい同じだと思う

Java土方を除けば、静的/動的に関わらず
安全なプログラムを組むことは可能ってことでFA

ドウテキガー、セイテキガーなどと言ってる奴は、学生か新人君だろ

動的言語は初心者用

むしろ初心者には、静的言語をお勧めしたい。

むしろ、性的言語が欲しい (*´д｀*)

クリムゾン語ってのがあるって聞いたことがある

しかしスレがここまで伸びるとは
やっぱり静的/動的言語の間の壁って半端ないのな

クリンゴン語じゃないので？

このスレのレスの半分は、Java厨が１人でカキコんだものだろ

昔からずっと手で計算してたような人達は型にこだわらない
個人競技しか想定してないし
集合知(笑)では安全なソフトは作れないと思ってる

>>213
> 変えた時点で見つからなければ修正に時間がかかる。

CIサーバつかってれば、＊手元でコンパイルする前に＊privateメソッドの欠如が判明するが？
おまえ、他の奴も言ってたけど、マジでチーム開発経験ないだろ…

テストを言語（もしくはIDE）の中に組み込むべきだな
関数単位程度でいいから自動的にコンパイル時にテストするぐらいしてくれ

>>554
さっきスタートレックみたばっかりの俺もクリンゴン語を思い出してしまった

>>558
Eiffelのように、関数ごとに事前条件と事後条件をアサーションとして記述すれば、
あと10年もしたら各関数の事前条件と事後条件からテストデータを自動生成してくれるようになる。

ドウテキガー、セイテキガー、ドカタガー（笑）

>>557
> CIサーバつかってれば、＊手元でコンパイルする前に＊privateメソッドの欠如が判明するが？

サーバー側でコンパイルすればわかるって話だろ？
静的言語なら。

CIサーバー使ってもリアルタイムじゃないから、
サーバーに処理を投げてから
答えが帰ってくるまで時間がかかる

土方同士、仲良くしようや。

　　　　　　　　　　　　_,,,-v''7￣'';;フ-,,_
　　　　　　　　　 _,,;;=二,ヾ ! / ／~ _,,--''''~ゝ
　　　　　　　　 ./'~ヾ,ヽ ヽ!iﾉ /,,=二─''''￣~~ヽ
　　　　　　　　　)⌒ヾ,厂~''^^''~~''''~''''＝二~~ヽi,
　　　　　　　　　ヽ⌒i　　土方歳三　　　　)ゞ,,~''-,,_i
　　　　　　　　　 ｿノi　　　　　　 _,,,,,_　 ヾ　~ヾ,　(
　　　　　　　　　(（ /| ,＝=,,　 ヽ,-'''' ~'　 く~ヾ, ヽ,ﾐ
　　　　　　　　　 ヾi .i ;''ゝ''ヽ.　 ｿ'ゝ'''ゝ　 ミvﾚ'ヽ
　　　　　　　　　　 ヽ!　　´ ::i　　 ｀　´　　 :i|'ｿﾉ'!ヽ!
　　　　　　　　　　　 '!,　　/ﾉ　　ヽ　　　　 i-''~i: | |
　　　　　　　　　　　　.i,　　 ｀_~´　 　　　　|~ゝiノ'
　　　　そうだな＞　　ヽ　~ --￣` 　 ／ﾉ~(
　　　　　　　　　　　　　　'i, 　　　　_,,-'',／ / |
　　　　　　　　　　　 _,,-''i~ ゝ--=二-''~ ／／~''ヽ,_
　　　　　　　　　_,,-'i　　 :i'-,,_-￣ _,,--''_,-|　　　 　i~'i-,,,,_
　　　　_,,-''''￣~　 /　　　|''--ヾ,ノ,;;-'''~　 :|,　　　　:|　|:　 ~''''--,,_
　　 ,ノ　'!　　　|￣~'ヽ,　 :|　　 /o''　　　　∧　　　　:|　'　　　 ／　ヽ
　 /''-　 :|　　/|　　　　＼|　　 |o　　　　　|　＼＿,,,,─''''~|　/　　_;;-ゝ,
/　　　　:|　/　!　　　　　|　　 |o　　　　　:|　　　　　　　　| /　／　　　 i
/-,,　　　 |:/　 :|　　　　 :|　　 :|o　　　　　 |　　　　　　　 ,!,!　/_,,-''''￣''ゝ
/,,_　~'''-,,_ﾚ　　 :|　　　　|　　　:|o;;,　　　　 |　　　　　　　/:|　/'　　　''￣''|
|　 ~''-,,_　:|　　　 :|　　　 |　　　 |o◎　　　 :|　　　　　　 / :| /　　　　　　 ヽ

そんなもん言語じゃなくてIDEで対応できるだろ

土方さんじゃなくて井出さんだったみたいだな

ところでこのスレでテスト書いてる人って網羅率どのくらいなの？
どのくらいまでいってコンパイラが出す程度のエラーはテストで出し切れるって認識なのか知りたい。

みんなが勉強する前にテストをばらしておくと
テストに出ない所を勉強するやつはいなくなる

>>562
CIサーバがチェックインのたびに単体テスト動かせば、
動的言語だろうが静的言語だろうが、
チームメンバーがチェックアウトする前にprivateメソッドの欠如が判明する。

安全うんぬん言うんだから、これぐらい常識だと思っていたのだが。。。

>>568
カバー率90%、テスト成功率100%を切ったらチェックイン拒否してます。

>>566
つうかさ、privateメソッドの話だろ？
privateメソッドなんてそもそも同名なメソッドは少ないんだから、
その名前のメソッド叩いてる箇所を総チェックしても問題ない。

ポリモーフィズムが高くなって単純な文字列検索じゃ厳しいのはpublicなメソッドだ。
publicなメソッドだったらどのみち自分勝手な変更は許されないだろ。
まずはチーム内外のコンセンサスを得る必要がある。
だから静的型だろうが動的型だろうが大差ない。

したがって、privateメソッドでもpublicメソッドでも、
メソッド名変更とかやる程度の話じゃ、動的型も静的型も大差なし。Q.E.D.

>>572
たぶんJava厨はEclipseのリファクタリング機能で
メソッド名の変更が出来るのを開発に重要な機能だと
勘違いしたんだろうね

大差ないて

あらあら

まあまあ

「Java土方には安全なソフトは作れない」が正しいスレタイだったな
勝手にインターフェース変更すんなよw

土方ってJavaかPHPのイメージ。

土方といえば、Javaと.ＮＥＴ(C#,VB,APS...)だろ

PHPは土方っていうより、デザイナー流れみたいな人が使ってるイメージなんだが

本物の土方はperlを使う。

PHP屋はPerl屋に嫌われているけどな

Java厨はみんなに嫌われてるね。

MATLABかOctave使おうよ

Rだろ

Rが素晴らしいことに異論は無いが
書き込むスレ間違ってない？

究極超人か..

>>581
Perlはあんま土方ってイメージない。おっさんとか爺さん、老害ってイメージ。

PerlとPythonはハッカー御用達の言語だからな

>>572
> その名前のメソッド叩いてる箇所を総チェックしても問題ない。

その名前のメソッド叩いてる箇所を総チェックする必要がある。



> まずはチーム内外のコンセンサスを得る必要がある。

得たあとはどうする？ 結局変更するだろ？


反論終わり

どうも理論バカなのかな？
現実として起こっていることを
知らないみたいだよね。

そして

コンセンサスを得る必要があるかどうかはコードを
修正するのとは別のレイヤーの話であって全く関係ないよね。

むしろ簡単な修正であっても同意が得られないとしたら
それは動的言語だと静的言語に比べて影響範囲が分かりづらいからじゃね？
って話になるだろうね。

一回作成したpublicメソッドを、何があっても絶対に変更してはならない。
なんてコーディング規約の会社だったら、開発はすごく窮屈だろうね。

あ、何万のユーザーがいるオープンソースライブラリの話なんかしてないよ。
よくある一般的なソース非公開のデスクトップアプリやウェブサービスの話だ。

ということでpublicメソッドでも変更することはありえます。そーいう前提で。

変更しやすいのはどっちなのか、言うまでもない。

>>571
冗談とか嫌味抜きで羨ましいな。そこまでテストに理解のある人間が上にいる会社なのか。

Java厨の開発行程の50%は
メソッド名の変更作業です

などという悪口しか言えなくなった動的言語厨でした。

実際に開発の大半を占めるのは間違ってもメソッド名の変更ではないよなw

メソッド名の変更というからいけないんだろうな。
学術的（笑）に書けば権威に騙されるだろうｗ

静的言語ではRename Methodと呼ばれるリファクタリングが適用しやすい
http://en.wikipedia.org/wiki/Rename_method
> Rename method
> From Wikipedia, the free encyclopedia
> Rename Method is a refactoring that changes a name of
> a method into a new one, that better reveals its purpose.
> To have clearer, more understandable code, programmers
> would optimally want to change method names to reflect exactly what the method does.

>>597
リファクタリングを適用しやすいのは明らかに静的言語だよ。

リファクタリングカタログ（英語）
http://www.refactoring.com/catalog/index.html
こっちに93個のリファクタリング技法がのってるけど
半分ぐらいは静的言語なら簡単に適用できるはず。

静的言語の場合に適用が楽なリファクタリング例

> Add Parameter
引数が変わるとンパイルエラーがでるから修正箇所が分かりやすい

> Collapse Hierarchy
Salesmanクラスを参照しているところを見つけやすし。

> Extract Class
Extractしたクラスで元のクラスの参照を見逃しているとエラーが起きる

> Extract Method
引数にし忘れるとエラーになる


ほんの少し見ただけだけど、静的言語のほうがリファクタリングが楽だね。

最近の土方は、リファクタリングという言葉を使えるようになったんだな。
めでたいことだ。

リファクタリングなら>>123でとっくにに出てますが・・・

「土方」という言葉は>>214が初出。

土方なんて言うヤツのほうが無知なのでは？

とっくにって、つい２，３日前じゃん。

２，３日前でも「土方」という言葉を使うやつは、
このスレでリファクタリングという言葉が使われていることを見れたはずだ。

つまり「土方」という言葉を使ってるやつは、過去レスみないで叩いている。
しかもメソッド名の変更が、リファクタリングカタログにも乗っている
テクニックであることを知らずに馬鹿にしているだけと露呈してるんだよ。

「無知」という言葉は>>603が初出。
無知なんて言う奴のほうが池沼なのでは？

つまり、「無知」とう言葉を使うやつは、
このスレで土方という言葉が使われていることを見れたはずだ。

つまり「無知」という言葉を使ってるやつは、過去スレみないで叩いている。
しかも、Java厨が、土方のカタログにも乗っている
底辺であることを知らずに馬鹿にしているだけだと露呈してるんだよ。

あーあｗ


あーあｗ

テストコードが書いてあるから、静的言語の構文チェックは必要ないってのも違うよね。

たしかにテストコードがあれば、エラーが出たということは分かる。
だけど、どこでエラーがでたか具体的な場所を表示できるかどうかでみれば、
構文チェックがあれば、テストコードよりも具体的な場所を
指摘できることがある。

例えば引数の数が増えたときとか。

構文チェックもテストコードの一つと考えれば、
テストコードは多いほうがいいと気づくと思うんだがねぇ。

つまり、MixiもGreeもTwitterもGoogleもFacebookも安全じゃないってこと？
そりゃやぺーな、JavaScriptとか危険すぎるな。Ajaxとか使ってる場合じゃないな。
おー、こわい、こわい

もうみんな、Javaで作ればいいのに。そしたらみんな安心できるのにね。

>>610
静的型言語も必ずしも安全と言う訳じゃないけど、危険度で言えばイエス

結局は開発者の技量の方が重要だけど

> 静的型言語も必ずしも安全と言う訳じゃないけど、危険度で言えばイエス
国語力も必要ですね

>>590
> その名前のメソッド叩いてる箇所を総チェックする必要がある。

privateメソッドの話だよな？
たかがクラス内の参照をチェックするのがそんな大変なのか？
だとしたら、おまえ、プログラマの適性ないわ。

> 得たあとはどうする？ 結局変更するだろ？

コンセンサスを得たあと、一人で全部修正するのか？
depricateしたりして「穏やかに」移行していくんだろが。
断言できる。お前は「本物の」開発にプログラマとして参加した経験がない。

リファクタリングが元々動的OO言語から来ていることも知らずに
Java衷がドヤ顔してるねぇw

自動テストを実行すればインターフェースの変更くらい
動的言語でもエラーチェックできる。
ただ、自動テストの実行終了が待てないくらい
Java厨は頻繁にインターフェース変更するんだってwww

>>614
お前はプログラマに向いてないな。
機械で自動化できることをしないで、
自分の目で捜すということをしている時点で
向いてないよ。

大変かどうかではない。どれだけ楽をするか。
怠慢というプログラマ三大美徳を知らんようだ。

> コンセンサスを得たあと、一人で全部修正するのか？

一人で修正しようが、なんだろうが修正することに変わりはないだろ。
静的言語なら、@deprecatedとマークを付けることでコンパイル時に
このメソッドを使っていると警告を出すことだってできる。
何にせよ修正するとき静的言語のほうがリファクタリングが楽になることは事実なのだ。

> お前は「本物の」開発にプログラマとして参加した経験がない。
そうやって決め付ける。決め付けないと満足できないんだな。
そういうのは「お前の母ちゃんデベソ」と言ってるレベルだと気づけ。

難癖しかつけなくなったな

>>614
「俺の開発が本物だ！」ｷﾘｯ
とか言いたいのか？ｗｗｗ

Java土方が参加するような大規模開発では、
とてもプログラマとは呼べないカスが多数チームに居る。
彼らはバグだらけのコードをチェックインしたりするので
居るだけでマイナスの存在なんだが、だからといって
簡単にチームから外したりクビにすることも出来ない。

ではどうするか。

Javaのような静的言語なら、そういうカスPGにはどこからも参照されない
無害なモジュールを延々リファクタリングさせる。
これなら正しいコードを破壊されることも無いし、少なくともコンパイルできない
コードがチェックインされる心配も無い。
しかも、実際には穴掘って埋めるような虚しい行為にも関わらず
何故かJava土方は嬉々としてやるので、彼らが鬱になったりする心配もなし。

というわけで、底辺における大規模開発ではJavaのような静的言語しか
使えないわけ。Q.E.D.

もうすっかり、静的言語　＝　Java という前提で語られてるな。

Java厨 vs. その他の静的/動的言語PG、だからね

c++でもそのまま通じる論調ばかりなのに

オーバーロードかオーバーライドができるという前提で語れば
他の言語でも同じだよな

動的言語ではOOPしない方が良い
OOPに懐疑的な人に向いている

正確には、延々とメソッドのリネームばっかりやってる
>>620の土方プログラマには動的言語は荷が重い。
それ以外なら、開発における比重も頻度も低いので問題ない。

静的言語だと100万行超えたあたりからつらくなる
動的言語だと１万行超えたあたりからつらくなる

非常に実感に近い

動的言語が優位なのは100行くらいまでだな
重いIDE立ち上げてプロジェクト作る手間が省ける
それ以上なら静的言語使った方が楽

それは lib/ とか share/ とか、pipe や socket の相手側の行数を数えてないから。

バカ発見

>>626
動的言語で１万行とか、普通そんなにダラダラ書かないぞ。
動的言語の用途だとせいぜい長くとも1000行ぐらい。

JavaはXMLの設定ファイルの記述だけで1000行超えますが、何か？

>>631
良くも悪くもFA

1000行ってうちだと１つの関数の長さだぞw

分割しろｗ

>>632
javaは静的な。

>>634
ムダだらけ。
ビジネスロジックを書いてるなら動的は危険だからやめろ。

学生時代に友達のひどいコードを書きなおしたら3000行が100行になった。

Perlはクラス1個でパッケージ1個分の満腹感

動きゃーいいんだよ、動きゃぁ！

>>632
設定ファイルはプログラムじゃないよ。

>>617
動的型言語でも、privateメソッド叩いている箇所は
自動的に処理できるよ。
だって、privateなんだもんw

型に詳しい君には理由は明白だよな？w

>>636
Javaにも動的型検査があることは無視かい？

>>626
まあ、そんなもんだな。
そんでもって、同じ仕様から実装しても、それぐらいのコード量の比率になる。

バカの1万行は普通の人の1000行だからなぁ

この業界で動的言語使う仕事してるプログラマの9割はプログラマとは名ばかりの
おかしな連中だもん。
日本のIT業界のレベル低すぎだと思う。

ジャバ厨が、リファクタリングのためにメソッド名を変更するんだと、嬉々として自慢してるけど、
そもそも、メソッド名や変数名の変更なんてものは、リファクタリングのごく一部であって、他に、
メソッドやクラス、インターフェースの抽出、分岐処理のポリモーフィズム化、メンバの移動、
継承と委譲の変更、デザインパターンの適用、引数オブジェクトの導入...等など、場合によっては
既存コードにドラスティックに手を加える必要もあるわけで、その場合、コンパイルのチェックなど
ほとんど手助けにならないし、これらのリファクタリングを勇気をもって実施するためには、結局、
ユニットテスト用のコードが必要になってくる。そして一般的にリファクタリングという場合、これ
らのケースで実施されることの方が多いだろう。

静的型付け言語だから、テストの手を抜いてよいという話ではないし、静的型付け言語だから安全
なんだと自慢できるほどシステム開発は呑気なものではない。

ジャバ厨の主張は、医療保険に入っているから煙草も酒も気楽にやれるよと言ってるようなものであり、
そもそもなぜ病気にかかるのか、病気にかからないためにはどうすればよいのかいう、より重要なこと
を疎かにしているんだろう。むろん医療保険に入るにこしたことはないが、日頃から健康に気を使い、
検診を受けている健康な人にとっては、それほど大きな問題ではないのだよ。

だからJava厨の仕事はメソッド名を延々と変えることなの
彼らの仕事を否定しちゃ可哀想だよ

>>646
静的型付け言語は型テストがコンパイル時に終わるので、
テストが大幅に楽になるよ。

>>648
静的型言語であっても動的型検査が必要な言語が多いですが。Javaとか。

今時は動的型言語でもIDEが簡易型検査やってくれたりする。
動的型ではtypoが見つからないとか、いつの時代よ？

>>648
静的型付け言語だから、テストが楽になるという話は聞いたことないな。
関数の仕様として、INとOUT、引数のとりうる値が明確に定められていて、
それに対するテストが必要だとして、静的型付け言語だからという理由で
いったいどれだけ、テストが楽になるというんだ。

そもそもテストを作るときに、静的型付け言語だからこれはやらなくていい
なとか項目を選りわけて作ってるのか？　　そんな話聞いたことない。

>>650
typoだけでなく、横着して意図的に型を無視した処理を防止する意味でも静的型付けは有効だよ。

動的型付けだと、例えば引数に整数しか認めていない関数なのに、
引数に文字列を入れてエラーが出る、とかよくあるじゃん。
整数しか認めていないよ、ということをコンパイラが検出してくれるのは大助かり。

動的言語、例えばPHPで、文字列の前にプレフィックスをつけて返す関数があったとして、

function add_prefix($str) {
　return 'prefix_' . $str;
}

これを
$res = add_prefix('hoge'); // 引数が文字列
と　呼ぼうが、
$res = add_prefix(100); // 引数が数値
と呼ぼうが

PHP的には間違いじゃないんだよ。むしろ、この融通性が動的言語のメリットとも言える。

引数が誤ったものかどうかは、呼び出し側のコンテキストによるが、それを見逃すリスクと
利便性を計りにかけて、利便性をとったのが動的言語といえる。この利便性のおかげで
コード量が減りバグが混在するリスクを減らし、生産性を高めている。

むろん、コーディングする側は、型指定がないことのリスクを認識した上でコーディング
する必要があるが、それに十分見合うだけの利益を享受している。

もし、引数として数値を認めたくない場合は、関数内にassert文なり、型チェックのコード
をいれとくさ。

>>654
そのメリットを静的型付けで実現するために型推論があるんだよ。
Haskellでは型を明記しなくてもほとんど推論してくれるから、
動的言語のメリットを持ったまま型の安全性を確保できるようになった。

DBは、DBでいろいろな型をもち、JavaはJavaでJavaの型をもち、
DBにいれるときや、DBから取り出すときに、いちいち相互の型に
変換しなけりゃいけないのが面倒くさいよね。

特に日付まわりとか、Date型だったり、Timestamp型だったり、
文字列型だったりするから、それをJavaの型と相互変換とか、
関数化してはあっても、フィールド数が多かったりすると、いちいち
それを通すのが面倒くさかったりするよね。

まぁ最近は、ORMとかつかったりする場合もあるけど、それでも
設定ファイルを書くときに意識しないといけなかったりとか、面倒
くさいよね。

>>656
その辺は動的言語だって型変換は必要だろう。

動的言語は型を意識しなくても使える言語っていう意味じゃないよ。

い-や。DBから取り出した値を変数に代入するだけ。
オブジェクトをnewして、フォーマッタやカレンダをnewして、パースして、とかしなくていいし。

>>652
意図的に型を無視したプログラミングをしているのなら、
「きちんと」型を無視したプログラムを書けたほうがいい。

防止なんてされたら、その「意図」が達成されないじゃないか。

まあ、君にとっては動的型=悪なのだろう。
そこで思考停止しているのなら、単なる宗教だ。

>>655
おいおい、Haskellは「型付け」を自動的に推論してくれるのであって、
「型変換」を自動的にやってくれやしないぞ。

なんだか付け焼刃だなあ。

勝手にコアージョンしたら型推論自体が成り立たないしw

>>661
え？なんで型変換？

a -> Either a (Either b (Either c ...)) がアップキャストで
その逆がダウンキャストだよね

ここまで契約プログラミング無し

>>661
>>655じゃないが、>>654への回答として間違ってないだろ
多態性は自動でしてくれる

型変換とか、キャストの事だろ普通
紛らわしい

>>656
そんなにめんどくさいならObject型を使えばいいよ。
それで静的言語特有の型チェックが失われて、
動的言語レベルまで落ちちゃうけどｗ

それよりもORMにさせれば面倒さはなくなって
しかも動的言語レベルに落ちない。

>>659
> い-や。DBから取り出した値を変数に代入するだけ。
> オブジェクトをnewして、フォーマッタやカレンダをnewして、パースして、とかしなくていいし。

日付型はアウトだね。データベースから取り出したとき文字なのか数値なのかわからない。
文字であっても、どういうフォーマットなのか不明だしね。

それから、フォーマッタやカレンダが出てくるときは、ユーザーからの入力されたということだから
どっちみちフォーマッタやカレンダが必要だよ。不正な文字列の場合もあるしね。

実際にやってみたけど、静的言語での
リファクタリングのやりやすさは半端ないね。

テストコードがあってリファクタリングする。
ここまでは動的型言語でも静的型言語でも同じ。

違うのは、リファクタリング作業そのもの。

例えて言うならそうだね。マークシート方式のテスト。
テスト結果は自動化されてすぐに出る。
でもシャーペンで塗るのと、鉛筆で塗るのでは
作業の速さが段違いでしょ？ それと一緒。

>>654
これ、rubyやpythonじゃエラーにならね？
てか、phpでもホントに動くの？

自分、昔こんなコード試して、エラー出た覚え有るんだが

str = "hello" + 100

phpでは正しく動くって事？
$に秘密が？

rubyだとクラス変数が$で始まるんだけど、phpは違うって事？

Java厨房の仕事の９割方はリファクタリングなんでですぅ。
毎日毎日、９時から２２時まで糞コードのリファクタリングしてますぅ。
２２時から２４までは次の仕様のコーディングしてますぅ。
JavaとEclipseを使ってなかったらと思うとぞっとしますう。

え、テストコードコード？　そんなもん書いてませんよぉ。
そんなもん書く暇ないし、書き方しらないし、第一、上司がそんな工数くれませんよぉ。

でもリファクタリングはしますょぉ。えぇもう一日のほとんどはリファクタリングしてますよぉ。えへへっ

>>670
お前がキモイ

静的言語ならコーディング全般楽になるね。

コード補完が正しく動くのも
静的言語ならではだしな。

プログラマの仕事は設計、考える事であって
コーディングではない。

だからコーディングはサクサク進められる
静的言語がいい。

本質的なところに集中するために
本質的ではないところは極力自動化すべき

ええぇぇぇぇぇぇぇぇっ！

えぇその通りです。動的言語なら1行で済むことを10行かかるけど、
コード補完が手伝ってくれるから、全然苦になりませんよぉ。
なんか仕事したぁって気にさせてくれるから、一石二鳥ですよぉ。

> えぇその通りです。動的言語なら1行で済むことを10行かかるけど
これは嘘です。

えへっバレた？　やっぱり？　ゴメン書き直しますぅ。

動的言語なら1行で済むことを20行かかるけどぉ

結局、動的言語のほうが優れているという点は
何一つ出てないよね。

静的言語じゃなくても、頑張れば追いつけるって話ばかりで。

>>676
じゃあ、10倍速く作れよとか、
給料1/10でいいな？とか言ったら
たいてい黙るんだよなｗ

標準入力から読み込んだテキスト内のhogeをhageに変換して出力する処理。
Perlで書くと、

!/usr/bin/env perl
while (<>) { s/hoge/hage/; print; }

なんと、2行！　ロジック部分はなんと1行。

これをJavaで書くと．．．

えぇぇぇぇぇぇぇぇぇぇぇぇぇぇ！

ただいまJava厨が一生懸命考え中です。しばらくお待ちください．．．

うん。こういうくだらない例ぐらいしかでてこないｗ

仕事だと一ファイル数百行×ファイル数十個は
ぐらい簡単に行くからな。

そのレベルになるととても動的言語ではやりたくなくなるよね。
動的言語が優れてるのはテストがいらないような
小さなスクリプトまで

クラスや関数を5つ以上使いだすレベルになったら、
動的言語はコード量が静的言語とほとんど変わらなくなるよ。
これマジ。やってみ。

あれれれぇぇぇぇぇぇぇぇ！？

そういえば、Java厨はコードを出してこないよねぇ。なんでだろ。

静的言語は安全っ！(｀・ω・?ｴ)ｷﾘｯ

こればっかりぃ　なんでだろぅ！？

Perlはhtmlのタグを除去する処理も2行でかけちゃうんだよぉ。

#!/usr/bin/env perl
while (<>) { s/<.*?>//g; print; }

Javaで書くと何行かかるぅ？
たまにはコードでみせてちょうだい。土方の汚名を返上したければ。

ただいま、Eclipseを起動中です。しばらくお待ちください．．．

じゃあPerlでクラスを書いてみよう。メソッドは一つ
package Class;
sub new{
　my $class = shift;
　my $self = {};
　return bless $self, $class;
}
sub foo {
　my $self = shift;
　my $value = shift;
　print $value;
}
1;

これをJavaで書くと？

そうなんだよなぁ。動的言語の欠点は
ある程度の規模になると、逆にコードが長くなってしまう。

Perl使ってて嫌なのは、
この変数、この関数、このモジュール使われてるの？
ってやつだな。

ソースコード見て一見使ってないように見える。
実際使ってない。

なのにコンピュータはそれを教えてくれない。
馬鹿なのかって思う。

>>688
なに最後の1ってwwだせええwww

Javaで>>686とか書こうとすると
なんちゃらReaderをchainingするところで心が折れるな

超短距離なら車より人間のほうが早いってのに似てるね。
あと行数だと改行しなかったもん勝ちだけどほんとにそれで良いのかな…
Perlの得意とする分野の処理はそりゃ短く書ける構文が用意してあるよね。
その代わり上でも書いてるように普通の何てことない処理を書くと長いか無駄な記号が増える。
かと言ってJavaありきで話進めても進展なさそうだから、scalaとかもーちょいまともなもので話進められないもんかね。

> Perlはhtmlのタグを除去する処理も2行でかけちゃうんだよぉ。
>
> #!/usr/bin/env perl
> while (<>) { s/<.*?>//g; print; }

こう言うのはある意味害になってるよな。簡単にかけると勘違いしてる。

その場で書いてしまうから関数にするって発想に乏しい。
タグを除去するなら、タグを除去するという関数にした方がいい。

で関数にする手間がかかるが、一度関数にすればあとはそれを呼ぶだけ。
だから規模が大きくなるほどコード量の差はなくなってしまう。

あとなんで関数にするかというと、あとでバグを修正するためだよ。
たとえばこの例だと、スクリプトやコメント内の<や>にマッチして誤爆する。
動的言語は簡単なものにしか適用できないというサンプルかよ。

Padreってしってる？ Per用のIDE

Padre, the Perl IDE
http://padre.perlide.org/

これの素晴らしいところは、
PadreのPerl Application Development and Refactoring Environmentの
略からもわかるようにRefactoringに力を入れてるってところ。

つまりPerlでもIDEが自動的にRefactoringを行ってくれるんだよ。

試しにメソッドの抽出を行ってみ。


予想の斜め上をいった全く使いものにならない変換してくれるので
動的言語ではIDEのリファクタリングサポートにも限界があるってわかるｗ

この画像すばらしいよね。
http://padre.perlide.org/trac/raw-attachment/wiki/Screenshots/Padre_0.47_Win7_autocomplete.jpg

Perlでもコード補完が動いているように見える。



でも実際には、パッケージ名:: ← この::を使った形式だけで
通常良く使われる$obj->ではコード補完してくれない。

なぜなら$objは型がないから補完すべきメソッドがわからない。

その例は、動的、静的とは関係がない。

正規表現って厳密にやろうとすると
途端に難しくならね？

>>685
関数5つ以上使ってる例

Python実装のSchemeサブセット
http://norvig.com/lis.py

>>697
厳密というか理論に忠実なものはただのオートマトンだから極めてシンプルだけど
最適化を考えると複雑になってしまうね
単純なクリーネ代数の性質を使った簡約ですら制約付きの項書き換えシステムを組まないといけないので

C#最強？

このスレではJavaな人たちが頑張ってるから俺らは黙ってようぜ

>>697
メールアドレスの正規表現とかも馬鹿らしいしな。
正規表現は各パーツの形（メールアドレスだったら@の左の部分とか）を
識別するもので、全部を正規表現で表すのは見にくいし、
メンテナンスもしづらいだろう。

>>696
すごく関係あるよ。

正規表現なしで書こう
→行き当たりばったりで書いて頓挫
→オートマトンを書き始める
→あれこれって正規表現じゃねということに気づく

まで読んだ

ここまで、Java厨のコードなし。

今日も一日メソッド名を変換するお仕事
がんばってね！

このスレ見てわかるのはJavaって普及してんだってことと
動的言語使ってるやつの経験値が低いこと

メールアドレスのようなものは正規表現じゃなくてパーサジェネレータを使うんですよ
特に再帰を含むような文法定義は正規表現の表現力では力不足でLLとかPEGを使って書く
勿論その実装にはオートマトンが使われてるわけだけどもユーザが直接それを意識することはない

なんで静的型付けの代表がJavaなんだ、という疑問

それはC++より人口多いからだと思うけどね
関数型は静的動的が論点になってないっぽいし

>>707
このスレのJava厨が経験値高いとか
何の冗談だよwww

論理的な推論ができないんだな

Java厨ってJavaしかできない印象があるな。

動的言語プログラムは日常的なプログラミングの補助としても使える。
思いついたアイデアをぱっと試したり、プロト作ったり、簡単なタスクを実装したり、
真のプログラマは、静的言語も動的言語も苦にしない。

「この関数の引数の型はなんだっけ」と忘れる事がよくある動的

どう論理的な推論（笑）したら
動的言語使ってるやつの経験値低いことがわかったの？ww

だれも補助として使えないといってないのに。
動的言語で一万行超えてもまったく遜色ないって言うのであれば
そのノウハウを本で出せば大注目されるよ。

>>714
つ @param

不便をノウハウで何とかしようというは根本的解決にならないのでは。

ほらね。予想通りに釣れすぎ。

>>717
doxygenは言語ではない。

で@paramは誰もテストしないから間違ってるんですね。

てか、仮にコメントにちゃんと引数の型を書いといても、わざわざそれを見に行くのがめんどくさい。
静的型付け言語なら型が合わなければコンパイル時に教えてくれるんだから、
最初から静的使っとけばいいんだよ。

>>717
その記述の妥当性は誰も検証しないから、間違っている可能性もある。

>>722
たいていにそれをできるIDEがあるってレスが返ってくるね。
俺は同意。

>>724
IDEでは完全に型検査できないでしょ。
もしそれができるなら最初から実行時に検査するわけなんだから。

>>725
あごめん。>>722に同意。

さらに依存型を使った言語ならこれまでコメントで書いていた
引数に求められる条件とか戻り値が保障する性質そのものを型として表現できるんだぜ
実用性はまだまだだけど・・・

動的言語のメリットは型推論で満足できるのだから、もはや動的言語は不要だという意見もあるよ。
あと、動的言語はコンパイラが作りにくいから、いつまでたってもライトウェイト。

Java厨は、もうずっと、コンパイルチェックガー、コンパイルチェックガーと
泡ふきながら、うわごとのように唱え続けているね。おもしろいねぇ。

静的言語＝Javaとか思ってる低学歴がいるスレはここですか

JVMで動く、JRubyとか、JPythonとかあるんだから、使えよもったいない。
お前らの大好きなEclipseでコーディングできるぞ。

動的言語を積極的に使うべき理由があるなら教えて欲しいもんだ

そんぐらい自分で気づけよw

>>729
そのメリットも理解できないもんな

>>733
まさに狼少年

静的言語の代表格だしたけりゃjavaじゃなくてscalaもってこいや
java程度だと総合力で動的言語に負ける

scalaよりStandard MLの方が一般的じゃない？

トイプログラマは黙ってて

次世代型javaとしての立場ならscalaかなぁと思って

scalaってそんなに普及してるの？

普及してる
普及し始めてる
普及するかもしれない
普及したらいいな

ポジショントークばっかり。討論するスレじゃないのね。

scalaの話はやめろーっ！　Java厨がついてこれないから...(´・ω・`)

Perl厨はJavaすら理解できないｗ
討論ってのは両者がお互いの立場を理解できてこそ成立するのであって、
Perlしか理解していないPerl厨とは討論が成り立たないのは自明。

まともな議論なんて俺らがせんでも形式手法研究してる奴等がいくらでもしてくれてるからな

別に俺らがしてもいいんだよ。
やろうぜ。

じゃ結論持ってきて

結論だしたら終わるだろ。馬鹿か。

結論：
強力な型システム持ってる言語ならそうでない言語ではコメントやドキュメントとして表現されていた要求や保証を型等の
言語内の概念で扱う事ができて、その検証を処理系が自動で行うことが可能である
この性質を生かせれば、そうでない言語に比べて安全といえる
ただし生かせれば、の話な

結論：静的言語でも動的言語でも安全なプログラムは組める。
ただしJava厨だけは論外。

IronPython使ってみたけど、
普通にC#使った方がいいと思った

理由を書かないんだな

>>752
やっぱりVisualStudioじゃない？

関数型言語、形式手法マンセーのトイプログラマも論外

このスレは平行線だが確信できた

今使用してる言語からscalaに移行しろって言われたとき、
動的言語使いの方がJava厨よりあっさり移行できると思うぞwww
ていうか、Java厨ってJava以外何か使えんの？

C/C++使ってるときにJavaが浸透していくのみてたから
それなりにメリットある言語は流行るはず

>>754
JRや株関係では関数型言語での案件もあるんだがな。

トイプログラムならな

あれ、動的、静的言語の話かと思ったら何時の間にかプログラマーの話になってたのか。
マ板でやった方が良いのか？

コアシステムだよ。
ロジックを組むのに関数型言語ほど向いた言語はない。

やはり>>622であることが明らかに

コアトイシステム

Java厨が動的言語を批判するのは型付けの問題じゃなくて
単純に「Javaじゃないから」なので、静的型付けでも
scalaや関数型言語は同様に批判します。

Java厨を批判しても誰も擁護しないということは、Java厨なんてのはこのスレに居ないのでは。
つまり、Java批判厨の一人芝居。

メソッド名の変更が忙しくて、今それどころじゃないんだろ

C++ユーザーだけど

>>666
せめてコアージョンとキャストの違いぐらい理解してから出直してこい

>>768
コアージョンって何ですか？

型の議論をするならせめて
型変換、キャスト、コアージョンの違い
静的多態と動的多態の違い
ユニバーサル多態とアドホック多態の違い
パラメトリック多態と包含多態の違い
ぐらいは理解してくれないと議論が成立しない。

>>770
ああ、君はそういうタイプね。
議論する能が無いから煙に巻く手口か。

無能な奴ほど煙に巻いて逃げおおせようという奴が多いから相手にしてもしょうがない。

>>770
すみません

こちらの方はどうなるんでしょう？

>>669
＞>>654
＞これ、rubyやpythonじゃエラーにならね？
＞てか、phpでもホントに動くの？
＞
＞自分、昔こんなコード試して、エラー出た覚え有るんだが
＞
＞str = "hello" + 100
＞
＞phpでは正しく動くって事？
＞$に秘密が？
＞
＞rubyだとクラス変数が$で始まるんだけど、phpは違うって事？

詳しそうなので、お願いします

phpで、文字列の連結は、
$a . $b

数値の足し算は、
$a + $b


>>654 が使ってるのは、前者

文字列文脈では数値は文字列に、数値文脈では文字列は数値に自動でcoerceしてるのか

安全なソフトなんて作る必要ないよ
クラッシュしたら修正して再起動すればいい

ここは釣堀吊り上げられて俺

うわ…Java宙は本当にコアージョン知らない馬鹿なの？

>>774
rubyでエラーが出たのは、文字連結と加算演算子が同じだからと言う理解で良いんでしょうか。。。

>>778
このスレにコアージョン知ってるやつが何人いると思ってるんだよwww

>>778
コアージョンがよくわからないので、勉強したいのですが、
おすすめの本などありますか？

>>780
このスレじゃなくて、この板(一部の底辺WebPG除いて)では常識だと思ってたけど、違うのか?

scalaのimplicit conversionとかHaskellのunsafeCoerceとかcommon lispのcoerce
とか型理論のnatural isomorphic typeは知ってるけど
一般的なコアージョンというのは聞いたことない説明とか参考文献の紹介を願う

>>782
そういう幼稚なレッテル貼りは無意味だからやめたら。
せっかく重要なキーワードもってきたのが台無しだよ。

coercionなんてそもそも静的/動的関係ねー

ところでどうせカタカナにするならコアーションじゃまいか

ああ、なんだ、コアーションって言語特有の用語か。
F#とか由来みたい。
言語毎にいろんな用語を勝手に作られるからなぁ。
コアージョンで検索してもそれらしい意味が出てこないし、なんだろうと思った。

F#由来のわけないじゃん

どっちにしろ大した意味はない。
大げさに語るほどでもないだろ。

ま、もともとcoercionの例(>>654)を見て、
何を思ったのかHaskellの型推論なら同じことが出来るとか
アホなこと書いたやつがいたのが発端。
こんなのHaskell使いが書くわけないから多分Java厨だろうね。

でもいまどきは動的言語であっても型付けは強いのが主流だから
あんまり>>654みたいなのを動的言語とはこういうもんだみたいに言われるのはなあ

>>790
haskellの型推論なら同じことができるよ。
できないと思っていたのか？

>>792
Haskellの型は静的に決まるけど>>654の場合は実行時
ぜんぜんちがう

>>793
動的に決まるとどんないいことがあるの？

>>654をC#で書くと

string AddPrefix(object str) { return "prefix_" + str; }

なんで静的言語でも簡単にできることを
"動的言語のメリット"　とか言い出すのかな？

C#ならそうかもしらんが、Javaでやる場合、いちいちプリミティブ型からインスタンスを生成して渡さなきゃならないからな。

●rubyでの実装
def add_prefix (str)
return 'prefix_' + str.to_s;
end


●perlでの実装
sub add_prefix {
return 'prefix_' . shift;
}

●pythonでの実装
def add_prefix(s):
return 'prefix_' + str(str);

ちょっと訂正

●rubyでの実装
def add_prefix (str)
　return 'prefix_' + str.to_s;
end


●perlでの実装
sub add_prefix {
　return 'prefix_' . shift;
}

●pythonでの実装
def add_prefix(s):
　return 'prefix_' + str(s);

>>795
そうやって相手の出方を見た後なら簡単に真似できるが
真っ先に自分でやるのは難しいだろ
もっと静的に書きたい気持ちをリセットするのに時間がかかる

Visual BASIC 最強

VB6は、静的言語と動的言語の悪い所どりした言語だったね。

だからcoercionは型付けの静的/動的は関係ないの。
ただHaskellの型推論ならできるとか
無知丸出しの書き込みにツッコミ入れられてるだけ。

>>801
では、haskellの例をお願いしますm(__)m

>>801
>>654はコアーションとは無関係だぞ。

>>802
add_prefix :: (Show a) => a -> String
add_prefix = (++) "prefix_" . show

コアーションとか言わず実行時の型変換でいいんじゃないか
通じてないもの

>>803
文字列と数値の連結だよ？なんで無関係だと思ったの？

【ActiveScript】RubyをWindowsで使うスレ【GUI】
http://hibari.2ch.net/test/read.cgi/tech/1155031689/

このスレでwindows+ruby+GUIは鬼門だと書いてたんだが、本当か？

だったら、C#やDelphiの方がwindowsでGUIは有利だな

コンパイラ言語の方がGUIには向いてるって事でおk？

Windowsなんか使うなよ... (´・ω・`)

>>807
特定の環境と特定の言語についての
たった一例から一般化しすぎだろ

Qtは最近JavaScriptを採用したぜ

JavaScriptの採用自体は結構前じゃなかったか

その通りなんだけど、強力にJavaScript推すようになったのは最近だよね。

うん、それは最近だ

>>808
ごめん……(´・ω・｀)でもなんで？

つ ttp://cruel.org/freeware/hacker.html

>>806
何が言いたいのかさっぱりわからん。
型推論で整数がこようが文字列がこようがバッチリやりたい処理ができてるじゃん。

やりたいことが出来るか否かじゃなくて
「型推論」で出来るって言ってるのがアホなの。
そりゃShow使って自分でcoerceすれば出来るわい。

ところで>>804ってどの辺が型推論なんだろう
Showを継承してる型aならなんでもいいよ、的なコードじゃないの？

>>818
showのどのインスタンスを呼び出すかを推論している。

アホすぎる。>>804とか思いっきり型の定義書いてるだろ。
多相型（総称型）と型推論を混同してる。

>>820
混同も何もhaskellでは同じだよ。

Show a以上に具体的な型が決まることはないように思うんだけどなあ

今日はJava厨がおとなしいな．．

素直に暇だから来てくださいって言えばいいのにｗ

来て欲しかったら自分からネタだしたら？

>>803
え…w

>>821
パラメトリック多相がない型推論もあるし、
型推論がないパラメトリック多相もある。

パラメトリック多相と(ユニフィケーションベースの)型推論は相性がいいが、
別々の技術要素だ。

君がHaskell村に籠もってるから、どっちも同じに見えるだけ。

>>826
いやいや、>>803とか書いちゃう低能が
その辺分かってるわけ無いじゃん
おそらくHaskell使ったこと無いJava厨でしょう

>>819
正確に言えば、>>804だけではshowのインスタンスは確定していない。
例えばどこかで add_prefix (x + 1)とかあったら、showのインスタンスが確定する。

一見するとコアージョンと同等なことを包含多態とパラメトリック多態の組み合わせで実現しているが、
単に文字列に変換するだけでなく、多段階のコアージョンならどうだろう？
式x + yについて、xとyはそれぞれ整数、多倍長整数、浮動小数点数、有理数、複素数のどれかを
互いに独立して与えられるとする。
xが整数でyが浮動小数点数ならば、xを浮動小数点数に変換する。
xが複素数でyが有理数ならば、yを複素数に変換する。

これを型クラスで実現できるか？

PHPの文字列⇔数値の自動変換はPerlを踏襲したんか？

Haskellでトイプログラムつくったことが誇りです

型族でいけそうなけなさそうな

動的言語は、型に関する条件とそれ以外の条件を区別しない
つまり (Show a) => ... と if ... then ... を区別したくない

それが危険だというなら、問題の本質は if の危険性であって
静的型付けは対症療法の一つにすぎない

問題の本質は人間の脳味噌の性能だろ

>>829
あの辺は自動変換というより「演算子が戻り値型を決めてる」って印象が強いかな

>>681は最新のPerlだと以下のように書けるかな？

print s/hoge/hage/r while <>;

Perlはワンライナーとしては有用だね

起動オプションを使えばループすら不要だしな。

perl -np -e "s/hage/hoge/g";

業務でJAVA使ってるけど、RUBYとかと比べるとやっぱひどいと思うわ
インターフェースとか、ジェネリックスはどういうつもりでああいう仕様なのか
小一時間問い詰めたくなる

言語なんてどうでも良い。

所詮、どんぐりの背比べ。似たり寄ったりだわ

じゃあ一生バイナリエディタだけ使ってあらゆるファイルを編集してればいいと思うよ
もちろんプログラミングも

Javaで文字列を引数とするような処理を
俺が動的言語に書き換えるなら引数を文字列化して処理する仕様にするかな

動と静をあわせ持った言語は無いの？

>>841
haskell、Ocamlなどの関数型言語はコンパイラとインタプリタ両方インストールされるの多いよ

貧乏土方は、Javaを使い、セレブ土方は、.NETを使い、その他のオシャレさんは、動的言語を使う
って感じか．．．

セレブ土方って何だよ

>>843
まあ、基幹業務みたいに信頼性重視はネットワーク、ローカル問わず静的
ネットサービスとか、Webや社内LANで情報やファイルのシェアは動的って住み分けになってる感は有るな

土方はどこでも土方だけどな

打ち合わせ相手にデザイナーが顔出すかどうかだけの違い

才能あるデザイナーが全部作ってるとかも耳にする事も有るが

ぶっちゃけ、静的か動的かは関係なくて、
コンパイラやIDEがどれだけソースコードの意味を理解して、
プログラマの開発をサポートできるかだよね。

それが静的言語なら静的に（実行しなくても）決まることが多いから
動的言語なら実行しないとわからないようなことが
実行する前からわかりやすいってだけで

煽ることしかできなくなったか

チームの開発効率の話を個人の資質の話にするバカ

>>832
> それが危険だというなら、問題の本質は if の危険性であって
> 静的型付けは対症療法の一つにすぎない

いや、問題の本質がどこにあるかは大して重要じゃないんだよ。
問題を解決するための糸口の一つにはなるかもしれないけど、
一番重要なのは、問題を解決するための方法として何が挙げられるか。

１．静的言語を使う。
２．ミスが無いように人間がひたすら頑張る
３．実行前にミスを無くすことは諦め、実行フェーズ以降に問題解決を先送りにする。

>>848
チームの開発効率と個人の資質も
どちらも大事だと思います。

チームの開発効率は、チーム内で一番優れた人の
個人の資質よりも上にはならない。

Javaは確かにコンパイルエラーは出してくれるけれど、デプロイに時間がかかるんで、
トライ＆エラーが面倒臭いんだよね。
コンパイル時間も短いとはいえ、時間食うんで、チリも積もればなんとやらなんだよね。

>>850
別の話を混ぜるなと言っている

>>849
静的な型付けは問題の一部を解決するだけ
=> 残りの部分はテストを書いたりして解決する必要がある
=> あれ？ちゃんとテスト書いたら一緒に型エラーも見つかるわ
=> 動的型付けでも良くね？

>>850
これは本当
自分、趣味グラマーだが、割とオープンな雰囲気の会社に勤めてた時期が有ったんだが、有能な人は他人のバグを修正しつつ自分の分の開発を進めるって言うのが常で、見てて可哀想だった

静的型付けで
記述が簡潔で
オブジェクト指向が組み込みで
obj.method() の形式でメソッドが呼び出せて
ネイティブコンパイル出来て
出来れば型推論もあると嬉しいんだけど

そんな言語無いかな

動的型付け言語が安全だろうとなかろうと、使いたい言語が全部動的型付けだから困ったもんだ

>>853
大規模になるとテストケースは爆発的に増えて、自動化でも網羅出来なくなる
そこに、最後まで型エラーも拭い去れないとか怖過ぎ

LLスレで教わったんだけどこれなんか

>>855
http://force7.de/nimrod/

かわいそうなのは有能なひとを集められないから

>>851
デプロイという言葉を知っているなら
ホットデプロイって言葉も知っていると思うけど？
開発中ならデプロイはコードを修正すると自動で完了する。

それにユニットテストはデプロイ環境でやるもんじゃない。
まさかいちいち手動でブラウザで実行してテストしてるの？

それから動的言語でも大規模になるとmod_perlや
mod_rubyなどを使うわけで、デプロイと同じように
Apacheの再起動が必要。

デプロイに関しては現実的には大差がない。

>>857
アリガトン
調べてみる！

>>853
> 静的な型付けは問題の一部を解決するだけ


問題の一部を解決するもの　＞ 問題の一部が解決できない物



例：エアバッグ搭載

交通事故の一部を解決するもの　＞　交通事故の一部が解決できない物


冷静になれよ。銀の弾丸などない。
どちらがベターかで話せ。

>>855
OcamlとF#かな。。。
OcamlはC並のネイティブ吐けるとか言われてるけど、haskellの勉強の過程で入門書読んだだけで、実際に使った事は無い

つーか、エラーは早い段階で分かったほうが
修正も早いってこと知らないのかな？

ソフトウェアだけのことじゃなくてなんでもそうだよ。
ミスは早いうちに対処していれば、リカバリー早くなる。


ユニットテストではすべてのテストを自動化できない。
=> どっちみち人間がすべての機能を実行してテストする必要がある。
=> あれ？ 人間がテストするならユニットテストで見つかるエラーも見つかるわ
=> ユニットテストいらなくね？

>>853が言っていることはこれと同じ。

>>863
静的型言語派だが、それも極端杉

※個人の感想です

>>863
俺も静的言語派だが、こんなアホと一緒にされるのは
ごめん被る

>>859
ホットデプロイでもロードに時間かかるじゃん。
コンパイルにも時間かかる。実行するのにも時間かかる。
数秒の時間ではあるけど、積もれば結構な時間だし、
トライ&エラーでサクサク開発というのとはちょっと違う
んだよなぁ。

例えば、この変数の値をちょっとみたいとか、関数の戻り値
を調べたいなと思った時に、デバッガでブレークポイントはって
止めて調べるといった手順をふむより、ちょっとprint文書いて
出力してみるといったことが、Javaの場合、ちょっと億劫に感じる。
ま、数秒の差ではあるんだけど。でも面倒くさい。

俺も静的言語派だが○○○○ ← ここに煽ることしかできなくなったセリフを入れてください。

>>867
> ホットデプロイでもロードに時間かかるじゃん。

だからユニットテストならデプロイは不要。
こっちを無視すんな。

人間がコード上の間違いを捜すほうが時間かかる。
塵も積もればな。

>>867
デバッガでブレークポイントはるだけなら、
コードの修正いらないんだから
デプロイもいらないじゃん。

ユニットテストならデプロイは不要って誰が決めたんだ？

しかし、Eclipseの糞重さは、イライラが積もるな

>>861
型に対して可能なテストは「その変数の指すオブジェクトに対して
これをすることはできるか？」だけだ。
一方、テストは通常オブジェクトの振る舞いについてテストする。
後者の方が明らかに強いテストで、後者を通るなら前者も通る。
だから、型エラーが出るならテストが不十分ってこと。

実際、動的言語で十分なカバレッジを達成したときには型エラー
なんて見ないぞ？実際に動的言語で開発した経験あるのか？

これでも読んで落ち着こうか

Strong Typing vs. Strong Testing
https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk

>>871
そもそも、ユニットテストとはユニットのテストなので
ウェブサーバーはもちろんデータベースなどの
ソースコード以外の外部の何かは使用しないのが常識。
テストを早く実行する妨げにもなる。

>>873
君は両方やるという考えはないのかな？

両方やると二度手間、無駄ではないかの答えは、
エラーは早く検出し早く直す物というのが答えだ。

>>873
> 実際、動的言語で十分なカバレッジを達成したときには型エラー
> なんて見ないぞ？実際に動的言語で開発した経験あるのか？

言い換えると

十分なカバレッジを達成しなければ
型エラーを見ることがあることだろ。

十分なカバレッジを得るまで時間がかかる。

>>873
それは当たり前だがや
そこまで行くのに、コンパイル時にエラーで見つかるのと、テストで見つけるのはどっちが早いかだがや

他のテストは実質的に同じ事するだがや

実際、動的言語で開発した場合に判明する、型不一致に起因する
エラーの割合なんて、全体の不具合の中で１％にも満たないだろ。
それより、動的言語から得られる恩恵の方がはるかに大きいよ。

Javaでありがちなヌルポとかにもお目にかからないしな。

「○○という条件なら問題ない」という言い方は、
「○○という条件を達成しないかぎり問題がある。」
と言い換えられます。

注意しましょうｗ

> Javaでありがちなヌルポとかにもお目にかからないしな。

え？

$obj = null;
$obj->foo();

これでヌルポにならない言語なんてあるの？
あ、エラーメッセージが違うとかそういう話かｗ

>>879
> それより、動的言語から得られる恩恵の方がはるかに大きいよ。

動的言語で得られる恩恵の殆どは
静的言語でできるからなぁ。

恩恵？　なにそれ？

>>875
いやいやいや、ユニットテストでもWWWやDB周りのテストも当然するだろ。
人がしなくていいんだよ、Mechanizeとか使ってテストケース書いて自動化も
できるし。何ゆってんの？

えーと、見つかるのが早いか遅いかが
争点になってますが、何で早くみつけなきゃいけないの？

静的言語だと、型の不一致が見つかったら
下手すりゃクラス構造とかの設計まで見直す必要が出てきて
修正が大変になるから早く見つかった方が良いだろうけど、
動的言語なら何時見つけても修正の手間は一緒だぞ？

Javaの設定ファイルは糞。XMLというだけで糞。マジキチ

>>883
それは機能テスト。

テスト自動化＝ユニットテストのように
間違ってる人多いんだよな。

>>884
> えーと、見つかるのが早いか遅いかが
> 争点になってますが、何で早くみつけなきゃいけないの？

直すまでの時間が短いから

>>884
> 静的言語だと、型の不一致が見つかったら
> 下手すりゃクラス構造とかの設計まで見直す必要が出てきて
> 修正が大変になるから早く見つかった方が良いだろうけど、
> 動的言語なら何時見つけても修正の手間は一緒だぞ？

その例だと、動的言語のほうが時間がかかる。

型の不一致が見つかる場合は、例えばこの変数に入れてはいけない
値をいれた時。一箇所直しても、他の箇所で入れてるかもしれない。

動的言語だと、あるコードを実行してそのことに気づいても、
気づいたところ以外で同じ間違いしている可能性を排除できない。

つまり捜し回ることになる。

>>886

ServletのdoPost()やdoGet()メソッドのテストも、立派な単体テストだろが。
何ゆってんの？

>>881
PythonもRubyもならないよ
Noneやnilのfooを呼んだってCよろしく0番地にアクセスするわけじゃないから

doPostやdoGetを直接呼べや。

>>890
エラーが表面化しないだけで、正しく動いてねーだろうがｗ

こういう状態が一番困る。

>>884
本気でそう思ってるの？
動的静的関係なく、後から手直しって大変になるのは変わらんぞ？
そりゃあ手直し自体は動的の方が楽だろうさ
でも、その分後から大量に発覚する確率も高いわけよ

一定の規模を超えると、後から発覚するバグの数に違いが大きく出ると感じてるんだがな

どっかで定量的に比較してないもんかね

プログラマが人間だっていう視点から言えば、追い込み時期にバグが見つかるのは心が折れるぞ
実際に逃げる奴も居るらしい

>>891
そんなもんテストになるかw
まぁ、がんばってフォームの入力値や、認証データ、環境変数、クッキーの値など、
想定する環境と同じようにメソッド渡せればいいかもしれんが、そのテストコードを
用意するだけでひと苦労だなw

>>889
えーと、単体テストでは出来る限り単体の
クラスをテストするって知ってるかな？

だから単体テストというわけだけど。

あんた、doPostやdoGetで
いろんな処理をしすぎてない？

コントローラではユーザー入力の値のチェックをする程度で
その後の処理はサービスクラスなどに渡すんだよ。
（そしてサービスクラスをユニットテストする）

動的言語のぬるぽ的なエラーは、Javaほどメンドクサイ事態になることはほとんどない。

>>894
だから、それはユニットテストじゃないってば。

ユニット＝単体。
お前がやってるのは単体ではない。

別に機能テストが無駄という意味じゃない
それはユニットテストではないという話だ。

たぶん初心者のようにコントローラで
コードをがしがし書いてるんだろうが、
まあどの言語でもいいからウェブフレームワークを勉強しろ。

今時doGetとかdoPostを使ってる時点で
15年前かよって思ったがな。

Java厨は、複数画面の遷移がある処理のテストも人が手動で動かして目視でやってるのか

○○厨っていってるやつは、
なにか恨みでもあるのか？

>>892
nil.foo()したらその時点で例外吐いて止まるよ

>>900
なんて例外？

ちょっとまて。画面の遷移と表示まで全自動なの？

nil pointer exceptionなんじゃね？

>>893
本音を言うと、型エラーが大量に発覚なんて一度も経験無いから、
そういうことを言う人はどういうコード書いてるのかなって思う。

こっちこそ聞きたいよ。あんたはそんなに型エラー発生させてるの？

C++使いにはあほらしい話題だ

単体テスト = TT

ソースを一番最初に読むのはコンパイラじゃなくて、書いた人
網羅しなくていいなら、検出する早さでも人が圧倒的に早いよ
機械でやるべきことは、多少遅くてもいいから網羅すること

>>897
あぁ、じゃぁStrutsのActionメソッドでもいいよ。Actionメソッドはテストするんだろ？
どっにしても、引数には、HttpServletRequestやHttpServletResponseが含まれるじゃねーか。
この引数とそれに対する挙動が正常なことを確認する単体テストはしないのかよ。気楽なもんだな。

>>896
バカか
ノウハウありゃ大した差では無いわ

それよりデバッグ終盤の自分が修正した箇所が他に影響してないって保証の方が安心感があるわ

自分自身の自信とは別で、保証されてるんだぜ？
デスマじゃ無い時は余裕もってテストを眺めてられるってもんよ

>>888
テストで見つかったところだけ直せば良いんだよ。
どうせ最終的には高いテストカバレッジまで持ってくんだろ？
だったら最終的には全部見つかるさ。

>>908
だから機能テストとしてはするが、
単体テストではしない。

その部分は単体テストをしなくていいように
コードを最小限にする。

>>902
マクロで書けるだろ
動的静的関係ない

結局議論は意味なくてシェアで決まるんだよな
Javascriptが今後どう変化していくかは注目。

>>897
>今時doGetとかdoPostを使ってる

何という俺。
職業プログラマじゃないんでフレームワークとか覚える時間が勿体ない。
どうせ1年に100個も画面を作らないし。

目視のテストで全自動ｗ

お前らテスト書く時間あっていいな。
ゲーム業界なんてプロトタイピング＝マスターアップだぞ。

ゲーム業界じゃあ動的言語は実行クソ遅すぎて
別の意味で使い物にならないのでは？

Strutsももう古いと思うがｗ

>>917
GCあった時点でアウト

>>915
全自動はねーよ
特にデザイン系は人間の感覚しか頼りにならん

いずれにしても、不具合のほとんどは、実行時に発生する。型の不一致をやらかす
ような奴は、学生か新人君ぐらいだろ。

ほとんどの不具合は、論理的なものや、例外の見逃しや、想定外の仕様や、挙動
によるものだ。

Javaだって、文字列に数値いれたはずが、数値に変換する時に例外発生したとか、
日付の書式変換で例外が発生したとか、そんなんが多いんだろ？

>>971
Lua が結構使われていると聞いた気が

Luna

Lua

Luaは使われてるけどデメリット解決されてない

使われているってことはメリットが大きいってことだろ

>>926
メリットが
・ホットスワップ可能
なんだけどね

>>921
> Javaだって、文字列に数値いれたはずが、数値に変換する時に例外発生したとか、
> 日付の書式変換で例外が発生したとか、そんなんが多いんだろ？

いまどきのフレームワークを使えば、
ユーザーの数字入力は数値型変数に直接がはいるイメージになる。
型変換コードは書かない。

型に合わない入力はフレームワークの設定で
簡単にエラーメッセージとして表示できるようになってる。

>>927
総合的なメリットの話をしているんだが

>>929
？

>>921
想定外の仕様ってか使用だな
これが一番厄介だ
GUI作る時はこれが地獄の元

CUIとか、専用機器の組み込みはこっちが処理の流れ作れるから楽

みんなウィザード気取ってるけどどうしょもないコードしか挙がってこない現実

>>928
なんでフォームからの入力値のチェック限定なんだよ
DBからの読み込み、ファイルからの読み込み、Webサービスの戻り値、リモートコールの呼び出し
INPUTはいろいろあるだろうが。

みんなテストの網羅率そんなに高いのか。
そーするとテストコードの量も増えそうだけど、動的言語はその辺不安じゃないのかな？
テストのテストまで書かないだろうし。
あとは型変換でこけるんじゃなくて、呼び出し元の仕様変更でパラメーター数が
変わらないような時もちょっと怖いかなと思ってるんだけどそうでもないのかな？モックにしてると気づかなさそうで。

new,deleteなんて忘れねーよという奴は信用しない

>>933
例えばファイルからの入力で
ファイルに数値が入っている前提だとして、
間違って文字列が入っていたとする。

静的言語ならすぐさま数値型変数にいれて
プログラムのメイン処理では全部数値型を使う。
だから、入力して変換する部分ですぐにバグがあることが表面化するけど

これが動的言語なら、文字列のまま
プログラムのメイン処理に進んでしまう。
バグが表面化するまで時間がかかる。

>>934
高いわけねーだろｗ

だがそれを認めると
テストコードがあるから動的言語でも大丈夫
という主張が崩れるんだよｗ

>>934
んにゃ
素人さん(？)が想像してるより泥臭い人力の場面は多分にあるw
人間の目しか信用出来ない場面って、結構あるべ

第一、ゲーム業界のゲームバランスなんて、人間以外何がやるってんだよwww

自分はプログラマじゃなくてテスターだったんだがなw
(ゲーム業界ではない)

>>936
% ruby -e 'Float("TNOK")'
-e:1:in `Float': invalid value for Float(): "TNOK" (ArgumentError)
% python -c 'float("TNOK")'
ValueError: could not convert string to float: 'TNOK'

>>937
えー、お前の所と一緒にすんなよ
まあテストしないなら静的言語の方が安全なんじゃね？
テストしてある動的言語のプログラムよりはボロいけど

楽したいじゃんといいつつテストは網羅するぜという矛盾

ところが実際は、動的言語でもほとんど問題にならないし、問題があってもたいていはすぐにわかる。

その数値を計算や、書式変換する必要があるなら、そこでエラーになるし。たんに表示するだけなら、
そもそも文字列として扱うだけだし。そのことが問題であれば、データの生成元の責任ということになる。

実際、動的言語で型の不一致で致命的なもんだいを引き起こすことなどほとんどないと言っていい。
ほんとうの不具合は、静的言語も動的言語も他のところにある。
型の不一致にたいして、どんだけ悲観的なんだよ。心配しすぎだろ。　他に心配しなきゃならんことが
いくらでもあるだろが。

どのくらいのコードサイズ前提で語ってるか宣言してから書き込んでくれ

フラットなコードと、きちんとモジュール化されたコードでは
同じサイズのコードでも取り回しが全然違う件

>>941
静的言語ならテストは網羅しなくていいとか冗談きついぜ

さぁ、寝るか

してないくせに何いってんだ

何を持って網羅っていってんの？

業務系に限って言えば、型は数値と文字列と配列と連想配列があれば、ほとんどの処理は大丈夫だな。

>>942
んなの当たり前
問題わな
製品として出した後から修正出来ないとか、修正が難かしい(許可が下りにくいとか時間が掛かるとか)

そういう環境に動的言語は向かないんよ

一回出したらバグが在ろうが何だろうが、余程ひどいバグじゃない限り走らせ続けるってプログラムは大規模でも組み込みでも多いのよ

修正が容易かどうかじゃなくて、どの位の動作が保証出来るか？が重要なんだよ

>>948
たぶんC0カバレッジ

型はbyteしかなくてもいいｗ

>>950
本番前のテストでの修正が容易いって言ってんだよ
なんで本番後の話になってんだよ
動作の保証はテストでやれよ

机上の空論

実際、動的言語では型はあまり意識しない。という意識はするが、
そこまで神経質に気をはって使うわけではない。だいたい型の種類も
少ないが、基本は文字列。数値として使う場合は、それが数値として
使えればいい。極端にいえば、その変数が数値としての性質もって
いればいい。いわゆる、ダックタイピングってやつで、それが流儀
みたいな感じになってしまった。そいつがガーと鳴けばアヒルだろうと。

>>953
それは本質的に動的も静的も同じだろ
テストも万能ではないのは結構前から知られてるし、そうなると静的型言語が選ばれる事になる

客にとっては開発が容易とか関係無いのよ
客にとって、オペレーターとか、エンドユーザーの奇想天外な操作でも対応出来るかどうかが問題なだけ
テストとは別の形で保証出来るから採用されるんだよ

本質的に同等のクオリティに出来るとしてもね
作ってる側も、本質的に同等のクオリティだと太鼓判押せないし、そんな責任取りたくないし

>>953
動作の保証じゃなくて、
文法の保証はいつやるべき？

１００じゃないんだから０でもいっしょだろ！

>>958
詐欺罪でタイーホ

静的言語は動作後が楽になるんじゃなくて
動作までが楽になると考えればいい。

ここまで読んだ。
本気でTDDとかBDDって流行ってないんだね。

>>961
どの言語でもできる手法では優位に立てない
優位に立てないなら安全とは言えない
という論調が強いからね
要は、克己的なことより他人との比較を重視する人が多い

　　　　　　　　まもなくここは　乂1000取り合戦場乂　となります。

　 　 　 ＼∧＿ﾍ　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　,,､,､,,,　/ ＼〇ノゝ∩ ＜　1000取り合戦、いくぞｺﾞﾙｧ！！　　　　　　　,,､,､,,,
　　　　/三√ ﾟДﾟ)　/　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿　　,,､,､,,,
　　 　　/三/| ﾟＵﾟ|＼　　　　　　,,､,､,,,　　　　　　　　　　　　　　　　　　　　　　　,,､,､,,,
　,,､,､,,,　Ｕ （:::::::::::）　　,,､,､,,,　　　　　　　　　＼オーーーーーーーッ！！／
　　 　 　//三/|三|＼　　　　　∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　∪　 ∪　　　　　　 （　　　　）　　　 （　　　　 ）　　　（　　　　）　　　 ）
　,,､,､,,,　　　　　　　,,､,､,,,　　∧＿∧∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　,,､,､,,,　　　　　　 （　　　　）　　　 （　　　　）　　　 （　　　　）　　　 （　　　　）

動的言語でもプログラム中のAPIドキュメントととして関数なりメソッドなりの入り口に
想定される引数の型と戻り値の型を書くと思うんだけど、これを利用しないのって勿体無くない？
少なくとも処理系作る側になると型情報は欲しい。

強力な型システムがあればそれをそのまま型としてコード内で2級以上の市民として扱えるいうのはある
ただプログラマがそれを利用できるかは別問題な

一時期Cで組み込み型排除して全部enumとtypedef用意してた

>>964
Pythonでtype annotationとかそれっぽいのがあった気がする
よくよく調べたらがっかりした覚えがあるけど

annotationでは駄目なのだ
言語内で1級市民として扱える仕組みでないと

Pythonなら俺は、例えば数値を受け取るメソッドを

def foo(n):
    n = int(n)

で書き始めるかな

動的言語は型の扱いがややこしい。
混乱の元だよね。

分かって使ってるとへ思えない
理解するくらいなら他の言語のほうがいい

pythonで
>>> "12"+1
を実行すると
TypeError: cannot concatenate 'str' and 'int' objects
っていうエラーが出てきます。
動的言語なのになんでですか？

>>970
処理系が解釈するのも人間が解釈するのも複雑で、デメリットのほうが多いような気がしてる。