Ich habe einen Link zu So You Think You Know C gesehen? von Oleksandr Kaleniuk auf Hacker News und war angenehm überrascht. Ich habe ein paar Kommentare zu kniffligen Teilen von C erwartet und sie gefunden, aber es gibt noch viel mehr. Der Untertitel des kostenlosen Buches lautet And Ten More Short Essays on Programming Languages. Gute Lektüre.
Dieser Beitrag gibt einige meiner Reaktionen auf die Aufsätze, meine noch kürzeren Aufsätze zu Kaleniuks kurzen Aufsätzen.
Mein C
Der erste Aufsatz handelt von undefinierten Teilen von C. Dieser Aufsatz, zusammen mit dieser Grundierung zur C-Verschleierung , die ich heute auch in den Hacker-Nachrichten gefunden habe, reicht aus, um jemanden schreiend vor der Sprache davonlaufen zu lassen. Und doch stoße ich in der Praxis auf keine dieser Fallstricke und finde das Schreiben von C irgendwie angenehm.
Ich habe eine atypische Menge an Freiheit, und das beeinflusst meine Erfahrung. Ich verwalte keinen Code, den jemand anderes geschrieben hat – ich habe meine Gebühren vor Jahren dafür bezahlt – und vermeide daher einfach die Verwendung von Funktionen, die ich nicht vollständig verstehe. Und normalerweise habe ich die Wahl zwischen verschiedenen Sprachen, daher verwende ich C nur, wenn es einen guten Grund gibt, C zu verwenden.
Ich würde erwarten, dass all diese dunklen Ecken von C Unfälle sind, die darauf warten, passiert zu werden. Selbst wenn ich nicht absichtlich undefinierte oder irreführende Merkmale der Sprache verwende, könnte ich sie versehentlich verwenden. Und doch scheint das in der Praxis nicht zu passieren. C oder zumindest meine persönliche Untergruppe von C ist in der Praxis sicherer als in der Theorie.
APL
Der zweite Aufsatz befasst sich mit APL. Es scheint, dass jeder, der lange genug programmiert, schließlich APL erforscht. Ich habe vor Jahren Iversons ACM-Vorlesungsnotation als Denkwerkzeug heruntergeladen und beabsichtige weiterhin, sie zu lesen. Vielleicht komme ich endlich dazu, wenn sich die Dinge verlangsamen. Kaleniuk sagte etwas über APL, das ich vorher noch nicht gehört hatte:
[APL] entstand überhaupt nicht als Computersprache. Es wurde vom Harvard-Mathematiker Kenneth E. Iverson als bessere Notation für die Tensoralgebra vorgeschlagen. Es sollte von Hand auf eine Tafel geschrieben werden, um mathematische Ideen von einer Person auf eine andere zu übertragen.
Es gibt eine Notation, die Iverson eingeführt hat und die ich ziemlich oft benutze, seine hier beschriebene Notation der Indikatorfunktion . Ich habe erst kürzlich einen Bericht für einen Kunden verwendet, der das Schreiben erheblich vereinfacht hat. Vielleicht sollte ich mir noch etwas von Iverson ausleihen.
Fortran
Ich habe Fortran zuletzt während der Clinton-Administration geschrieben und hätte nie gedacht, dass ich es wieder sehen würde, und dennoch erwarte ich, dass ich es später in diesem Jahr für ein Projekt verwenden muss. Die Sprache hat sich seit meinem letzten Besuch ziemlich modernisiert, und ich gehe davon aus, dass die Verwendung nicht so schlecht sein wird.
Anscheinend sind Fortran-Programmierer Teil der dunklen Materie der Programmierer , weitaus zahlreicher als man es aufgrund der Sichtbarkeit erwarten würde. Kaleniuk erzählt die Geschichte eines NASA-Programmierwettbewerbs, bei dem Einsendungen in Fortran geschrieben werden mussten. Die NASA hat den Wettbewerb abgesagt, weil sie von Einsendungen überwältigt waren.
Syntax
In seinem letzten Aufsatz gibt Kaleniuk einige Ideen, was er tun würde, wenn er eine neue Sprache entwerfen würde. Sein erster Punkt ist, dass unsere Syntax willkürlich eingeschränkt ist. Wir verwenden immer noch die kleine Sammlung von Symbolen, die vor 50 Jahren einfach eingegeben werden konnten. Infolgedessen sind Symbole stark überladen. Reguläre Ausdrücke sind ein Paradebeispiel dafür, dass derselbe Charakter in verschiedenen Kontexten mehrere Rollen spielen muss.
Ich stimme Kaleniuk im Prinzip zu, dass wir in der Lage sein sollten, unser Symbolvokabular zu erweitern, und in der Praxis hat dies jedoch nicht gut funktioniert. Es ist jetzt zum Beispiel möglich, λ als lambdaim Quellcode zu verwenden, aber das mache ich nie.
Ich vermute, der Grund, warum wir uns an die alten Symbole halten, ist, dass wir an einem lokalen Maximum festhalten: Kleine Änderungen sind keine Verbesserungen. Ein ehemaliger Kunde hatte eine Haskell-Codebasis, die ein Nicht-ASCII-Zeichen verwendete, einen griechischen oder russischen Buchstaben, wenn ich mich richtig erinnere. Das Zeichen wurde ziemlich oft verwendet und machte den Code etwas leichter lesbar. Aber es hat die Werkzeugkette verwüstet und sie haben sie schließlich entfernt.
Vielleicht lohnt sich eine uneingeschränkte Verpflichtung, mehr Symbole zu verwenden. Es würde nicht mehr Aufwand erfordern, 100 Nicht-ASCII-Zeichen zuzulassen, als eines zuzulassen. Für diese Angelegenheit muss der Quellcode nicht einmal auf Textdateien, ASCII oder Unicode beschränkt sein. Aber auch solche Bemühungen sind gescheitert. Dies kann ein weiteres lokales Maximalproblem sein. Eine radikale Abkehr vom Status quo mag sich lohnen, aber es gibt keine Möglichkeit, schrittweise dorthin zu gelangen. Und radikale Abweichungen scheitern fast immer, weil sie gegen Gall ‚Gesetz verstoßen: Ein komplexes System, das funktioniert, hat sich aus einem einfachen System entwickelt, das funktioniert hat.
