Warum werden alte Programmiersprachen weiter überarbeitet?

Diese Frage lautet nicht: "Warum verwenden die Leute immer noch alte Programmiersprachen?" Ich verstehe das ganz gut. Die beiden Programmiersprachen, die ich am besten kenne, sind C und Scheme. Beide stammen aus den 70er Jahren.

Kürzlich las ich über die Änderungen in C99 und C11 gegenüber C89 (die in der Praxis immer noch die am häufigsten verwendete Version von C zu sein scheint und die Version, die ich von K & R gelernt habe). Wenn man sich umschaut, sieht es so aus, als würde jede stark genutzte Programmiersprache mindestens einmal pro Jahrzehnt oder so eine neue Spezifikation erhalten. Sogar Fortran wird immer wieder überarbeitet, obwohl die meisten Benutzer FORTRAN 77 verwenden.

Vergleichen Sie dies beispielsweise mit dem Ansatz des Schriftsatzsystems TeX. Im Jahr 1989, mit der Veröffentlichung von TeX 3.0, erklärte Donald Knuth, dass TeX über alle Funktionen verfügt und zukünftige Versionen nur noch Fehlerkorrekturen enthalten würden. Auch darüber hinaus hat er erklärt, dass nach seinem Tod "alle verbleibenden Bugs zu Features werden" und absolut keine weiteren Updates vorgenommen werden. Andere können TeX nach Belieben verteilen und haben dies bereits getan. Die resultierenden Systeme werden jedoch umbenannt, um anzuzeigen, dass sie sich von der offiziellen TeX unterscheiden. Dies liegt nicht daran, dass Knuth TeX für perfekt hält, sondern daran, dass er den Wert eines stabilen, vorhersehbaren Systems versteht, das in fünfzig Jahren dasselbe tun wird wie jetzt.

Warum folgen die meisten Programmiersprachendesigner nicht demselben Prinzip? Wenn eine Sprache relativ neu ist, ist es natürlich sinnvoll, dass sie eine Zeit des raschen Wandels durchläuft, bevor sie sich niederlässt. Und niemand kann gegen geringfügige Änderungen Einwände erheben, die nicht viel mehr bewirken, als bestehende Pseudostandards zu kodifizieren oder unbeabsichtigte Messwerte zu korrigieren. Aber wenn eine Sprache nach zehn oder zwanzig Jahren noch verbesserungswürdig zu sein scheint, warum nicht einfach die Sprache wechseln oder neu anfangen, anstatt zu versuchen, das zu ändern, was bereits verwendet wird? Wenn einige Leute wirklich objektorientiertes Programmieren in Fortran wollen, warum nicht "Objective Fortran" für diesen Zweck erstellen und Fortran selbst in Ruhe lassen?

Ich nehme an, man könnte sagen, dass C89 unabhängig von zukünftigen Revisionen bereits ein Standard ist und nichts die Leute davon abhält, ihn weiter zu verwenden. Das stimmt, aber Konnotationen haben Konsequenzen. GCC warnt im pedantischen Modus vor Syntax, die entweder veraltet ist oder eine etwas andere Bedeutung in C99 hat, was bedeutet, dass C89-Programmierer den neuen Standard nicht einfach vollständig ignorieren können. Es muss also einen Vorteil in C99 geben, der ausreicht, um jedem, der die Sprache verwendet, diesen Mehraufwand aufzuerlegen.

Dies ist eine echte Frage, keine Aufforderung zum Streiten. Natürlich habe ich eine Meinung dazu, aber im Moment versuche ich nur zu verstehen, warum dies nicht nur so ist, wie die Dinge bereits gemacht werden. Ich nehme an, die Frage ist:

Was sind die (realen oder wahrgenommenen) Vorteile der Aktualisierung eines Sprachstandards gegenüber der Schaffung einer neuen Sprache auf der Grundlage der alten?

Ich denke, die Motivation für Sprachdesigner, vorhandene Sprachen zu überarbeiten, besteht darin, Innovationen einzuführen und gleichzeitig sicherzustellen, dass ihre Ziel-Entwicklergemeinschaft zusammen bleibt und die neue Sprache übernimmt: Das Verschieben einer vorhandenen Community in eine neue Revision einer vorhandenen Sprache ist effektiver als das Erstellen einer neuen Community um eine neue Sprache. Dies zwingt natürlich einige Entwickler, den neuen Standard zu übernehmen, auch wenn sie mit dem alten in Ordnung waren: In einer Community müssen Sie manchmal bestimmte Entscheidungen einer Minderheit auferlegen, wenn Sie die Community zusammenhalten möchten.

Bedenken Sie auch, dass eine Allzwecksprache versucht, so viele Programmierer wie möglich zu bedienen, und häufig in neuen Bereichen eingesetzt wird, für die sie nicht entwickelt wurde. Anstatt auf Einfachheit und Stabilität des Designs zu setzen, kann die Community neue Ideen (auch aus anderen Sprachen) einbeziehen, wenn die Sprache neue Anwendungsbereiche erschließt. In einem solchen Szenario können Sie nicht erwarten, dass Sie es beim ersten Versuch richtig machen.

Dies bedeutet, dass sich die Sprachen im Laufe der Jahre grundlegend ändern können und die letzte Überarbeitung möglicherweise ganz anders aussieht als die erste. Der Name der Sprache wird nicht aus technischen Gründen beibehalten, sondern weil sich die Entwicklergemeinschaft bereit erklärt, einen alten Namen für eine neue Sprache zu verwenden. Der Name der Programmiersprache kennzeichnet also eher die Community ihrer Benutzer als die Sprache selbst.

Die Motivation, warum viele Entwickler dies für akzeptabel (oder sogar wünschenswert) halten, ist, dass ein schrittweiser Übergang zu einer etwas anderen Sprache einfacher und weniger verwirrend ist als ein Sprung in eine völlig neue Sprache, dessen Beherrschung mehr Zeit und Mühe in Anspruch nehmen würde. Bedenken Sie, dass es eine Reihe von Entwicklern gibt, die eine oder zwei Lieblingssprachen haben und nicht sehr daran interessiert sind, neue (radikal unterschiedliche) Sprachen zu lernen. Und selbst für diejenigen, die gerne neue Dinge lernen, ist das Erlernen einer neuen Programmiersprache immer eine schwierige und zeitraubende Aufgabe.

Es kann auch vorzuziehen sein, Teil einer großen Gemeinschaft und eines reichen Ökosystems zu sein, als Teil einer sehr kleinen Gemeinschaft, die eine weniger bekannte Sprache verwendet. Wenn sich die Community also entscheidet, weiterzumachen, entscheiden sich viele Mitglieder, zu folgen, um Isolation zu vermeiden.

Als Nebenbemerkung denke ich, dass das Argument, Evolution zuzulassen und dabei die Kompatibilität mit altem Code aufrechtzuerhalten, eher schwach ist: Java kann C-Code aufrufen, Scala kann leicht mit Java-Code integriert werden, C # kann mit C ++ integriert werden. Es gibt viele Beispiele, die zeigen, dass Sie problemlos mit Legacy-Code arbeiten können, der in einer anderen Sprache geschrieben wurde, ohne dass Quellcode-Kompatibilität erforderlich ist.

HINWEIS

Aus einigen Antworten und Kommentaren geht hervor, dass einige Leser die Frage als "Warum müssen sich Programmiersprachen weiterentwickeln?" Interpretiert haben.

Ich denke, das ist nicht der Hauptpunkt der Frage, da es offensichtlich ist, dass sich Programmiersprachen weiterentwickeln müssen und warum (neue Anforderungen, neue Ideen). Die Frage ist eher "Warum muss diese Evolution in einer Programmiersprache stattfinden, anstatt viele neue Sprachen hervorzubringen?"

Abwärtskompatibilität ist Ihre Antwort. Eine bestimmte Sprache, insbesondere eine weit verbreitete Sprache wie C, kann Code enthalten, der jahrzehntelang unverändert in Betrieb ist. Wenn eine Wartung erforderlich ist, ist es hilfreich, Compiler zu haben, die diese Art von Plattform weiterhin unterstützen, während sie auf modernen Systemen für die Entwicklungsarbeit ausgeführt werden. Standardisierungen und Sprachversionsaktualisierungen tragen dazu bei, die Programmierpraktiken auf dem neuesten Stand zu halten, und vermitteln den erfahrenen Programmierern, die möglicherweise nicht in der Lage sind, eine ganz "neue" Sprache zu lernen, ein Gefühl der Vertrautheit.

Denken Sie daran, dass viele der aktualisierten Sprachen weniger aktualisiert sind als "neue glänzende Teile aufgeschraubt haben". Die Bestien von früher lauern oft noch im Inneren.

Denken Sie daran, dass Knuth ein Akademiker ist und dass TeX nur als korrekt und nicht aktualisiert gilt.

Ich denke, die offensichtliche Antwort ist, dass beim Sprachdesign und der Systemarchitektur immer noch Fortschritte erzielt werden und dass sich genügend Menschen für die älteren Sprachen interessieren, um die neueren Techniken (mehrere Kerne, besseres Threading oder Speichermodelle) zu nutzen, die sie verwenden an oder in den Sprachstandard eingebrannt. Es ist auch hilfreich, "eine echte Möglichkeit" zu haben, Dinge zu tun (z. B. XML-Parsing, DB-Zugriff), auf die Sie zählen können, unabhängig davon, auf welchem ​​Compiler oder auf welcher Plattform Sie sich befinden, anstatt von einem Drittanbieter abhängig zu sein Bibliothek, die möglicherweise installiert ist oder nicht (und möglicherweise nicht die von Ihnen benötigte Version usw.).

Die grundlegenden Konzepte oder Ziele einer Allzwecksprache verlieren nicht an Relevanz. Kleinere Änderungen in der Arbeitsumgebung oder der Hardware erfordern jedoch, dass einer Sprache Aktualisierungen oder kleine Funktionen hinzugefügt werden.

Die Art und Weise, wie Algorithmen in einer Sprache ausgedrückt werden, ändert sich nicht, obwohl möglicherweise eine bessere Unterstützung für 64-Bit-Typen oder eine bessere Unterstützung für reguläre Ausdrücke oder eine robustere Unterstützung für neue Arten von Dateisystemen erforderlich ist.

Es gibt einige Fälle, in denen 'neue' Funktionen zu vorhandenen Sprachen hinzugefügt werden, aber in vielen Fällen handelt es sich bei diesen Änderungen um Vereinfachungen von Dingen, die die Leute bereits auf die harte Tour gemacht haben. (Siehe C ++ mit Funktionen höherer Ordnung anstelle von Funktionszeigern und Funktoren.)

Dies ist ein bisschen wie eine Betrachtung der gesprochenen Sprache.

In der Vergangenheit gab es Wörter, die nicht so oft verwendet wurden wie jetzt (oder für eine andere Bedeutung verwendet wurden).

z.B. nett: in (sehr altem) Englisch hat es die fast umgekehrte Bedeutung zu der, die wir heute verwenden, besonders wenn es verwendet wird, um einen Charakter zu beschreiben.

Schlecht: Vor nicht allzu langer Zeit hatte Schlecht nur eine einzige Bedeutung, jetzt kann es etwas bedeuten, das "super erstaunlich" ist (es wird auf eine blöde Art und Weise verwendet (ich habe wahrscheinlich die blöde Rechtschreibung vermisst)!

Eine weitere Neuerung ist das Mobiltelefon 'Text speak' für geschriebene Sprachen.

Ich persönlich verstehe nicht, warum sich eine Programmiersprache nicht auf ähnliche Weise entwickeln wird, Wörter und Funktionen bestimmte Bedeutungen / Handlungen haben und es erforderlich ist, sich zu ändern, um neue Ideen, neue Methoden einzubeziehen.

Ich kenne Leute, die viele verschiedene Sprachen sprechen, und sie schlagen oft vor, dass es nach dem 3. oder 4. einfacher wird, eine neue Sprache zu lernen.

Ich weiß nicht, ob es Programmierer gibt, die eine ähnliche Erfahrung haben, ich wäre nicht überrascht, wenn es solche gibt.

Ich weiß, dass mir das Programmieren in JAVA sehr gut gefällt (so gut wie das Sprechen in Englisch). Dies bedeutet nicht, dass ich nicht in amerikanischem Englisch oder australischem Englisch kommunizieren kann, obwohl es einige „Fallstricke“ gibt, auf die ich achten muss . Ähnlich wie bei der Umstellung von Java auf PHP auf Perl sind die Konstrukte ähnlich, aber es gibt kleine Stolpersteine, die mich ausfindig machen und mich dazu bringen, meinen Kopf gegen die Wand zu schlagen.

Dies unterscheidet sich vom Übergang von Englisch nach Französisch oder von Java nach SAS. Diese sind so unterschiedlich, dass es eine Weile dauert, bis man sie beherrscht.

Wie auch immer, das ist meine Meinung dazu.