Leitende Philosophie
1. Programmiersprachen für Menschen
Programmiersprachen sind die Art und Weise, wie Menschen mit Computern kommunizieren. Ein Computer ist bereit, in jeder Sprache zu sprechen, die eindeutig ist. Der Grund, warum wir Hochsprachen haben, liegt darin, dass Menschen mit maschineller Sprache überfordert wären. Das Wesen von Programmiersprachen besteht darin, unser fragiles menschliches Gehirn vor der Überlastung durch eine Vielzahl von Details zu schützen.
Architekten wissen, dass einige Entwurfsprobleme greifbarer sind als andere. Eines der klarsten und abstraktesten Entwurfsprobleme ist das Brückenbauen. In diesem Fall besteht Ihre Aufgabe darin, die erforderliche Distanz mit möglichst wenig Material zu überwinden. Am anderen Ende des Spektrums steht das Design von Stühlen. Stuhldesigner müssen ihre Zeit damit verbringen, über menschliche Hinterteile nachzudenken.
Die Softwareentwicklung weist eine ähnliche Differenzierung auf. Das Entwerfen von Algorithmen zur Datenweiterleitung über Netzwerke ist ein anspruchsvolles, abstraktes Problem, ähnlich wie bei der Konstruktion von Brücken. Hingegen ist die Gestaltung von Programmiersprachen vergleichbar mit dem Design von Stühlen: Man muss die menschlichen Schwächen berücksichtigen.
Es fällt vielen von uns schwer, dies zu erkennen. Die Gestaltung eleganter mathematischer Systeme klingt für die meisten von uns wesentlich ansprechender, als den menschlichen Schwächen nachzugeben. Die Rolle mathematischer Eleganz besteht darin, dass ein gewisses Maß an Eleganz die Programme verständlicher macht. Doch Eleganz ist nicht alles.
Wenn ich sage, dass Programmiersprachen so gestaltet werden sollten, dass sie menschliche Schwächen berücksichtigen, meine ich nicht, dass sie 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 kann mir nicht vorstellen, dass jemand Spaß daran hätte, in einer Sprache zu programmieren, in der alle Variablen mit dem Buchstaben „x“ und ganzzahligen Indizes bezeichnet werden.
2. Entwerfen Sie für sich selbst und Ihre Freunde
Ein Blick auf die Geschichte der Programmiersprachen zeigt, dass die besten Sprachen oft von ihren eigenen Schöpfern entworfen wurden, während die schlechtesten häufig für andere Menschen entwickelt wurden.
Wenn Sprachen für andere Menschen entworfen werden, ist dies oft eine spezifische Gruppe von Menschen: Die Nutzer sind nicht so intelligent wie die Schöpfer der Sprache. Dadurch entsteht 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 hochgradig eine Sprache ist. C ist relativ niedrig, wurde jedoch von seinen Erfindern für deren Gebrauch entwickelt, weshalb Hacker sie lieben.
Das Argument, dass Sprachen für schlechte Programmierer entworfen werden sollten, liegt darin, dass es mehr schlechte Programmierer als gute gibt. Vielleicht ist das so. Aber eine kleine Anzahl guter Programmierer schreibt überproportional viel mehr Software.
Ich habe eine Frage: Wie kann man eine Programmiersprache entwickeln, die selbst die besten Hacker anspricht? Ich glaube, diese Frage ist vergleichbar mit der Frage, wie man eine gute Programmiersprache erstellt. Aber selbst wenn es das nicht ist, bleibt es eine interessante Frage.
3. Geben Sie dem Programmierer so viel Kontrolle wie möglich.
Viele Sprachen (insbesondere solche, die für andere entwickelt wurden) benehmen sich wie Aufpasser: Sie versuchen, Sie von Dingen abzuhalten, die ihrer Meinung nach nicht nützlich für Sie sind. Ich vertrete eine gegenteilige Ansicht: Geben Sie dem Programmierer so viel Kontrolle wie möglich.
Als ich zum ersten Mal Lisp lernte, gefiel mir am meisten, dass wir auf Augenhöhe kommunizierten. In anderen Sprachen, die ich zuvor gelernt hatte, gab es die Sprache und mein Programm in dieser Sprache, und sie existierten recht unabhängig voneinander. Aber in Lisp waren die Funktionen und Makros, die ich schrieb, die gleichen, auf denen die Sprache selbst basierte. Ich hätte die Sprache selbst umschreiben können, wenn ich gewollt hätte. Sie hatte den gleichen Reiz wie Software mit offenem Quellcode.
4. Kürze ist die Schwester des Talents.
Kürze wird oft unterschätzt und sogar verachtet. Aber wenn man in die Herzen von Hackern schaut, erkennt man, dass sie Kürze sehr schätzen. Wie oft haben Sie gehört, dass Hacker mit Begeisterung berichten, dass sie in APL mit nur wenigen Codezeilen erstaunliche Dinge schaffen können? Ich bin überzeugt, dass wirklich kluge Menschen dies zu schätzen wissen.
Ich denke, dass alles, was Programme kürzer macht, gut ist. Es sollte eine Vielzahl von Bibliotheksfunktionen geben, alles, was implizit sein kann, sollte es auch sein; die Syntax sollte weitestgehend kurz sein; selbst die Namen der Entitäten sollten kurz gehalten werden.
Und nicht nur Programme sollten kurz sein. Handbücher sollten ebenfalls kurz sein. Ein großer Teil der Handbücher ist mit Erklärungen, Vorbehalten, Warnungen und Sonderfällen überladen. Wenn Sie ein Handbuch kürzen möchten, ist es am besten, die Sprache zu korrigieren, die so viele Erklärungen erfordert.
5. Akzeptieren Sie, was Hackertum ist.
Viele Menschen wünschen sich, dass das Hacken wie Mathematik oder zumindest wie eine Naturwissenschaft wäre. Ich denke, dass Hacken eher der Architektur ähnelt. Architektur hat mit Physik zu tun, da ein Architekt ein Gebäude entwerfen muss, das nicht einstürzt. Aber das wahre Ziel eines Architekten besteht darin, ein großartiges Gebäude zu schaffen und nicht nur Entdeckungen im Bereich der Statik zu machen.
Was Hacker lieben, ist es, großartige Programme zu entwickeln. Und ich denke, dass wir zumindest in unseren eigenen Gedanken daran denken sollten, dass es wunderbar ist, großartige Programme zu schreiben, auch wenn diese Arbeit sich schwer in übliche intellektuelle Währungen wissenschaftlicher Arbeiten umsetzen lässt. Aus intellektueller Sicht ist es ebenso wichtig, eine Sprache zu entwickeln, die Programmierer lieben, wie auch eine fürchterliche, die die Idee verkörpert, über die 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 umfangreich, dass es gefährlich sein kann. Wenn es länger dauert, eine Funktion in einer Bibliothek zu finden, die das erfüllt, was Sie benötigen, als diese Funktion selbst zu schreiben, dann macht der gesamte Code nichts anderes, als Ihr Handbuch aufzublähen. (Die Handbücher von Symbolics waren ein Beispiel dafür.) Daher müssen wir das Problem der Organisation von Bibliotheken lösen. Ideal wäre es, sie so zu gestalten, dass der Programmierer erraten kann, welche Funktion der Bibliothek passt.
2. Haben die Menschen wirklich Angst vor Präfix-Syntax?
Es handelt sich um ein offenes Problem, da ich seit mehreren Jahren darüber nachdenke und immer noch keine Antwort weiß. Präfix-Syntax erscheint mir völlig natürlich, vielleicht abgesehen von ihrer Verwendung in der Mathematik. Aber es könnte so sein, dass die große Mehrheit der Unbeliebtheit von Lisp einfach auf die ungewohnte Syntax zurückzuführen ist... Ob man etwas dagegen unternehmen sollte, wenn das der Fall ist, ist eine andere Frage.
3. Was benötigen Sie für Server-Software?
Ich bin der Meinung, dass die meisten Anwendungen, die in den nächsten zwanzig Jahren entwickelt werden, Webanwendungen sein werden. Das bedeutet, dass Programme auf Servern gehostet werden und über einen Webbrowser mit Ihnen kommunizieren. Um solche Anwendungen zu erstellen, benötigen wir neue Ansätze.
Eine dieser Neuerungen ist die Unterstützung eines neuen Ansatzes für die Bereitstellung von Serveranwendungen. Anstelle von ein oder zwei großen Releases im Jahr, wie es bei Desktop-Software der Fall ist, wird Serversoftware in Form einer Reihe kleinerer Änderungen veröffentlicht. Sie können fünf oder zehn Releases pro Tag haben. Jeder Nutzer hat immer die neueste Version.
Wissen Sie, wie man Programme so entwirft, dass sie wartbar sind? Serversoftware muss so konzipiert sein, dass sie anpassbar ist. Sie sollten in der Lage sein, Änderungen leicht vorzunehmen oder zumindest zu wissen, was eine kleine Änderung ist und was wichtig ist.
Eine weitere nützliche Eigenschaft in Serversoftware könnte unerwartet die kontinuierliche Bereitstellung sein. In einer Webanwendung können Sie etwas verwenden wie , um die Auswirkungen von Subroutinen in einer zustandslosen Welt von Web-Sessions zu erleben. Die Kontinuität der Bereitstellung kann sich lohnen, wenn diese Möglichkeit nicht zu teuer ist.
4. Welche neuen Abstraktionen sind noch zu entdecken?
Ich bin mir nicht sicher, wie vernünftig diese Hoffnung ist, aber persönlich würde ich mir sehr wünschen, eine neue Abstraktion zu entdecken — etwas, das ebenso bedeutsam sein könnte wie erstklassige Funktionen 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 bedeutete die Erstellung von Anwendungen das Schreiben von Desktop-Software. Und bei Desktop-Software gibt es einen starken Neigungs zur Entwicklung von Anwendungen in derselben Sprache wie das Betriebssystem. Vor zehn Jahren bedeutete Softwareentwicklung im Allgemeinen, Software in C zu schreiben. Schließlich hat sich die Tradition weiterentwickelt: Anwendungen müssen nicht in ungewöhnlichen Sprachen geschrieben werden. Diese Tradition hat sich so lange entwickelt, dass auch nicht-technische Personen, wie Manager und Risikokapitalgeber, dies verstanden haben.
Server-Software vernichtet dieses Modell vollständig. Mit Server-Software können Sie jede gewünschte Sprache auswählen. Das versteht fast niemand (insbesondere Manager und Risikokapitalgeber). Aber einige Hacker wissen das, weshalb wir von Indie-Sprachen wie Perl und Python gehört haben. Wir hören nicht von Perl und Python, weil Menschen sie zur Erstellung von Anwendungen für Windows verwenden.
Was bedeutet das für uns, die an der Entwicklung von Programmiersprachen interessiert sind? Es gibt ein potenzielles Publikum für unsere Arbeit.
2. Geschwindigkeit kommt von Profilern
Die Entwickler der Sprache oder zumindest die Implementierer mögen es, Compiler zu schreiben, die schnellen Code generieren. Aber ich glaube, das ist nicht der Grund, warum Sprachen schnell für die Benutzer sind. Knuth hat schon lange festgestellt, dass die Geschwindigkeit einzig von einigen wenigen Engpässen abhängt. Jeder, der versucht hat, ein Programm zu beschleunigen, weiß, dass man nicht erraten kann, wo der Engpass liegt. Der Profiler ist die Antwort.
Die Entwickler der Sprache lösen nicht das wahre Problem. Die Nutzer benötigen keine schnell laufenden Benchmarks. Sie brauchen eine Sprache, die aufzeigt, welche Teile ihres Programms überarbeitet werden müssen. In diesem Moment ist Geschwindigkeit in der Praxis gefragt. Vielleicht wäre es besser, wenn die Implementatoren der Sprache die Hälfte der Zeit, die sie mit der Optimierung des Compilers verbringen, in die Entwicklung eines guten Profilers investieren würden.
3. Sie benötigen eine Anwendung, die Ihre Sprache voranbringt.
Das mag nicht die letzte Wahrheit sein, aber es scheint, dass sich die besten Sprachen gemeinsam mit den Anwendungen entwickelt haben, in denen sie eingesetzt wurden. C wurde von Menschen erstellt, die systemnahe Programmierung benötigten. Lisp wurde teilweise für symbolische Differenzierung entwickelt, und McCarthy war so begierig, dass er bereits im ersten Dokument über Lisp im Jahr 1960 Differenzierungsprogramme zu schreiben begann.
Das ist besonders vorteilhaft, wenn Ihre Anwendung neue Probleme angeht. Das fordert Ihre Sprache heraus, neue Funktionen zu bieten, die Programmierer benötigen. Persönlich interessiert es mich, eine Sprache zu entwickeln, die gut für Serveranwendungen geeignet ist.
[Während der Diskussion äußerte Guy Steele auch diesen Gedanken und fügte hinzu, dass die Anwendung nicht darin bestehen sollte, einen Compiler für Ihre Sprache zu schreiben, es sei denn, Ihre Sprache ist dafür gedacht, Compiler zu schreiben.]
4. Die Sprache sollte geeignet sein, um Einmalprogramme zu erstellen.
Sie wissen, was ein Einmalprogramm bedeutet: Es ist eine schnelle Lösung für ein spezifisches Problem. Wenn Sie sich umsehen, werden Sie feststellen, dass viele ernsthafte Programme als Einmalprogramme begann. Ich wäre nicht überrascht, wenn die meisten Programme ursprünglich als Einmalprogramme entwickelt wurden. Daher sollte, wenn Sie eine Sprache schaffen wollen, die für die Softwareentwicklung insgesamt geeignet ist, auch die Möglichkeit zur Erstellung von Einmalprogrammen gegeben sein, denn dies ist der Ausgangspunkt vieler Programme.
5. Syntax ist mit Semantik verbunden.
Traditionell wird angenommen, dass Syntax und Semantik sehr unterschiedliche Aspekte sind. Das mag schockierend klingen, ist aber nicht so. Ich denke, dass das, was Sie in Ihrem Programm erreichen möchten, eng mit der Art und Weise verbunden ist, wie Sie es ausdrücken.
Kürzlich sprach ich mit Robert Morris, und er bemerkte, dass die Überladung von Operatoren einen großen Vorteil in der Dominanz von Sprachen mit infixaler Syntax darstellt. In Sprachen mit präfiguraler Syntax ist jede Funktion, die Sie definieren, im Grunde ein Operator. Wenn Sie einen neuen Typ von Zahl, den Sie erfunden haben, addieren möchten, können Sie einfach eine neue Funktion definieren, um ihn hinzuzufügen. Wenn Sie das in einer Sprache mit infixaler Syntax tun, werden Sie feststellen, dass es einen erheblichen 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 angesagt, neue Programmiersprachen zu entwickeln. Das ist heute nicht mehr so. Aber ich denke, dass die Server-Software die Schaffung neuer Sprachen wieder populär machen wird. Mit Server-Software können Sie jede Sprache verwenden, die Sie möchten. Wenn also jemand eine Sprache erstellt, die besser erscheint als die anderen, wird es Menschen geben, die bereit sind, sie zu verwenden.
2. Zeitmanagement
Richard Kelsey brachte diese Idee vor, deren Zeit wieder gekommen ist, und ich unterstütze sie voll und ganz. Meine Vermutung (und auch die von Microsoft) ist, dass viele Berechnungen von Desktop-Computern auf Remote-Server verschoben werden. Mit anderen Worten, das Zeitalter der Zeitteilung ist zurück. Ich denke, wir werden Unterstützung auf Sprachebene benötigen. Beispielsweise haben Richard und Jonathan Reeves viel Arbeit geleistet, um die Prozessplanung in Scheme 48 zu implementieren.
3. Effizienz
Kürzlich schien es, als wären Computer bereits schnell genug. Immer häufiger hören wir von Bytecode, was für mich bedeutet, dass wir noch über Reserven verfügen. Aber ich denke, dass wir dies mit Server-Software nicht haben. Jemand muss für die Server, auf denen die Software läuft, und die Anzahl der Benutzer, die ein Server pro Maschine unterstützen kann, wird ein Faktor ihrer Kapitalkosten sein.
Ich denke, dass Effizienz von Bedeutung sein wird, insbesondere in den Engpässen der Berechnungen. Dies wird besonders wichtig für Eingabe-/Ausgabeoperationen sein, da Serveranwendungen viele solcher Operationen produzieren.
Am Ende könnte sich herausstellen, dass Bytecode nicht die Lösung ist. Momentan scheinen Sun und Microsoft direkt im Wettbewerb um das Bytecode-Feld zu stehen. Sie tun dies jedoch, weil Bytecode ein praktischer Ort ist, um sich in den Prozess einzuschleusen, und nicht, weil Bytecode per se eine gute Idee ist. Es könnte sogar sein, dass dieser gesamte Kampf unbemerkt bleibt. Das wäre amüsant.
Fallen und Stolpersteine
1. Kunden
Das ist nur eine Vermutung, aber es scheint, dass nur die Anwendungen gewinnen werden, die vollständig serverseitig sind. Software zu entwerfen, die auf der Annahme basiert, dass jeder Ihren Client haben wird, ist wie eine Gesellschaft zu schaffen, die auf der Annahme basiert, dass alle ehrlich sind. Das wäre zwar sehr bequem, aber Sie müssen annehmen, dass das niemals der Fall sein wird.
Ich denke, dass es eine schnelle Zunahme von Geräten mit Internetzugang geben wird, und man kann annehmen, dass sie grundlegendes HTML und Formulare unterstützen werden. Haben Sie einen Browser auf Ihrem Handy? Wird das Telefon in Ihrem PalmPilot sein? Hat Ihr Blackberry einen größeren Bildschirm? Werden Sie in der Lage sein, von Ihrem Gameboy aus ins Internet zu gehen? Von Ihrer Uhr? Ich weiß es nicht. Und ich muss das nicht herausfinden, wenn ich darauf setze, dass alles auf dem Server sein wird. Es ist einfach viel zuverlässiger, alle Daten auf dem Server zu haben.
2. Objektorientierte Programmierung
Ich verstehe, dass diese Aussage umstritten ist, aber ich halte OOP nicht für etwas Wichtiges. Ich denke, es ist eine geeignete Paradigma für spezifische Anwendungen, die besondere Datenstrukturen benötigen, wie z.B. Fenster-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 teilweise mögen, weil es viele Dinge liefert, die wie Arbeit aussehen. Was natürlich als Liste ganzer Zahlen dargestellt werden könnte, kann nun als Klasse mit allen Arten von Gerüsten präsentiert werden, mit Lärm und Hektik.
Ein weiterer attraktiver Aspekt der objektorientierten Programmierung (OOP) ist, dass Methoden einen ähnlichen Effekt wie Funktionen erster Klasse bieten. Das ist jedoch keine Neuigkeit für Programmierer, die mit Lisp arbeiten. Wenn Sie echte Funktionen erster Klasse haben, können Sie sie auf jede Weise verwenden, die zur Lösung des Problems passt, anstatt alles in eine Vorlage aus Klassen und Methoden zu quetschen.
Ich denke, das bedeutet für das Sprachdesign, dass Sie OOP nicht zu tief in die Sprache integrieren sollten. Vielleicht liegt die Antwort darin, allgemeinere, grundlegende Konzepte anzubieten und den Menschen zu erlauben, beliebige Objektsysteme in Form von Bibliotheken zu entwerfen.
3. Design durch ein Komitee
Wenn Ihr Sprachdesign von einem Komitee erstellt wird, sitzen Sie in der Falle, und das nicht nur aus den weithin bekannten Gründen. Es ist bekannt, dass Komitees dazu neigen, umständliche und inkonsistente Sprachdesigns zu schaffen. Aber ich denke, das größte Risiko ist, dass sie keine Risiken eingehen. Wenn eine einzelne Person an der Spitze steht, übernimmt sie Risiken, die ein Komitee niemals bereit wäre einzugehen.
Muss man Risiko eingehen, um eine gute Sprache zu schaffen? Viele Menschen vermuten vielleicht, dass das Entwerfen von Sprachen etwas ist, bei dem man sich sehr eng an traditioneller Weisheit orientieren sollte. Ich würde behaupten, dass dem nicht so ist. In allen anderen Bereichen, in denen Menschen tätig sind, steht die Belohnung in einem Verhältnis zum Risiko. Warum sollte es beim Entwerfen von Sprachen anders sein?
Quelle: habr.com
