Was sind Beispiele für Inkonsistenz und Unvollständigkeit in Unix / C?

In Richard Gabriels berühmtem Aufsatz The Rise of Worse is Better stellt er karikaturisierte Versionen der Designphilosophien MIT / Stanford (Lisp) und New Jersey (C / Unix) in Bezug auf Einfachheit, Korrektheit, Konsistenz und Vollständigkeit gegenüber. Er führt das Beispiel des "PC-Verlierer-Problems" an ( das an anderer Stelle von Josh Haberman erörtert wurde ), um zu argumentieren, dass Unix der Einfachheit der Implementierung Vorrang vor der Einfachheit der Schnittstelle einräumt.

Ein anderes Beispiel, das ich mir ausgedacht habe, sind die unterschiedlichen Herangehensweisen an Zahlen. Lisp kann beliebig große Zahlen darstellen (bis zur Größe des Speichers), während C Zahlen auf eine feste Anzahl von Bits begrenzt (normalerweise 32-64). Ich denke, das zeigt die Richtigkeitsachse.

Was sind einige Beispiele für Konsistenz und Vollständigkeit? Hier sind alle Beschreibungen von Gabriel (die er zugibt, dass es sich um Karikaturen handelt):

Der MIT / Stanford-Ansatz

• Einfachheit - Das Design muss sowohl in der Implementierung als auch in der Benutzeroberfläche einfach sein. Es ist wichtiger, dass die Schnittstelle einfach ist als die Implementierung.
• Korrektheit - Das Design muss in allen beobachtbaren Aspekten korrekt sein. Falschheit ist einfach nicht erlaubt.
• Konsistenz - Das Design darf nicht inkonsistent sein. Ein Design darf etwas weniger einfach und weniger vollständig sein, um Inkonsistenzen zu vermeiden. Konsistenz ist ebenso wichtig wie Korrektheit.
• Vollständigkeit - das Design muss so viele wichtige Situationen abdecken, wie es praktisch ist. Alle vernünftigerweise erwarteten Fälle müssen abgedeckt werden. Einfachheit darf die Vollständigkeit nicht übermäßig beeinträchtigen.

Der New Jersey-Ansatz

• Einfachheit - Das Design muss sowohl in der Implementierung als auch in der Benutzeroberfläche einfach sein. Es ist wichtiger, dass die Implementierung einfach ist als die Schnittstelle. Einfachheit ist die wichtigste Überlegung in einem Design.
• Korrektheit - Das Design muss in allen beobachtbaren Aspekten korrekt sein. Es ist etwas besser, einfach als richtig zu sein.
• Konsistenz - Das Design darf nicht zu inkonsistent sein. In einigen Fällen kann die Konsistenz der Einfachheit halber geopfert werden. Es ist jedoch besser, diejenigen Teile des Designs zu löschen, die mit weniger häufigen Umständen zu tun haben, als entweder Komplexität der Implementierung oder Inkonsistenz einzuführen.
• Vollständigkeit - das Design muss so viele wichtige Situationen abdecken, wie es praktisch ist. Alle vernünftigerweise erwarteten Fälle sollten abgedeckt werden. Die Vollständigkeit kann zugunsten einer anderen Qualität geopfert werden. Tatsächlich muss die Vollständigkeit geopfert werden, wenn die Einfachheit der Implementierung gefährdet wird. Konsistenz kann geopfert werden, um Vollständigkeit zu erreichen, wenn die Einfachheit beibehalten wird; Besonders wertlos ist die Konsistenz der Schnittstelle.

Bitte beachte, dass ich nicht frage, ob Gabriel Recht hat (eine Frage, die für StackExchange nicht geeignet ist), sondern nach Beispielen, auf die er sich möglicherweise bezogen hat.

Der Titel der Frage deutet darauf hin, dass Sie einige grundlegende Inkonsistenzen in der Benutzeroberfläche interessieren könnten:

Unix-Befehle folgen keiner bestimmten Syntax für die Angabe von Optionen und Flags. Zum Beispiel verwenden die meisten Befehle einzelne Buchstaben, denen ein '-' als Flag vorangestellt ist cat -n some_file, aber Ausnahmen wie tar tf some_file.tarund dd in=some_file out=some_other_file count=2existieren in häufig verwendeten Befehlen.

Unix und seine Nachkommen und Verwandten haben mehrere leicht unterschiedliche Syntaxen für reguläre Ausdrücke. Shells verwenden "*", während andere Programme (grep, egrep, vi) ". *" Verwenden. egrep hat '+' und '|' grep als betreiber nicht.

Die grundlegende Systemaufrufschnittstelle "Alles ist eine Datei" könnte als unvollständig angesehen werden: Lesen / Schreiben / Suchen / Schließen passt nicht zu jedem E / A-Gerät. Die dringend benötigten Ausnahmen werden in "ioctl" -Aufrufe zusammengefasst, aber Geräte wie Soundkarten passen nicht einmal so gut.

Konsistenz

Lisp hat eine sehr konsistente Syntax, alle Spracherweiterungen können natürlich über Makros und dergleichen eingebettet werden. C hat andererseits eine ziemlich Code-Syntax, die es einem erlaubt, einige "Abkürzungen" zu nehmen, so dass C-Code in einigen Fällen tatsächlich einfacher aussieht.

Vollständigkeit

Wenn Sie in Lisp kein bestimmtes Sprachfeature benötigen, können Sie es selbst mit Makros implementieren. C hat auch Präprozessor, aber es ist ziemlich verwirrend.

Die Zeichenfolgen von C dürfen kein Zeichen 0 enthalten, und die Bibliotheksfunktionen sind nicht für den Umgang mit Binärdaten geeignet.

Dateinamen auf Unix-Systemen dürfen weder Zeichen 0 noch Zeichen 47 (Schrägstrich) enthalten.

In der ursprünglichen Implementierung von Unix waren die Dateinamen auf 14 Zeichen beschränkt. In späteren Versionen wurde diese Einschränkung nur gelockert. sie haben es nicht beseitigt.

Hinzugefügt : Die E2BIGSystemfehlerbedingung, wenn versucht wurde, execmit einer Argumentliste zu arbeiten, die zu viele Argumente enthält, oder wenn zu viel Speicher belegt ist oder wenn die Umgebung zu groß ist.

Unix ist für diese Art von willkürlicher Einschränkung berüchtigt. Bis zum Aufkommen von Perl im Jahr 1987 war der Umgang mit großen Datenmengen oder Datenmengen mit langen Datensätzen oder Binärdaten äußerst unzuverlässig.

IIRC mein Lehrer sagte, dass die Unfähigkeit, char *Variablen in switchAnweisungen in C zu verwenden, eine Sache der Inkonsistenz ist, aber für mich war das eine Frage der Allgemeinheit (Vollständigkeit). Ich denke, es ist besser, "Konsistenz" nur in Ihren Algorithmen oder im Software-Design zu verwenden, nicht in der Programmiersprache selbst (zumindest nicht in Sprachen wie C. Vielleicht hat eine fehlerhafte Sprache Konsistenzprobleme), weil die Programmiersprachen solide Standards haben, die den Bereich der Regeln definieren und arbeiten, indem Sie Eingaben auf Regeln anwenden. Also, wenn etwas in der Sprache nicht erlaubt ist, ist es geplant , nicht erlaubt zu sein und ist keine Inkonsistenz in der Sprache, IMHO.

1. Ich habe Allgemeingültigkeit als Vollständigkeit verwendet. Ich denke, sie sind dasselbe. vielleicht bin ich falsch.
2. Dies ist keine Antwort. vielleicht vorschlag oder meine meinung.

Das beste Beispiel, das ich habe, ist der arme Benutzer, der eine Datei mit dem Namen .. -rund Namen eingegeben hat rm *.

Ob diese Geschichte wahr ist oder nicht, sie ist zum Klassiker eines Unix-Haters geworden.

Siehe Das Unix-Haters Handbook , die eine Einführung von Dennis Ritchie hat sich, für viele dieser Beispiele.

Ich füge hinzu, dass das Vermeiden dieser Art von Problemen eine wichtige Rolle bei der Entwicklung von Microsofts Power Shell gespielt hat.

• Die unzähligen Bedeutungen derselben (kurzen) Flags für Befehle sind sicherlich inkonsistent.
• Jedes Programm, das reguläre Ausdrücke verwendet, hat eine eigene Syntax
• Konfigurationsdateien für Dienste haben alle unterschiedliche Syntax (dies kann zum Teil verzeiht werden, Ihr Mailer-Daemon hat wenig mit Ihrem Webserver oder dem Systemstart zu tun, aber immer noch)
• Es gibt verschiedene Editoren! Benutzer verwenden verschiedene Muscheln !! Warum gibt es so viele Desktop-Umgebungen?!?

OTOH, die Tatsache, dass die Shell die Globs erweitert und nicht das Programm, beseitigt viele irritierende Inkonsistenzen, die in anderen Systemen vorhanden sind. Dies gilt auch für die Tatsache, dass Sie mit demselben Befehl eine Datei von einem Ort zum anderen im Dateisystem, auf eine Diskette oder von einer Zip-Diskette auf Band kopieren können.

Also ja, Unix ist inkonsistent. So sind die anderen Systeme, nur anders ;-)

LISP, das Zahlen mit unendlicher Genauigkeit unterstützt, im Vergleich zu C, das nur Maschinen-Ganzzahlen unterstützt, ist kein Beispiel für die 'Richtigkeit' der Sprache. Es ist eine einfache Sache, die sich aus der Tatsache ergibt, dass die Sprachen sehr unterschiedliche Designziele hatten.

Der Punkt von C sollte eine Sprache in der Nähe des Computers sein, mit der Betriebssysteme implementiert werden können. Maschinen unterstützen (meistens) keine unendlich genauen Dezimalzahlen. Maschinen haben (meistens) ganze Zahlen mit festen Bitlängen.