Pourquoi les anciens langages de programmation continuent-ils d'être révisés?

Cette question n'est pas "Pourquoi les gens utilisent-ils encore les anciens langages de programmation?" Je le comprends très bien. En fait, les deux langages de programmation que je connais le mieux sont C et Scheme, tous deux remontant aux années 70.

Je lisais récemment des articles sur les modifications apportées aux versions C99 et C11 par rapport à C89 (qui semble toujours être la version de C la plus utilisée dans la pratique et la version que j'ai apprise de K & R). En regardant autour de vous, il semble que chaque langage de programmation très utilisé reçoit une nouvelle spécification au moins une fois par décennie environ. Même Fortran reçoit toujours de nouvelles révisions, malgré le fait que la plupart des utilisateurs l'utilisent toujours.

Comparez cela à l’approche du système de composition TeX, par exemple. En 1989, avec la sortie de TeX 3.0, Donald Knuth déclara que TeX était complet et que les versions futures ne contiendraient que des corrections de bugs. Même au-delà de cela, il a déclaré qu'à sa mort, "tous les bogues restants deviendront des fonctionnalités" et qu'aucune autre mise à jour ne sera faite. D'autres sont libres d'utiliser TeX et l'ont fait, mais les systèmes résultants sont renommés pour indiquer qu'ils sont différents de TeX officiel. Ce n'est pas parce que Knuth pense que TeX est parfait, mais parce qu'il comprend la valeur d'un système stable et prévisible qui fera la même chose dans cinquante ans.

Pourquoi la plupart des concepteurs de langages de programmation ne suivent-ils pas le même principe? Bien sûr, lorsqu'une langue est relativement nouvelle, il est logique qu'elle passe par une période de changements rapides avant de s'installer. Et personne ne peut vraiment s'opposer à des modifications mineures qui ne font que codifier des pseudo-normes existantes ou corriger des lectures inattendues. Mais lorsqu'une langue semble encore avoir besoin d'amélioration après dix ou vingt ans, pourquoi ne pas simplement la bifurquer ou recommencer, plutôt que d'essayer de changer ce qui est déjà utilisé? Si certaines personnes veulent vraiment faire de la programmation orientée objet en Fortran, pourquoi ne pas créer "Objective Fortran" à cette fin et laisser Fortran lui-même?

Je suppose que l’on pourrait dire que, indépendamment des révisions futures, C89 est déjà une norme et que rien n’empêche les utilisateurs de continuer à l’utiliser. C'est un peu vrai, mais les connotations ont des conséquences. En mode pédant, GCC mettra en garde sur une syntaxe dépréciée ou ayant une signification légèrement différente en C99, ce qui signifie que les programmeurs C89 ne peuvent tout simplement pas ignorer la nouvelle norme. C99 doit donc comporter un avantage suffisant pour imposer ces frais généraux à tous les utilisateurs du langage.

C'est une vraie question, pas une invitation à argumenter. Bien entendu, j’ai une opinion à ce sujet, mais pour le moment, j’essaie seulement de comprendre pourquoi ce n’est pas simplement la façon dont les choses se passent. Je suppose que la question est:

Quels sont les avantages (réels ou perçus) de la mise à jour d'une norme linguistique par opposition à la création d'une nouvelle langue basée sur l'ancienne?

Je pense que la motivation des concepteurs de langage pour réviser les langages existants est d'introduire l'innovation tout en veillant à ce que leur communauté de développeurs cible reste unie et adopte le nouveau langage: déplacer une communauté existante vers une nouvelle révision d'un langage existant est plus efficace que de créer une nouvelle communauté. autour d'une nouvelle langue. Bien sûr, cela oblige certains développeurs à adopter la nouvelle norme, même si l'ancienne règle convenait: dans une communauté, vous devez parfois imposer certaines décisions à une minorité si vous souhaitez que la communauté reste unie.

En outre, considérons qu'un langage général tente de servir le plus grand nombre de programmeurs possible et qu'il est souvent appliqué à de nouveaux domaines pour lesquels il n'a pas été conçu. Ainsi, au lieu de viser la simplicité et la stabilité du design, la communauté peut choisir d'incorporer de nouvelles idées (même issues d'autres langues) au fur et à mesure que la langue évolue vers de nouveaux domaines d'application. Dans un tel scénario, vous ne pouvez pas vous attendre à bien faire les choses du premier coup.

Cela signifie que les langues peuvent subir de profonds changements au fil des ans et que la dernière révision peut paraître très différente de la première. Le nom de la langue n'est pas conservé pour des raisons techniques, mais parce que la communauté de développeurs accepte d'utiliser un ancien nom pour une nouvelle langue. Ainsi, le nom du langage de programmation identifie la communauté de ses utilisateurs plutôt que le langage lui-même.

Pour l’OMI, de nombreux développeurs trouvent cela acceptable (ou même souhaitable), c’est qu’une transition progressive vers une langue légèrement différente est plus facile et moins déroutante qu’un saut dans une langue complètement nouvelle qui leur demanderait plus de temps et d’efforts pour la maîtriser. Considérez qu’un certain nombre de développeurs ont une ou deux langues préférées et n’apprécient guère l’apprentissage de nouvelles langues (radicalement différentes). Et même pour ceux qui aiment apprendre de nouvelles choses, apprendre un nouveau langage de programmation est toujours une activité difficile et qui prend du temps.

En outre, il peut être préférable de faire partie d'une grande communauté et d'un écosystème riche que d'une très petite communauté utilisant un langage moins connu. Ainsi, lorsque la communauté décide de passer à autre chose, de nombreux membres décident de suivre pour éviter l'isolement.

En guise de commentaire, je pense que l'argument qui consiste à autoriser l'évolution tout en maintenant la compatibilité avec le code existant est plutôt faible: Java peut appeler du code C, Scala peut facilement s'intégrer au code Java, C # peut s'intégrer au C ++. De nombreux exemples montrent que vous pouvez facilement interfacer avec du code hérité écrit dans une autre langue sans avoir besoin de la compatibilité du code source.

REMARQUE

D'après certaines réponses et certains commentaires, il semble que certains lecteurs aient interprété la question comme suit: "Pourquoi les langages de programmation doivent-ils évoluer?"

Je pense que ce n’est pas l’essentiel de la question, car il est évident que les langages de programmation doivent évoluer et pourquoi (nouvelles exigences, nouvelles idées). La question est plutôt "Pourquoi cette évolution doit-elle avoir lieu dans un langage de programmation au lieu de générer de nombreux nouveaux langages?"

La compatibilité ascendante est votre réponse. Une langue donnée, en particulier une langue largement utilisée telle que C, peut avoir un code en fonctionnement, non modifié, pendant des décennies. S'il est nécessaire d'effectuer des tâches de maintenance, il est utile de disposer de compilateurs capables de cibler ce type de plate-forme tout en fonctionnant sur des systèmes modernes destinés au développement. Les normalisations et les mises à jour de versions linguistiques aident à maintenir les pratiques de programmation à jour tout en fournissant un sentiment de familiarité aux programmeurs expérimentés qui peuvent être réticents à apprendre un tout «nouveau» langage.

Gardez à l'esprit que beaucoup de langues mises à jour sont moins mises à jour que "ont de nouveaux éléments brillants verrouillés". Les bêtes d'antan se cachent souvent encore à l'intérieur.

Pour ce qui est de Knuth, rappelez-vous qu’il est un universitaire et que TeX n’est prouvé que comme correct, pas mis à jour.

Je pense que la réponse évidente est que des progrès sont encore réalisés dans la conception des langages et l'architecture système, et que suffisamment de gens se soucient des langages plus anciens pour pouvoir tirer parti des nouvelles techniques (plusieurs cœurs, de meilleurs modèles de thread ou de mémoire) pour pouvoir les maîtriser. sur ou cuit dans la norme de langue. Il est également utile d’avoir une "seule vraie façon" de faire (par exemple, l'analyse XML, l'accès aux bases de données) sur laquelle vous pouvez compter, quel que soit le compilateur ou la plate-forme sur laquelle vous vous trouvez, plutôt que de dépendre de tiers. bibliothèque qui peut ou non être installée (et peut être ou non la version dont vous avez besoin, etc.).

Les concepts ou objectifs fondamentaux autour desquels s'articule le langage à usage général ne perdent pas leur pertinence. Cependant, des changements mineurs dans l'environnement de travail ou le matériel exigent que des mises à jour ou de petites fonctionnalités soient ajoutées à une langue.

La façon dont les algorithmes sont exprimés dans un langage ne changera pas, même si celui-ci peut nécessiter une prise en charge plus propre des types 64 bits, une prise en charge plus régulière des expressions régulières ou une prise en charge plus robuste des nouveaux types de systèmes de fichiers.

Il existe quelques cas où de «nouvelles» fonctionnalités sont ajoutées aux langues existantes, mais dans de nombreux cas, ces modifications constituent une simplification des tâches que les gens faisaient déjà à la dure. (Voir C ++ en utilisant des fonctions d'ordre élevé au lieu de pointeurs de fonctions et de foncteurs.)

C'est un peu comme une considération du langage parlé.

Dans le passé, il y avait des mots qui n'étaient pas utilisés aussi souvent qu'ils le sont maintenant (ou utilisés pour un sens différent).

par exemple. sympa: en (très vieux), l’anglais a un sens presque inverse de celui que nous utilisons aujourd’hui, en particulier pour décrire le caractère de quelqu'un.

Mauvais: il n’ya pas très longtemps, mauvais n’avait qu’un seul sens, maintenant il peut vouloir dire quelque chose de "super étonnant" (il est utilisé de façon fesicous (j’ai probablement manqué le mot épelé fesicous)!

Une autre nouveauté est le téléphone mobile «Text Speak» pour les langues écrites.

Personnellement, je ne vois pas pourquoi un langage de programmation ne se développerait pas de manière similaire. Les mots et les fonctions ont des significations / actions spécifiées, et il est nécessaire de changer pour incorporer de nouvelles idées, de nouvelles méthodologies.

Je connais des gens qui parlent beaucoup de langues différentes et ils suggèrent souvent qu’après 3 ou 4, il devient plus facile d’en apprendre une nouvelle.

Je ne sais pas s'il y a des programmeurs qui ont une expérience similaire, je ne serais pas surpris s'il y en avait.

Je sais que je me sens heureux de programmer en JAVA (tout comme je me sens heureux de parler en anglais) Cela ne signifie pas que je ne peux pas communiquer en «anglais américain» ou en «anglais australien», bien qu'il y ait des «pièges» à surveiller . Un peu comme aller de Java à PHP en Perl, les constructions sont similaires, mais il y a peu de pièges pour me prendre et me faire cogner la tête contre le mur.

Cela diffère du passage de l'anglais au français ou de Java à SAS. Celles-ci sont si différentes qu'il faut beaucoup de temps pour les maîtriser.

Quoi qu'il en soit, c'est mon point de vue.