Wenn sich eine Sprache schnell ändert, ist das eine gute Sache?

Ich habe einige Sprachen gesehen, die sich schnell ändern (ich meine, sie werden zum Beispiel jedes Jahr verbessert), und andere, die sich langsam verbessern.

Meine Frage: Wenn sich eine Sprache schnell ändert, ist das eine gute oder eine schlechte Sache für den Programmierer? Lernen Programmierer gerne etwas Neues in der Sprache oder bleiben sie lieber bei dem, was sie bereits wissen?

Wenn sich eine Sprache schnell ändert, ist das eine gute oder eine schlechte Sache für den Programmierer?

Gut

• Die Änderungen könnten einige nette syntatische Zucker hinzufügen, die das Schreiben von zukünftigem Code mit weniger Fehlern erleichtern
• Die Änderungen können eine gemeinsame Redewendung / ein gemeinsames Entwurfsmuster vereinheitlichen, für das sich Programmierer selbst implementieren mussten oder auf Dritte vertrauen mussten.
• Die Änderungen erleichtern möglicherweise die Integration in Technologien, mit denen die Sprache normalerweise verwendet wird
• Die Änderungen können dabei helfen, häufige Fehler zu vermeiden
• Die Änderungen können gefährliche Programmierpraktiken veralten oder beseitigen
• Die Änderungen können nützliche Ergänzungen zur Standardbibliothek der Sprache für Dinge enthalten, die ich früher selbst implementiert habe oder für die ich mich auf Dritte stütze.

Schlecht

• Die Sprache hat die Komplexität erhöht - neue Funktionen passen möglicherweise nicht immer gut zu den älteren Funktionen (z. B. die Beziehung von C ++ zu C).
• Legacy-Code ist möglicherweise veraltet und funktioniert in der neuen Version der Sprache ohne Updates möglicherweise nicht mehr (Python 2.x -> 3.x)
• Compiler und andere Tools für die Sprache müssen aktualisiert werden. Jetzt gibt es möglicherweise mehrere Versionen.
• Bibliotheken von Drittanbietern unterstützen möglicherweise nicht die neuere Version der Sprache
• Trotz der Existenz eines Standards kann es einige Zeit dauern, bis ein standardmäßiger / normaler Weg gefunden ist, um neue Funktionen zu implementieren und einige der unklareren Fälle ihres Verhaltens zu definieren

Lernen Programmierer gerne etwas Neues in der Sprache oder bleiben sie lieber bei dem, was sie bereits wissen?

Viele Programmierer befriedigen gerne ihre Neugier, indem sie mit den neuen Funktionen spielen. Dies bedeutet jedoch nicht, dass die neuen Funktionen im Seriencode immer geeignet sind. Dies ist eine Einzelfallentscheidung, bei der die Vorteile der neuen Funktionen gegen die Kosten für die Aktualisierung in der jeweiligen Situation abgewogen werden müssen.

Ich habe vielleicht Spaß daran, neue Funktionen kennenzulernen, aber am Ende des Tages ist es mir sehr wichtig, jemandem ein nützliches Produkt zu liefern. Ich muss das Toolset auswählen, das modern genug sein wird, um eine angemessene Unterstützung und Stabilität zu bieten, aber nicht so alt, dass ich nicht einigermaßen produktiv sein kann.

Verbesserungen sind großartig ... wenn sie abwärtskompatibel sind .

C # macht das gut. Sie fügen Dinge wie lamdba-Ausdrücke, bessere Unterstützung für Multithreading, linq, ... hinzu. Ihr fünf Jahre altes C # 2.0-Programm funktioniert jedoch weiterhin einwandfrei, ohne dass Änderungen erforderlich sind, und kann problemlos auf C # 4.0 aktualisiert werden, ohne dass Änderungen erforderlich sind.

Das Erlernen neuer Dinge ist großartig, wenn Sie damit Ihre Aufgaben einfacher und schneller erledigen können. Wenn es sich lohnt, eine Stunde zu lernen, um Stunden Entwicklungszeit zu sparen, lohnt es sich.

Ich möchte regelmäßige Verbesserungen, aber ich möchte nicht, dass es eine 500-Kloc-Codebasis zerstört und ein umfangreiches "Upgrade-Projekt" auslöst, damit der Code so funktioniert, wie er mit der vorherigen Version funktioniert.

Sprachstabilität ist ein Muss für Unternehmen und Entwickler. Änderungen in der Sprache sind willkommen, wenn sie Probleme lösen oder Funktionen einführen, die in früheren Releases übersehen wurden. Das Ändern der Sprache, sodass sie im Trend liegt oder nur, weil Sie mit einem Konkurrenten aufholen möchten, ist nicht so gut.

Wenn die Sprache im Laufe der Zeit stabil ist, konzentrieren sich die Entwickler nicht mehr auf das Erlernen der Sprache, weil sie diese beherrschen würden, und konzentrieren sich darauf, dem Geschäft mit dem zu dienen, was sie wissen. Das Ergebnis ist ein kürzeres Projekt, zufriedene Endbenutzer und stolze Entwickler!

Veränderungen sind auch mit Lernkosten und -zeit verbunden. Nicht alle Arbeitgeber sind bereit, Entwickler in neuen Funktionen zu schulen. Dies stellt eine erhebliche Belastung für die Entwickler dar, um sich selbst zu schulen. Dies ist nicht trivial. Spezialisierte Kurse können zwischen 1.500 und 3.500 USD kosten.

Kontinuierliche Änderungen können Entwickler an "Legacy" -Software binden. Nehmen Sie den Fall eines ASP-Entwicklers, der in zwei Jahren keine Erfahrung mit MVVM gemacht hat, oder den Fall eines Windows Forms-Entwicklers, der WPF nicht gelernt hat. Diese Sperrung kann die Entwicklerkarriere erheblich beeinträchtigen.

Im Laufe der Zeit sieht die Architektur der Software in einem Unternehmen aus wie ein Gartensalat. Alle Arten von Tools und Versionen, und Sie werden feststellen, dass Projekte nichts anderes tun, als Software von einer Version auf die nächste zu aktualisieren, ohne geschäftlichen Gewinn.

Ich glaube nicht, dass es eine richtige Antwort gibt.

Allgemein gesagt, wenn eine Sprache relativ jung ist, gibt es viel mehr Freiheit, relativ große Änderungen relativ schnell vorzunehmen. Es gibt keine große Basis an vorhandenem Code, die aufgebrochen werden könnte, sodass die Leute im Allgemeinen viel offener für Experimente sind.

Mit zunehmendem Alter der Sprache, vorausgesetzt, die Benutzerzahl reicht aus, um sich wirklich darum zu kümmern, werden aufgrund des vorhandenen Codes immer strengere Einschränkungen hinsichtlich der Änderungsmöglichkeiten vorgenommen. Es gibt nicht nur mehr Code, der mehr Funktionen nutzt, sondern es ist auch schwieriger zu erraten, welche Änderungen den Code beschädigen könnten, sondern die Erwartungen der Benutzer ändern sich.

Nehmen wir zum Beispiel an, es gab ungefähr die gleiche Anzahl von Leuten, die Ruby und Fortran geschrieben haben. Angenommen, in beiden war ungefähr die gleiche Menge Code enthalten. Ich würde sagen , die Chancen ziemlich gut, dass eine Veränderung , die genau den gleichen Prozentsatz von jedem brach (und in eine Weise, die korrekt über die gleiche Arbeit nahm) würde sein , viel mehr akzeptabel Ruby - Benutzer als Fortran - Benutzer in der Regel (Zumindest unter der Annahme, dass dies eine Verbesserung darstellt).

Ich denke, viel hängt auch von der Wahrnehmung der Sprache ab. Menschen, die sich für eine Sprache entscheiden, weil sie "auf dem neuesten Stand" ist, stellen sich mit größerer Wahrscheinlichkeit große Änderungen vor, die einen Großteil des vorhandenen Codes beschädigen, wenn es das ist, was erforderlich ist, um sie auf dem neuesten Stand zu halten .

Ein weiterer Faktor ist die Größe und Lebenserwartung der Projekte, für die die Sprache bestimmt ist. Eine Sprache, die für relativ kleine Projekte geeignet ist oder die wir von Anfang an kennen, hat eine kurze Lebenserwartung (z. B. eine Web-Benutzeroberfläche) und kann relativ häufig Probleme verursachen, da es unwahrscheinlich ist, dass viele Leute weiterhin dieselbe Codebasis verwenden für etwa 10 Jahre jedenfalls. Eine Sprache (z. B. C ++ oder Java), die für größere Projekte mit einer längeren Lebensdauer, die beispielsweise 5 Jahre dauern kann, um zu einer Erstveröffentlichung zu gelangen, besser geeignet ist, wird möglicherweise drei oder vier Jahrzehnte lang regelmäßig verwendet (und kontinuierlich weiterentwickelt) eine große Menge mehr Stabilität.

Ich habe mir von einem Typen sagen lassen, dass er sein C ++ mag, und das wird auch so bleiben. Er interessiert sich nicht für D, er möchte C # nicht kennen und auch nicht benutzen. Er lernte Java, weil er für die vielen Projekte, die er zu erledigen hatte, und anscheinend leistet er gute Arbeit in den Sprachen, die er kennt

Ein anderer liebt C ​​# und kennt nicht jedes Schlüsselwort oder die .NET 4-Bibliotheken (asynchron und alle) und hat die abstrakten Schlüsselwörter oder verwendeten Attribute nicht verwendet.

Ich sage nur, die meisten Leute kümmern sich nicht darum

Die Auswirkungen des Upgrades brechen jetzt (für Bibliotheken oder kompilierten Code), und die Leute werden sich darum kümmern.

Ich antworte für C # (aber diese Analyse kann auch auf Scala angewendet werden):

Diese Funktionsänderung verursacht einige Probleme, wenn Sie sich einem "Stil" einer Sprache nähern:

Im Jahr 2011 kann C # viele verschiedene Dinge tun, und das ist gut so. Leider hat es zwei verschiedene Paradigmen (wenn nicht mehr):

• OOP
• Funktional (denken Sie an Lambda-Funktionen und LINQ)

Verschiedene Arten der Typprüfung

• Dynamische Eingabe
• Statische Eingabe

Es ist nicht immer klar, wann Sie das eine oder andere verwenden möchten.

Ich denke, es hängt wirklich von der Sprache und den folgenden Faktoren ab, die die Sprache hat. Zum Beispiel denke ich, dass wenn C # und Java Änderungen in einem schnelleren Tempo veröffentlichen würden, dies akzeptiert würde (solange sie abwärtskompatibel sind, wie Carra sagte). Wenn sich die Sprache jedoch noch nicht verbessert hat und sich immer noch schnell ändert, würde ich mich nicht darum kümmern, da die Chance besteht, dass das, was ich heute zu lernen versuche, völlig anders sein wird als das, was in 6 Monaten herauskommt da die sprache neu / unbeliebt ist, würde es mir nicht schaden (sprich: meine karriere), sie einfach weiterzugeben.