Leitende Philosophie
1. Programmiersprachen für Menschen
Programmiersprachen sind die Art und Weise, wie Menschen mit Computern kommunizieren. Der Computer spricht gerne jede Sprache, die eindeutig ist. Der Grund, warum wir höhere Programmiersprachen haben, liegt darin, dass Menschen mit der Maschinensprache nicht umgehen können. Der Sinn von Programmiersprachen besteht darin, zu verhindern, dass unser armes, zerbrechliches menschliches Gehirn von einer Menge Details überwältigt wird.
Architekten wissen, dass manche Designprobleme banaler sind als andere. Eines der deutlichsten und abstraktesten Designprobleme ist der Entwurf von Brücken. Ihre Aufgabe besteht in diesem Fall darin, mit möglichst wenig Material die benötigte Distanz zurückzulegen. Am anderen Ende des Spektrums steht das Stuhldesign. Stuhldesigner sollten ihre Zeit damit verbringen, über menschliche Hinterteile nachzudenken.
Bei der Softwareentwicklung gibt es einen ähnlichen Unterschied. Das Entwerfen von Algorithmen zum Routing von Daten durch ein Netzwerk ist ein schönes, abstraktes Problem, wie das Entwerfen von Brücken. Wobei das Entwerfen von Programmiersprachen wie das Entwerfen von Stühlen ist: Man muss sich mit menschlichen Schwächen auseinandersetzen.
Den meisten von uns fällt es schwer, dies zu akzeptieren. Für die meisten von uns klingt die Entwicklung eleganter mathematischer Systeme viel attraktiver, als den menschlichen Schwächen nachzugeben. Die Rolle mathematischer Eleganz besteht darin, dass ein gewisses Maß an Eleganz das Verständnis von Programmen erleichtert. Aber die Eleganz hört hier nicht auf.
Und wenn ich sage, dass Sprachen so konzipiert sein sollten, dass sie menschliche Schwächen berücksichtigen, meine ich damit nicht, dass Sprachen für schlechte Programmierer konzipiert sein sollten. Die Realität ist, dass Sie Software für die besten Programmierer entwickeln sollten, 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 dargestellt werden.
2. Gestalte für dich und deine Freunde
Wenn man sich die Geschichte der Programmiersprachen ansieht, stellt man fest, dass die meisten der besten Sprachen für die Verwendung durch ihre Autoren entwickelt wurden, während die meisten der schlechtesten Sprachen für andere Leute entwickelt wurden.
Wenn Sprachen für andere Menschen entwickelt werden, geht es immer um eine bestimmte Gruppe von Menschen: Menschen, die nicht so intelligent sind wie die Schöpfer der Sprache. So erhalten Sie eine Sprache, die von oben herab zu Ihnen spricht. Cobol ist das prominenteste Beispiel, aber die meisten Sprachen sind von diesem Geist durchdrungen.
Es hat nichts damit zu tun, wie hochrangig die Sprache ist. C ist ziemlich niedrigstufig, wurde aber für die Verwendung durch seine Autoren entwickelt, weshalb Hacker es lieben.
Das Argument für die Entwicklung von Sprachen für schlechte Programmierer besteht darin, dass es mehr schlechte als gute Programmierer gibt. Vielleicht ist das so. Aber diese kleine Zahl guter Programmierer schreibt überproportional mehr Software.
Mich interessiert die Frage: Wie können wir eine Sprache entwickeln, 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 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 Babysitter: Sie versuchen, Sie vor Dingen zu warnen, von denen sie glauben, dass sie schlecht für Sie sind. Ich bin der gegenteiligen 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 sprachen. In den anderen Sprachen, die ich bis dahin gelernt hatte, gab es eine Sprache und mein Programm in dieser Sprache, und sie existierten völlig getrennt voneinander. Aber in Lisp waren die Funktionen und Makros, die ich schrieb, dieselben, in denen die Sprache selbst geschrieben war. 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 Witzes
Kürze wird unterschätzt und sogar verachtet. Doch wenn man in die Herzen der Hacker blickt, erkennt man, dass sie eine Vorliebe für Kürze haben. Wie oft haben Sie schon gehört, wie Hacker voller Begeisterung darüber schwärmen, wie sie beispielsweise in APL mit nur ein paar Zeilen Code erstaunliche Dinge erreichen können? Ich glaube, dass wirklich kluge Leute dem tatsächlich gerne Beachtung schenken.
Ich denke, dass fast alles, was Programme kürzer macht, eine gute Sache ist. Es sollte viele Bibliotheksfunktionen geben, alles, was implizit sein kann, sollte es auch sein. die Syntax sollte prägnanter sein; Auch die Namen der Entitäten sollten kurz sein.
Und nicht nur Programme sollten kurz sein. Handbücher sollten außerdem kurz sein. Ein Großteil der Handbücher enthält Erklärungen, Vorbehalte, Warnungen und Sonderfälle. Wenn Sie das Handbuch kürzen müssen, besteht die beste Möglichkeit darin, die Sprache zu korrigieren, die so viele Erklärungen erfordert.
5. Erkennen, was Hacking ist
Viele Menschen wünschen sich, dass Hacken Mathematik oder zumindest so etwas wie Wissenschaft wäre. Ich denke, Hacken hat eher etwas mit Architektur zu tun. Architektur hat insofern mit Physik zu tun, als dass der Architekt ein Gebäude entwerfen muss, das nicht einstürzt. Das wahre Ziel des Architekten besteht jedoch darin, ein großartiges Gebäude zu errichten und nicht darin, Entdeckungen auf dem Gebiet der Statik zu machen.
Hacker lieben es, großartige Programme zu erstellen. Und ich denke, dass wir zumindest im Geiste nicht vergessen sollten, dass das Schreiben großartiger Programme großartig ist, auch wenn sich diese Arbeit nicht so leicht in die übliche intellektuelle Sprache akademischer Arbeiten übertragen lässt. Aus intellektueller Sicht ist es genauso wichtig, eine Sprache zu entwickeln, die Programmierer lieben, wie eine schreckliche Sprache zu entwickeln, die eine Idee verkörpert, über die man einen Artikel veröffentlichen kann.
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 länger dauert, in einer Bibliothek eine Funktion zu finden, die Ihren Anforderungen entspricht, als diese Funktion selbst zu schreiben, wird durch den Code lediglich Ihr Handbuch dicker. (Die Symbolik-Handbücher waren ein Beispiel dafür.) Wir müssen also das Problem der Bibliotheksorganisation lösen. Idealerweise sollten sie so gestaltet sein, dass der Programmierer erraten kann, welche Bibliotheksfunktion funktionieren wird.
2. Haben die Leute wirklich Angst vor der Präfixsyntax?
Dies ist in dem Sinne ein offenes Problem, dass ich seit mehreren Jahren darüber nachdenke und die Antwort noch immer nicht kenne. Die Präfixsyntax erscheint mir völlig natürlich, außer vielleicht bei 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, falls das zutrifft, etwas dagegen unternommen werden sollte, ist eine andere Frage.
3. Welche Serversoftware benötigen Sie?
Ich denke, dass die meisten Anwendungen, die in den nächsten zwanzig Jahren geschrieben werden, Webanwendungen sein werden, in dem Sinne, dass die Programme auf einem Server gespeichert werden und über einen Webbrowser mit Ihnen kommunizieren. Und um solche Anwendungen zu schreiben, brauchen wir neue Dinge.
Eine dieser Dinge ist die Unterstützung einer neuen Art der Veröffentlichung von Serveranwendungen. Anstatt ein oder zwei Hauptversionen pro Jahr wie bei Desktop-Software wird Serversoftware in einer Reihe kleiner Änderungen veröffentlicht. Möglicherweise haben Sie fünf oder zehn Veröffentlichungen pro Tag. Und jeder hat immer die neueste Version.
Wissen Sie, wie man Programme so gestaltet, dass sie wartbar sind? Serversoftware muss so konzipiert sein, dass sie veränderbar ist. Sie sollten in der Lage sein, es problemlos zu ändern oder zumindest wissen, was eine kleine Änderung bedeutet und was wichtig ist.
Ein weiterer Aspekt, der bei Serversoftware plötzlich nützlich sein kann, ist die Kontinuität der Bereitstellung. In einer Webanwendung könnten Sie etwas wie Folgendes verwenden: um die Wirkung von Routinen in der zustandslosen Welt der Websitzungen zu erzielen. Eine kontinuierliche Versorgung kann sich lohnen, wenn die Option nicht zu teuer ist.
4. Welche neuen Abstraktionen müssen noch entdeckt werden?
Ich bin nicht sicher, wie vernünftig diese Hoffnung ist, aber persönlich würde ich wirklich gerne eine neue Abstraktion entdecken – etwas, das einen ebenso großen Unterschied machen könnte wie erstklassige Funktionen oder Rekursion oder zumindest Standardparameter. Vielleicht ist das ein unmöglicher Traum. Solche Dinge bleiben oft ungeöffnet. Aber ich gebe die Hoffnung nicht auf.
Wenig bekannte Geheimnisse
1. Sie können jede gewünschte Sprache verwenden.
Früher bedeutete das Erstellen von Anwendungen das Erstellen von Desktop-Software. Und bei Desktop-Software besteht eine große Tendenz, Anwendungen in derselben Sprache wie das Betriebssystem zu schreiben. Vor zehn Jahren bedeutete das Schreiben von Software im Allgemeinen, dass man Software in C schrieb. Mit der Zeit entwickelte sich die Tradition weiter: Anwendungen müssen nicht in ausgefallenen Sprachen geschrieben werden. Und diese Tradition hat sich über einen so langen Zeitraum entwickelt, dass auch Laien wie Manager und Risikokapitalgeber sie erlernt haben.
Serverseitige Software revolutioniert dieses Modell. Mit serverseitiger Software kann man jede beliebige Programmiersprache verwenden. Das hat bisher kaum jemand verstanden (vor allem nicht Manager und Risikokapitalgeber). Einige Programmierer hingegen schon, weshalb man von Indie-Sprachen wie Perl und Python hört. Man hört nicht von Perl und Python, weil sie zur Entwicklung von Anwendungen verwendet werden. Windows.
Für uns als Menschen, die sich für die Entwicklung von Programmiersprachen interessieren, bedeutet dies, dass es ein potenzielles Publikum für unsere Arbeit gibt.
2. Geschwindigkeit kommt von Profilern
Sprachdesigner oder zumindest Sprachimplementierer schreiben gerne Compiler, die schnellen Code generieren. Aber ich glaube nicht, dass das die Sprachen für Benutzer schnell macht. Knuth hat schon vor langer Zeit erkannt, 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. Die Antwort ist Profiler.
Die Sprachdesigner 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. Daher wäre es vielleicht besser, wenn Sprachimplementierer die Hälfte ihrer Zeit, die sie für die Compileroptimierung aufwenden, in das Schreiben eines guten Profilers investieren würden.
3. Sie brauchen eine App, die Ihre Sprache fördert
Dies ist vielleicht nicht das letzte Wort, aber es scheint, dass sich die besten Sprachen zusammen mit den Anwendungen entwickelt haben, die sie verwendet haben. C wurde von Leuten geschrieben, die Systemprogrammierung wollten. Lisp wurde teilweise für die symbolische Differenzierung entwickelt und McCarthy war so erpicht darauf, loszulegen, dass er bereits im ersten Lisp-Artikel von 1960 mit dem Schreiben von Differenzierungsprogrammen begann.
Dies ist besonders gut, wenn Ihre App ein neues Problem löst. Dadurch erhält Ihre Sprache neue Funktionen, die Programmierer wünschen. Persönlich bin ich daran interessiert, eine Sprache zu schreiben, die sich gut für Serveranwendungen eignet.
[Während der Diskussion brachte auch Guy Steele diesen Punkt zur Sprache 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 für das Schreiben von Compilern konzipiert.]
4. Die Sprache sollte zum Schreiben einmaliger Programme geeignet sein.
Sie wissen, was ein einmaliges Programm bedeutet: Es wird verwendet, wenn Sie schnell eine begrenzte Aufgabe lösen müssen. Ich denke, wenn Sie sich umsehen, werden Sie viele ernsthafte Programme finden, die als einmalige Aktionen begannen. Es würde mich nicht überraschen, wenn die meisten Programme zunächst einmalig wären. Wenn Sie also eine Sprache erstellen möchten, die zum Schreiben von Software im Allgemeinen geeignet ist, sollte sie auch zum Schreiben einmaliger Programme geeignet sein, da dies die Anfangsphase vieler Programme darstellt.
5. Syntax hängt mit Semantik zusammen
Traditionell werden Syntax und Semantik als zwei völlig unterschiedliche Dinge betrachtet. Das mag schockierend klingen, ist es aber nicht. Ich denke, was Sie mit Ihrem Programm erreichen möchten, hängt davon ab, wie Sie es ausdrücken.
Ich habe kürzlich mit Robert Morris gesprochen und er stellte fest, dass die Operatorüberladung ein großes Plus für Sprachen mit Infix-Syntax ist. In Sprachen mit Präfixsyntax ist jede von Ihnen definierte Funktion tatsächlich ein Operator. Wenn Sie einen neuen Zahlentyp hinzufügen möchten, den Sie sich ausgedacht haben, können Sie einfach eine neue Funktion zum Hinzufügen definieren. 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 im Laufe der Zeit wiederkehren
1. Neue Programmiersprachen
Rückblickend auf die 1970er Jahre war es in Mode, neue Programmiersprachen zu entwickeln. Dies ist derzeit nicht der Fall. Ich bin jedoch davon überzeugt, dass Serversoftware die Entwicklung neuer Sprachen wieder in Mode bringen wird. Mit Serversoftware können Sie jede beliebige Sprache verwenden. Wenn also jemand eine Sprache entwickelt, die besser als die anderen zu sein scheint, wird es Leute geben, die sich für deren Verwendung entscheiden.
2. Zeitteilung
Diese Idee stammt von Richard Kelsey, dessen Zeit nun wieder gekommen ist, und ich unterstütze sie voll und ganz. Ich (und Microsoft) gehe davon aus, dass ein Großteil der Computerarbeit vom Desktop auf Remote-Server verlagert wird. Mit anderen Worten: Time-Sharing ist zurück. Ich denke, dies muss auf Sprachebene unterstützt werden. Richard und Jonathan Reeves haben beispielsweise viel Arbeit investiert, um die Prozessplanung in Scheme 48 einzuführen.
3. Effizienz
In letzter Zeit schien es, als wären Computer schnell genug. Wir hören immer öfter von Bytecode, was für mich zumindest bedeutet, dass wir über ausreichend Rechenleistung verfügen. Ich glaube aber, dass dies bei Serversoftware nicht der Fall ist. Irgendjemand wird dafür bezahlen müssen. ServerDie Anzahl der Benutzer, die der Server pro Maschine unterstützen kann, wird durch den Faktor ihrer Kapitalkosten dividiert.
Ich denke, dass die Effizienz eine Rolle spielen wird, zumindest bei Rechenengpässen. Dies ist insbesondere für E/A-Vorgänge wichtig, da Serveranwendungen viele solcher Vorgänge ausführen.
Am Ende könnte sich herausstellen, dass Bytecode nicht die Antwort ist. Sun und Microsoft liegen derzeit im Bytecode-Bereich offenbar im Kopf-an-Kopf-Rennen. Aber sie tun es, weil Bytecode ein praktischer Ort ist, um sich in einen Prozess einzubetten, und nicht, weil Bytecode selbst eine gute Idee ist. Es könnte sein, dass dieser ganze Kampf unbemerkt bleibt. Es wäre lustig.
Fallen und Fallstricke
1. Kunden
Dies ist nur eine Vermutung, aber der Punkt ist, dass nur die Anwendungen davon profitieren, die vollständig serverbasiert sind. Das Entwerfen einer Software, die auf der Annahme basiert, dass jeder Ihr Kunde sein wird, ist wie das Entwerfen einer Gesellschaft, die auf der Annahme basiert, dass jeder ehrlich sein wird. Es wäre sicherlich praktisch, aber Sie müssten akzeptieren, dass es nie passieren würde.
Ich denke, dass die Zahl internetfähiger Geräte rapide zunehmen wird und man davon ausgehen kann, dass sie grundlegende HTML- und Formularfunktionen 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 Ihrer Uhr? Ich weiß nicht. Und ich muss es nicht herausfinden, wenn ich darauf wette, dass alles auf dem Server ist. 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 eine große Sache ist. Ich denke, dies ist ein geeignetes Paradigma für bestimmte Anwendungen, die bestimmte Datenstrukturen erfordern, wie etwa Fenstersysteme, Simulationen, CAD-Systeme. Ich sehe aber nicht, warum es für alle Programme geeignet sein sollte.
Ich glaube, die Leute in großen Unternehmen mögen OOP teilweise, weil es viele Dinge wie Arbeit aussehen lässt. Was natürlicherweise beispielsweise als Liste von Ganzzahlen dargestellt werden könnte, kann jetzt als Klasse mit allen möglichen Gerüsten, mit Lärm und Aufregung dargestellt werden.
Ein weiteres attraktives Merkmal der OOP besteht darin, dass Ihnen die Methoden einen Teil der Wirkung erstklassiger Funktionen bieten. Für Lisp-Programmierer ist das jedoch nichts Neues. Wenn Sie über echte erstklassige Funktionen verfügen, können Sie diese einfach so verwenden, wie es für die jeweilige Aufgabe geeignet ist, anstatt alles in eine Vorlage aus Klassen und Methoden zu packen.
Ich denke, für das Sprachdesign bedeutet dies, dass man OOP nicht zu tief darin einbetten sollte. Vielleicht besteht die Antwort darin, allgemeinere, grundlegendere Dinge anzubieten und die Leute beliebige Objektsysteme als Bibliotheken entwerfen zu lassen.
3. Entwurf durch ein Komitee
Wenn Ihre Sprache von einem Komitee entworfen wird, sitzen Sie in der Falle, und das nicht nur aus den Gründen, die jeder kennt. Es ist allgemein bekannt, dass Ausschüsse dazu neigen, holprige und inkonsistente Sprachdesigns zu produzieren. Ich glaube jedoch, dass die große Gefahr darin besteht, dass sie keine Risiken eingehen. Wenn eine Person die Verantwortung übernimmt, geht sie Risiken ein, die das Komitee niemals eingehen würde.
Ist es notwendig, Risiken einzugehen, um eine gute Sprache zu schaffen? Viele Leute vermuten vielleicht, dass man sich bei der Sprachgestaltung ziemlich genau an die konventionelle Weisheit halten sollte. Ich wette, das stimmt nicht. Bei allem anderen, was Menschen tun, ist die Belohnung proportional zum Risiko. Warum sollte es bei der Sprachgestaltung anders sein?
Source: habr.com
