Fünf Fragen zum Entwerfen von Programmiersprachen

Leitmotiv

1. Programmiersprachen für Menschen

Unter Programmiersprachen versteht man das Sprechen mit Computern. Der Computer spricht gerne jede Sprache, die nicht mehrdeutig ist. Der Grund, warum wir Hochsprachen haben, ist, dass die Leute nicht mit Maschinensprache umgehen können. Die Essenz von Programmiersprachen besteht darin, zu verhindern, dass unser armes, zerbrechliches menschliches Gehirn mit einer Vielzahl von Details überladen wird.

Architekten wissen, dass einige Designprobleme profaner sind als andere. Eines der klarsten und abstraktesten Designprobleme ist das Brückendesign. In diesem Fall ist es Ihre Aufgabe, die erforderliche Strecke mit möglichst wenig Material zurückzulegen. Am anderen Ende des Spektrums steht das Design von Stühlen. Stuhldesigner sollten ihre Zeit damit verbringen, sich Gedanken über menschliche Esel zu machen.

Die Softwareentwicklung weist einen ähnlichen Unterschied auf. Das Entwerfen von Algorithmen zum Weiterleiten von Daten über ein Netzwerk ist ein gutes abstraktes Problem, wie das Entwerfen von Brücken. Während das Entwerfen von Programmiersprachen dem Entwerfen von Stühlen gleicht, muss man mit menschlichen Schwächen fertig werden.

Den meisten von uns fällt es schwer, dies zu realisieren. Das Entwerfen eleganter mathematischer Systeme klingt für die meisten von uns viel attraktiver, als sich menschlichen Schwächen hinzugeben. Die Rolle der mathematischen Eleganz besteht darin, dass ein gewisser Grad an Eleganz das Verständnis von Programmen erleichtert. Aber alles ist nicht auf Eleganz beschränkt.

Und wenn ich sage, dass Sprachen so gestaltet sein sollten, dass menschliche Schwächen berücksichtigt werden, dann bedeutet das nicht, dass Sprachen für schlechte Programmierer konzipiert sein sollten. In der Tat sollten Sie Software für die besten Programmierer entwerfen, aber auch die besten Programmierer haben ihre Grenzen. Ich glaube nicht, dass jemand in einer Sprache programmieren möchte, in der alle Variablen durch den Buchstaben "x" mit ganzzahligen Indizes gekennzeichnet sind.

2. Entwerfen Sie für sich und Ihre Freunde

Wenn Sie sich die Geschichte der Programmiersprachen ansehen, wurden die meisten der besten Sprachen für die Verwendung durch ihre eigenen Autoren entwickelt, und die meisten der schlechtesten wurden für andere Personen entwickelt.

Wenn Sprachen für andere Menschen entworfen werden, handelt es sich immer um eine bestimmte Gruppe von Menschen: Die Menschen sind nicht so schlau wie die Schöpfer der Sprache. So erhalten Sie eine Sprache, die herablassend zu Ihnen spricht. Cobol ist das deutlichste Beispiel, aber die meisten Sprachen sind von diesem Geist durchdrungen.

Das hat nichts damit zu tun, wie gut die Sprache ist. C ist ziemlich niedrig, aber es wurde für die Verwendung durch seine Autoren erstellt, weshalb Hacker es lieben.

Das Argument für das Entwerfen von Sprachen für schlechte Programmierer ist, dass es mehr schlechte als gute Programmierer gibt. Vielleicht ist das so. Aber diese kleine Anzahl guter Programmierer schreibt unverhältnismäßig mehr Software.

Mich interessiert die Frage, wie man eine Sprache schafft, die den besten Hackern gefällt. Es scheint mir, dass diese Frage mit der Frage, wie man eine gute Programmiersprache erstellt, identisch ist. Aber auch wenn dies nicht der Fall ist, ist es zumindest eine interessante Frage.

3. Geben Sie dem Programmierer so viel Kontrolle wie möglich

Viele Sprachen (insbesondere solche, die für andere Personen erstellt wurden) verhalten sich wie Kindermädchen: Sie versuchen, Sie vor Dingen zu warnen, die Ihrer Meinung nach für Sie nicht nützlich sind. Ich bin der gegenteiligen Meinung: Geben Sie dem Programmierer so viel Kontrolle wie möglich.

Als ich Lisp zum ersten Mal studierte, mochte ich am meisten, dass wir zu gleichen Bedingungen sprachen. In anderen Sprachen, die ich zu dieser Zeit studiert hatte, gab es eine Sprache, und es gab mein Programm in dieser Sprache, und sie existierten ziemlich getrennt. Aber in Lisp waren die Funktionen und Makros, die ich geschrieben habe, dieselben, in denen die Sprache selbst geschrieben wurde. Ich könnte die Sprache selbst umschreiben, wenn ich wollte. Es hatte den gleichen Reiz wie Open-Source-Software.

4. Kürze - die Schwester des Talents

Kürze wird unterschätzt und sogar verachtet. Aber wenn Sie in die Herzen der Hacker schauen, werden Sie feststellen, dass sie die Kürze wirklich lieben. Wie oft haben Sie schon von Hackern gehört, die liebevoll sagen, dass sie in der APL erstaunliche Dinge mit nur wenigen Codezeilen tun können? Ich glaube, dass wirklich kluge Leute dem wirklich gerne Aufmerksamkeit schenken.

Ich glaube, dass fast alles, was Programme kürzer macht, gut ist. Es sollte viele Bibliotheksfunktionen geben, alles, was implizit sein kann - sollte so sein; Die Syntax sollte prägnanter sein. gerade Entitätsnamen sollten kurz sein.

Und nicht nur Programme sollten kurz sein. Handbücher sollten auch kurz sein. Ein Großteil der Handbücher enthält Erklärungen, Haftungsausschlüsse, Warnungen und Sonderfälle. Wenn Sie das Handbuch kürzen müssen, ist es am besten, die Sprache zu korrigieren, für die so viele Erklärungen erforderlich sind.

5. Erkennen Sie, was Hacking ist.

Viele Leute möchten, dass Hacken Mathematik ist oder zumindest etwas Ähnliches wie Naturwissenschaften. Ich denke, Hacking ist eher wie Architektur. Architektur ist mit Physik verbunden, in dem Sinne, dass der Architekt ein Gebäude entwerfen muss, das nicht fallen wird, aber das eigentliche Ziel des Architekten ist es, ein großartiges Gebäude zu schaffen und keine Entdeckungen auf dem Gebiet der Statik zu machen.

Was Hacker lieben, ist großartige Programme zu erstellen. Und ich denke, zumindest in unseren eigenen Gedanken sollten wir uns daran erinnern, dass das Schreiben wundervoller Programme wundervoll ist, auch wenn diese Arbeit nicht einfach in die gewöhnliche intellektuelle Währung wissenschaftlicher Werke übersetzt werden kann. Aus intellektueller Sicht ist es ebenso wichtig, eine Sprache zu entwickeln, die Programmierer lieben werden, und eine schreckliche Sprache zu entwickeln, die die Idee verkörpert, über die Sie einen Artikel veröffentlichen können.

Offene Fragen

1. Wie organisiere ich große Bibliotheken?

Bibliotheken werden zu einem wichtigen Bestandteil von Programmiersprachen. Sie werden so groß, dass es gefährlich sein kann. Wenn es länger dauert, eine Funktion in der Bibliothek zu finden, die das tut, was Sie benötigen, als diese Funktion selbst zu schreiben, wird Ihr Handbuch durch den gesamten Code nur verdickt. (Ein Beispiel hierfür waren Handbücher zu Symbolik.) Wir müssen also das Problem der Organisation von Bibliotheken lösen. Entwerfen Sie sie idealerweise so, dass der Programmierer erraten kann, welche Bibliotheksfunktion geeignet ist.

2. Haben die Leute wirklich Angst vor der Präfix-Syntax?

Dies ist ein offenes Problem in dem Sinne, dass ich über mehrere Jahre nachgedacht habe und die Antwort immer noch nicht kenne. Die Präfix-Syntax erscheint mir völlig natürlich, möglicherweise auch in der Mathematik. Aber es kann sein, dass der größte Teil von Lisps Unbeliebtheit einfach auf eine ungewohnte Syntax zurückzuführen ist ... Hat das irgendetwas damit zu tun, wenn es wahr ist, ist dies eine andere Frage.

3. Was benötigen Sie für die Serversoftware?

Ich denke, dass die meisten Anwendungen, die in den nächsten zwanzig Jahren geschrieben werden, Webanwendungen sein werden, in dem Sinne, dass sich die Programme auf dem Server befinden und über einen Webbrowser mit Ihnen kommunizieren werden. Und um solche Anwendungen zu schreiben, brauchen wir neue Dinge.

Eines dieser Dinge ist die Unterstützung einer neuen Methode zum Freigeben von Serveranwendungen. Anstelle von ein oder zwei Hauptversionen pro Jahr, wie z. B. Desktop-Software, wird die Serversoftware in einer Reihe kleiner Änderungen veröffentlicht. Sie können fünf oder zehn Veröffentlichungen pro Tag haben. Und jeder wird immer die neueste Version haben.

Wissen Sie, wie Sie Programme entwerfen, die unterstützt werden sollen? Die Serversoftware muss anpassungsfähig sein. Sie sollten es leicht ändern können oder zumindest wissen, was eine geringfügige Änderung bedeutet und was wichtig ist.

Eine andere Sache, die in der Serversoftware nützlich sein kann, ist plötzlich die Kontinuität der Lieferung. In einer Webanwendung können Sie CPS verwenden , um den Effekt von Routinen in der statusfreien Welt von Websitzungen zu erzielen. Möglicherweise lohnt sich eine kontinuierliche Lieferung, wenn diese Gelegenheit nicht zu teuer ist.

4. Welche neuen Abstraktionen müssen noch geöffnet werden?

Ich bin mir nicht sicher, wie vernünftig diese Hoffnung ist, aber ich persönlich würde wirklich gerne eine neue Abstraktion entdecken - etwas, das genauso wichtig sein könnte wie erstklassige Funktionen oder Rekursionen oder zumindest die Standardparameter. Vielleicht ist das ein unmöglicher Traum. Solche Dinge öffnen sich oft nicht. Aber ich verliere nicht die Hoffnung.

Wenig bekannte Geheimnisse

1. Sie können jede gewünschte Sprache verwenden

Bisher bedeutete die Erstellung von Anwendungen die Erstellung von Desktop-Software. Und in der Desktop-Software gibt es eine große Tendenz, Anwendungen in derselben Sprache wie das Betriebssystem zu schreiben. Vor zehn Jahren bedeutete das Schreiben von Software als Ganzes das Schreiben von Software in C. Am Ende hat sich die Tradition entwickelt: Anwendungen sollten nicht in ungewöhnlichen Sprachen geschrieben werden. Und diese Tradition hat sich so lange entwickelt, dass auch Nicht-Techniker wie Manager und Risikokapitalgeber dies gelernt haben.

Die Serversoftware zerstört dieses Modell vollständig. Mit der Serversoftware können Sie jede gewünschte Sprache verwenden. Kaum jemand anderes versteht das (insbesondere Manager und Risikokapitalgeber). Aber einige Hacker verstehen das, weshalb wir von Indy-Sprachen wie Perl und Python gehört haben. Wir hören nichts über Perl und Python, weil die Leute damit Windows-Anwendungen schreiben.

Was bedeutet dies für uns Menschen, die an der Gestaltung von Programmiersprachen interessiert sind, dass es ein potentielles Publikum für unsere Arbeit gibt.

2. Geschwindigkeit kommt von Profilern

Sprachentwickler oder zumindest deren Implementierer lieben es, Compiler zu schreiben, die schnellen Code generieren. Aber ich denke, das ist nicht das, was Sprachen für Benutzer schnell macht. Knut ist schon lange aufgefallen, dass die Geschwindigkeit nur von wenigen Engpässen abhängt. Und jeder, der versucht hat, das Programm zu beschleunigen, weiß, dass man den Engpass nicht erraten kann. Der Profiler ist die Antwort.

Sprachentwickler lösen das falsche Problem. Benutzer benötigen keine Benchmarks, um schnell arbeiten zu können. Sie benötigen eine Sprache, die anzeigt, welche Teile ihres Programms neu geschrieben werden sollen. An dieser Stelle ist in der Praxis Schnelligkeit gefragt. Daher ist es möglicherweise besser, wenn die Sprachimplementierer die Hälfte der Zeit damit verbringen, den Compiler zu optimieren und einen guten Profiler zu schreiben.

3. Sie benötigen eine Anwendung, mit der sich Ihre Sprache entwickelt

Vielleicht ist dies nicht die ultimative Wahrheit, aber es scheint, dass die besten Sprachen zusammen mit den Anwendungen, in denen sie verwendet wurden, entwickelt wurden. C wurde von Leuten geschrieben, die Systemprogrammierung benötigten. Lisp war zum Teil auf symbolische Differenzierung ausgelegt, McCarthy war so begierig, dass er bereits im ersten Lisp-Dokument 1960 damit begann, Differenzierungsprogramme zu schreiben.

Dies ist besonders gut, wenn Ihre Anwendung einige neue Probleme löst. Dies ermutigt Ihre Sprache, neue Funktionen zu haben, die Programmierer benötigen. Persönlich bin ich daran interessiert, eine Sprache zu schreiben, die für Serveranwendungen geeignet ist.

[Während der Diskussion äußerte Guy Steele auch diese Idee und fügte hinzu, dass die Anwendung nicht aus dem Schreiben eines Compilers für Ihre Sprache bestehen sollte, es sei denn, Ihre Sprache ist zum Schreiben von Compilern vorgesehen.]

4. Die Sprache sollte zum Schreiben von Einmalprogrammen geeignet sein.

Sie wissen, was ein einmaliges Programm bedeutet: Hier müssen Sie schnell ein begrenztes Problem lösen. Ich glaube, wenn Sie sich umschauen, werden Sie viele ernsthafte Programme finden, die als einmalige begannen. Es würde mich nicht wundern, wenn die meisten Programme einmalig starten würden. Wenn Sie also eine Sprache erstellen möchten, die zum Schreiben von Software im Allgemeinen geeignet ist, sollte sie zum Schreiben von Einmalprogrammen geeignet sein, da dies die Anfangsphase vieler Programme ist.

5. Syntax in Bezug auf Semantik

Es wird traditionell angenommen, dass Syntax und Semantik sehr unterschiedliche Dinge sind. Es mag schockierend klingen, ist es aber nicht. Ich denke, dass das, was Sie in Ihr Programm aufnehmen möchten, damit zusammenhängt, wie Sie es ausdrücken.

Ich habe vor kurzem mit Robert Morris gesprochen und festgestellt, dass das Überladen von Operatoren ein großes Plus beim Gewinnen von Sprachen mit Infix-Syntax ist. In Sprachen mit Präfixsyntax ist jede von Ihnen definierte Funktion ein Operator. Wenn Sie den neu erstellten Zahlentyp addieren möchten, können Sie einfach eine neue Funktion definieren, um sie hinzuzufügen. Wenn Sie dies in einer Sprache mit Infix-Syntax tun, werden Sie feststellen, dass es einen großen Unterschied zwischen der Verwendung eines überladenen Operators und dem Aufrufen einer Funktion gibt.

Ideen, die mit der Zeit zurückkommen

1. Neue Programmiersprachen

In den 1970er Jahren war es Mode, neue Programmiersprachen zu entwickeln. Nun ist das nicht so. Aber ich glaube, dass Server-Software wieder die Mode für das Erstellen neuer Sprachen zurückgeben wird. Mit der Serversoftware können Sie jede gewünschte Sprache verwenden. Wenn also jemand eine Sprache erstellt, die besser zu sein scheint als der Rest, gibt es Leute, die sich dafür entscheiden, sie zu verwenden.

2. Timesharing

Richard Kelsey hat diese Idee vorgebracht, deren Zeit wieder gekommen ist, und ich unterstütze sie voll und ganz. Ich vermute (und Microsoft auch), dass viele Berechnungen vom Desktop auf Remote-Server verschoben werden. Mit anderen Worten, die Zeitteilung ist zurückgekehrt. Ich denke, Sie brauchen Unterstützung auf Sprachniveau. Zum Beispiel haben Richard und Jonathan Reeves viel Arbeit geleistet, um die Prozessplanung in Schema 48 umzusetzen.

3. Effizienz

In letzter Zeit schienen Computer bereits recht schnell zu sein. Immer mehr hören wir von Bytecode, was zumindest für mich bedeutet, dass wir die Kraft auf Lager haben. Aber ich denke, dass wir mit Server-Software nicht haben. Jemand muss für die Server bezahlen, auf denen die Software ausgeführt wird, und die Anzahl der Benutzer, denen der Server pro Computer standhalten kann, ist ein Teil der Kapitalkosten.

Ich denke, dass Effizienz eine Rolle spielen wird, zumindest bei den Engpässen beim Computing. Dies ist besonders wichtig für E / A-Vorgänge, da Serveranwendungen viele solcher Vorgänge ausführen.

Am Ende könnte sich herausstellen, dass Bytecode keine Option ist. Derzeit scheinen sich Sun und Microsoft im Bytecode-Feld gegenüberzustehen. Aber sie tun dies, weil Bytecode ein bequemer Ort ist, um sich in den Prozess einzubetten, und nicht, weil Bytecode allein eine gute Idee ist. Es kann sich herausstellen, dass diese ganze Schlacht unbemerkt bleiben wird. Es wäre lustig.

Fallen und Fallen

1. Kunden

Dies ist nur eine Annahme, aber nur diejenigen Anwendungen, die vollständig serverseitig sind, werden davon profitieren. Das Entwerfen von Software unter der Annahme, dass jeder Ihren Kunden hat, ist wie die Schaffung einer Gesellschaft unter der Annahme, dass jeder ehrlich ist. Es wäre auf jeden Fall praktisch, aber Sie müssen davon ausgehen, dass es niemals passieren wird.

Ich denke, es wird eine rasche Zunahme von Geräten mit Zugang zum Web geben, und wir können davon ausgehen, dass sie grundlegende HTML- und Formularfunktionen unterstützen. Haben Sie einen Browser auf Ihrem Handy? Befindet sich in Ihrem PalmPilot ein Telefon? Wird Ihr BlackBerry einen größeren Bildschirm haben? Wirst du die Möglichkeit haben, von deinem Gameboy aus online zu gehen? Von deiner Uhr? Ich weiß nicht. Und ich muss nicht herausfinden, ob ich darauf wette, dass sich alles auf dem Server befindet. Es ist einfach viel zuverlässiger, alle Gehirne auf dem Server zu haben. .

2. Objektorientierte Programmierung

Ich verstehe, dass dies eine kontroverse Aussage ist, aber ich denke nicht, dass OOP etwas Wichtiges ist. Ich denke, dies ist ein geeignetes Paradigma für bestimmte Anwendungen, die bestimmte Datenstrukturen benötigen, wie Fenstersysteme, Simulationen, CAD-Systeme. Ich verstehe aber nicht, warum es für alle Programme geeignet sein soll.

Ich denke, dass die Leute in großen Unternehmen OOP lieben, zum Teil, weil es eine Menge von dem bietet, was nach Arbeit aussieht. Was natürlich als eine Liste von ganzen Zahlen dargestellt werden kann, kann jetzt als eine Klasse mit allen Arten von Gerüsten, mit Lärm und Hektik dargestellt werden.

Ein weiteres attraktives Merkmal von OOP ist, dass Methoden Ihnen einen gewissen Effekt erstklassiger Funktionen verleihen. Dies ist jedoch keine Neuigkeit für Lisp-Programmierer. Wenn Sie echte Funktionen der ersten Klasse haben, können Sie sie einfach in einer der Aufgabe entsprechenden Weise verwenden, anstatt alles aus Klassen und Methoden in eine Vorlage zu verschieben.

Ich denke, dies bedeutet für das Sprachdesign, dass Sie OOP nicht zu tief einbetten sollten. Vielleicht besteht die Antwort darin, allgemeinere und grundlegendere Dinge anzubieten und es den Menschen zu ermöglichen, beliebige Objektsysteme in Form von Bibliotheken zu entwerfen.

3. Entwurf vom Ausschuss

Wenn Ihre Sprache von einem Komitee verfasst wird, dann sind Sie nicht nur aus Gründen gefangen, die jeder kennt. Jeder weiß, dass Komitees dazu neigen, ein klumpiges, inkonsistentes Sprachdesign zu erstellen. Aber ich denke, dass die große Gefahr darin besteht, dass sie kein Risiko eingehen. Wenn eine Person an der Spitze steht, geht sie das Risiko ein, dass das Komitee niemals zustimmt.

Soll ich Risiken eingehen, um eine gute Sprache zu schaffen? Viele Menschen vermuten, dass man beim Entwerfen einer Sprache der traditionellen Weisheit ziemlich nahe kommen sollte. Ich wette, das ist es nicht. In allem anderen, was Menschen tun, ist die Belohnung proportional zum Risiko. Warum sollte das Sprachdesign anders sein?