Übersetzung: Tragödie der gemeinsamen lisp

Ursprünglicher Autor: Mark S. Miller
  • Übersetzung
Wir bieten Ihnen eine Übersetzung des Briefes von Mark Miller , einer der Teilnehmer auf JavaScript Standardization Committee. In diesem Brief spricht Mark darüber, wozu „schleichende Kunststücke“ beim Entwerfen von Programmiersprachen führen können. Und warum will er die Let-Block-Syntax nicht zu Javascript hinzufügen?

Ich werde die Initiative zum Hinzufügen einer solchen Syntax zu Javascript nicht unterstützen. Außerdem würde , wenn jemand genannt werden , dies zu tun, werde ich mein Bestes tun , um diese Initiative zu begraben. Und hier ist warum.

Die Entwickler lobten Algol, Smalltalk, Pascal und frühere Versionen von Scheme für ihre geringe Größe und schöne Syntax. JavaScript und C überzeugend für verschiedene Dinge kritisiert, und nur wenige konnten sie für Sprachen mit einem schönen Syntax verwechseln. Aber sie hatten eine kleine Spezifikationsgröße, und dies wurde von den Entwicklern immer geschätzt. Wenn kleine Beschreibung der Programmiersprache, welche Art von Sprache wahrgenommen wird oft als „kann ich die Syntax vollständig lernen und damit die Sprache perfekt lernen“, die dann zu: „Ich weiß ganz die Syntax geändert wurden. Ich mag die Tatsache, dass es in der Sprache nichts mehr gibt, was ich nicht kennen würde. “ Obwohl natürlich für JavaScript und C nur einige derjenigen, die dies glauben, diese Sprachen tatsächlich gründlich kennen. In ihren dunklen Ecken verbargen sich viele teuflisch verwickelte Details. Dennoch,

Die Ästhetik der kleinen Sprachspezifikation blieb bis ES5 erhalten. Ich war aktiv an der Entwicklung von ES5 und ES6 beteiligt und bin stolz auf meinen Beitrag zur Sprache. Ja, die ES6-Spezifikation ist viel größer als die von ES5, aber die Sprache selbst ist dennoch viel besser geworden. Wenn man bedenkt, wo wir angefangen haben, hätten wir keine solchen Fortschritte bei der Benutzerfreundlichkeit von ES6 erzielt, ohne die Spezifikationen erheblich zu erweitern. Und ich bereue die meisten Add-Ons, die ES5 zu ES6 gemacht haben, nicht. Wenn ich die Gelegenheit hätte, in die Vergangenheit zurückzukehren und alles noch einmal abzuspielen, würde ich höchstwahrscheinlich dasselbe tun.

Aber jedes der Add-Ons, die ES5 zu ES6 machten, musste eine sehr hohe Messlatte erfüllen. Psychologisch spielte dies für uns eine große Rolle, da wir mit ES5 angefangen haben, dessen Spezifikationsgröße wir immer noch schätzen. Wenn die Spezifikationsgröße klein ist, sieht jede hinzugefügte Verbesserung wie eine signifikante Zunahme des "Gewichts" der Spezifikation aus. Die Vorteile von Funktionen sind für diejenigen, die sie anbieten, klar ersichtlich. Aber für eine Sprache mit einer kleinen Spezifikation ist der Preis einer solchen Funktion auch für jeden klar ersichtlich - wie viel Komplexität sie der Sprache hinzufügt.

Wenn die Komplexität der Programmiersprache einen bestimmten Wert überschreitet - zum Beispiel, wie in LaTeX, Common Lisp, C ++, PL / 1 oder moderne Java ist die Erfahrung in der Verwendung dieser Sprache in eine schmerzhafte Wahl verwandelt „ein Feature-Set“ für den persönlichen Gebrauch des scheinbar endlosen Ozeans eines Merkmal der Sprache . Die meisten davon wollen wir nie studieren. Trotzdem können wir die Vorteile einer einzelnen neuen Funktion leicht einschätzen, auch wenn uns die Menge der Funktionen der Sprache endlos vorkommt. Die Komplexität, die diese Funktion der Sprache hinzufügt, ist jedoch nicht so einfach zu bewerten. Diejenigen, die über neue Funktionen für solche Sprachen sprechen, können die Komplexität dieser Funktionen nicht mehr „spüren“. Schließlich ist unendlich plus eins ohnehin unendlich. Der Tod von tausend Schnitten, der diese monströsen Zungen uneingeschränkt wachsen lässt.

Kolleginnen und Kollegen, ich frage Sie, wenn Sie eine neue Funktion für die Sprache bewerten - setzen Sie einen höheren Standard als "Es würde Spaß machen, wenn wir mehr schreiben könnten." Ich glaube, dass die ES6-Spezifikation immer noch in einem Zustand ist, in dem es möglich ist, unbegrenztes Wachstum zu vermeiden. Dies ist jedoch nur möglich, wenn wir uns auf den Wunsch beschränken, ein wenig mehr Funktionen auszufüllen und für alles, was wir der Sprache hinzufügen möchten, nur die höchsten Qualitätsstandards einzuhalten. Als Gemeinschaft werden wir ein leichtes Gefühl von Panik in Bezug auf ES6 Größenangaben nicht verhindern. Im Idealfall wird diese Panik eher zunehmen als abnehmen, wenn sich die Größe der Sprachspezifikation dem Punkt nähert, an dem keine Rückkehr mehr möglich ist.

Grüße,
Mark

Anmerkung des Übersetzers


Der Vorschlag, wonach Mark diese Notiz schrieb, finden sich hier . Es wurde vorgeschlagen, syntaktischen Zucker zuzugeben, der es stattdessen erlauben würde

{ // блок для защиты локальных переменных
  let a = 2, b, c; // локальные переменные
  ...
}


Schreib etwas wie

let (a = 2, b, c) {
}


Der Übersetzer teilt die Meinung von Mark. Außerdem glaube ich, dass es Zeit ist, diesen Teil in eine Funktion, eine Methode, ein Mixin oder etwas anderes umzugestalten, wenn der Code einen Teil davon in einem solchen „let-Block“ isolieren muss. Weil die Komplexität nicht schläft und Millers Brieftasche nur darauf wartet, etwas abzuschneiden, das für den klaffenden Programmierer benötigt wird.

Jetzt auch beliebt: