Fünf Fragen zur Gestaltung von Programmiersprachen

Leitphilosophie

1. Programmiersprachen für Menschen

Programmiersprachen sind die Art und Weise, wie Menschen mit Computern kommunizieren. Der Computer freut sich, in jeder Sprache zu kommunizieren, die nicht mehrdeutig ist. Der Grund, warum wir Hochsprachen haben, liegt darin, dass Menschen mit Maschinensprache nicht zurechtkommen. Der Sinn von Programmiersprachen besteht darin, unser schwaches, empfindliches menschliches Gehirn vor einer Überlastung mit Details zu bewahren.

Architekten wissen, dass einige Designprobleme bodenständiger sind als andere. Eines der klarsten und abstraktesten Designprobleme ist der Brückenbau. In diesem Fall besteht Ihre Aufgabe darin, die erforderliche Distanz mit so wenig Material wie möglich zu überbrücken. Am anderen Ende des Spektrums befindet sich die Gestaltung von Stühlen. Stuhldesigner müssen ihre Zeit damit verbringen, über menschliche Hinterteile nachzudenken.

Die Softwareentwicklung hat eine ähnliche Differenzierung. Die Gestaltung von Algorithmen zur Datenübertragung durch ein Netzwerk ist ein gutes, abstraktes Problem, ähnlich dem Brückenbau. Während die Gestaltung von Programmiersprachen vielmehr der Stuhldesign ist: man muss mit menschlichen Schwächen umgehen.

Es fällt den meisten von uns schwer, das zu erkennen. Die Gestaltung eleganter mathematischer Systeme klingt für viele von uns viel attraktiver als die Nachsicht mit menschlichen Schwächen. Die Rolle mathematischer Eleganz liegt darin, dass ein gewisses Maß an Eleganz Programme verständlicher macht. Doch Eleganz ist nicht alles.

Und wenn ich sage, dass Sprachen so gestaltet werden sollten, dass sie menschliche Schwächen berücksichtigen, meine ich nicht, dass Sprachen für schlechte Programmierer entworfen werden sollten. Tatsächlich sollten Sie Software für die besten Programmierer entwerfen, aber selbst die besten Programmierer haben ihre Grenzen. Ich glaube nicht, dass jemand Freude daran hätte, in einer Sprache zu programmieren, in der alle Variablen mit dem Buchstaben „x“ und ganzzahligen Indizes bezeichnet wären.

2. Entwerfen Sie für sich selbst und für Ihre Freunde

Wenn Sie sich die Geschichte der Programmiersprachen ansehen, wurden die meisten der besten Sprachen von ihren eigenen Schöpfern entworfen, während die meisten der schlechtesten für andere Menschen entworfen wurden.

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

Das hat nichts damit zu tun, wie hochsprachenmäßig eine Sprache ist. C ist ziemlich niedrigstufig, aber es wurde für die Nutzung durch seine Schöpfer entworfen, weshalb Hacker es lieben.

Das Argument für das Design von Sprachen für schlechte Programmierer ist, dass es mehr schlechte Programmierer als gute gibt. Das ist wahrscheinlich wahr. Aber eine kleine Anzahl guter Programmierer schreibt unverhältnismäßig mehr Software.

Ich interessiere mich für die Frage, wie man eine Sprache schafft, die den besten Hackern gefällt? Ich denke, diese Frage ist identisch mit der Frage, wie man eine gute Programmiersprache erstellt?, aber selbst wenn das nicht so ist, ist es zumindest eine interessante Frage.

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

Viele Sprachen (insbesondere die, die für andere Menschen entwickelt wurden) benehmen sich wie Kinderwärter: Sie versuchen, Sie vor Dingen zu warnen, von denen sie denken, dass sie für Sie nicht nützlich sind. Ich vertrete die gegenteilige Meinung: Geben Sie dem Programmierer so viel Kontrolle, wie Sie können.

Als ich zum ersten Mal Lisp lernte, gefiel mir am besten, dass wir auf Augenhöhe kommunizierten. In anderen Sprachen, die ich bis dahin gelernt hatte, gab es die Sprache und mein Programm in dieser Sprache, und sie existierten recht getrennt. Aber in Lisp waren die Funktionen und Makros, die ich schrieb, dieselben, mit denen die Sprache selbst geschrieben wurde. Ich konnte die Sprache selbst umschreiben, wenn ich wollte. Sie hatte die gleiche Anziehungskraft wie Open-Source-Software.

4. Kürze ist die Schwester des Talents

Kürze wird unterschätzt und sogar verachtet. Aber wenn Sie in die Herzen von Hackern schauen, werden Sie sehen, dass sie Kürze sehr schätzen. Wie oft haben Sie gehört, dass Hacker liebevoll darüber sprechen, dass sie zum Beispiel in APL erstaunliche Dinge mit nur ein paar Zeilen Code machen können? Ich glaube, dass wirklich kluge Menschen in der Tat Wert darauf legen.

Ich glaube, dass fast alles, was Programme kürzer macht, gut ist. Es muss zahlreiche Bibliotheksfunktionen geben, alles, was implizit sein kann, sollte so sein; die Syntax sollte weitgehend kurz sein; selbst die Namen von Entitäten sollten kurz sein.

Und nicht nur Programme sollten kurz sein. Handbücher sollten ebenfalls kurz sein. Ein guter Teil der Handbücher ist mit Erklärungen, Vorbehalten, Warnungen und Sonderfällen gefüllt. Wenn Sie ein Handbuch kürzen müssen, ist die beste Option, die Sprache zu korrigieren, die so viele Erklärungen benötigt.

5. Erkennen Sie, was Hacking ist

Viele Menschen wünschten sich, Hacking wäre Mathematik oder zumindest etwas Ähnliches wie Naturwissenschaften. Ich denke, dass Hacking mehr mit Architektur zu tun hat. Architektur hängt mit Physik zusammen, insofern als der Architekt ein Gebäude entwerfen muss, das nicht einstürzt, aber das wahre Ziel des Architekten ist es, ein großartiges Gebäude zu schaffen und nicht Entdeckungen im Bereich der Statik zu machen.

Was Hacker lieben, ist, großartige Programme zu erstellen. Und ich denke, dass wir zumindest in unseren eigenen Gedanken im Hinterkopf behalten sollten, dass es großartig ist, bemerkenswerte Programme zu schreiben, auch wenn diese Arbeit sich nicht leicht in die übliche intellektuelle Währung wissenschaftlicher Arbeiten übersetzen lässt. Aus intellektueller Sicht ist es ebenso wichtig, eine Sprache zu entwickeln, die Programmierer lieben werden, wie auch eine schreckliche Idee zu schaffen, zu der Sie einen Artikel veröffentlichen können.

Offene Probleme

1. Wie organisiert man große Bibliotheken?

Bibliotheken werden zu einem wichtigen Bestandteil von Programmiersprachen. Sie werden so groß, dass es gefährlich werden kann. Wenn es mehr Zeit erfordert, eine Funktion in einer Bibliothek zu finden, die das tut, was Sie benötigen, als diese Funktion selbst zu schreiben, dann führt der gesamte Code nur dazu, dass Ihr Handbuch aufgebläht wird. (Die Handbücher von Symbolics sind ein Beispiel dafür.) Daher müssen wir das Problem der Organisation von Bibliotheken lösen. Idealerweise sollten sie so entworfen werden, dass der Programmierer erraten kann, welche Funktion der Bibliothek geeignet ist.

2. Sind die Leute wirklich vom Präfix-Syntax eingeschüchtert?

Es ist ein offenes Problem, insofern ich seit einigen Jahren darüber nachdenke und immer noch keine Antwort weiß. Der Präfix-Syntax erscheint mir absolut natürlich, vielleicht abgesehen von seiner Verwendung in der Mathematik. Aber es könnte sein, dass ein großer Teil der Unbeliebtheit von Lisp einfach auf die ungewohnte Syntax zurückzuführen ist… Sollten wir etwas dagegen unternehmen, wenn das wahr ist? Das ist eine andere Frage.

3. Was benötigen Sie für Server-Software?

Ich denke, dass die meisten Anwendungen, die in den nächsten zwanzig Jahren geschrieben werden, Webanwendungen sein werden, in dem Sinne, dass Programme auf einem Server gehostet werden und über einen Webbrowser mit Ihnen kommunizieren. Um solche Anwendungen zu schreiben, benötigen wir neue Ansätze.

Eine dieser Neuerungen ist die Unterstützung eines neuen Ansatzes zur Veröffentlichung von Serveranwendungen. Anstelle von ein oder zwei großen Versionen pro Jahr, wie bei Desktop-Software, wird Server-Software in Form einer Reihe kleiner Änderungen veröffentlicht. Sie könnten fünf oder zehn Versionen pro Tag haben. Und alle haben immer die neueste Version.

Wissen Sie, wie man Programme so entwirft, dass sie pflegbar sind? Server-Software muss so entworfen sein, dass sie änderbar ist. Sie sollten in der Lage sein, sie einfach zu ändern oder zumindest zu wissen, was eine kleine Änderung bedeutet und was wichtig ist.

Eine weitere Sache, die in Server-Software nützlich sein kann, ist unerwartete Kontinuität der Lieferung. In einer Webanwendung können Sie etwas wie CPS, verwenden, um den Effekt von Subprogrammen in einer zustandslosen Welt von Web-Sitzungen zu erzielen. Kontinuität der Lieferung kann sich lohnen, wenn diese Möglichkeit nicht zu teuer ist.

4. Welche neuen Abstraktionen müssen noch entdeckt werden?

Ich bin mir nicht sicher, wie vernünftig diese Hoffnung ist, aber persönlich würde ich es sehr gerne sehen, eine neue Abstraktion zu schaffen – etwas, das eine ebenso große Bedeutung haben könnte wie Funktionen erster Klasse oder Rekursion oder zumindest Standardparameter. Vielleicht ist das ein unerfüllbarer Traum. Solche Dinge werden oft nicht entdeckt. Aber ich gebe die Hoffnung nicht auf.

Wenig bekannte Geheimnisse

1. Sie können jede Sprache verwenden, die Sie möchten

Früher verstand man unter der Erstellung von Anwendungen die Entwicklung von Desktop-Software. In der Desktop-Software gibt es eine große Neigung, Anwendungen in derselben Sprache wie das Betriebssystem zu schreiben. Vor zehn Jahren bedeutete die Softwareentwicklung insgesamt, Software in C zu schreiben. Letztendlich hat sich diese Tradition weiterentwickelt: Anwendungen müssen nicht in exotischen Sprachen geschrieben werden. Und diese Tradition hat sich so lange entwickelt, dass auch nicht-technische Personen wie Manager und Risikokapitalgeber sie erlernt haben.

Server-Software zerstört dieses Modell vollständig. Mit Server-Software können Sie jede Sprache verwenden, die Sie möchten. Fast niemand versteht das noch (besonders Manager und Risikokapitalgeber). Aber einige Hacker verstehen es, weshalb wir von solchen indie-Sprachen wie Perl und Python gehört haben. Wir hören nicht von Perl und Python, weil die Leute sie zur Entwicklung von Anwendungen für Windows nutzen.

Was bedeutet das für uns, die wir an der Gestaltung von Programmiersprachen interessiert sind? Es gibt ein potenzielles Publikum für unsere Arbeit.

2. Geschwindigkeit kommt von Profiler

Die Entwickler der Sprache oder zumindest ihre Implementierer lieben es, Compiler zu schreiben, die schnellen Code generieren. Aber ich denke, dass nicht das die Sprachen für die Benutzer schnell macht. Knuth hat schon lange bemerkt, dass die Geschwindigkeit nur von einigen wenigen Engpässen abhängt. Und jeder, der versucht hat, ein Programm zu beschleunigen, weiß, dass man nicht erraten kann, wo der Engpass ist. Der Profiler ist die Antwort.

Die Entwickler der Sprache greifen nicht das richtige Problem an. Die Benutzer brauchen nicht, dass Benchmarks schnell laufen. Sie benötigen eine Sprache, die aufzeigen kann, welche Teile ihres Programms neu geschrieben werden müssen. An diesem Punkt ist Geschwindigkeit in der Praxis erforderlich. Vielleicht wäre es besser, wenn die Implementierer der Sprache die Hälfte der Zeit, die sie mit der Optimierung des Compilers verbringen, stattdessen mit dem Schreiben eines guten Profilers verbringen würden.

3. Sie benötigen eine Anwendung, die Ihre Sprache weiterentwickelt.

Vielleicht ist das nicht die letzte Wahrheit, aber es scheint, dass die besten Sprachen sich zusammen mit den Anwendungen entwickelt haben, in denen sie verwendet wurden. C wurde von Leuten geschrieben, die systemprogrammierung benötigten. Lisp wurde teilweise für symbolische Differenzierung entwickelt. McCarthy konnte es kaum erwarten zu beginnen, sodass er bereits im ersten Dokument über Lisp im Jahr 1960 mit dem Schreiben von Differenzierungsprogrammen begann.

Es ist besonders gut, wenn Ihre Anwendung einige neue Probleme löst. Das zwingt Ihre Sprache dazu, neue Funktionen zu haben, die Programmierer benötigen. Persönlich interessiert es mich, eine Sprache zu schreiben, die für Serveranwendungen geeignet ist.

[Während der Diskussion äußerte Guy Steele auch diesen Gedanken 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 für das Schreiben von Compilern gedacht.]

4. Die Sprache sollte geeignet sein, um Einwegprogramme zu schreiben.

Sie wissen, was ein Einwegprogramm bedeutet: Es ist, wenn Sie schnell ein begrenztes Problem lösen müssen. Ich denke, dass, wenn Sie sich umschauen, Sie viele ernsthafte Programme entdecken werden, die als Einwegprogramme begonnen haben. Ich wäre nicht überrascht, wenn die meisten Programme als Einwegprogramme begonnen haben. Wenn Sie also eine Sprache schaffen wollen, die für das Schreiben von Software im Allgemeinen geeignet ist, sollte sie auch für das Schreiben von Einwegprogrammen geeignet sein, denn das ist die Anfangsphase vieler Programme.

5. Syntax ist mit Semantik verbunden.

Traditionell wird angenommen, dass Syntax und Semantik stark unterschiedliche Dinge sind. Vielleicht klingt es schockierend, aber das ist es nicht. Ich denke, dass das, was Sie in Ihrem Programm erreichen wollen, damit verbunden ist, wie Sie es ausdrücken.

Neulich sprach ich mit Robert Morris, und er bemerkte, dass die Überladung von Operatoren ein großer Vorteil für die Sprachen mit infixiertem Syntax ist. In Sprachen mit präfixierter Syntax ist jede Funktion, die Sie definieren, tatsächlich ein Operator. Wenn Sie eine neue Zahl hinzufügen möchten, die Sie erfunden haben, können Sie einfach eine neue Funktion zur Addition definieren. Wenn Sie das in einer infixierten Sprache tun, werden Sie feststellen, dass es einen großen Unterschied zwischen der Verwendung eines überladenen Operators und dem Aufruf einer Funktion gibt.

Ideen, die mit der Zeit zurückkehren

1. Neue Programmiersprachen

In den 1970er Jahren war es in Mode, neue Programmiersprachen zu entwickeln. Das ist jetzt nicht mehr so. Aber ich glaube, dass serverseitige Software die Mode zur Schaffung neuer Sprachen wiederbeleben wird. Mit serverseitiger Software können Sie jede Sprache verwenden, die Sie möchten; also wenn jemand eine Sprache schafft, die besser als die anderen erscheint, werden es Menschen geben, die sich entscheiden, sie zu verwenden.

2. Zeitteilung

Richard Kelsey brachte diese Idee ein, deren Zeit zurückgekehrt ist, und ich unterstütze sie voll und ganz. Meine Vermutung (und auch die von Microsoft) ist, dass viele Berechnungen von Desktops auf entfernte Server verlagert werden. Mit anderen Worten, die Zeitteilung ist zurückgekehrt. Ich denke, dass es auf Sprachebene Unterstützung dafür benötigt. Zum Beispiel haben Richard und Jonathan Reeve viel Arbeit investiert, um das Prozessplanen in Scheme 48 zu implementieren.

3. Effizienz

Neulich schien es, dass Computer schnell genug sind. Immer häufiger hören wir von Bytecode, was zumindest für mich bedeutet, dass wir Leistung in Reserve haben. Aber ich denke, dass wir mit serverseitiger Software diese nicht haben. Jemand muss für Server, auf denen die Software läuft, und die Anzahl der Benutzer, die der Server pro Maschine bewältigen kann, wird ein Divisor ihrer Kapitalausgaben sein.

Ich denke, dass Effizienz wichtig sein wird, zumindest in den Engpässen der Berechnungen. Besonders wichtig wird es für Ein- und Ausgabeoperationen sein, da serverseitige Anwendungen viele solcher Operationen durchführen.

Letztendlich könnte sich herausstellen, dass Bytecode nicht die Lösung ist. Sun und Microsoft scheinen im Moment direkt auf dem Bytecode-Feld gegeneinander zu kämpfen. Aber sie tun dies, weil Bytecode ein praktischer Ort ist, um sich in den Prozess einzufügen, nicht weil Bytecode an sich eine gute Idee ist. Es könnte sein, dass dieser gesamte Kampf unbemerkt bleibt. Das wäre amüsant.

Fallen und Tricks

1. Clients

Es ist nur eine Vermutung, aber die Gewinner werden wahrscheinlich nur die Anwendungen sein, die vollständig serverseitig sind. Software zu entwerfen, die auf der Annahme basiert, dass jeder deinen Client hat, ähnelt der Schaffung einer Gesellschaft, die auf der Annahme basiert, dass alle ehrlich sein werden. Es wäre definitiv bequem, aber man müsste akzeptieren, dass es so etwas nie geben wird.

Ich denke, es wird einen schnellen Anstieg an Geräten mit Webzugang geben, und man kann davon ausgehen, dass sie grundlegendes HTML und Formulare unterstützen werden. Hast du einen Browser auf deinem Telefon? Wird das Telefon in deinem PalmPilot sein? Wird dein Blackberry einen größeren Bildschirm haben? Hast du die Möglichkeit, von deinem Gameboy aus ins Internet zu gehen? Von deiner Uhr aus? Ich weiß es nicht. Und ich muss es nicht herausfinden, wenn ich darauf setze, dass alles auf dem Server sein wird. Es ist einfach viel zuverlässiger, alle Denkleistung auf dem Server zu haben.

2. Objektorientierte Programmierung

Ich verstehe, dass dies eine umstrittene Aussage ist, aber ich halte OOP nicht für etwas Wichtiges. Ich denke, es ist ein geeigneter Paradigmen für spezifische Anwendungen, die bestimmte Datenstrukturen benötigen, wie grafische Systeme, Simulationen, CAD-Systeme. Aber ich verstehe nicht, warum es für alle Programme geeignet sein sollte.

Ich denke, dass Menschen in großen Unternehmen OOP mögen, teilweise weil es vieles bietet, was wie Arbeit aussieht. Was natürlicherweise als, sagen wir, eine Liste ganzer Zahlen dargestellt werden kann, kann jetzt als Klasse mit allen Arten von Baugerüsten, Lärm und Hektik dargestellt werden.

Eine weitere ansprechende Eigenschaft von OOP ist, dass Methoden Ihnen eine Art Effekt der ersten Klasse Funktionen geben. Aber das ist für Programmierer in Lisp nichts Neues. Wenn Sie echte Funktionen erster Klasse haben, können Sie sie einfach auf jede Weise verwenden, die der gestellten Aufgabe entspricht, statt alles in ein Muster aus Klassen und Methoden zu zwängen.

Ich denke, dass das für das Sprachdesign bedeutet, dass man die OOP nicht zu tief einbetten sollte. Vielleicht liegt die Antwort darin, allgemeinere, grundlegende Dinge anzubieten und den Leuten zu erlauben, beliebige objektbasierte Systeme in Form von Bibliotheken zu entwerfen.

3. Design durch ein Komitee

Wenn Ihr Sprache von einem Komitee entworfen wird, dann befinden Sie sich in einer Falle, und das nicht nur aus den allgemein bekannten Gründen. Es ist bekannt, dass Komitees dazu tendieren, eine klobige, inkonsistente Sprachgestaltung zu schaffen. Aber ich denke, dass die große Gefahr darin besteht, dass sie keine Risiken eingehen. Wenn eine Person an der Spitze steht, übernimmt sie Risiken, die ein Komitee niemals bereit wäre, einzugehen.

Muss man Risiken eingehen, um eine gute Sprache zu schaffen? Viele Menschen könnten vermuten, dass das Design einer Sprache etwas ist, bei dem man sich recht nah an traditionellem Wissen orientieren sollte. Ich würde wetten, dass das nicht der Fall ist. In allem anderen, was Menschen tun, ist die Belohnung proportional zum Risiko. Warum sollte es beim Design von Sprachen anders sein?

Quelle: habr.com