アカウント名:
パスワード:
バグってるからデバッガで追いかけてみたら、maxLengthのスペルミスでmaxlengthだったとか、そんなのが多くていやになるわ。世の中動的型の言語のファンが多いけど、こういうアホなミスをするのって俺だけなのか。最近はサーバーサイドまでjavascriptを使おうって動きがあるみたいだけど、ほんとうにかんべんしてほしい。
> maxLengthのスペルミスでmaxlengthだったとか、そんなのが多くていやになるわ。
そういうケアレスミスは言語に関係なくあるよ
コンパイルエラーになるか、ランタイムエラーになるかの違いは、大きいと思うんだ。動的言語の場合、エラーにさえならないことがあって、よりたちが悪い。
動的言語の場合、エラーにさえならないことがあって、よりたちが悪い。
run-timeよりまえにバリデーションしたいなら、例えばjavascriptだったらjavascript lintにかければよいと思います。eclipseでjavascript lintをつかって事前validationしていた経験があります。https://www.google.co.jp/search?q=javascript+lint [google.co.jp]
compilerやlinkerがエラーを出すのは原則的にはプログラマーのためでなく自分たちの(タスクが完了できない)ためで、その作業自体がないインタプリタ言語では。。。
# インタプリタ言語の場合、run-timeと対になる意味でのcompile-timeってなんていうんだろ。。。
必ずしもそうではないし、インタプリタ言語もいまどきはJITコンパイルですよ。
これはコンパイルの有無じゃなくて動的かどうかってことです。静的なら実行前に、その変数がどのクラスのオブジェクトか決まっていて、呼び出したメソッドがあるかどうかは実行前に決定されてるけれど、動的だとクラスは決まってないし、違うクラスでも実行時にメソッド追加されるかもしれないしで、実行時でないとそのメソッドの呼び出しがエラーかどうかがわからない。つまり言語仕様として許されているかどうかです。その意
"コンパイルエラー"に対する発言ということで静的型付けだけで書いてたのでご指摘thxです。おっしゃるとおり、動的型付け言語ではrun-timeでしかつかまえられない、逆にrun-timeでしか、しかも動作する条件が揃わないと発見し得ないエラーが存在しますね。。。そういったrun-time errorに関して静的解析ツールもあるにはありますが、あたりまえですが一般的なコンディションしかチェックできませんし、結果的にはUnitTest的な解決法が無難かもです。(UnitTestで条件抽出の網羅性とか頑張る必要は当然あります)
perlはコンパイルフェーズって言ってます。pythonは特に名前なさそうですが、コンパイルフェーズ・コンパイルタイムどっちでも意味通るんじゃないかな。
コメありがとうございます。やっぱりコンパイルと言うんですね。勉強になります。
あたりまえですが一般的なコンディションしかチェックできませんし、結果的にはUnitTest的な解決法が無難かもです。(UnitTestで条件抽出の網羅性とか頑張る必要は当然あります)
で、大規模開発だと強制されなければ品質が保てない。過度に動的なのはバグの元、ってのと、静的だと柔軟性が損なわれ開発スピードが損なわれる。時代はアジャイル、ってのとjava vs LLでよくあるパターン
ま、用途ですよね。ちょっとしたアプレットやスキンとかの類ならpythonやjavascriptが合うだろうし、大きなアプリならやっぱりC++じゃないかと。現状がそうであるように。
>静的だと柔軟性が損なわれ開発スピードが損なわれる。時代はアジャイル、ってのとアジャイル開発と動的言語とは関係ないと思うが。たぶんアジャイル開発のことをよく分かって無い人の発言と思われ。
そもそも静的だから開発速度が落ちるかというと、むしろ逆のことの方が多いかな。なにしろ動的言語だと、タイプ量は減ってもそれ以上にデバッグに時間がかかるから。規模が大きくなればなるほど致命的になる.
大規模開発だと強制されなければ品質が保てない。過度に動的なのはバグの元、ってのと、静的だと柔軟性が損なわれ開発スピードが損なわれる。時代はアジャイル、ってのとjava vs LLでよくあるパターン
全くもってそのとおりです(´・ω・`)最近ではbakeしろだの、CIUnitつかえだの言われながら、前述のトレードオフの狭間で揺れ動くσ(゚∀゚ )オレ的な日常でございます。結局は両極端でなく現実解としてよい落とし所をみつけないといけないですね。。。# そういえば昔C++でUnitTest超マジメに組んだらほんと一生楽しめそうな雰囲気でした
別AC(#2330722)ですが一言コメントします。
アジャイル開発と動的言語とは関係ないと思うが。
もちろんそれぞれの要素は独立していますが、動的言語=lightweight languageと仮定すれば、軽量かつ高速開発を意図したagile developmentと方向性は合致していると思います。そういう意味で、agileでLLを使う頻度は静的型付けのものと比べて高いものとおもいますので、無理な発言ではないと私は考えました。
そもそも静的だから開発速度が落ちるかというと、むしろ逆のことの方が多いかな。なにしろ動的言語だと、タイプ量は
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
Javascript, Ruby, Python, PHP あたりの動的型の言語は普及してほしくない (スコア:0)
バグってるからデバッガで追いかけてみたら、maxLengthのスペルミスでmaxlengthだったとか、そんなのが多くていやになるわ。
世の中動的型の言語のファンが多いけど、こういうアホなミスをするのって俺だけなのか。
最近はサーバーサイドまでjavascriptを使おうって動きがあるみたいだけど、ほんとうにかんべんしてほしい。
Re: (スコア:3)
> maxLengthのスペルミスでmaxlengthだったとか、そんなのが多くていやになるわ。
そういうケアレスミスは言語に関係なくあるよ
Re: (スコア:1)
コンパイルエラーになるか、ランタイムエラーになるかの違いは、大きいと思うんだ。
動的言語の場合、エラーにさえならないことがあって、よりたちが悪い。
Re: (スコア:1)
動的言語の場合、エラーにさえならないことがあって、よりたちが悪い。
run-timeよりまえにバリデーションしたいなら、例えばjavascriptだったらjavascript lintにかければよいと思います。eclipseでjavascript lintをつかって事前validationしていた経験があります。
https://www.google.co.jp/search?q=javascript+lint [google.co.jp]
compilerやlinkerがエラーを出すのは原則的にはプログラマーのためでなく自分たちの(タスクが完了できない)ためで、その作業自体がないインタプリタ言語では。。。
# インタプリタ言語の場合、run-timeと対になる意味でのcompile-timeってなんていうんだろ。。。
Re: (スコア:1)
compilerやlinkerがエラーを出すのは原則的にはプログラマーのためでなく自分たちの(タスクが完了できない)ためで、その作業自体がないインタプリタ言語では。。。
必ずしもそうではないし、インタプリタ言語もいまどきはJITコンパイルですよ。
これはコンパイルの有無じゃなくて動的かどうかってことです。
静的なら実行前に、その変数がどのクラスのオブジェクトか決まっていて、呼び出したメソッドがあるかどうかは実行前に決定されてるけれど、動的だとクラスは決まってないし、違うクラスでも実行時にメソッド追加されるかもしれないしで、実行時でないとそのメソッドの呼び出しがエラーかどうかがわからない。
つまり言語仕様として許されているかどうかです。その意
Re: (スコア:0)
"コンパイルエラー"に対する発言ということで静的型付けだけで書いてたのでご指摘thxです。
おっしゃるとおり、動的型付け言語ではrun-timeでしかつかまえられない、逆にrun-timeでしか、しかも動作する条件が揃わないと発見し得ないエラーが存在しますね。。。そういったrun-time errorに関して静的解析ツールもあるにはありますが、あたりまえですが一般的なコンディションしかチェックできませんし、結果的にはUnitTest的な解決法が無難かもです。(UnitTestで条件抽出の網羅性とか頑張る必要は当然あります)
perlはコンパイルフェーズって言ってます。
pythonは特に名前なさそうですが、コンパイルフェーズ・コンパイルタイムどっちでも意味通るんじゃないかな。
コメありがとうございます。やっぱりコンパイルと言うんですね。勉強になります。
Re:Javascript, Ruby, Python, PHP あたりの動的型の言語は普及してほし (スコア:0)
あたりまえですが一般的なコンディションしかチェックできませんし、結果的にはUnitTest的な解決法が無難かもです。(UnitTestで条件抽出の網羅性とか頑張る必要は当然あります)
で、
大規模開発だと強制されなければ品質が保てない。過度に動的なのはバグの元、ってのと、
静的だと柔軟性が損なわれ開発スピードが損なわれる。時代はアジャイル、ってのと
java vs LLでよくあるパターン
ま、用途ですよね。
ちょっとしたアプレットやスキンとかの類ならpythonやjavascriptが合うだろうし、
大きなアプリならやっぱりC++じゃないかと。現状がそうであるように。
Re:Javascript, Ruby, Python, PHP あたりの動的型の言語は普及してほし (スコア:1)
>静的だと柔軟性が損なわれ開発スピードが損なわれる。時代はアジャイル、ってのと
アジャイル開発と動的言語とは関係ないと思うが。
たぶんアジャイル開発のことをよく分かって無い人の発言と思われ。
そもそも静的だから開発速度が落ちるかというと、むしろ逆のことの方が多いかな。
なにしろ動的言語だと、タイプ量は減ってもそれ以上にデバッグに時間がかかるから。
規模が大きくなればなるほど致命的になる.
Re: (スコア:0)
大規模開発だと強制されなければ品質が保てない。過度に動的なのはバグの元、ってのと、
静的だと柔軟性が損なわれ開発スピードが損なわれる。時代はアジャイル、ってのと
java vs LLでよくあるパターン
全くもってそのとおりです(´・ω・`)
最近ではbakeしろだの、CIUnitつかえだの言われながら、前述のトレードオフの狭間で揺れ動くσ(゚∀゚ )オレ的な日常でございます。
結局は両極端でなく現実解としてよい落とし所をみつけないといけないですね。。。
# そういえば昔C++でUnitTest超マジメに組んだらほんと一生楽しめそうな雰囲気でした
Re: (スコア:0)
別AC(#2330722)ですが一言コメントします。
アジャイル開発と動的言語とは関係ないと思うが。
もちろんそれぞれの要素は独立していますが、動的言語=lightweight languageと仮定すれば、軽量かつ高速開発を意図したagile developmentと方向性は合致していると思います。
そういう意味で、agileでLLを使う頻度は静的型付けのものと比べて高いものとおもいますので、無理な発言ではないと私は考えました。
そもそも静的だから開発速度が落ちるかというと、むしろ逆のことの方が多いかな。
なにしろ動的言語だと、タイプ量は