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?
programming-languages
Simon Smith
quelle
quelle
Antworten:
Gut
Schlecht
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.
quelle
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.
quelle
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.
quelle
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.
quelle
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.
quelle
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.
quelle
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):
Verschiedene Arten der Typprüfung
Es ist nicht immer klar, wann Sie das eine oder andere verwenden möchten.
quelle
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.
quelle