Die Tragödie von Common Lisp: Warum populäre Sprachen immer komplexer werden

Angepasst an die Diskussion im Jahr 2015 . Hier ist Common Lisp nur eines von vielen guten Beispielen.


Die Zukunft von JavaScript?

Ich arbeite seit 2007 im JavaScript Standards Committee (TC39). Wir schätzen die Einfachheit der Sprache, haben aber im Laufe der Zeit die Wachsamkeit verloren. Die Komplexität begann unkontrolliert zu wachsen. Wir sollten herausfinden, warum dies natürlich geschieht, was der Preis ist und was wir dagegen tun müssen. Dieser Artikel richtet sich nicht nur an Kollegen von TC39, sondern auch an alle, die den Entwicklungspfad von JavaScript oder einem Standard beeinflussen möchten, der einem ähnlichen Druck ausgesetzt war. Lerne aus unseren Fehlern!

Algol, Smalltalk, Pascal und Early Scheme wurden als kleine und schöne Sprachen geliebt. Frühes C und JavaScript wurden zu Recht für viel kritisiert und selten als schön bezeichnet. Aber sie waren auch klein und es wurde sehr geschätzt. Wenn die Sprache klein ist, wird unsere Einschätzung oft durch das Gefühl bestimmt: „Ich kann alles lernen und es beherrschen“ und dann: „Ich weiß alles. Mir gefällt, dass es keine unbekannten Details mehr gibt . “ Im Fall von C und JavaScript ist es jedoch unwahrscheinlich, dass jemand die Sprache vollständig beherrscht, da die Details tatsächlich teuflisch komplex waren. Dennoch hat das Gefühl einer "kleinen Sprache" in vielerlei Hinsicht die Zufriedenheit des täglichen Gebrauchs bestimmt.

Die Ästhetik des JavaScript-Minimalismus wurde im EcmaScript-5-Standard beibehalten. Ich habe mich aktiv an der Entwicklung von EcmaScript-5 und EcmaScript-2015 beteiligt und bin in beiden Fällen stolz auf meinen Beitrag. EcmaScript-2015 hat erheblich an Größe zugenommen, aber Verbesserungen mit sich gebracht. Angesichts unserer Anfänge war es unmöglich, JavaScript ohne eine solche Vergrößerung zu verbessern. Ich bereue die meisten Add-Ons nicht, die dazu geführt haben, dass EcmaScript-5 auf EcmaScript-2015 aufgeblasen wurde. Wenn Sie zurückgehen, würde ich wahrscheinlich in vielen Fällen ähnliche Ergänzungen vorschlagen.

Jede der Ergänzungen musste eine sehr hohe Messlatte überwinden. Psychologisch machte dies Sinn, weil wir uns mit dem EcmaScript-5-Minimalismus befasst haben. Wenn die Sprache klein ist, wird jede zusätzliche Funktion intuitiv als signifikante prozentuale Zunahme der Größe der Sprache empfunden. Die spezifischen Vorteile eines Features sind für seine Befürworter immer sichtbar. Für eine kleine Sprache ist der Beitrag der neuen Funktion zur Steigerung der Gesamtzahl auch weiterhin für alle sichtbar.

Sobald eine Sprache eine bestimmte Komplexität überschreitet - beispielsweise LaTeX, Common Lisp, C ++, PL / 1, modernes Java -, wird das Programmieren eher zum Ausschneiden einer Teilmenge von Funktionen für den persönlichen Gebrauch aus einem unendlichen Meer von Funktionen, von denen wir die meisten niemals beherrschen und in Einklang bringen werden mit diesem. Sobald die Sprache als „unendlich“ wahrgenommen wird, werden die spezifischen Vorteile der neuen Funktion immer noch verstanden. Die mit zusätzlicher Komplexität verbundenen Gesamtkosten sind jedoch nicht mehr offensichtlich. Sie werden von denjenigen, die über eine neue Funktion diskutieren, nicht mehr gespürt.

$$ .

Sogar $$ .

Dies ist der Tod von tausend Schnitten, wodurch diese Monster ohne Einschränkungen wachsen.

Deshalb bitte ich alle, die Einfluss auf die Sprache haben, bei der Prüfung einer neuen Funktion einen höheren Balken als "Es ist gut, eine solche Gelegenheit zu haben, nicht wahr?" Zu berücksichtigen. Ich glaube, dass sich EcmaScript-2015 auf dem Grenzgebiet befindet, wo ein grassierendes Wachstum immer noch verhindert werden kann, aber nur, wenn wir uns gegenseitig mit hohen Standards für eine vorgeschlagene neue Funktion zurückhalten. Als Community brauchen wir ein allgemeineres Gefühl der Panik über die Größe, die EcmaScript 2015 bereits erreicht hat. Idealerweise sollte mit dem Wachstum der Zunge die Panik zunehmen, nicht abnehmen, wenn sich die Größe dem Punkt ohne Wiederkehr nähert.

Einige Unterschiede

Halten Sie einen minimalen ungleichmäßigen Druck

Die Relevanz des Minimalismus nimmt ab, wenn wir von einer Basissprache zu Bibliotheken wechseln. Die Standardsprache als Ganzes kann wie folgt dargestellt werden:

• Grundlegende Syntax : Sonderformen, die durch lokale Erweiterung einer anderen Syntax nicht genau ausgedrückt werden können.
  
• Semantischer Zustand : Ein Zustand, der durch Berechnung manipuliert wird.
  
• Eingebaute Kernel : Ein Teil der integrierten Bibliothek, der Funktionen bereitstellt, die benutzerdefinierter Code allein nicht bereitstellen kann.
  
• Nicht-Kernel-Intrinsics: Integrierte Bibliotheken, die in JavaScript implementiert werden können, aber der semantische Status oder die im Kernel integrierten Module hängen von ihnen ab. Über einen Proxy können Sie beispielsweise ein Array im Benutzercode implementieren. Andere im Kernel integrierte Module sind jedoch bereits von Array abhängig, wodurch dieses bestimmte Array eine privilegierte Position gegenüber allen vorgeschlagenen Ersetzungen erhält.
  
• Syntaktischer Zucker : Syntax, die durch lokale Erweiterung der grundlegenden Syntax ausgedrückt werden kann.
  
• Globale Bibliotheken zur Vereinfachung : Kann mit nicht privilegiertem Benutzercode implementiert werden, wobei jedoch globale Standardbenennungspfade im ursprünglichen globalen Namespace berücksichtigt werden.
  
• Standardmodule für mehr Komfort : Von der Community entwickelte Module, die als Standard zugelassen sind.

Ich habe sie der Reihe nach aufgelistet, entsprechend meinem Gefühl, die Wachstumskosten zu erhöhen und dem dringenden Bedürfnis nach Minimalismus. All dies erfordert Disziplin. Nur beim letzten Punkt können wir unbegrenztes Wachstum zulassen, aber es ist ratsam, dass Kandidaten von der Community getestet und de facto akzeptiert werden. Im Idealfall wird das TC39-Komitee kein Engpass mehr sein, da die externen Prozesse de facto und de jure in der Lage sein werden, Standardmodule zur Vereinfachung unabhängig voneinander zu entwickeln.