最新のプログラミング言語のほとんどで、Design by Contractのサポートが制限されているのはなぜですか？

私は最近、Design by Contract（DbC）を発見しましたが、コードを記述する非常に興味深い方法であることがわかりました。とりわけ、それは提供するように思われるでしょう：

• より良いドキュメント。契約は文書であるため、契約が期限切れになることは不可能です。また、コントラクトはルーチンの動作を正確に指定するため、再利用のサポートに役立ちます。
• 簡単なデバッグ。プログラムの実行はコントラクトが失敗した瞬間に停止するため、エラーは伝播できず、違反した特定のアサーションが強調表示されると考えられます。これにより、開発時およびメンテナンス時にサポートが提供されます。
• より良い静的分析。DbCは基本的にHoareロジックの単なる実装であり、同じ原則を適用する必要があります。

それに比べて、コストはかなり小さいようです。

• 余分な指タイプ。契約書を綴る必要があるため。
• 契約書の作成に慣れるには、ある程度のトレーニングが必要です。

現在、主にPythonに精通しているため、実際には前提条件（不適切な入力に対して例外をスローするだけ）を作成することが可能であり、特定の事後条件を再度テストするためにアサーションを使用することもできます。しかし、「古い」または「結果」などの特定の機能をシミュレートすることは、最終的に非Pythonicと見なされる余分な魔法なしでは不可能です。（さらに、サポートを提供するライブラリがいくつかありますが、ほとんどの開発者がそうではないように、最終的にはそれらを使用するのは間違っているでしょう。）それは他のすべての言語でも同様の問題だと思います（もちろん、エッフェル）。

私の直感では、サポートの欠如はある種の慣行に対する拒絶の結果であるに違いないが、オンラインでの検索は有益ではなかったと教えてくれます。ほとんどの現代言語がほとんどサポートを提供していないように見える理由を誰かが明確にできるかどうか疑問に思っていますか？DbCに欠陥があるか、過度に高価ですか？それとも、エクストリームプログラミングやその他の方法論のために時代遅れになっているのでしょうか？

ほぼすべてのプログラミング言語でサポートされています。

必要なのは「アサーション」です。

これらは「if」ステートメントとして簡単にコーディングできます。

if (!assertion) then AssertionFailure();

これにより、入力制約のコードの先頭にそのようなアサーションを配置することにより、コントラクトを作成できます。戻り点のそれらは出力制約です。コード全体に不変条件を追加することもできます（ただし、実際には「契約による設計」の一部ではありません）。

だから、プログラマーは彼らをコーディングするのが面倒だからではなく、あなたがそれをできないからではない、と私は主張する。

コンパイル時のブール定数「チェック」を定義し、ステートメントを少し修正することで、ほとんどの言語でこれらをもう少し効率的にすることができます。

if (checking & !Assertion) then AssertionFailure();

構文が気に入らない場合は、マクロなどのさまざまな言語抽象化手法を使用できます。

いくつかの現代言語は、このための素晴らしい構文を提供します。それは、「現代の言語サポート」という意味です。それはサポートですが、かなり薄いです。

現代の言語のほとんどがあなたに与えないものは、「一時的な」アサーション（任意の前または後の状態[時間演算子「最終的に」）であり、本当に興味深いコントラクトを書きたい場合に必要です。IFステートメントは役に立ちませんここにいる。

おっしゃるように、Design by Contract は Eiffelの機能です。Eiffelは、以前はコミュニティで十分に尊敬されていたプログラミング言語の1つでしたが、一度も取り上げられたことはありません。

DbCは、最も一般的な言語ではありません。なぜなら、主流のプログラミングコミュニティが、コードに制約/期待を追加することはプログラマーに期待される「合理的な」ことだと受け入れたのは比較的最近のことです。プログラマーにとってユニットテストの重要性を理解するのは一般的なことであり、それはプログラマーが引数を検証してメリットを確認するためにコードを挿入することを受け入れるようになるまで浸透しました。しかし、10年前には、おそらくほとんどのプログラマーは「それは、あなたが常に大丈夫だと知っているもののための単なる余分な仕事だ」と言うでしょう。

今日、平均的な開発者のところに行って事後条件について話すと、彼らは熱心にうなずき、「OK、それは単体テストのようなものだ」と言うだろうと思います。そして、前提条件について話すと、「OK、それはパラメーター検証のようなもので、常にそうするわけではありませんが、わかっています、大丈夫だと思います...」 、彼らは「ジー、これはどのくらいのオーバーヘッドですか？さらに多くのバグをキャッチしますか？」と言い始めます。等

だから、DbCが非常に広く採用されるまでにはまだ長い道のりがあると思います。

私の直感は、サポートの欠如は、ある種の練習の拒否の結果でなければならないことを教えてくれます...

偽。

これは設計上の慣例です。コード（エッフェルスタイル）で明示的に具体化するか、コード（ほとんどの言語）またはユニットテストで暗黙的に具体化できます。設計プラクティスが存在し、うまく機能しています。言語サポートは、マップ全体にあります。ただし、単体テストフレームワークでは多くの言語に存在します。

ほとんどの現代言語がほとんどサポートを提供していないように見える理由を誰かが明確にできるかどうか疑問に思っていますか？DbCに欠陥があるか、過度に高価ですか？

高いです。そして。さらに重要なことは、特定の言語では証明できないことがいくつかあります。たとえば、ループ終端はプログラミング言語では証明できません。「高次」証明機能が必要です。したがって、ある種の契約は技術的に表現できません。

それとも、エクストリームプログラミングやその他の方法論のために時代遅れになっているのでしょうか？

いや

ほとんどの場合、単体テストを使用して、DbCが満たされていることを示します。

Pythonについては、既に述べたように、DbCはいくつかの場所にあります。

1. docstringおよびdocstringテストの結果。

2. 入力と出力を検証するためのアサーション。

3. 単体テスト。

さらに。

読み書き可能なプログラミングスタイルのツールを採用して、DbC情報を含み、クリーンなPythonと単体テストスクリプトを生成するドキュメントを作成できます。リテラシープログラミングアプローチを使用すると、契約書と完全なソースを含む素敵な文献を書くことができます。

ただ推測。「Design by Contract」はエッフェルの商標であるため、それほど人気が​​ない理由の一部かもしれません。

1つの仮説は、十分に大きな複雑なプログラム、特にターゲットが移動するプログラムの場合、契約自体の質量がプログラムコードだけの場合よりもバグが多く、デバッグが困難になる場合があります。他のパターンと同様に、収益の減少を超えて使用される可能性があるだけでなく、より的を絞った方法で使用された場合の明確な利点もあります。

もう1つの考えられる結論は、「マネージ言語」の人気が、選択したマネージ機能（契約による配列境界など）の契約による設計サポートの現在の証拠であるということです。

ほとんどの主流言語が言語にDbC機能を持たない理由は、それを実装することの費用対効果の比率が、言語実装者にとって高いことです。

この一方はすでに他の回答で検討されており、単体テストおよびその他のランタイムメカニズム（またはテンプレートメタプログラミングを使用したコンパイル時メカニズム）によって、DbCの利点の多くが既に得られます。したがって、利点はありますが、かなり控えめなものと考えられます。

もう1つの側面はコストです。DbCを既存の言語にレトロに適合させることは、重大な変更であり、起動するには非常に複雑です。古いコードを壊さずに言語に新しい構文を導入するのは困難です。既存の標準ライブラリを更新して、このような広範囲に及ぶ変更を使用すると、費用がかかります。したがって、既存の言語でDbC機能を実装するにはコストがかかると結論付けることができます。

また、テンプレートのほとんどの契約であり、したがってDbCにある程度関連する概念は、長年の作業が必要であると推定されるため、最新のC ++標準から削除されたことにも注意してください。言語に対するこれらの大きな、広範囲で抜本的な変更は、実装するには非常に困難です。

DbCは、コンパイル時に契約を確認できれば、契約に違反するプログラムを実行できないようにするために、より広範囲に使用されます。

コンパイラのサポートがなければ、「DbC」は「不変条件/仮定をチェックし、違反した場合は例外をスローする」ための単なる別名です。

簡単な説明がありますが、ほとんどの人（プログラマーを含む）は、必要と思わない限り、余分な作業を望んでいません。安全性が非常に重要と考えられるアビオニクスプログラミングは、それなしではほとんどのプロジェクトを見たことがない。

しかし、Webサイト、デスクトップ、またはモバイルプログラミングを検討している場合、クラッシュや予期しない動作は悪いこととは見なされず、プログラマはバグを報告するときに余分な作業を避け、後で修正するだけで十分と考えられます。

これはおそらく、Adaは素晴らしい言語ですが、信頼性の高いシステムを構築したい場合、それが仕事に最適な言語であるため、コーディング作業が必要になるため、Adaが航空プログラミング業界以外で取り上げたことがないと思う理由ですAdaに基づく言語）。

C＃のコントラクトライブラリによる設計は、Microsoftによる実験的なものであり、信頼性の高いソフトウェアを構築するのに非常に役立ちますが、市場で勢いをつけたことはありません。

アサーションは、事前/事後条件および不変条件の完全な機能サポートとは異なります。それらをエミュレートすることはできますが、適切にサポートされている言語/コンパイラは「抽象構文ツリー」分析を行い、単純に表明できない論理エラーをチェックします。

編集：私は検索を行いましたが、以下は役立つかもしれない関連する議論です：https : //stackoverflow.com/questions/4065001/are-there-any-provable-real-world-languages-scala

主な理由は次のとおりです。

1. 人気のない言語でのみ利用可能です
2. 同じことを実際にやりたい人が既存のプログラミング言語で異なる方法で行うことができるので、それは不要です。
3. 理解して使用することは困難です。適切に実行するには専門知識が必要なので、少数の人々がそれを実行します
4. それを行うには大量のコードが必要です-プログラマは書く文字の量を最小限に抑えることを好みます-長いコードが必要な場合、何かが間違っているに違いありません
5. 利点はそこにありません-それは価値があるようにするだけの十分なバグを見つけることができません