アカウント名:
パスワード:
静的型付けがあると機械的に検証しやすいのでバグ削減効果があるのはわかるが、それも程度問題じゃないかな?文法的にも記述的にもなんの問題もないが、その動作では都合が悪いという仕様バグの方がよほど大きな問題であるケースが多数派だと思うのです。
:wq
静的型付けな言語の方がIDEのサポートが強力に作用するってのもある。Rubyなんかは実行上は型安全だけどIDEがサポートしやすい型安全性が全力で否定されてるのでだいぶキツい。
rubyでプログラム組んでるけど、rubyで開発するのは正直地獄だと思う・実行してみたら、メソッドがないと言われて落ちる・ある機能を実装→うまくいかない→あるメソッドで渡す型がメソッドの期待するものと違っていたなんてことが良く起こるし…
ruby推進派に言わせればテスト書けというけど、テスト書くのって面倒なんですよ(中にはテスト書けないやつもあるし)
Ruby固有の話は特にないようなので、あなたの会社ではPHPもPythonもダメですね。
テスト書かないで、そこそこの規模の物を作るの?正直、信じられんな。テストないと、デバッグしてるつもりがバグ入れに、てなっちゃうじゃん。
自分はヘタレなので、コンパイルが通った後は、変数の取り違いやロジックの書き間違いのデバグに苦しめられる。むしろ、動的型付けの方が抽象度が高い分、簡潔に書けるために、変数の取り違いやロジックの書き間違いは少な目だし、早い段階から動的にチェックできるので、早く書き上げられる。
まあ、動的型付けの言語を使っていても、静的にチェックできる部分はチェックしたいとは思うけど、動的型付けの言語で書くのは自分用のものだから、実行時エラーがあっても、その都度、直すので、結局のところ、どうでも良かったりする。
#ただ、弱い型付けだけは勘弁。
テストは書いてるけど、正直言って面倒です静的言語なら必要ない部分まで書かないといけないので…
> テストないと、デバッグしてるつもりがバグ入れに、
の意味がわかってないのか...あとで作業が増えて結局はるかに面倒になるよってことなのに。
世にはテストコード否定するところがあるんですよ。。しょぼいバグが多いわ見ただけでエラーになるパターンあるわ。で、言うと切れる、おまえがおかしいと人格攻撃もセットなのが特徴ですね。
ユニットテスト見せたら、あんな奴いらんと会社に言われて切られるというオチも一度。
それrubyじゃなくダックタイプ系言語共通の話だよね。
てかテスト書くの面倒って……釣りだよね?釣りじゃなきゃ、一刻も早くIT業界からドロップアウトすべきだ。その方が本人にもその会社にも社会全般にもいい。
書ける部分はもちろん書いてますし、書かないでリファクタリングなんて恐ろしくてできないんですが…実物がないとテストができないやつとかあるんですよ設計が悪いと言われればそれまでですが
上の人とは別人ですが。ある程度の規模ならテストを書いたほうがいいのは当然ですが、書いたところで>実行してみたら、メソッドがないと言われて落ちる>ある機能を実装→うまくいかない→あるメソッドで渡す型がメソッドの期待するものと違っていたというのはあまり有効に排除できませんからねぇ。テストケース自動生成とかがもっと発達すればどうなるか分かりませんが、そういうのは静的型付けのお家芸ですし。
結局コード内にドキュメントとして型を書くとか、関数の入り口で型チェックするとかいう話になって、それなら静的型付けでいいんじゃないかということに・・・
個人的にRubyはPythonなどに比べて特に動的型付けの暗黒面が強い印象がありますが、なんででしょうね。DSLみたいなアクロバティックな部分が多いからでしょうか。# javascriptはほとんど触ったことないですがあれも大変そう
わたしは Python より Ruby のブロックの方に魅力感じますけどねぇ。Python、書き方よく分からんというのもあるけど。配列に突っ込むときの型チェックというけど、動的言語のチェックは、静的言語における型チェックとは違いますよねぇ。メソッドのあるかなしかのチェックで、型チェックじゃない。すると、配列に適応する処理の抽出の仕方が、そもそも動的言語と静的言語とはまったく違う。同じメソッドがあり、その結果が期待通りでさえあれば、型は違っていていい。それと相まって、ブロックでの処理ぶん回しって、なかなか魅力あると思うんですけど。まあ、用もないところでの黒魔術は止めてくれというのは、同意します。テストは、致命的バグ仕込まない程度の要所要所でいいのでは?足りない分は、リファクタするとき、慌てて追加www
VBが一番理想的だなと思ったVal型なら動的言語として振る舞い、必要なら型を指定できるという
javaのrequestクラスや、関数プログラムのモナドみたいに、大枠は静的だけど、内部の各メンバは動的やり放題とか、スクリプト言語でも、オブジェクト拡張時には性的だとかドッチもドッチにしか見えないですが、、
もううろ覚えだけど、String 型の a = "1", b = "2" に対して、a + b と書くとコンパイルエラーにも実行時エラーにもならずに 3 になるような言語が理想的なんですか?
>スクリプト言語でも、オブジェクト拡張時には性的だとか
拡張時には性的……(ゴクリ)
>ruby推進派に言わせればテスト書けというけど、テスト書くのって面倒なんですよ
面倒じゃないやり方もある。勉強しましょう。
>(中にはテスト書けないやつもあるし)
自動テストの普及前はともかく、現在ではテストのかけない設計は悪い設計です。勉強しましょう。
勉強しないで新しいやり方をやると地獄なのは、Rubyに限らず当たり前ですね。
Rubyは過大な勉強を強いるプログラミング言語ってことですね。もっと楽な他の言語を使います。
ヤメテ!これいじょうPHPの評判を下げるのはやめて!
勉強しないでプログラムをしようとする人は、あとでより苦労をすることになるのだが。
苦労が好きならどうぞ。でもなるべく、まわりりに迷惑をかけないでね。
そうやって車輪の再発明は繰り返されるのだろうな
ふむう。面倒でないやり方とは?
向き不向きはありますが、テスト駆動開発をしっかりやると、流れ作業的にさくさくと進むので、面倒さがかなり減ります。
> ある機能を実装→うまくいかない→あるメソッドで渡す型がメソッドの期待するものと違っていた
これは文法エラーと同じレベルのもので、そもそもプログラムとして動かないでしょうから、commitされることはほとんど無いでしょうし、今回のような評価の場合には、問題としては出てこないでしょうね。
コードを書くのがどれだけ楽かというもっと人間寄りの評価をすれば、この辺りは問題になってくるかも知れませんが。
お前は、プログラマーを、特にPHPerという人種をなめている。
「gitの最新ソースで、型が違うってエラーが出たんだけど」「eclipseで構文エラーは出ていないので、動くと思ってコミットした。通すの面倒だから動作確認はしていないしテストは面倒なので書いていない(キリッ」
なんてざらですよ。これ一つとっても、コンパイルのある静的型付け言語の方が優れていると感じます。
# そこまで酷くなくても、PHPとかはそもそも変数の型が状況によって変わることがありえてしまうので、このパターンは通ったけど別パターンだと型エラー、みたいなソースが書けてしまうのですよね…
テストが通ってないのにリリースされる言語なので [tokumaru.org]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
それでも銀の弾丸ではない (スコア:3, 興味深い)
静的型付けがあると機械的に検証しやすいのでバグ削減効果があるのはわかるが、それも程度問題じゃないかな?
文法的にも記述的にもなんの問題もないが、その動作では都合が悪いという仕様バグの方がよほど大きな問題であるケースが多数派だと思うのです。
:wq
Re: (スコア:2, 興味深い)
静的型付けな言語の方がIDEのサポートが強力に作用するってのもある。
Rubyなんかは実行上は型安全だけどIDEがサポートしやすい型安全性が全力で否定されてるのでだいぶキツい。
Re:それでも銀の弾丸ではない (スコア:0)
rubyでプログラム組んでるけど、rubyで開発するのは正直地獄だと思う
・実行してみたら、メソッドがないと言われて落ちる
・ある機能を実装→うまくいかない→あるメソッドで渡す型がメソッドの期待するものと違っていた
なんてことが良く起こるし…
ruby推進派に言わせればテスト書けというけど、テスト書くのって面倒なんですよ
(中にはテスト書けないやつもあるし)
Re:それでも銀の弾丸ではない (スコア:3, すばらしい洞察)
Ruby固有の話は特にないようなので、あなたの会社ではPHPもPythonもダメですね。
Re: (スコア:0)
テスト書かないで、そこそこの規模の物を作るの?
正直、信じられんな。
テストないと、デバッグしてるつもりがバグ入れに、
てなっちゃうじゃん。
Re: (スコア:0)
Re: (スコア:0)
自分はヘタレなので、コンパイルが通った後は、変数の取り違いやロジックの書き間違いのデバグに苦しめられる。むしろ、動的型付けの方が抽象度が高い分、簡潔に書けるために、変数の取り違いやロジックの書き間違いは少な目だし、早い段階から動的にチェックできるので、早く書き上げられる。
まあ、動的型付けの言語を使っていても、静的にチェックできる部分はチェックしたいとは思うけど、動的型付けの言語で書くのは自分用のものだから、実行時エラーがあっても、その都度、直すので、結局のところ、どうでも良かったりする。
#ただ、弱い型付けだけは勘弁。
Re: (スコア:0)
テストは書いてるけど、正直言って面倒です
静的言語なら必要ない部分まで書かないといけないので…
Re: (スコア:0)
> テストないと、デバッグしてるつもりがバグ入れに、
の意味がわかってないのか...
あとで作業が増えて結局はるかに面倒になるよってことなのに。
Re: (スコア:0)
世にはテストコード否定するところがあるんですよ。。
しょぼいバグが多いわ見ただけでエラーになるパターンあるわ。
で、言うと切れる、おまえがおかしいと人格攻撃もセットなのが特徴ですね。
ユニットテスト見せたら、あんな奴いらんと会社に言われて切られるというオチも一度。
Re: (スコア:0)
それrubyじゃなくダックタイプ系言語共通の話だよね。
てかテスト書くの面倒って……釣りだよね?
釣りじゃなきゃ、一刻も早くIT業界からドロップアウトすべきだ。
その方が本人にもその会社にも社会全般にもいい。
Re: (スコア:0)
書ける部分はもちろん書いてますし、書かないでリファクタリングなんて恐ろしくてできないんですが…
実物がないとテストができないやつとかあるんですよ
設計が悪いと言われればそれまでですが
Re: (スコア:0)
上の人とは別人ですが。
ある程度の規模ならテストを書いたほうがいいのは当然ですが、書いたところで
>実行してみたら、メソッドがないと言われて落ちる
>ある機能を実装→うまくいかない→あるメソッドで渡す型がメソッドの期待するものと違っていた
というのはあまり有効に排除できませんからねぇ。
テストケース自動生成とかがもっと発達すればどうなるか分かりませんが、そういうのは静的型付けのお家芸ですし。
結局コード内にドキュメントとして型を書くとか、関数の入り口で型チェックするとかいう話になって、
それなら静的型付けでいいんじゃないかということに・・・
個人的にRubyはPythonなどに比べて特に動的型付けの暗黒面が強い印象がありますが、なんででしょうね。
DSLみたいなアクロバティックな部分が多いからでしょうか。
# javascriptはほとんど触ったことないですがあれも大変そう
Re: (スコア:0)
わたしは Python より Ruby のブロックの方に魅力感じますけどねぇ。
Python、書き方よく分からんというのもあるけど。
配列に突っ込むときの型チェックというけど、
動的言語のチェックは、静的言語における型チェックとは違いますよねぇ。
メソッドのあるかなしかのチェックで、型チェックじゃない。
すると、配列に適応する処理の抽出の仕方が、
そもそも動的言語と静的言語とはまったく違う。
同じメソッドがあり、その結果が期待通りでさえあれば、型は違っていていい。
それと相まって、ブロックでの処理ぶん回しって、なかなか魅力あると思うんですけど。
まあ、用もないところでの黒魔術は止めてくれというのは、同意します。
テストは、致命的バグ仕込まない程度の要所要所でいいのでは?
足りない分は、リファクタするとき、慌てて追加www
Re:それでも銀の弾丸ではない (スコア:1)
VBが一番理想的だなと思った
Val型なら動的言語として振る舞い、必要なら型を指定できるという
Re: (スコア:0)
javaのrequestクラスや、関数プログラムのモナドみたいに、
大枠は静的だけど、内部の各メンバは動的やり放題とか、
スクリプト言語でも、オブジェクト拡張時には性的だとか
ドッチもドッチにしか見えないですが、、
Re: (スコア:0)
もううろ覚えだけど、String 型の a = "1", b = "2" に対して、a + b と書くとコンパイルエラーにも
実行時エラーにもならずに 3 になるような言語が理想的なんですか?
Re:それでも銀の弾丸ではない (スコア:1)
>スクリプト言語でも、オブジェクト拡張時には性的だとか
拡張時には性的……(ゴクリ)
Re: (スコア:0)
それそのもの(メソッドがあるか自体)のテストはないなど、あきらかに不要なチェックはしないし、昔の単純なコンパイラよりも効率的にテストに織り込まれていくし、すぐに動かしたければコンパイルなしで動き出す。
ただ最近の型推論を備えてきている言語のコンパイラは優秀なので、そんなのコンパイルすりゃわかるじゃんという場面も多いよね。
Re: (スコア:0)
>ruby推進派に言わせればテスト書けというけど、テスト書くのって面倒なんですよ
面倒じゃないやり方もある。
勉強しましょう。
>(中にはテスト書けないやつもあるし)
自動テストの普及前はともかく、
現在ではテストのかけない設計は悪い設計です。
勉強しましょう。
勉強しないで新しいやり方をやると地獄なのは、
Rubyに限らず当たり前ですね。
Re: (スコア:0)
Rubyは過大な勉強を強いるプログラミング言語ってことですね。
もっと楽な他の言語を使います。
Re: (スコア:0)
ヤメテ!
これいじょうPHPの評判を下げるのはやめて!
Re: (スコア:0)
勉強しないでプログラムをしようとする人は、
あとでより苦労をすることになるのだが。
苦労が好きならどうぞ。
でもなるべく、まわりりに迷惑をかけないでね。
Re: (スコア:0)
そうやって車輪の再発明は繰り返されるのだろうな
Re: (スコア:0)
ふむう。面倒でないやり方とは?
Re: (スコア:0)
向き不向きはありますが、
テスト駆動開発をしっかりやると、
流れ作業的にさくさくと進むので、
面倒さがかなり減ります。
Re: (スコア:0)
> ある機能を実装→うまくいかない→あるメソッドで渡す型がメソッドの期待するものと違っていた
これは文法エラーと同じレベルのもので、そもそもプログラムとして動かないでしょうから、
commitされることはほとんど無いでしょうし、今回のような評価の場合には、問題としては出てこないでしょうね。
コードを書くのがどれだけ楽かというもっと人間寄りの評価をすれば、この辺りは問題になってくるかも知れませんが。
>commitされることはほとんど無いでしょう (スコア:0)
お前は、プログラマーを、特にPHPerという人種をなめている。
「gitの最新ソースで、型が違うってエラーが出たんだけど」
「eclipseで構文エラーは出ていないので、動くと思ってコミットした。通すの面倒だから動作確認はしていないしテストは面倒なので書いていない(キリッ」
なんてざらですよ。これ一つとっても、コンパイルのある静的型付け言語の方が優れていると感じます。
# そこまで酷くなくても、PHPとかはそもそも変数の型が状況によって変わることがありえてしまうので、このパターンは通ったけど別パターンだと型エラー、みたいなソースが書けてしまうのですよね…
Re: (スコア:0)
テストが通ってないのにリリースされる言語なので [tokumaru.org]