Leitende Philosophie
1. Programmiersprachen für Menschen
Programmiersprachen sind die Art und Weise, wie Menschen mit Computern sprechen. Der Computer spricht gerne jede Sprache, die nicht mehrdeutig ist. Der Grund, warum wir Hochsprachen haben, liegt darin, dass Menschen nicht mit Maschinensprache umgehen können. Der Zweck von Programmiersprachen besteht darin, zu verhindern, dass unser armes, fragiles menschliches Gehirn von zu vielen Details überwältigt wird.
Architekten wissen, dass einige Designprobleme banaler sind als andere. Zu den klarsten und abstraktesten Entwurfsproblemen gehört der Entwurf von Brücken. In diesem Fall besteht Ihre Aufgabe darin, die erforderliche Strecke mit möglichst wenig Material zurückzulegen. Am anderen Ende des Spektrums steht das Stuhldesign. Stuhldesigner sollten ihre Zeit damit verbringen, über die Hintern der Menschen nachzudenken.
Bei der Softwareentwicklung gibt es einen ähnlichen Unterschied. Das Entwerfen von Algorithmen zum Weiterleiten von Daten durch ein Netzwerk ist ein schönes, abstraktes Problem, genau wie das Entwerfen von Brücken. Während das Entwerfen von Programmiersprachen wie das Entwerfen von Stühlen ist: Man muss sich mit menschlichen Schwächen auseinandersetzen.
Das ist für die meisten von uns schwer zu begreifen. Das Entwerfen eleganter mathematischer Systeme klingt für die meisten von uns viel attraktiver als das Ausnutzen menschlicher Schwächen. Die Rolle der mathematischen Eleganz besteht darin, dass ein gewisses Maß an Eleganz das Verständnis von Programmen erleichtert. Aber es geht nicht nur um Eleganz.
Und wenn ich sage, dass Sprachen so gestaltet werden sollten, dass sie menschlichen Schwächen Rechnung tragen, meine ich nicht, dass Sprachen für schlechte Programmierer konzipiert sein sollten. Eigentlich sollten Sie Software für die besten Programmierer entwickeln, aber selbst die besten Programmierer haben ihre Grenzen. Ich glaube nicht, dass es irgendjemandem Spaß machen würde, in einer Sprache zu programmieren, in der alle Variablen durch den Buchstaben „x“ mit ganzzahligen Indizes gekennzeichnet werden.
2. Entwerfen Sie für sich selbst und Ihre Freunde
Wenn man sich die Geschichte der Programmiersprachen anschaut, sind die meisten der besten Sprachen für die Verwendung durch ihre eigenen Autoren konzipiert und die meisten der schlechtesten für die Verwendung durch andere.
Wenn Sprachen für andere Menschen entwickelt werden, handelt es sich immer um eine bestimmte Gruppe von Menschen: Menschen sind nicht so schlau wie die Schöpfer der Sprache. So bekommst du eine Zunge, die zu dir herabredet. Cobol ist das prominenteste Beispiel, aber die meisten Sprachen sind von diesem Geist durchdrungen.
Es hat nichts damit zu tun, wie hoch das Niveau der Sprache ist. C ist auf einem relativ niedrigen Niveau, wurde aber für die Verwendung durch seine Autoren entwickelt, weshalb Hacker es lieben.
Das Argument dafür, Sprachen für schlechte Programmierer zu entwerfen, ist, dass es mehr schlechte als gute Programmierer gibt. Vielleicht ist das so. Aber diese kleine Zahl guter Programmierer schreibt unverhältnismäßig mehr Software.
Meine Frage ist: Wie erstellt man eine Sprache, die die besten Hacker anspricht? Mir scheint, dass diese Frage mit der Frage, wie man eine gute Programmiersprache erstellt, identisch ist, aber selbst wenn das 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 Menschen entwickelt wurden) verhalten sich wie Kindermädchen: Sie versuchen, Sie vor Dingen zu warnen, von denen sie glauben, dass sie für Sie nicht nützlich sind. Ich vertrete die gegenteilige Ansicht: Geben Sie dem Programmierer so viel Kontrolle wie möglich.
Als ich Lisp zum ersten Mal lernte, gefiel mir am besten, dass wir auf Augenhöhe miteinander redeten. In den anderen Sprachen, die ich zu diesem Zeitpunkt gelernt hatte, gab es eine Sprache und mein Programm in dieser Sprache, und sie existierten ganz 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 ist die Schwester des Talents
Kürze wird unterschätzt und sogar verachtet. Aber wenn man in die Herzen der Hacker blickt, erkennt man, dass sie die Kürze wirklich mögen. Wie oft haben Sie schon gehört, dass Hacker liebevoll darüber reden, wie sie beispielsweise in APL mit nur ein paar Codezeilen erstaunliche Dinge tun können? Ich vermute, wirklich kluge Leute achten tatsächlich gerne darauf.
Ich glaube, dass fast alles, was Programme kürzer macht, eine gute Sache ist. Es sollte viele Bibliotheksfunktionen geben, alles, was implizit sein kann, sollte so sein; die Syntax sollte prägnanter sein; Auch Entitätsnamen sollten kurz sein.
Und nicht nur Programme sollten kurz sein. Auch Handbücher sollten kurz sein. Ein großer Teil der Handbücher ist mit Erläuterungen, Haftungsausschlüssen, Warnungen und Sonderfällen gefüllt. Wenn Sie das Handbuch kürzen müssen, ist es am besten, die erklärungsbedürftige Sprache zu korrigieren.
5. Erkennen Sie, was Hacking ist
Viele Menschen möchten, dass Hacken Mathematik oder zumindest etwas Ähnliches wie Naturwissenschaften ist. Ich denke, dass Hacken eher mit Architektur zu tun hat. In der Architektur geht es um Physik, da ein Architekt ein Gebäude entwerfen muss, das nicht einstürzt. Das eigentliche Ziel eines Architekten besteht jedoch darin, ein großartiges Gebäude zu schaffen, und nicht darin, Entdeckungen auf dem Gebiet der Statik zu machen.
Hacker lieben es, großartige Programme zu erstellen. Und ich denke, dass wir uns zumindest in unseren eigenen Gedanken daran erinnern sollten, dass das Schreiben großartiger Programme eine wunderbare Sache ist, auch wenn sich diese Arbeit nicht leicht in die übliche intellektuelle Aktualität wissenschaftlicher Arbeiten übersetzen lässt. Aus intellektueller Sicht ist es genauso wichtig, eine Sprache zu entwerfen, die Programmierer lieben werden, wie eine schreckliche Sprache zu entwerfen, die eine Idee verkörpert, über die man einen Aufsatz veröffentlichen kann.
Offene Punkte
1. Wie organisiert man 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, in einer Bibliothek eine Funktion zu finden, die das tut, was Sie brauchen, als diese Funktion selbst zu schreiben, dann macht der gesamte Code Ihr Handbuch nur dicker. (Die Symbolics-Handbücher waren ein Beispiel dafür.) Wir müssen also das Problem der Bibliotheksorganisation lösen. Gestalten Sie sie idealerweise so, dass der Programmierer erraten kann, welche Bibliotheksfunktion geeignet ist.
2. Haben die Leute wirklich Angst vor der Präfixsyntax?
Dies ist ein offenes Problem in dem Sinne, dass ich seit mehreren Jahren darüber nachdenke und immer noch keine Antwort weiß. Die Präfixsyntax erscheint mir völlig natürlich, abgesehen vielleicht von ihrer Verwendung in der Mathematik. Aber es kann sein, dass ein Großteil der Unbeliebtheit von Lisp einfach auf die ungewohnte Syntax zurückzuführen ist ... Ob es sich lohnt, etwas dagegen zu unternehmen, wenn das stimmt, ist eine andere Frage.
3. Was benötigen Sie an Serversoftware?
Ich denke, die meisten Anwendungen, die in den nächsten zwanzig Jahren geschrieben werden, werden Webanwendungen sein, in dem Sinne, dass Programme auf einem Server liegen und über einen Webbrowser mit Ihnen kommunizieren. Und um solche Bewerbungen zu schreiben, brauchen wir neue Dinge.
Eines dieser Dinge ist die Unterstützung einer neuen Möglichkeit, Serveranwendungen freizugeben. Anstelle von ein oder zwei großen Veröffentlichungen pro Jahr, wie Desktop-Software, wird Server-Software in einer Reihe kleiner Änderungen veröffentlicht. Möglicherweise haben Sie fünf oder zehn Veröffentlichungen pro Tag. Und jeder wird immer die neueste Version haben.
Wissen Sie, wie man Programme so gestaltet, dass sie wartbar sind? Serversoftware muss veränderbar gestaltet sein. Sie sollten es leicht ändern können oder zumindest wissen, was eine kleine Änderung bedeutet und was wichtig ist.
Eine weitere Sache, die bei Serversoftware nützlich sein kann, ist plötzlich die Kontinuität der Bereitstellung. In einer Webanwendung können Sie so etwas wie verwenden um die Wirkung von Routinen in der zustandslosen Welt der Websitzungen zu erzielen. Eine kontinuierliche Versorgung kann sich lohnen, wenn die Funktion nicht zu teuer ist.
4. Welche neuen Abstraktionen müssen noch entdeckt werden?
Ich bin mir nicht sicher, wie berechtigt diese Hoffnung ist, aber ich persönlich würde wirklich gerne eine neue Abstraktion entdecken – etwas, das genauso aussagekräftig sein könnte wie erstklassige Funktionen oder Rekursion oder zumindest Standardparameter. Vielleicht ist das ein unmöglicher Traum. Solche Dinge werden oft nicht entdeckt. Aber ich verliere nicht die Hoffnung.
Wenig bekannte Geheimnisse
1. Sie können jede gewünschte Sprache verwenden
Früher bedeutete die Erstellung von Anwendungen die Erstellung von Desktop-Software. Und bei 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 im Allgemeinen, Software in C zu schreiben. Mit der Zeit entwickelte sich die Tradition: Anwendungen sollten nicht in ungewöhnlichen Sprachen geschrieben werden. Und diese Tradition hat sich schon so lange entwickelt, dass sie auch von Laien wie Managern und Risikokapitalgebern gelernt wurde.
Serversoftware zerstört dieses Modell vollständig. Mit Serversoftware können Sie jede gewünschte Sprache verwenden. Fast niemand versteht das noch (besonders Manager und Risikokapitalgeber). Aber einige Hacker verstehen das, weshalb wir von Indy-Sprachen wie Perl und Python hören. Wir hören nichts von Perl und Python, weil die Leute sie zum Schreiben von Windows-Anwendungen verwenden.
Was bedeutet das für uns Menschen, die sich für das Design von Programmiersprachen interessieren, dass es ein potenzielles Publikum für unsere Arbeit gibt?
2. Geschwindigkeit kommt von Profilern
Sprachentwickler oder zumindest Sprachimplementierer schreiben gerne Compiler, die schnellen Code generieren. Aber ich glaube nicht, dass das Sprachen für Benutzer schnell macht. Knuth hat schon vor langer Zeit darauf hingewiesen, dass die Geschwindigkeit von wenigen Engpässen abhängt. Und jeder, der schon einmal versucht hat, ein Programm zu beschleunigen, weiß, dass man nicht erraten kann, wo der Engpass liegt. Profiler ist die Antwort.
Sprachentwickler lösen das falsche Problem. Benutzer benötigen keine Benchmarks, um schnell zu laufen. Sie benötigen eine Sprache, die zeigen kann, welche Teile ihres Programms neu geschrieben werden müssen. An dieser Stelle ist in der Praxis Schnelligkeit gefragt. Vielleicht wäre es also besser, wenn Sprachimplementierer die Hälfte der Zeit, die sie für die Optimierung des Compilers aufwenden, in das Schreiben eines guten Profilers investieren würden.
3. Sie benötigen eine App, die Ihre Sprache weiterentwickelt
Dies ist vielleicht nicht die endgültige Wahrheit, aber es scheint, dass sich die besten Sprachen 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 die symbolische Differenzierung entwickelt, und McCarthy war so gespannt darauf, damit anzufangen, dass er 1960 im ersten Lisp-Aufsatz sogar damit begann, Differenzierungsprogramme zu schreiben.
Dies ist besonders gut, wenn Ihre Anwendung einige neue Probleme löst. Dies führt dazu, dass Ihre Sprache über neue Funktionen verfügt, die sich Programmierer wünschen. Persönlich bin ich daran interessiert, eine Sprache zu schreiben, die sich gut für Serveranwendungen eignet.
[Während der Diskussion machte auch Guy Steele diesen Punkt deutlich 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 zum Schreiben von Compilern konzipiert.]4. Die Sprache muss zum Schreiben von Einmalprogrammen geeignet sein.
Sie wissen, was ein One-Shot-Programm bedeutet: Es geht darum, schnell ein begrenztes Problem zu lösen. Ich glaube, wenn Sie sich umschauen, werden Sie viele ernsthafte Programme finden, die als Einzelstücke begannen. Es würde mich nicht wundern, wenn die meisten Programme einmalig wären. Wenn Sie also eine Sprache erstellen möchten, die sich zum Schreiben von Software im Allgemeinen eignet, sollte diese auch zum Schreiben einmaliger Programme geeignet sein, da dies die Anfangsphase vieler Programme ist.
5. Syntax hängt mit Semantik zusammen
Traditionell wird angenommen, dass Syntax und Semantik sehr unterschiedliche Dinge sind. Das mag schockierend klingen, ist es aber nicht. Ich denke, was Sie mit Ihrem Programm erreichen wollen, hängt davon ab, wie Sie es ausdrücken.
Ich habe kürzlich mit Robert Morris gesprochen und er hat darauf hingewiesen, dass die Überladung von Operatoren ein großer Vorteil für den Sieg von Sprachen mit Infix-Syntax ist. In Sprachen mit Präfixsyntax ist jede von Ihnen definierte Funktion tatsächlich ein Operator. Wenn Sie einen neuen, von Ihnen erstellten Zahlentyp hinzufügen möchten, können Sie einfach eine neue Funktion definieren, um ihn 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 Aufruf einer Funktion gibt.
Ideen, die mit der Zeit wiederkommen
1. Neue Programmiersprachen
Rückblickend auf die 1970er Jahre war es in Mode, neue Programmiersprachen zu entwickeln. Dies ist jetzt nicht der Fall. Aber ich glaube, dass Serversoftware die Entwicklung neuer Sprachen wieder in Mode bringen wird. Mit Serversoftware können Sie jede gewünschte Sprache verwenden. Wenn also jemand eine Sprache erstellt, die besser zu sein scheint als die anderen, wird es Leute geben, die sich dafür entscheiden, sie zu verwenden.
2. Zeitteilung
Richard Kelsey hatte diese Idee, deren Zeit nun wieder gekommen ist und ich unterstütze sie voll und ganz. Meine Vermutung (und auch die von Microsoft) ist, dass ein Großteil der Rechenleistung vom Desktop auf Remote-Server verlagert wird. Mit anderen Worten: Time-Sharing ist zurück. Ich denke, dass dies auf sprachlicher Ebene unterstützt werden muss. Richard und Jonathan Reeves haben beispielsweise viel Arbeit geleistet, um die Prozessplanung in Scheme 48 zu implementieren.
3. Effizienz
Kürzlich schien es, als seien Computer bereits schnell genug. Wir hören immer mehr über Bytecode, was zumindest für mich bedeutet, dass wir über einige Leistungsreserven verfügen. Aber ich denke, dass wir das bei Serversoftware nicht haben. Jemand muss für die Server bezahlen, auf denen die Software läuft, und die Anzahl der Benutzer, die der Server pro Maschine unterstützen kann, ist ein Teiler seiner Kapitalkosten.
Ich denke, dass Effizienz eine Rolle spielen wird, zumindest bei Rechenengpässen. 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 nicht die Lösung ist. Im Bytecode-Bereich scheinen Sun und Microsoft derzeit ein Kopf-an-Kopf-Rennen zu liefern. Aber sie tun dies, weil Bytecode ein praktischer Ort ist, um sich in einen Prozess einzubetten, und nicht, weil Bytecode selbst eine gute Idee ist. Es kann sein, dass dieser ganze Kampf unbemerkt bleibt. Es wäre lustig.
Schlingen und Schlingen
1. Kunden
Das ist nur eine Vermutung, aber es ist so, dass die einzigen Anwendungen, die davon profitieren, diejenigen sind, die vollständig serverseitig sind. Die Entwicklung von Software, die davon ausgeht, dass jeder einen Kunden hat, ist wie die Gestaltung einer Gesellschaft, die von der Annahme ausgeht, dass jeder ehrlich ist. Es wäre auf jeden Fall praktisch, aber man muss davon ausgehen, dass es nie passieren wird.
Ich denke, dass es einen schnellen Anstieg an webfähigen Geräten geben wird, und wir können davon ausgehen, dass sie grundlegendes HTML und Formulare unterstützen werden. Haben Sie einen Browser auf Ihrem Telefon? Wird Ihr PalmPilot über ein Telefon verfügen? Wird Ihr Blackberry einen größeren Bildschirm haben? Können Sie mit Ihrem Gameboy auf das Internet zugreifen? Von deiner Uhr? Ich weiß nicht. Und ich muss es nicht herausfinden, wenn ich wette, dass alles auf dem Server sein wird. Es ist einfach viel zuverlässiger, alle Köpfe auf dem Server zu haben. .
2. Objektorientierte Programmierung
Mir ist klar, dass dies eine kontroverse Aussage ist, aber ich glaube nicht, dass OOP so wichtig ist. Ich denke, dass dies ein geeignetes Paradigma für bestimmte Anwendungen ist, 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, die Leute in großen Unternehmen lieben OOP, auch weil dadurch viele Dinge wie Arbeit aussehen. Was natürlicherweise beispielsweise als Liste ganzer Zahlen dargestellt werden könnte, kann jetzt als Klassenzimmer mit allerlei Gerüsten, Trubel und Hektik dargestellt werden.
Ein weiteres attraktives Merkmal von OOP besteht darin, dass Methoden einen Teil der Wirkung erstklassiger Funktionen bieten. Für Lisp-Programmierer ist das jedoch keine Neuigkeit. Wenn Sie über wirklich erstklassige Funktionen verfügen, können Sie diese einfach so verwenden, wie es für die jeweilige Aufgabe geeignet ist, anstatt alles in eine Reihe von Klassen und Methoden zu packen.
Ich denke, was das für das Sprachdesign bedeutet, ist, dass man OOP nicht zu tief darin einbetten sollte. Vielleicht besteht die Antwort darin, allgemeinere, grundlegendere Dinge anzubieten und den Leuten die Möglichkeit zu geben, beliebige Objektsysteme als Bibliotheken zu entwerfen.
3. Entwurf durch ein Komitee
Wenn Ihre Sprache von einem Komitee entworfen wird, dann sitzen Sie in der Falle, und das nicht nur aus Gründen, die jeder kennt. Jeder weiß, dass Gremien dazu neigen, klumpige, inkonsistente Sprachdesigns zu erstellen. Aber ich denke, die große Gefahr besteht darin, dass sie kein Risiko eingehen. Wenn eine Person das Sagen hat, geht sie Risiken ein, die das Komitee niemals eingehen würde.
Muss man Risiken eingehen, um eine gute Sprache zu entwickeln? Viele Leute könnten vermuten, dass man beim Sprachdesign ziemlich nah an der traditionellen Weisheit bleiben muss. Ich wette, das ist nicht der Fall. Bei allem anderen, was Menschen tun, ist die Belohnung proportional zum Risiko. Warum sollte es beim Sprachdesign anders sein?
Source: habr.com