Unix / Cの不整合と不完全性の例は何ですか？

リチャードガブリエルの有名なエッセイThe Rise of Worse is Betterは、MIT / Stanford（Lisp）とNew Jersey（C / Unix）デザインの似顔絵バージョンを、シンプルさ、正確さ、一貫性、完全性の軸に沿って比較しています。彼は、「PC敗者問題」（Josh Habermanが別の場所で議論した）の例を挙げて、Unixがインターフェースの単純さよりも実装の単純さを優先していると主張します。

私が思いついたもう1つの例は、数値へのさまざまなアプローチです。Lispは任意の大きな数値（メモリのサイズまで）を表現できますが、Cは数値を固定ビット数（通常は32〜64）に制限します。これは正しさの軸を示していると思います。

一貫性と完全性の例は何ですか？ガブリエルのすべての説明は次のとおりです（彼は似顔絵だと認めています）。

MIT /スタンフォードのアプローチ

• シンプルさ-設計は、実装とインターフェースの両方においてシンプルでなければなりません。インターフェイスは実装よりも単純であることが重要です。
• 正確性-設計は、観察可能なすべての側面において正しいものでなければなりません。不正確さは単に許可されません。
• 一貫性-設計は一貫していてはいけません。一貫性を保つために、デザインの単純さや完成度を少し下げることができます。一貫性は正確さと同じくらい重要です。
• 完全性-設計は、実用的な限り多くの重要な状況をカバーする必要があります。合理的に予想されるすべてのケースをカバーする必要があります。シンプルさは、完全性を過度に低下させることは許されません。

ニュージャージーのアプローチ

• シンプルさ-設計は実装とインターフェースの両方でシンプルでなければなりません。実装がインターフェースよりも単純であることがより重要です。シンプルさは、設計において最も重要な考慮事項です。
• 正確性-設計は、観察可能なすべての側面において正しいものでなければなりません。正しいよりも単純である方がわずかに優れています。
• 一貫性-設計が過度に一貫していてはなりません。場合によっては一貫性を犠牲にして単純化することもできますが、実装の複雑さや不整合を導入するよりも、あまり一般的ではない状況に対処する設計の部分を削除する方が適切です。
• 完全性-設計は、実用的な限り多くの重要な状況をカバーする必要があります。合理的に予想されるすべてのケースをカバーする必要があります。他の品質を優先して、完全性を犠牲にすることができます。実際、実装の単純さが危険にさらされるたびに、完全性が犠牲になります。シンプルさを維持する場合、完全性を達成するために一貫性を犠牲にすることができます。特に価値がないのは、インターフェースの一貫性です。

Gabrielが正しいかどうかを尋ねているのではないことに注意してください（これはStackExchangeには不適切な質問です）。

質問のタイトルは、いくつかの基本的なユーザーインターフェイスの不一致があなたに興味を示すかもしれないことを示唆しています。

Unixコマンドは、オプションとフラグを指定するための特定の構文に従いません。たとえば、ほとんどのコマンドは、フラグ：として「-」が前に付いた1文字を使用しますが、一般的に使用されるコマンドには、およびなどのcat -n some_file例外があります。tar tf some_file.tardd in=some_file out=some_other_file count=2

Unixとその子孫および親類には、複数のわずかに異なる正規表現構文があります。シェルは「*」を使用しますが、他のプログラム（grep、egrep、vi）は「。*」を使用します。egrepには「+」と「|」があります 演算子として、grepはしません。

基本的な「すべてがファイル」システムコールインターフェイスは不完全であると見なされる可能性があります。読み取り/書き込み/シーク/クローズはすべてのI / Oデバイスに適合するわけではありません。ひどく必要な例外は「ioctl」呼び出しにまとめられますが、サウンドカードのようなデバイスはそれにもうまく適合しません。

一貫性

Lispは非常に一貫した構文を持ち、すべての言語拡張はマクロなどを介して自然に埋め込むことができます。一方、Cにはコードシンタックスがあり、「ショートカット」を使用できるため、場合によってはCコードは実際には単純に見えます。

完全

Lispでは、必要な特定の言語機能がない場合は、マクロを使用して自分で実装できます。Cにもプリプロセッサがありますが、ややこしいです。

Cの文字列に文字0を含めることはできず、そのライブラリ関数はバイナリデータを処理するのに適していません。

Unixシステムのファイル名には、文字0または文字47（スラッシュ）を含めることはできません。

Unixの元の実装では、ファイル名は14文字に制限されていました。それ以降のバージョンでは、この制限のみが緩和されました。彼らはそれを排除しませんでした。

追加：E2BIGシステムエラー状態。exec引数が多すぎる、メモリが多すぎる、または環境が大きすぎる引数リストで。

Unixは、この種のarbitrary意的な制限で有名です。1987年にPerlが登場するまで、大きなデータセット、長いレコードを持つデータセット、またはバイナリデータの処理は非常に信頼できませんでした。

IIRCの私の先生は、Cのステートメントでchar *変数を使用できないswitchことは矛盾の問題であると言いましたが、私にとってそれは一般性（完全性）の問題でした。プログラミング言語にはルールのドメインを定義する堅固な標準があるため、プログラミング言語自体ではなく、アルゴリズムまたはソフトウェア設計だけで「一貫性」を使用する方が良いと思います（少なくともCなどの言語ではそうではありません。入力をルールに適用することで機能します。したがって、言語で何かが許可されていない場合、それは許可されないことを計画し、言語、IMHOの矛盾ではありません。

1. 完全性として一般性を使用しました。それらは同じものだと思います。たぶん私は間違っています。
2. これは答えではありません。多分提案や私の意見。

私が持っている最良の例は、という名前のファイル.. -rを入力した貧しいユーザーですrm *。

この物語が真実であるかどうかにかかわらず、それはUnix嫌いの古典になりました。

これらの例の多くについては、デニスリッチー自身による紹介があるUnix-Haters Handbookを参照してください。

さらに、これらのタイプの問題を回避することは、MicrosoftのPower Shellの設計における主要な力であると付け加えます。

• 確かに、コマンドに対する同じ（短い）フラグの無数の意味は矛盾しています。
• 正規表現を使用する各プログラムには、独自の構文があります
• サービスの構成ファイルはすべて異なる構文です（一部は許されますが、メーラーデーモンはWebサーバーまたはシステムの起動とほとんど共通しませんが、それでも）
• さまざまなエディターがあります！ユーザーは異なるシェルを使用します!! なぜそんなに多くのデスクトップ環境があるのですか？！？

OTOH、シェルがプログラムではなくグロブを拡張するという事実は、他のシステムに存在する多くの刺激的な矛盾を排除します。同じコマンドを使用して、filessytemのある場所から別の場所、ディスケット、またはZipディスクからテープにファイルをコピーできるという事実も同じです。

それで、はい、Unixは矛盾しています。他のシステムも同様です;-)

無限精度の数値をサポートするLISPとマシン整数のみをサポートするCは、言語の「正確さ」の例ではありません。言語が非常に異なる設計目標を持っていたという事実から生じる単純な問題です。

Cのポイントは、オペレーティングシステムの実装に使用できるマシンに近い言語になることでした。マシンは（ほとんど）無限精度の10進数をサポートしていません。マシンには（ほとんど）固定ビット長の整数があります。