Conservez un langage de programmation compatible avec les versions antérieures plutôt que de corriger ses défauts

Tout d’abord, un contexte (ce que la plupart d’entre vous connaissent de toute façon):

Chaque langage de programmation populaire a une évolution claire, la plupart du temps marquée par sa version: vous avez Java 5, 6, 7, etc., PHP 5.1, 5.2, 5.3, etc. nouvelles fonctionnalités, nouveaux frameworks, etc. Bref, c'est bien.

Mais qu'en est-il des problèmes de langue (ou de plate-forme)? Si et quand il y a quelque chose qui ne va pas dans une langue, les développeurs l'évitent (s'ils le peuvent) ou apprennent à vivre avec.

Maintenant, les développeurs de ces langages reçoivent beaucoup de commentaires des programmeurs qui les utilisent. Il est donc logique que, avec le temps (et les numéros de version), les problèmes dans ces langues disparaissent lentement mais sûrement. Eh bien pas vraiment. Pourquoi? Compatibilité ascendante, voilà pourquoi. Mais pourquoi est-ce vrai? Lire ci-dessous pour une situation plus concrète.

Le meilleur moyen d'expliquer ma question est d'utiliser PHP comme exemple:

PHP est aimé et détesté par des milliers de personnes. Toutes les langues ont des défauts, mais apparemment PHP est spécial. Découvrez ce blog . Il a une très longue liste de failles dites en PHP. Maintenant, je ne suis pas un développeur PHP (pas encore), mais j’ai tout lu et je suis sûr qu’une bonne partie de cette liste sont de véritables problèmes. (Pas tout, puisqu'il est potentiellement subjectif).

Maintenant, si j'étais l'un des gars qui développent activement PHP, je voudrais sûrement résoudre ces problèmes, un par un. Toutefois, si je le fais, le code reposant sur un comportement particulier du langage sera rompu s’il est exécuté sur la nouvelle version. En résumé en 2 mots: compatibilité ascendante.

Ce que je ne comprends pas, c'est: pourquoi devrais-je conserver une compatibilité ascendante avec PHP? Si je publie la version 8 de PHP avec tous ces problèmes corrigés, ne puis-je pas y mettre un gros avertissement disant: "N'exécutez pas de vieux code sur cette version!"?

Il y a une chose appelée dépréciation. Nous l'avons depuis des années et ça marche. Dans le contexte de PHP: regardez comment de nos jours, les gens découragent activement l'utilisation des mysql_*fonctions (et recommandent plutôt mysqli_*PDO). La dépréciation fonctionne. Nous pouvons l'utiliser. Nous devrions l'utiliser. Si cela fonctionne pour des fonctions, pourquoi ne devrait-il pas fonctionner pour des langues entières?

Disons que je (le développeur de PHP) fais ceci:

• Lancer une nouvelle version de PHP (disons 8) avec tous ces défauts corrigés
• Les nouveaux projets commenceront à utiliser cette version, car elle est bien meilleure, plus claire, plus sécurisée, etc.
• Cependant, afin de ne pas abandonner les anciennes versions de PHP, je publie régulièrement des mises à jour, corrige des problèmes de sécurité, des bugs, etc. Ceci est logique pour des raisons que je ne répertorie pas ici. C'est une pratique courante: regardez par exemple comment Oracle conservait la mise à jour de la version 5.1.x de MySQL, même si elle se concentrait principalement sur la version 5.5.x.
• Après environ 3 ou 4 ans, je cesse de mettre à jour les anciennes versions de PHP et je les laisse mourir. C'est bien, car au cours de ces 3 ou 4 années, la plupart des projets seront passés à PHP 8 de toute façon.

Ma question est la suivante: toutes ces étapes ont-elles un sens? Serait-ce si difficile à faire? Si cela peut être fait, alors pourquoi ne le fait-on pas?

Oui, l'inconvénient est que vous supprimez la compatibilité ascendante. Mais n'est-ce pas un prix à payer? En revanche, dans 3 ou 4 ans, vous aurez une langue qui règle 90% de ses problèmes… une langue beaucoup plus agréable à travailler. Son nom assurera sa popularité.

EDIT : OK, donc je ne me suis pas exprimé correctement en disant que dans 3 ou 4 ans, les gens passeraient à l'hypothétique PHP 8. Ce que je voulais dire était: dans 3 ou 4 ans, les gens utiliseront PHP 8 s'ils commencent une nouveau projet.

Cela a l'air bien, mais ça marche rarement dans la pratique; les gens sont extrêmement réticents à modifier le code en cours d'exécution, et même pour les nouveaux projets en plein champ, ils hésitent beaucoup à changer de langue / version qu'ils connaissent déjà.

Changer le code existant qui fonctionne "qui fonctionne bien" ne fait pas partie des priorités de tout projet. Plutôt que de faire un effort sur les choses que les responsables pensaient déjà payées, simplement pour pouvoir passer à une version plus récente d’un langage ou d’une plate-forme, ils vont décider que les développeurs doivent rester sur l’ancienne version "pour le moment". Vous pouvez essayer d'attirer vos utilisateurs avec des fonctionnalités exceptionnelles disponibles uniquement dans la nouvelle version, mais le risque est que vous risquiez de réduire votre base d'utilisateurs sans gain clair pour la langue; De l'avis général, il est difficile de comparer les caractéristiques modernes et modernes avec le prix d'une base d'installation fragmentée, et vous courez le risque d'obtenir la réputation d'être un "tapis roulant amélioré".

(Évidemment, la plupart de ces pratiques ne s'appliquent pas aux projets écrits par des amateurs simplement pour leur propre plaisir. Toutefois, PHP est rarement choisi de manière disproportionnée par les pirates, car c'est un tel plaisir d'écrire avec. )

Vous sous-estimez l'impact de la compatibilité ascendante; votre estimation selon laquelle tous les projets actifs migreraient dans 3 ou 4 ans est beaucoup trop optimiste.

Supposons que je sois un développeur PHP. PHP a des défauts, mais je sais comment contourner ces défauts - c'est l'une des raisons pour lesquelles je suis payé en tant que développeur PHP. Supposons maintenant que PHP 8 soit corrigé et corrigé, mais ce n'est pas compatible avec les versions antérieures. Par conséquent:

• Je dois passer du temps à mettre à jour mon code pour PHP 8. C'est le temps que je pourrais consacrer à répondre aux demandes des clients, à mettre en œuvre de nouvelles fonctionnalités et à faire face à la concurrence.
• Même après avoir effectué cette opération , il est fort probable que j’ai manqué un cas critique ou un problème de compatibilité imprévu, en introduisant des bogues dans mon code.

Cela étant, il y a une forte incitation à ne jamais migrer vers PHP 8, même si c'est "meilleur, plus clair, plus sécurisé, etc." On estime qu'il reste encore des milliards de lignes de COBOL (!) - bien qu'il existe évidemment de bien meilleures technologies disponibles, le coût d'une mise à jour, associé au risque de bugs, n'en vaut simplement pas la peine.

Deuxièmement, même si je décide de migrer mon propre code, toute application non triviale dépend de bibliothèques tierces, et rien ne garantit que les bibliothèques tierces migreront. Par exemple, Python 3 est sorti en décembre 2008, mais Django (probablement le principal framework Web Python) n'avait pas de support Python 3 stable et prêt pour la production depuis près de cinq ans (voir ici et ici ).

Vous faites beaucoup d'hypothèses sur le comportement humain. Si vous le changez trop, les gens évalueront vos concurrents, car ils devront de toute façon passer des efforts importants pour changer de fournisseur. Pour les langues open source, on utilisera simplement l'ancienne version.

Regardez python pour un exemple. 3.x est disponible depuis quatre ans et n'est pas encore largement adopté. Les gens essaient de l'utiliser pour de nouveaux projets, mais je pense que vous sous-estimez la quantité de travail de code nécessaire à la maintenance.

Bien sûr, la plupart des gens ne considéraient pas que python 2.x était "imparfait". Ils n'avaient pas de plaintes comme les utilisateurs de php. Php est dans une position beaucoup plus précaire, car beaucoup de gens ne la conservent que par sa grande base de code. Si vous perdiez la compatibilité ascendante, beaucoup de personnes saisiraient l’occasion qu’elles attendaient pour passer en python.

Pour n'importe quelle langue autre que PHP, je dirais que oui, c'est tout à fait logique! C’est exactement ce que fait Python avec le passage à Python 3.

Cependant, le problème avec PHP est qu’il ya trop de failles dans la conception même du langage. Par conséquent, ce que vous appelez "PHP 8" serait un langage complètement différent. Et si vous deviez changer de langue, pourquoi vous en tiendriez-vous au nouveau PHP plutôt qu’à aucune des alternatives existantes et stables?

De plus, la communauté PHP est extrêmement lente à adapter quelque chose de nouveau. Regardez combien de temps il a fallu pour s'en débarrasser register_globals. On sait que cela pose un risque pour la sécurité depuis l'an 2000. Il n'a finalement été supprimé que 12 ans plus tard. Un autre exemple, lorsque PHP5 a été introduit, c'était une énorme amélioration par rapport à PHP4, mais la communauté ne l'a pas adapté. J'ai pris 4 ans et des actions massives telles que GoPHP5 pour relancer l'adoption. Et cela n'a même pas eu beaucoup de changements incompatibles en arrière.

Clause de non-responsabilité: Je gère un groupe d'utilisateurs ColdFusion.

ColdFusion souffre des mêmes problèmes: aimé par beaucoup, méprisé par beaucoup. En outre, des tonnes et des tonnes de FUD basées sur des versions antérieures à Java. ColdFusion 10, sorti l'année dernière, est un énorme vendeur et la semaine dernière, je me suis inscrit pour tester la pré-version de la version 11. De plus, il existe deux alternatives majeures open source, l'une soutenue par JBoss.

J'aimerais implémenter des TONNES de nouvelles fonctions dans CF10, mais il peut s'avérer difficile de migrer de CF 7 ou 8 en fonction de la taille de votre base de code, du nombre de projets à venir et des ressources dont vous disposez pour tout êtes sur la dernière version. J'ai rencontré un certain nombre de différences syntaxiques mineures entre 8 et 9, ainsi que des cas extrêmes où le code ne se compile pas de la même manière. Une fois trouvées, je les ai documentées dans nos normes de codage afin qu'elles ne soient pas utilisées dans les projets futurs ou par les nouveaux développeurs.

Cela dit, si ColdFusion 11 (ou n’importe quel langage de programmation) désapprouvait complètement certaines fonctions et syntaxes, le niveau d’effort pour trouver et remplacer des fonctionnalités pourrait être énorme. L'effort de test pourrait être gigantesque. Les entreprises paieront-elles leurs développeurs, responsables de l'assurance qualité et chefs de projet pour trouver, remplacer et tester toutes ces choses obsolètes? Douteux.

Si la dernière version d'un langage est compatible avec les versions antérieures, mais qu'elle augmente les performances sans modification du code (CF9 est environ 30% plus rapide que CF8 et CF10 est beaucoup plus rapide que CF9), qui se soucie de modifier les appels de fonction s'ils fonctionnent encore?

En tant qu’entreprise, nous devons nous efforcer de plaire à nos clients et de répondre à leurs besoins pour pouvoir facturer des services, développer l’entreprise et recruter plus de clients.

FWIW, j'aimerais beaucoup avoir la dernière version de jQuery à un moment donné, mais certaines fonctions étant obsolètes quelques versions après ce que nous utilisons, et vu le volume de JavaScript que nous avons dans le système, je ne sais pas comment nous allons retirer cela.

Il y a un compromis ici; certains bogues ont VRAIMENT besoin d'être corrigés, mais certaines choses ne peuvent pas être changées sans détruire le code de quelqu'un quelque part. Je me souviens de quelqu'un qui a déclaré, en tant que "règle", que chaque correction de bug briserait le projet de quelqu'un, aussi obscur ou de toute évidence, le bogue serait-il utilisé, quelqu'un l'utilisera pour quelque chose. Telle est la nature des programmeurs.

C'est (à mon avis) la différence entre les versions majeures, les versions mineures et les révisions. En principe général:

• Les versions majeures sont supposées contenir des modifications importantes.
• Les versions mineures peuvent modifier légèrement le comportement.
• Les révisions devraient être assez compatibles entre elles.

Par exemple, si j'écris quelque chose dans la v2.3 d'une langue, je ne m'attendrais pas à constater de différence si je passe à la v2.3.2. Si je passe à la v2.4, quelques petites choses pourraient changer - de petites modifications de syntaxe, certaines fonctions se comportent un peu différemment, je dois donc modifier la logique, etc. Si je passe à la v3.0, je ne serais pas surpris que cela tombe en panne. entièrement - fonctions obsolètes ou manquantes, opérations non prises en charge ou modifiées au point de ne pas pouvoir les réajuster, il me faut en réalité réécrire certaines fonctions pour prendre en compte les nouveaux changements.

Modifier:

L'article de Advanced VM Branching Strategies de Steve Vance dit ceci:

En règle générale, il existe deux à trois niveaux de libération, nommés par des numéros liés à des périodes (par exemple, 1.2.3). [...] Dans cette structure, le premier numéro est associé à une version majeure, ce qui indique que la fonctionnalité et les améliorations fonctionnelles apportées par rapport à la version précédente sont significatives. il peut également y avoir des incompatibilités importantes nécessitant une migration. Le deuxième numéro représente une version mineure, qui contient des améliorations mineures de fonctionnalités et de fonctions, un nombre important de corrections de bugs et aucune incompatibilité. Le troisième numéro fait référence à un niveau de correctif, signifiant presque exclusivement un ensemble de corrections de bugs; aucune amélioration de fonctionnalité ou de fonction et aucune incompatibilité n'est autorisée entre les niveaux de correctif.

La seule modification à apporter est le principe susmentionné selon lequel les programmeurs trouvent souvent le moyen "d'utiliser" les bogues. Ainsi, une version mineure comportant "un nombre important de corrections de bogues et aucune incompatibilité" pourrait être difficile, car il est probable que ceux-ci Les bogues vont casser quelque chose qui les a utilisés, ou vont rendre inutile une solution de contournement et commencer à causer des problèmes.

Cela dépend vraiment de la cible du langage - quels types d'applications sont conçus pour être construits avec le langage.

Par exemple, en ignorant Android, Java est principalement utilisé dans les systèmes et les entreprises de grande taille; ces types d'applications ont tendance à devenir très volumineux, à la fois en taille et en durée. Cela a des implications. imaginez un système avec 500K + LoC sur lequel un travailleur de 50 ingénieurs et plus en phase de développement. Typiquement, ce type de système entre en maintenance après cela avec 10 développeurs; maintenant, si la langue change et que les modifications ne sont pas compatibles avec les versions antérieures, le projet ne peut pas être facilement migré vers une nouvelle version, car les programmeurs qui ont écrit certaines parties ont disparu et personne ne veut y toucher. C’est le problème le moins important, le plus gros problème réside dans le fait qu’il est assez coûteux d’adapter une application 500 LoC à de nouvelles contraintes de langage. Par exemple, si les génériques n’ont pas été implémentés avec effacement de type etList list = new List(); ne pas compiler des millions de lignes de code aurait besoin d'être réécrit - ce qui coûte très cher.

D'autre part, PHP a tendance à être utilisé sur le Web pour des applications plus simples. il est généralement développé par un seul programmeur ou une petite équipe. L'idée est que les développeurs connaissent assez bien l'ensemble du projet et peuvent intégrer plus facilement les changements de langue. En outre, son objectif est de créer un site très rapidement, et le plus rapide sera le mieux. Ainsi, si une nouvelle fonctionnalité linguistique peut le faire mieux, elle est mise en œuvre même à des coûts de compatibilité en amont.

On peut affirmer que Microsoft a opéré un changement similaire avec ASP.NET (en tant que successeur d’ASP classique) ou avec VB.NET (bien qu’ils aient fait tellement de concessions avec ce dernier que la plupart des avantages du "redémarrage" du langage ont été perdus).

Quoi qu'il en soit, si quelqu'un se souvient du cauchemar de la migration du code VB6 vers VB.NET, même à l'aide d'un outil de migration, il conviendra immédiatement que les outils de migration de langue ne fonctionnent pas très bien pour les mises à jour linguistiques majeures.

Il est peut-être possible de faire avancer la plate-forme, mais vous devez tout de même fournir une prise en charge pour les API "obsolètes" via au moins quelques révisions.

Un grand nombre des "défauts" dont parlent beaucoup les gens dans les langages de programmation populaires ne sont pas, ce sont les choses que le jouet préféré du crieur du jour a pour défaut de langage, DONC ce langage est fondamentalement imparfait parce qu'il manque de cela.
Le prochain battage médiatique vient, la langue est soudainement imparfaite car elle n’adhère pas à ce battage médiatique.

Le manque de fermetures en Java est un exemple classique. Ce n'est pas du tout un défaut de langage, et changer de langage (comme c'est tristement à l'ordre du jour) pour les inclure risque de le paralyser ou, à tout le moins, de le rendre beaucoup plus difficile à lire et à comprendre.

Ce que trop de gens perdent de vue, c’est que chaque langue a ses forces et ses faiblesses et que tenter de créer quelque chose qui allie les forces de tout en évitant toute faiblesse ne fera que créer un monstre totalement inutilisable, qui est bon à rien, incroyablement infranchissable, impossible à utiliser efficacement.

Ajoutez, comme d'autres l'ont fait remarquer, la compatibilité ascendante est essentielle pour conserver les utilisateurs existants, dont beaucoup ne dépenseront PAS des milliers d'heures et des millions de dollars / euros pour adapter leurs millions de bases de code de ligne à tout ce qui vous semble "meilleur". que la version du langage qu’ils utilisent depuis des années, et vous avez toute une série de très bons arguments pour rester en retrait et si vous voulez jouer avec une nouvelle idée sur-typée qui est censée être le prochain "tueur de java" que vous " Il est préférable de jouer avec ce jouet plutôt que de crier que "Java is", à moins qu’il "soit réparé", soit un clone de ce jouet.

Je suggérerais que les versions les plus récentes d’un langage s’efforcent de s’assurer que 99,99999% du code compilé à la fois dans l’ancienne et la nouvelle version du langage fonctionne de manière identique dans les deux à moins qu’il ne soit délibérément conçu pour ne pas le faire, et que la plupart du temps lorsque la nouvelle version refuse le code compilé sous l'ancienne version, ce sera parce que le code était - au mieux - louche, et aurait dû être écrit d'une manière différente qui compilerait à la fois avec l'ancien et le nouveau compilateur.

Par exemple, si je concevais un nouveau langage similaire à Java ou C #, j'interdirais les conversions de type implicite dans certains contextes où ces langages le permettent. Comme exemple simple en C #, étant donné

int someInt;
double someDouble;

il someInt.Equals(someDouble)est garanti que l'expression renvoie false, quel que soit le contenu des variables. Il compile car doublepeut être converti en Objectet inta une Equalssurcharge pour ce type, de sorte que le compilateur effectue la conversion et effectue l'appel. Si je concevais une nouvelle version de C # et du .NET Framework, je l’aurais interdire la conversion de la boxe, car il ne pourrait rien faire d’utile. Il est possible qu'un programme effectue une telle comparaison d'une manière inutile mais inoffensive. Si le compilateur rejette ce code, ce programme serait brisé, mais la correction ou la suppression de ce code inutile constituerait une amélioration.

Comme exemple légèrement moins clair, supposons que

float f=16777216f;
int i=16777217;

et considérez l'expression f==i. Il est possible que certains code fait des comparaisons float / entier et fonctionne correctement, mais le code doit être réécrite comme soit f==(float)i, (double)f==i;ou (double)f==(double)i;[ intà la doublepromotion est sans perte, de sorte que les deux derniers équivaudrait]. Une partie du code qui compare directement floatet les integervaleurs peuvent toujours faire face à des nombres qui sont suffisamment petites pour que floatet les doublecomparaisons se comporter de manière identique, mais un compilateur ne peuvent généralement pas savoir; le code devrait indiquer clairement le type de comparaison nécessaire plutôt que d'espérer que les règles du langage correspondent à l'intention du programmeur.

Il est préférable de ne jamais casser la compatibilité en arrière.

Microsoft a remplacé le langage de programmation VB6 par un nouveau langage totalement incompatible avec la compatibilité. Ainsi, même aujourd'hui, le VB6, âgé de 16 ans, est toujours plus populaire que la version dotNet (indice Tiobe, août 2014). Et Gartner estime que 14 milliards de lignes de code VB6 sont encore utilisées.

En 2014, Microsoft a de nouveau dû annoncer qu'il ne mettrait pas à jour VB6, même s'il était à la demande de la communauté de programmation Visual Basic. Mais ils ont étendu la prise en charge de VB6 jusqu’au «au moins» 2024, et cela fonctionne très bien sous Windows 7 et 8. Ce sera plus de 26 ans de support pour la même version de VB6.

Pourquoi les logiciels existants devraient-ils être réécrits, même Microsoft n'a jamais "mis à jour" Office pour utiliser dotNet?

La compatibilité avec les versions antérieures pose quelques problèmes différents. Certains des problèmes proviennent du fait que la plupart des langages de programmation sont également des plates-formes (interprètes / runtimes), d'autres problèmes proviennent d'une hypothèse de la nature humaine.

A. Le code écrit dans des versions plus anciennes ne bénéficierait pas des nouvelles versions améliorant les performances, la sécurité ou les fonctionnalités. Vous pouvez atténuer ce problème en prenant en charge plusieurs versions principales du compilateur / interprète, mais il s’agit d’un énorme gaspillage de ressources (c’est-à-dire qu’il est coûteux ou prend beaucoup de temps et qu’il est pénible).

B. Le code écrit pour les versions plus récentes peut ne pas être compatible avec le code écrit dans les versions plus anciennes. Vous pouvez contourner ce problème en ayant un interprète / compilateur capable de gérer plusieurs versions majeures du langage, mais cela est plus pénible que de prendre en charge des interprètes / compilateurs séparés (la solution de contournement pour A).

C. Les changements majeurs, s’ils se produisent trop souvent / rapidement, rendent également le langage plus difficile à utiliser, car vous avez plus à apprendre et à désapprendre. Les modifications apportées à une langue peuvent pousser les utilisateurs à changer de langue ou les inciter à continuer à utiliser des versions obsolètes de la langue et à ne jamais basculer vers la nouvelle version (comme ce fut le cas avec python). Là encore, les changements peuvent également attirer de nouveaux utilisateurs et exciter les anciens.

D. La nouvelle documentation doit être conservée et maintenue. C'est toujours une expérience assez déroutante de rechercher des éléments sur Google et de constater que vous lisez les documents pour une version différente de celle que vous utilisez actuellement.

Globalement, si vous créez un langage de programmation dans lequel les modules externes ne doivent pas se soucier de la version que vous utilisez, il est presque certainement correct de rétablir la compatibilité avec les versions antérieures pour les bonnes raisons (pour corriger les principaux défauts du langage). . Il est probable que la principale raison pour laquelle cela ne soit pas fait est que les concepteurs de langages de programmation surestiment ( pour contredire la réponse de quelqu'un d'autre ) les coûts de la rupture de la compatibilité, en particulier à un stade précoce. En réalité, les problèmes de rupture de compatibilité peuvent être contournés ou alimentés par les utilisateurs de cette langue. Et cela ne concerne pas uniquement les langages de programmation; cela s'applique aux API, aux interfaces utilisateur - vraiment n'importe quelle interface dans n'importe quelle situation.

Facebook agace énormément les gens lorsqu'il modifie son interface utilisateur ou ses API de développeur. Dans le passé, il était difficile de travailler avec la plate-forme. Dans certains cas, les API ont tout simplement cessé de fonctionner à l'improviste. Mais les gens ont continué à l'utiliser, et maintenant les API et les interfaces utilisateur sont plus performantes qu'elles ne l'étaient il y a 5 ans. Les gens vont se plaindre du changement, que ce soit bon ou mauvais pour eux, mais ce n'est pas une bonne raison de renoncer à ce changement. Malheureusement, les développeurs de langages de programmation utilisent cette raison pour préserver les problèmes de leur langage.

Voici donc deux autres raisons pour lesquelles les langues ne font pas de changements radicaux pour s’améliorer:

E. Les développeurs de langues pensent que la peur du changement de leurs utilisateurs est une bonne raison de stagner leur langue

F. Les développeurs de langage ont un peu aimé leur langage quand ils l’ont créé, et ils pensent probablement que c’est parfait avec ses défauts.

G. En vieillissant, les langues cessent généralement d'avoir un petit groupe de développeurs et se transforment en bêtes construites par des comités. Cela signifie que les décisions concernant ces langues sont lentes et souvent conservatrices et peu créatives.

H. La dernière raison est que certains changements radicaux nécessitent une réévaluation importante des décisions de conception prises pour l’interprète / runtime. Parfois, les améliorations linguistiques nécessitent simplement trop de travail pour être réalisables. Je suppose que c'est un problème plus rare que la plupart des autres.

Souvent, les concepteurs de langage ne sont pas nécessairement des concepteurs d’outils. Ils ne pensent donc pas à une bonne solution à ce problème ou ne l’exécutent pas bien. Voici quelques solutions auxquelles je peux penser pour résoudre le problème des changements radicaux:

1. Observez les choses bien avant leur retrait.

2. Fournissez un bon outil de conversion standard. Python a fourni l’outil 2to3, mais il n’a pas été bien annoncé, n’a pas été livré en standard avec python 3, si je me souviens bien, et n’a même pas très bien fonctionné (je me souviens d’avoir dû parcourir manuellement les programmes générés par 2to3 pour résoudre les problèmes n'a pas réparé). Cet outil de conversion pourrait même être exécuté automatiquement si votre compilateur / interprète détecte une version plus ancienne. Quoi de plus facile?

Je ne sais pas si cela pose un problème pour le code PHP, mais dans de nombreuses langues, le code hérité n’est jamais mis à jour après des années ou, parfois, même pendant des décennies, car il fonctionne, il est trop important pour le faire fonctionner (disons millions de SLOC), il n’aurait donc aucun sens de le réécrire. C’est une des raisons pour lesquelles java a fait de la compatibilité avec le passé une question presque religieuse, malgré les problèmes connus, notamment dans les bibliothèques (même s’il est plus facile de les mettre à jour). Je suppose que beaucoup de code du noyau Linux n’a pas été mis à jour pendant des décennies, malgré l’adoption de normes comme C99 et C11.

Même dans les langues les moins "professionnelles", casser le code ancien et fonctionnel peut poser problème. C’est ce qui s’est passé avec Python 2 -> 3. Tout un tas de bibliothèques et de scripts système étaient stables et ne sont plus maintenus, non pas parce qu’ils ont été abandonnés, mais parce qu’ils étaient stables et faisaient leur travail. Les adapter prend quelques années. En tant que développeur, vous ne pouvez donc pas nécessairement accéder à python 3 si votre bibliothèque préférée n’a pas encore été déplacée. Par conséquent, votre propre code ne fonctionnera pas non plus sous python 3, ce qui entraînera une fragmentation de la communauté.

Le problème réside dans le problème de la compatibilité ascendante. La plupart des scripts PHP que j'exécute sont exécutés sur un ancien serveur RedHat. Si je devais utiliser la version la plus récente du langage pour les futurs scripts, je devrais alors mettre à jour PHP sur ce serveur - et risquer ainsi de voir mes anciens scripts brisés / prendre des heures pour réécrire tout l'ancien code avec le nouvelle norme. De plus, tous mes développeurs sont habitués à ce que PHP réagisse d'une certaine manière (qu'elle soit "cassée" ou non). S'il ne réagit plus de la sorte, cela pourrait constituer un obstacle majeur à la productivité, car les développeurs devront peut-être se réapprendre à utiliser PHP.