アカウント名:
パスワード:
十分かつできの良い仕様書があってそれを元にコードを書くのなら型ありの言語も良いとは思う。
これは何を言っているんだろう?逆に不十分なドキュメントしかない環境では,動的型付けの言語の方が優れていると言いたい?
私の理解が間違いでなければ,動的型付けであれば, 開発者が意図していない型をもつ入力が与えられても,なんとなく動作しているように見えることがある,という話になるのだと思います.そして変な入力が与えられたら, その時は実行時にコケればいい.「ドキュメントに書かれてないし, それはそれでいいんだよ」という考え方でしょうか?
たぶん, この宗教論争で一つの争点の中心になるのは,これを「正しい」とするか「誤り」とするかの違いだと思います.
# 私はこれは誤りで,# 発覚した時点でドキュメントの修正に戻るのが本筋だと思います.# その具体的なタイミングを測るために,# コンパイルエラーとして怒られた方がいい
静的型付けなら意図しない型が入力に与えられることがないといっても、型さえ合っていれば間違いは見過ごされるから、なんとなく動作しているように見えることがある。そういう、型チェックで防げないバグは、実行時にもコケないからことがあるから検出が難しい。ロジックが間違っている場合も同様。
そういうバグや誤りに対しては、入力やコードをいじりながら試すのが手っ取り早いデバッグ手法となることが多いけど、静的型付けだと変数の型が変わってしまうような変更は難しいから、デバッグで使える手法が限定されてしまう。コードをいじるのはとんでもないという
コンパイルエラーで防げないバグはテストを書くのが一般的でしょう.その点, 動的型付け言語でも同じようにテストを書くけど,コードから型を判断できないため,境界テストのように論理的にテストを抽象化したとしても,テストの領域が無駄に大きく取る必要が出てくる.静的型付けはその型についてのみ考えればいい.
静的型付けだと変数の型が変わってしまうような変更は難しいから
全体で整合性を取ることが最終的に必要になるなら難しさは大差ないよ.仮に動的言語で部分的に変更をした場合,言語の機能により不整合な箇所を埋めてる.それが正しいとチェックする手間は, 型を変更する手間と大差ない.
動的言語と、詳細なドキュメントで設計を行う手法は、そもそもあまり相性がよくないのではないですかね。
それをやるなら静的言語がいいのは当たり前といえば当たり前で。
動的言語でやるための前提として、ドキュメントと同じくらいわかりやすい自動テストのテストケース、とか言うのがあると思いますが。
その辺を書ける能力は身につけたうえで、言っているのですかね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
最後の段落の意味? (スコア:2)
十分かつできの良い仕様書があってそれを元にコードを書くのなら型ありの言語も良いとは思う。
これは何を言っているんだろう?
逆に不十分なドキュメントしかない環境では,
動的型付けの言語の方が優れていると言いたい?
私の理解が間違いでなければ,
動的型付けであれば, 開発者が意図していない型をもつ入力が与えられても,
なんとなく動作しているように見えることがある,
という話になるのだと思います.
そして変な入力が与えられたら, その時は実行時にコケればいい.
「ドキュメントに書かれてないし, それはそれでいいんだよ」という考え方でしょうか?
たぶん, この宗教論争で一つの争点の中心になるのは,
これを「正しい」とするか「誤り」とするかの違いだと思います.
# 私はこれは誤りで,
# 発覚した時点でドキュメントの修正に戻るのが本筋だと思います.
# その具体的なタイミングを測るために,
# コンパイルエラーとして怒られた方がいい
Re: (スコア:0)
静的型付けなら意図しない型が入力に与えられることがないといっても、型さえ合っていれば間違いは見過ごされるから、なんとなく動作しているように見えることがある。そういう、型チェックで防げないバグは、実行時にもコケないからことがあるから検出が難しい。ロジックが間違っている場合も同様。
そういうバグや誤りに対しては、入力やコードをいじりながら試すのが手っ取り早いデバッグ手法となることが多いけど、静的型付けだと変数の型が変わってしまうような変更は難しいから、デバッグで使える手法が限定されてしまう。コードをいじるのはとんでもないという
Re: (スコア:0)
コンパイルエラーで防げないバグはテストを書くのが一般的でしょう.
その点, 動的型付け言語でも同じようにテストを書くけど,
コードから型を判断できないため,
境界テストのように論理的にテストを抽象化したとしても,
テストの領域が無駄に大きく取る必要が出てくる.
静的型付けはその型についてのみ考えればいい.
静的型付けだと変数の型が変わってしまうような変更は難しいから
全体で整合性を取ることが最終的に必要になるなら難しさは大差ないよ.
仮に動的言語で部分的に変更をした場合,
言語の機能により不整合な箇所を埋めてる.
それが正しいとチェックする手間は, 型を変更する手間と大差ない.
Re: (スコア:0)
動的言語と、詳細なドキュメントで設計を行う手法は、
そもそもあまり相性がよくないのではないですかね。
それをやるなら静的言語がいいのは当たり前といえば当たり前で。
動的言語でやるための前提として、
ドキュメントと同じくらいわかりやすい自動テストのテストケース、
とか言うのがあると思いますが。
その辺を書ける能力は身につけたうえで、
言っているのですかね。