it-swarm.com.de

Warum werden alte Programmiersprachen weiter überarbeitet?

Diese Frage ist nicht "Warum verwenden die Leute immer noch alte Programmiersprachen?" Ich verstehe das ganz gut. Tatsächlich sind die beiden Programmiersprachen, die ich am besten kenne, C und Scheme, die beide aus den 70er Jahren stammen.

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

Vergleichen Sie dies beispielsweise mit dem Ansatz des Satzsystems TeX. 1989, mit der Veröffentlichung von TeX 3.0, erklärte Donald Knuth, dass TeX vollständig ist und zukünftige Versionen nur Fehlerbehebungen enthalten würden. Auch darüber hinaus hat er erklärt, dass nach seinem Tod "alle verbleibenden Fehler zu Features werden" und absolut keine weiteren Aktualisierungen vorgenommen werden. Andere können TeX frei teilen und haben dies getan, aber die resultierenden Systeme werden 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 Designer von Programmiersprachen nicht demselben Prinzip? Wenn eine Sprache relativ neu ist, ist es natürlich sinnvoll, dass sie eine Phase schnellen Wandels durchläuft, bevor sie sich niederlässt. Und niemand kann wirklich gegen geringfügige Änderungen Einwände erheben, die nicht viel mehr bewirken, als vorhandene Pseudostandards zu kodifizieren oder unbeabsichtigte Messwerte zu korrigieren. Aber wenn eine Sprache nach zehn oder zwanzig Jahren immer noch verbessert werden muss, warum nicht einfach abspalten oder neu beginnen, anstatt zu versuchen, das zu ändern, was bereits verwendet wird? Wenn einige Leute wirklich objektorientierte Programmierung in Fortran durchführen möchten, 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 weiterhin zu verwenden. Das ist irgendwie wahr, aber Konnotationen haben Konsequenzen. GCC warnt im pedantischen Modus vor Syntax, die entweder veraltet ist oder in C99 eine subtil andere Bedeutung hat, was bedeutet, dass C89-Programmierer den neuen Standard nicht einfach völlig ignorieren können. C99 muss also einen Vorteil bieten, der ausreicht, um diesen Overhead jedem aufzuerlegen, der die Sprache verwendet.

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 es bereits gemacht wird. Ich nehme an, die Frage ist:

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

46
user71599

Ich denke, die Motivation für Sprachdesigner, vorhandene Sprachen zu überarbeiten, besteht darin, Innovationen einzuführen und gleichzeitig sicherzustellen, dass ihre Zielentwicklergemeinschaft zusammen bleibt und die neue Sprache übernimmt: Die Verlagerung einer vorhandenen Community auf eine neue Überarbeitung einer vorhandenen Sprache ist effektiver als die Schaffung einer neuen Community um eine neue Sprache. Dies zwingt einige Entwickler natürlich dazu, den neuen Standard zu übernehmen, auch wenn sie mit dem alten Standard gut zurechtkommen: In einer Community müssen Sie einer Minderheit manchmal bestimmte Entscheidungen 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 angewendet wird, für die sie nicht entwickelt wurde. Anstatt auf Einfachheit und Stabilität des Designs zu achten, kann die Community neue Ideen (auch aus anderen Sprachen) einbeziehen, wenn die Sprache in neue Anwendungsbereiche wechselt. In einem solchen Szenario können Sie nicht erwarten, dass es beim ersten Versuch richtig läuft.

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

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

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 die Community beschließt, weiterzumachen, entscheiden sich viele Mitglieder, zu folgen, um Isolation zu vermeiden.

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

NOTE

Aus einigen Antworten und Kommentaren scheine ich zu verstehen, dass einige Leser die Frage als "Warum müssen sich Programmiersprachen weiterentwickeln" interpretiert haben.

Ich denke, dies 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 Entwicklung in einer Programmiersprache stattfinden, anstatt viele neue Sprachen hervorzubringen?"

13
Giorgio

Abwärtskompatibilität ist Ihre Antwort. Eine bestimmte Sprache, insbesondere eine weit verbreitete Sprache wie C, kann Code enthalten, der seit Jahrzehnten unverändert in Betrieb ist. Wenn Wartungsarbeiten erforderlich sind, ist es hilfreich, Compiler zu haben, die auf diese Art von Plattform abzielen können, während sie auf modernen Systemen für Entwicklungsarbeiten ausgeführt werden. Standardisierungen und Aktualisierungen der Sprachversion helfen dabei, 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 angeschraubt haben". Die Tiere von früher lauern oft noch in ihnen.

Denken Sie für Knuth daran, dass er ein Akademiker ist und dass TeX nur als richtig erwiesen und nicht aktualisiert wird.

21
World Engineer

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 Vorteile neuerer Techniken (mehrere Kerne, bessere Threading- oder Speichermodelle) zu nutzen, die ihnen in die Quere kommen auf oder in den Sprachstandard gebacken. Es ist auch hilfreich, "eine echte Möglichkeit" zu haben, um Dinge zu tun (z. B. XML-Analyse, DB-Zugriff), auf die Sie zählen können, unabhängig davon, auf welchem ​​Compiler oder auf welcher Plattform Sie sich befinden, im Gegensatz zu Abhängigkeiten von Drittanbietern Bibliothek, die möglicherweise installiert ist oder nicht (und möglicherweise die von Ihnen benötigte Version usw. ist oder nicht).

5
TMN

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

Die Art und Weise, wie Algorithmen in einer Sprache ausgedrückt werden, ändert sich nicht, auch wenn möglicherweise eine sauberere Unterstützung für 64-Bit-Typen oder eine Standardunterstü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 führen diese Änderungen zu Vereinfachungen der Dinge, die die Leute bereits auf die harte Tour gemacht haben. (Siehe C++ mit Funktionen höherer Ordnung anstelle von Funktionszeigern und Funktoren.)

1
Ben