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

14

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à?

Simon Smith
la source
4
-1: Trop vague et hypothétique pour être répondu du tout. Qu'est-ce que "rapidement"? Qu'est-ce qui est "amélioré"? Si les modifications sont toutes rétrocompatibles, qu'importe? Veuillez améliorer la question pour être plus précis. Un langage concret qui évolue rapidement pourrait aider.
S.Lott
Les anciens programmes fonctionnent-ils toujours sans changement?
4
Je préfère certainement un langage qui ne change pas du tout, mais qui est suffisamment flexible pour permettre l'ajout de nouvelles fonctionnalités arbitraires en tant que bibliothèques. Des langues énormes et maladroites avec toutes les caractéristiques enfouies dans leurs noyaux monolithiques sont condamnées à pourrir.
SK-logic
Les «changements» et les «ruptures de compatibilité descendante» sont des choses complètement différentes. Ce dernier est le vrai problème.
user16764

Réponses:

16

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.

Doug T.
la source
Le C ++ n'est pas l'évolution du C, c'est un nouveau langage en quelque sorte compatible avec C.
Nikko
La plupart des gens n'utilisent pas correctement le C ++, ils l'utilisent comme c'était le C puisque, eh bien, ils le peuvent. Et, C ++ lorsqu'il est utilisé correctement est d'une complexité odieuse et a eu un historique de certains compilateurs ne prenant pas en charge toutes les fonctionnalités du langage.
sylvanaar
Autre élément clé en faveur de la stabilité: lorsque vous travaillez avec des environnements certifiés, les mises à jour linguistiques peuvent être un problème majeur. Le problème est que même pour une version de patch minuscule, tout le processus de certification doit être refait à zéro à chaque fois et cela prend beaucoup de temps.
Donal Fellows
@Nikko Je suis d'accord, mais il est largement rétrocompatible avec C, ce qui crée beaucoup de problèmes amusants :)
Doug T.
11

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.

Carra
la source
5

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.

mcottle
la source
4

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.

Aucune chance
la source
2

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.

Jerry Coffin
la source
2

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.


la source
L '«évolution» du C ++ est le C ++ 11, la nouvelle norme. "C #" ou "D" ne sont pas des évolutions C ++ .. Comme C ++ n'est pas l'évolution de C.
Nikko
1
@Nikko: Ah ha. Bon point. Tout sauf une petite poignée de programmeurs C ++ que je connais a même entendu parler de C ++ 0x ou C ++ 11. Je suis presque sûr qu'il ne s'en souciera pas ni ne regardera les fonctionnalités à moins que la société ne mette à niveau les compilateurs et qu'il arrive à voir quelque chose qui les rend assez curieux (j'espère que le déménagement en fait partie)
@ acidzombie24: Je programme en C ++ depuis longtemps (depuis 1995) et ma première impression de C ++ 11 est qu'il ajoute plus de complexité que de productivité réelle au langage: la sémantique du langage est devenue si complexe qu'elle est très facile à introduire des bugs très subtils et difficiles à repérer. Et cela coûte du temps à réparer, réduisant ainsi la productivité. Je pourrais changer d'avis si je suis obligé d'utiliser vraiment la nouvelle norme, mais même après avoir examiné certaines nouvelles fonctionnalités de manière approfondie, mon sentiment ne s'est pas beaucoup amélioré.
Giorgio
0

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.

volothamp
la source
0

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.

Jetti
la source