Si une langue change rapidement, est-ce considéré comme une bonne chose?

J'ai vu des langues qui changent rapidement (je veux dire qu'elles s'améliorent chaque année par exemple) et d'autres qui s'améliorent lentement.

Ma question, si une langue change rapidement est-ce une bonne ou une mauvaise chose pour le programmeur? Les programmeurs aiment-ils apprendre de nouvelles choses dans la langue ou préfèrent-ils s'en tenir à ce qu'ils savent déjà?

si une langue change rapidement, est-ce une bonne ou une mauvaise chose pour le programmeur?

Bien

• Les changements pourraient ajouter du sucre syntaxique agréable rendant le code futur plus facile à écrire avec moins de bogues
• Les modifications peuvent normaliser un modèle d'idiome / de conception commun que les programmeurs ont dû mettre en œuvre eux-mêmes ou utiliser pour des tiers.
• Les changements peuvent faciliter l'intégration aux technologies avec lesquelles le langage est généralement utilisé.
• Les changements peuvent aider à prévenir les erreurs courantes
• Les modifications peuvent déprécier ou éliminer les pratiques de programmation dangereuses
• Les changements peuvent avoir des ajouts utiles à la bibliothèque standard de la langue pour les choses que j'avais l'habitude d'avoir à implémenter moi-même ou à compter sur des tiers.

Mal

• Le langage a ajouté de la complexité - les nouvelles fonctionnalités peuvent ne pas toujours bien fonctionner avec les fonctionnalités héritées (c'est-à-dire la relation de C ++ avec C)
• Le code hérité peut être obsolète et peut ne plus fonctionner dans la nouvelle version du langage sans mises à jour (Python 2.x -> 3.x)
• Les compilateurs et autres outils pour la langue doivent être mis à jour. Il existe maintenant potentiellement plusieurs versions.
• Les bibliothèques tierces peuvent ne pas prendre en charge la nouvelle version de la langue
• Malgré l'existence d'une norme, il peut prendre du temps pour trouver un moyen standard / normal d'implémenter de nouvelles fonctionnalités et définir certains des cas les plus obscurs de leur comportement

Les programmeurs aiment-ils apprendre de nouvelles choses dans la langue ou préfèrent-ils s'en tenir à ce qu'ils savent déjà?

De nombreux programmeurs aiment satisfaire leur curiosité en jouant avec les nouvelles fonctionnalités. Cependant, cela ne signifie pas que les nouvelles fonctionnalités sont toujours appropriées dans le code de production. Il s'agit d'une décision au cas par cas qui doit peser les avantages des nouvelles fonctionnalités par rapport au coût de la mise à niveau dans sa situation spécifique.

Je pourrais m'amuser ou profiter de l'apprentissage de nouvelles fonctionnalités, mais en fin de compte, ce qui m'importe vraiment, c'est de fournir un produit utile à quelqu'un. Je dois choisir l'ensemble d'outils qui sera suffisamment moderne pour avoir un support et une stabilité raisonnables mais pas si anciens que je ne puisse pas être raisonnablement productif.

Les améliorations sont grandes ... si elles sont rétrocompatibles .

C # le fait bien. Ils ajoutent des expressions lamdba, un meilleur support pour le multithreading, linq, ... Mais votre programme C # 2.0 vieux de cinq ans fonctionnera toujours bien sans avoir besoin de changements et peut facilement être mis à niveau vers C # 4.0 sans avoir besoin de changements.

Apprendre de nouvelles choses est formidable s'il vous permet de faire vos tâches d'une manière plus simple et plus rapide. Si passer une heure à apprendre signifie économiser vos heures en temps de développement, cela en vaut la peine.

Je veux des améliorations régulières, mais je ne veux pas qu'il casse une base de code de 500 kloc et déclenche un "projet de mise à niveau" massif juste pour que le code fonctionne comme il le fait avec la version précédente.

La stabilité linguistique est indispensable pour les entreprises et les développeurs. Les changements de langue sont les bienvenus s'ils résolvent des problèmes ou introduisent des fonctionnalités qui manquaient dans les versions précédentes, mais changer de langue pour qu'il soit à la mode ou simplement parce que vous voulez rattraper un concurrent n'est pas si bon.

Lorsque la langue est stable, au fil du temps, les développeurs cessent de concentrer leurs efforts sur l'apprentissage de la langue parce qu'ils l'auraient maîtrisée et commenceraient à concentrer leurs efforts sur le service à l'entreprise avec ce qu'ils savent. Le résultat est un projet plus court, des utilisateurs finaux heureux et des développeurs plus fiers!

Le changement s'accompagne également de coûts et de temps d'apprentissage. Tous les employeurs ne sont pas disposés à informer les développeurs des nouvelles fonctionnalités. Cela ajoute un fardeau important aux développeurs pour se former ou bien - Ce n'est pas anodin, les cours spécialisés peuvent être de 1500 $ à 3500 $ chacun!

Un changement continu peut bloquer les développeurs dans des logiciels «hérités». Prenons le cas d'un développeur ASP qui n'a pas intercepté MVVM dans 2 ans ou le cas d'un développeur Windows Forms qui n'a pas appris WPF. Ce verrouillage peut nuire considérablement à la carrière de développeur.

Au fil du temps, l'architecture du logiciel dans une entreprise devient comme une salade de jardin. Toutes sortes d'outils et de versions et vous trouvez des projets qui commencent à ne faire que mettre à niveau le logiciel d'une version à l'autre sans aucun gain commercial.

Je ne pense pas qu'il y ait une seule réponse qui soit juste.

D'une manière générale, lorsqu'une langue est relativement jeune, il y a beaucoup plus de liberté pour effectuer des changements relativement importants relativement rapidement. Il n'y a pas une grande base de code existant à casser, donc les gens sont généralement beaucoup plus ouverts à l'expérimentation.

À mesure que la langue vieillit, en supposant qu'elle soit suffisamment large pour que quiconque s'en soucie vraiment, la base du code existant commence à imposer des restrictions de plus en plus strictes sur les modifications qui peuvent être apportées. Non seulement il y a plus de code utilisant plus de fonctionnalités, il est donc plus difficile de deviner quels changements pourraient casser le code, mais les attentes des gens changent.

Par exemple, supposons qu'il y ait à peu près le même nombre de personnes écrivant Ruby et Fortran. En outre, supposons qu'il y ait à peu près la même quantité de code dans les deux. Je dirais que les chances sont plutôt bonnes qu'un changement qui a cassé exactement le même pourcentage de chacun (et d'une manière qui a pris environ le même travail à corriger) serait beaucoup plus acceptable pour les utilisateurs Ruby que les utilisateurs Fortran en règle générale (au moins en supposant qu'ils y voient une amélioration).

Je pense que beaucoup dépend aussi de la perception que les gens ont de la langue au départ. Les gens qui choisissent une langue parce qu'elle est "à la pointe" sont beaucoup plus susceptibles de subir des changements majeurs qui cassent beaucoup de code existant, si c'est ce qu'il faut pour le garder à la pointe.

Un autre facteur est la taille et l'espérance de vie des projets auxquels la langue est destinée. Un langage qui s'adresse à des projets relativement petits ou à ceux que nous connaissons à l'avance a une courte espérance de vie (par exemple, une interface utilisateur Web) peut se passer de casser des choses relativement fréquemment, car il est peu probable que beaucoup de gens continuent à utiliser la même base de code pendant, disons, 10 ans de toute façon. Un langage (par exemple, C ++ ou Java) qui s'adresse davantage à des projets plus longs et de plus longue durée qui peuvent prendre, par exemple, 5 ans pour arriver à une version initiale, peut être utilisé régulièrement (et en développement continu) pendant trois ou quatre décennies une grande stabilité de plus de beaucoup.

Un gars m'a dit qu'il aimait son C ++ et que ça restera comme ça. Il ne se soucie pas ou n'a pas d'intérêt pour D, il ne veut pas connaître ni utiliser C #. Il a appris le java parce qu'il devait le faire pour les nombreux projets qu'il devait faire et il fait apparemment du bon travail dans les langues qu'il connaît

Un autre aime C # et ne connaît pas tous les mots clés ou connaît les bibliothèques .NET 4 (async et tous) et n'a pas utilisé les mots clés abstraits ou les attributs utilisés.

Je dis simplement que la plupart des gens ne s'en soucient pas

Maintenant, les effets de la mise à niveau se brisent (pour les bibliothèques ou le code compilé) les gens vont s'en soucier.

Je répondrai pour C # (mais cette analyse peut également s'appliquer à Scala):

Cette modification de fonctionnalité provoque certains problèmes lorsque vous approchez d'un "style" d'une langue:

En 2011, C # peut faire beaucoup de choses différentes, et c'est bien. Malheureusement, il a deux paradigmes différents (sinon plus):

• OOP
• Fonctionnel (pensez aux fonctions lambda et LINQ)

Différents styles de vérification de type

• Saisie dynamique
• Typage statique

Ce n'est pas toujours clair quand vous voulez utiliser l'un ou l'autre.

Je pense que cela dépend vraiment de la langue et des éléments suivants de la langue. Par exemple, je pense que si C # et Java commençaient à faire apparaître des changements à un rythme plus rapide, cela serait accepté (tant qu'ils sont rétrocompatibles comme l'a dit Carra ). Cependant, si la langue n'a pas encore gagné en popularité et qu'elle évolue encore rapidement, je sais que je ne m'en occuperais pas car il y a une chance que ce que j'essaie d'apprendre aujourd'hui soit totalement différent de ce qui est sorti dans 6 mois et comme la langue est nouvelle / impopulaire, cela ne me serait pas préjudiciable (lire: ma carrière) de la transmettre.