Warum sind UNIX / POSIX-Systemaufrufnamen so unleserlich?

43

Was ist der Grund für die Verwendung solcher aufschlussreichen Systemaufrufnamen wie timeund creatanstelle von getCurrentTimeSecsund createFileoder, vielleicht besser geeignet für Unix get_current_time_secsund create_file. Was mich zum nächsten Punkt bringt: Warum sollte jemand etwas cfsetospeedohne Kamelkasten oder zumindest Unterstriche wollen, um es lesbar zu machen? Natürlich hätten die Aufrufe mehr Zeichen, aber wir alle wissen, dass die Lesbarkeit von Code wichtiger ist, oder?

history posix system-calls

— Benjoyo
quelle

42

Weil sie Jahrzehnte vor der ungarischen Notation erfunden wurden, wurden Kameletui, Schlangenetui und dergleichen in Mode. Auch, weil Compiler damals nur über sehr wenige Ressourcen verfügten und die Bezeichnernamen auf (IIRC) 8 Zeichen begrenzt waren.

— lcd047

3

@phresnel Ich bin mir nicht sicher, welche Beziehung Sie zwischen Dateinamen und Variablen-IDs sehen, aber ich habe zwischen 8, 12 und 14 gezögert. Vielleicht war das Limit auch 14 für Variablen-IDs. Es war sicher nicht 256+. Wie für die Notationen: Bitte definieren Sie "immer". Hat Arminius CamelCase-Wörter verwendet? Vielleicht nicht. AFAIR, die ungarische Notation, wurde Anfang der 90er Jahre für Windows eingeführt. CamelCase und sneak_case waren spätere Varianten. Beide wurden natürlich vorher benutzt. Ich sage, dass sie Mitte der 90er Jahre populär geworden sind .

— lcd047

6

@phresnel: Beachten Sie, dass Ihr Link über die Einschränkungen des ersten Unix- Dateisystems spricht . Als Thompson, Richie et al. Beim Entwerfen von Unix mussten sie Unix auf Maschinen booten, auf denen Unix noch nicht ausgeführt wurde , dh in wahrscheinlich noch eingeschränkteren Umgebungen.

— DevSolar

11

Sie können sich genauso gut fragen, warum sie nicht in Deutsch geschrieben sind, denn das ist die naheliegendste Annäherung an die natürliche Sprache, die ich mir für die überlangen Monstrositäten vorstellen kann, die Java Programmierern beigebracht hat, zu akzeptieren ...

— R ..

12

Ich bin so froh, dass es so ist. Stellen Sie sich vor , wie eine ls -la | grepaussehen würde: listAllHiddenAndNormalFiles() | globallySearchARegularExpressionAndPrint().

— Pouya

61

Es liegt an den technischen Zwängen der Zeit. Der POSIX-Standard wurde in den 1980er Jahren erstellt und bezog sich auf UNIX, das 1970 geboren wurde. Mehrere C-Compiler waren zu dieser Zeit auf Bezeichner mit 6 oder 8 Zeichen beschränkt, sodass der Standard für die Länge von Variablen und Funktionen festgelegt wurde Namen.

Verwandte Fragen:

— dr01
quelle

5

Ich denke nicht, dass technische Einschränkungen zutreffen. Sie könnten Dateien größer als 6 Byte haben, Sie könnten Programme haben, die sich über Tausende von Codezeilen erstrecken. abstrakte Syntaxbäume sind viel tiefer als nur sechs Ebenen und haben viel mehr Knoten pro Ebene. Aus gutem Grund kann die Beschränkung auf 6 Zeichen keine technische, sondern eine geplante sein. Und es erklärt nicht, warum "creat" besser ist als "create". Können Sie auch die verschiedenen C-Compiler nennen, über die Sie sprechen? Ihre Antwort lautet wirklich "irgendwo irgendwo gehört".

— Phresnel

41

@phresnel: Er spricht nicht über die Dateigröße, die Anzahl der Zeilen oder die Tiefe des Syntaxbaums. Alte Versionen der C - Sprache, die nicht erfordern Compiler und Linker zu halten mehr als die ersten 31 Zeichen des Bezeichner mit interner Bindung, oder mehr als 6 für externe Identifikatoren . So get_current_date()und get_current_time()konnte von einigen dieser frühen Toolchains nicht unterschieden werden. Der Grund war, dass diese Systeme auf winzigen Stellflächen von wenigen Kilobyte arbeiteten.

— DevSolar

34

Aber du bist richtig creat(). Ken Thompson wurde einmal gefragt, was er anders machen würde, wenn er das UNIX-System neu entwerfen würde. Seine Antwort: "Ich würde Kreation mit einem e buchstabieren."

— DevSolar

8

@phresnel: Nur begrenzten Speicher zu haben, ist keine harte Grenze. Nur eine begrenzte Garantie unterstützte Länge von Identifikatoren ist . Wenn Ihnen nur 6 signifikante Charaktere garantiert sind, dann arbeiten Sie damit, wenn Sie es wert sind.

— DevSolar

6

FWIW, die alten Fortran-Standards sind auf 6 Zeichen beschränkt. In diesem Buch heißt es : "Die Fortran-Regel von sechs Zeichen in einem Bezeichner beruht auf der Tatsache, dass sechs Zeichen in einem IBM 704-Wort dargestellt werden können." Ich kann nicht für C sprechen, aber ich stelle mir vor, dass die Einschränkung einen sehr ähnlichen Ursprung hat (oder vielleicht einen identischen Ursprung)

— tpg2114

26

dr01 ist richtig, aber es gibt auch einen anderen Grund - Benutzerfreundlichkeit. Früher hatten Sie nicht so viel Komfort wie eine Tastatur, auf der Sie tippen konnten. Wenn Sie Glück hatten, hatten Sie so etwas wie eine alte Schreibmaschine. Wenn Sie Pech hatten, mussten Sie sich mit Systemen auseinandersetzen, deren Betrieb tatsächlich körperliche Arbeit erforderte (wie in, das Drücken der "Taste" erforderte viel Kraft), oder Sie haben manuell Löcher in eine Karte gestanzt.

Dies bedeutete, dass Sie auch innerhalb der Beschränkung von 6-8 Zeichen versucht haben, Ihre Befehle so kurz wie möglich zu halten. Deshalb hast du lsstatt listund creatstatt create. Code aus dieser Zeit ist voll von Variablen wie a, xund i- und natürlich, x2und Freunde. Das Tippen war eine Menge Arbeit - heutzutage sind Sie weniger mit dem Tippen beschäftigt listIndexals früher mit dem "Tippen" i- und es ist nicht mehr allzu langsam (insbesondere mit zusätzlichen Technologien wie der automatischen Vervollständigung).

Die eigentliche Frage ist: Warum bleiben so viele Unix-Redewendungen bestehen, obwohl sie nicht mehr wünschenswert sind?

— Luaan
quelle

23

Der Tag mein Kernel wechselt von timezu getCurrentTimeSecsoder so etwas, werde ich nur Stop - Upgrade es. Selbst mit meiner komfortablen Tastatur und der neuesten Hardware bleiben diese Namen äußerst praktisch und einfach (die Einfachheit ist eine der Grundlagen von UNIX). Ich habe wirklich nicht das Bedürfnis, diese Art von Java / C # -Namen in die C-Sprache zu bringen, geschweige denn in einen Linux-Kernel. IMO, aus der Sicht eines Kernel-Entwicklers oder UNIX-Entwicklers im Allgemeinen, sind diese Redewendungen keineswegs unerwünscht .

— John WH Smith

11

@Benjoyo unRootlyLongNamed.Packaged.nonsensicalFunctionist hässlich für mich, und ich bin mir lieber sicher, was es tut, man 2 timeals zu erraten, was es zu tun scheint.

— Muru

7

@Benjoyo Nun, jeder, der nicht an diese Umgebung gewöhnt ist, sollte in erster Linie keine Systemaufrufe verwenden, da sie speziell für diejenigen gedacht sind, die es sind. (Standard-) Bibliotheken sind für die anderen da. UNIX folgt nicht diesen "Regeln" für modisches Design , die es auf den ersten Blick leicht verständlich machen würden. Diejenigen, die es verwenden, ohne sich mit einem Dokument zu befassen, haben große Probleme, und nur wenige Mitglieder der UNIX-Community halten es für ein zu lösendes Problem.

— John WH Smith

4

@JohnWHSmith sicher, dass Kernel-Mode-Entwickler ihr System und seine Dokumente kennen, aber das ist kein Grund, keine präzisen und aussagekräftigen Namen zu haben.

— Benjoyo

7

@JohnWHSmith Als kleiner Entwickler, der nur Kerneltreiber geschrieben hat und aussagekräftige Namen bevorzugt, die nicht mit Abkürzungen gefüllt sind, muss ich widersprechen. Aber das ist in Ordnung, denn wenn Sie sich zum Beispiel den ursprünglichen Git-Quellcode ansehen, werden Sie feststellen, dass mindestens ein Kernel-Entwickler mit mir übereinstimmt. Obwohl, wenn Sie Linus sagen, dass sein get_Xoder remove_file_from_cache(könnte ich vorschlagen rmfc?) Für Kernel-Entwickler unerwünscht sind, tun Sie es bitte öffentlich - ich würde gerne seine Reaktion sehen.

— Voo

22

Zusätzlich zu den anderen Antworten möchte ich darauf hinweisen, dass Unix als Reaktion auf Multics, CTSS und andere moderne Betriebssysteme entwickelt wurde, deren Namenskonventionen wesentlich ausführlicher waren. Ein Gefühl für diese Betriebssysteme erhalten Sie unter http://www.multicians.org/devdoc.html . Zum Beispiel http://www.multicians.org/mspm-bx-1-00.html gibt change_nameals Befehl , um eine Datei für die Umbenennung; Vergleiche Unix mv.

Der Hauptgrund, warum die sehr kurzen Systemaufrufnamen bestehen bleiben, ist die Abwärtskompatibilität. Sie werden feststellen, dass neuere APIs in der Regel expliziter sind. zB gettimeofdayund clock_gettimestatt nur time.

(Auch heute ist die Verwendung whateverIndexanstelle ieines Schleifenindex ein automatischer Fehler bei der Codeüberprüfung in meinem Buch ;-)

— zwol
quelle

2

Ja. Es ist lustig, die technologischen Auseinandersetzungen über die Hardware-Fähigkeiten zu hören, wenn LISP-Maschinen älter sind als UNIX. Sicher, UNIX-Maschinen waren billiger zu kaufen , aber das war es auch schon. Das Hinzufügen von Wartungskosten (die im * nix-Land natürlich nicht zählen) drehte den Spieß um, aber es war sowieso kein überzeugendes Argument. (Und yup, iist in Ordnung für einen Index, wenn Sie beispielsweise ein Array iterieren. Koordinaten? Verwenden xund y. Durchqueren einer Ordnungszahl? Beschreibend sein.)

— Luaan

@Luaan LISP-Maschinen sind NICHT älter als Unix. Du scheiterst.

— Pizdelect

@pizdelect Das ist technisch gesehen richtig, aber die technische Wahrheit ist kein ausreichender Grund, jemanden anzugreifen.

— 17.

@pizdelect Sorry, ich meinte, Lisp ist älter als UNIX (und C). Aber LISP-Maschinen waren im Grunde genommen zeitgemäß, wenn man ihre kommerziellen Auswirkungen vergleicht (UNIX hatte einen Vorsprung von etwa drei Jahren, aber zu dem Zeitpunkt, als LISP-Maschinen kamen, waren die kommerziellen UNIX-Maschinen immer noch rar; der größte Teil von UNIX befand sich in der Wissenschaft oder in Deutschland ohne Unterstützung). Auf jeden Fall handelt es sich um eine Antwort auf die allgemeinen technologischen Argumente zu der Zeit, als sich die Menschen in den 80er Jahren tatsächlich zwischen UNIX-Maschinen und LISPMs entschieden und sich irrten. Das änderte sich mit Mikrocomputern, auf denen LISP sowieso schneller laufen konnte.

— Luaan

10

Dennis Ritchie setzte sich mit C die Einschränkung, dass es sich nicht auf Linker-Funktionen stützen würde, die Fortran nicht benötigte. Daher die Beschränkung auf 6 Zeichen für externe Namen.

— user207421
quelle

@Downvoter Da stimmst du vielleicht nicht mit Denni Ritchie überein, aber genau das hat er getan. Es ist sinnlos, diese Antwort herauszunehmen.

— user207421