Gibt es einen Mechanismus, um die Programmiersprache für Änderungen stabiler (kompatibler) zu machen?

Es gibt eine große Anzahl von Programmiersprachen. Einige von ihnen werden erwachsen und sehr beliebt. Die Leute benutzen solche Sprachen immer häufiger. Der Gründer einer solchen Sprache (oder der Gründungsorganisation / -gemeinschaft) versucht möglicherweise, Änderungen vorzunehmen, um die Sprache zu verbessern. Aber manchmal ist es aufgrund der Abwärtskompatibilität schwierig, einige Änderungen vorzunehmen. Solche hässlichen Dinge existieren in der Sprache bereits seit Jahren und werden von vielen Benutzern verwendet.

Gibt es in der Phase des Sprachentwurfs irgendwelche architektonischen Prinzipien oder Schritte, die dazu beitragen können, ihn stabiler zu machen, damit die Sprachentwickler nicht so ängstlich sind, die Abwärtskompatibilität zu brechen?

Sprachstabilität ist keine technische Entscheidung. Es ist ein Vertrag zwischen dem Sprachautor und den Nutzern.

Der Autor bewirbt eine bestimmte Version als mehr oder weniger stabil. Je weniger stabil eine Sprache ist, desto mehr Änderungen kann der Autor vornehmen. Jeder Benutzer, der an der Sprache interessiert ist, kann entscheiden, ob er Zeit in sie investieren möchte, um neue Funktionen zu erlernen oder Anwendungen zu entwickeln, die durch das Update des nächsten Monats möglicherweise beschädigt werden.

Die Verwendung einer instabilen Sprache kann interessant sein, weil Sie an einem neuen Konzept interessiert sind oder wenn Sie Ihr Feedback geben möchten. Wenn Sie ein Unternehmen sind, möchten Sie vielleicht lieber warten, bis eine Technologie stabiler ist, bevor Sie Ihre Zeit in sie investieren. Sie interessieren sich mehr für Dinge wie Markteinführungszeit und Benutzererfahrung.

Dies ist also ein Kommunikations- und Vertrauensproblem. Schauen Sie sich die Entwicklung der Rostsprache an. Sie sind sich völlig klar darüber, was sie verändern und was sie behalten. Wenn sie eine Entscheidung über ein bestimmtes Feature verzögern möchten, verwenden sie ein sogenanntes Feature-Gate. Auf der anderen Seite war das Angular-Team wegen der 2.0-Ankündigung sehr verärgert, da die Änderungen größer waren als erwartet.

Selbst Bibliotheksautoren müssen über die Stabilität ihrer Apis berichten. So gut wie jede Technologie, die von anderen verwendet wird, muss ein Gleichgewicht zwischen Stabilität und Perfektion finden. Ein Autohersteller kann die Position der Pedale nicht ändern, und ein Laptop-Designer erfindet aus demselben Grund kein neues Tastaturlayout: Sie helfen Ihren Benutzern nicht, wenn Sie keine Entscheidung darüber treffen können, wie sie Ihr Produkt verwenden.

• Beachten Sie, dass sich Sprachen im Laufe ihres Lebens ändern, unabhängig davon, wie gut sie von vornherein gestaltet sind. Versuchen Sie zunächst, nützlich und erweiterbar zu sein, anstatt sofort zu versuchen, die beeindruckendste Sprache der Welt herauszubringen. Eine mittelmäßige Sprache, die ich tatsächlich verwenden kann, ist mehr wert als jede wunderbare Programmiersprache, die es nur in der Theorie gibt.

• Betrachten Sie Möglichkeiten, um die Syntax erweiterbar zu machen, z. B. Makros. Makros sind nicht automatisch eine gute Sache und können zu leistungsfähig sein. Einige Sprachen haben von Anfang an eine sehr flexible Syntax, die den Bedarf an Makros reduziert. Einige zu berücksichtigende Szenarien:

  • Kann ich einen neuen Operator wie vorstellen, |>ohne die Sprache zu verlassen? Kann ich Vorrang und Assoziativität für diesen Operator festlegen?
  • Wie viel Zeremonie muss ich für eine Inline-Funktion / Lambda / Closure durchlaufen?
  • Kann ich die vorhandene Sprachsyntax verwenden, um eine foreach-Schleifensyntax zu implementieren? Ruby und Scala können dies beispielsweise durch ihre flexible Syntax für Methodenaufrufe mit Lambdas tun.

• Betrachten Sie Einrichtungen, um die Semantik erweiterbar zu halten. Gemeinsame Bedürfnisse sind:

  • Überladen von Operatoren, wobei benutzerdefinierte Typen vorhandenen Operatoren eine eigene Bedeutung zuweisen können. Dies macht eine Sprache in mathematisch anspruchsvollen Anwendungen viel angenehmer.
  • Buchstäbliche Überlastung. Kann ich String-Literale von meinem eigenen String-Typ erstellen? Kann ich alle numerischen Literale im aktuellen Bereich zu Bignums machen?
  • Metaobjekt-Protokolle. Wenn die Sprache keine Merkmale aufweist, kann ich sie im aktuellen Objektsystem implementieren? Kann ich eine andere Reihenfolge für die Methodenauflösung implementieren? Kann ich die Art und Weise austauschen, wie Objekte gespeichert werden oder wie Methoden versendet werden?
• Regressionstests haben. Viel Test. Nicht nur von den Sprachdesignern, sondern auch von den Benutzern geschrieben. Wenn Sie ein Feature hinzufügen, das diese Tests unterbricht, müssen Sie die Vorteile dieses Features sorgfältig gegen die Vorteile der Abwärtskompatibilität abwägen.
• Versionieren Sie Ihre Sprache. Nicht nur in Ihrer Dokumentation, sondern auch im Quellcode. Sobald Sie dies getan haben, ist der einzige Teil Ihrer Sprache, der sich nicht ändern kann, die Pragma-Syntax dieser Version. Beispiele: Mit Racket können Sie einen Dialekt festlegen. Perl ermöglicht es Ihnen use v5.20, alle abwärtskompatiblen Funktionen von Perl v5.20 zu aktivieren. Sie können auch einzelne Features wie explizit laden use feature 'state'. Ähnlich: Pythons from __future__ import division.
• Erwägen Sie, Ihre Sprache so zu gestalten, dass nur wenige reservierte Wörter angezeigt werden. Nur weil classeine Klasse eingeführt wird, heißt das noch lange nicht, dass ich keine lokale Variable mit dem Namen haben könnte class. In der Praxis führt dies zu Schlüsselwörtern, die Variablendeklarationen oder Methodendeklarationen einführen, entgegen der C-ähnlichen Tradition, Typnamen zum Einführen von Deklarationen zu verwenden. Eine andere Alternative ist die Verwendung von Sigils für Ihre $variables, wie in Perl und PHP.

Teile dieser Antwort sind beeinflusst von Guy Steeles Rede „Growing a Language“ (1998) ( pdf ) ( youtube ).

Ich denke, ein ziemlich wichtiger Schritt ist es, einen Paketmanager zu befördern, der auch die Version der Sprache selbst verwalten kann.

Zum Beispiel verwende ich SBT für Scala oder Leiningen für Clojure. In beiden Fällen kann ich pro Projekt angeben, welche Version der Sprache ich verwenden möchte . So ist es ganz einfach, grüne Projekte in der neuesten Version der Sprache zu starten und gleichzeitig die vorhandenen Projekte in einem angenehmeren Tempo zu aktualisieren, wenn überhaupt.

Abhängig von der Sprache müssen Sie möglicherweise trotzdem warten, bis die entsprechenden Bibliotheken auf die von Ihnen benötigte Version portiert wurden (dies ist beispielsweise in Scala der Fall), aber es macht die Sache trotzdem einfacher.