アカウント名:
パスワード:
> 十分かつできの良い仕様書があってそれを元にコードを書くのなら型ありの言語も良いとは思う。
コンパイラ開発などのマシン寄りのジョブならわからないでもないが、一般的なジョブで、仕様書が型に関係してくるのがよくわからない。
設計書なら型レベルの話がかかわってくることは理解できる。私の理解不足なのでしょうか。
仕様に曖昧さがなく、途中で変わらないってことでしょう。
仕様変更による設計の手戻りや、一部の設計を保留にしたまま開発を進行するといった状況が発生する場合だと、最初に型を定義しなくてはいけない静的言語は不利になると。
C++の設計者であるストラウトラシップも「抽象化は遅れてくるプロセスだ」って言ってますね。具体事象を抽象した存在であるところの型は、具体事象が不明確だったり変動する場合には適切に定義できないということだと思います。
動的言語は変数に型がないだけで、型というコンセプト自体は(OO言語であれば)あるわけですが、最初にコンパイルを通せるところまで型を厳密に定義する必要がない分、仕様が曖昧な状況では動的言語が有利だと。
現実には仕様が曖昧なケースも多いわけで、まあ理解できる意見だと思います。
元コメACです。
> 具体事象を抽象した存在であるところの型は、具体事象が不明確だったり変動する場合には適切に定義できないということだと思います。
この理由だとしたら納得です。ただし、この場合は型を含めた処理定義自体が未定の事態ですね。まあ、他コメでもリファクタリングの問題がでていたりするように、実感するところではあります。
元記事の意味の解釈は、これで納得することにしました。ありがとうございます。
仕様書に型に関連する記述がまったく無いとは思っていないですよね?出来の良い仕様書であれば、値の範囲とか、入出力されるデータの概要くらい書いていると想像がつくのですが、たいていは、その仕様書を元に設計書を記述するので、内容から型がまったく推測できない仕様書なんて、それって仕様書以前のただのメモ書きじゃないでしょうか。
> 値の範囲とか、入出力されるデータの概要くらい書いていると想像がつくのですが、
数値範囲と型は別の概念ではないでしょか。例えば、浮動小数点を扱う場合、プログラム内では単精度浮動小数型か倍精度浮動小数型、あるいは整数型を組み合わせてつかう、さらには文字列型を使うという選択肢もありえます。
仕様は目的と適用範囲の設定。それを開発環境に沿って具体化するのが設計。この辺の区分が違う世界なのでしょうかね。
もちろん他システムとのインターフェースでは、仕様書レベルで型が規定されることもありえますが、この場合は、それこそがジョブの目的なので仕様書で規定される事項に含まれます。
#この辺りの認識が違うと、宗教論争になるのは無理ないかもとちょっと納得
入出力される型については仕様として記述してるでしょうが、たとえばプログラム内部でどのようなクラスが使われるかまでは仕様書レベルでは決めていないのが普通では?
メモ書きだって仕様が記述されていれば立派な仕様書です。
会社、立場、状況によって、仕様書の書かれるべき範囲ってちがうのでは?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
関連性がわからない (スコア:0)
> 十分かつできの良い仕様書があってそれを元にコードを書くのなら型ありの言語も良いとは思う。
コンパイラ開発などのマシン寄りのジョブならわからないでもないが、
一般的なジョブで、仕様書が型に関係してくるのがよくわからない。
設計書なら型レベルの話がかかわってくることは理解できる。
私の理解不足なのでしょうか。
Re:関連性がわからない (スコア:1)
仕様に曖昧さがなく、途中で変わらないってことでしょう。
仕様変更による設計の手戻りや、一部の設計を保留にしたまま開発を進行するといった状況が発生する場合だと、
最初に型を定義しなくてはいけない静的言語は不利になると。
C++の設計者であるストラウトラシップも「抽象化は遅れてくるプロセスだ」って言ってますね。
具体事象を抽象した存在であるところの型は、具体事象が不明確だったり変動する場合には適切に定義できないということだと思います。
動的言語は変数に型がないだけで、型というコンセプト自体は(OO言語であれば)あるわけですが、
最初にコンパイルを通せるところまで型を厳密に定義する必要がない分、仕様が曖昧な状況では動的言語が有利だと。
現実には仕様が曖昧なケースも多いわけで、まあ理解できる意見だと思います。
Re: (スコア:0)
元コメACです。
> 具体事象を抽象した存在であるところの型は、具体事象が不明確だったり変動する場合には適切に定義できないということだと思います。
この理由だとしたら納得です。
ただし、この場合は型を含めた処理定義自体が未定の事態ですね。
まあ、他コメでもリファクタリングの問題がでていたりするように、
実感するところではあります。
元記事の意味の解釈は、これで納得することにしました。
ありがとうございます。
Re: (スコア:0)
仕様書に型に関連する記述がまったく無いとは思っていないですよね?
出来の良い仕様書であれば、値の範囲とか、入出力されるデータの概要くらい書いていると想像がつくのですが、
たいていは、その仕様書を元に設計書を記述するので、内容から型がまったく推測できない仕様書なんて、
それって仕様書以前のただのメモ書きじゃないでしょうか。
Re: (スコア:0)
> 値の範囲とか、入出力されるデータの概要くらい書いていると想像がつくのですが、
数値範囲と型は別の概念ではないでしょか。
例えば、浮動小数点を扱う場合、プログラム内では
単精度浮動小数型か倍精度浮動小数型、
あるいは整数型を組み合わせてつかう、さらには文字列型を使うという選択肢もありえます。
仕様は目的と適用範囲の設定。それを開発環境に沿って具体化するのが設計。
この辺の区分が違う世界なのでしょうかね。
もちろん他システムとのインターフェースでは、仕様書レベルで型が規定されることもありえますが、
この場合は、それこそがジョブの目的なので仕様書で規定される事項に含まれます。
#この辺りの認識が違うと、宗教論争になるのは無理ないかもとちょっと納得
Re: (スコア:0)
入出力される型については仕様として記述してるでしょうが、たとえばプログラム内部でどのようなクラスが使われるかまでは仕様書レベルでは決めていないのが普通では?
Re: (スコア:0)
メモ書きだって仕様が記述されていれば立派な仕様書です。
Re: (スコア:0)
会社、立場、状況によって、仕様書の書かれるべき範囲ってちがうのでは?