Gardez un langage de programmation rétrocompatible par rapport à la correction de ses défauts
Tout d'abord, un peu de contexte (des choses 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. La publication d'une nouvelle version rend de nouvelles API disponibles, corrige des bugs, ajoute de nouvelles fonctionnalités, de nouveaux frameworks etc. Donc, dans l'ensemble: c'est bien.
Mais qu'en est-il des problèmes de langue (ou de plate-forme)? Si et quand quelque chose 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 langues reçoivent beaucoup de commentaires des programmeurs qui les utilisent. Il est donc logique que le temps (et les numéros de version) passent, les problèmes dans ces langues disparaîtront lentement mais sûrement. Eh bien pas vraiment. Pourquoi? Rétrocompatibilité, c'est pourquoi. Mais pourquoi en est-il ainsi? Lisez ci-dessous pour une situation plus concrète.
La meilleure façon 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. Consultez cet article de blog . Il a une très longue liste de soi-disant défauts en PHP. Maintenant, je ne suis pas un développeur PHP (pas encore), mais j'ai lu tout cela et je suis sûr que une grande partie de cette liste sont en effet de vrais problèmes (pas tous, car c'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. Cependant, si je le fais, le code qui s'appuie sur un comportement particulier du langage se cassera s'il s'exécute sur la nouvelle version. En résumé en 2 mots: compatibilité descendante.
Ce que je ne comprends pas, c'est: pourquoi devrais-je conserver PHP rétrocompatible? Si je publie PHP version 8 avec tous ces problèmes résolus, ne puis-je pas juste mettre un gros avertissement dessus en disant: "Ne pas exécuter l'ancien code sur cette version!"?
Il y a une chose appelée dépréciation. Nous l'avons depuis des années et cela fonctionne. Dans le contexte de PHP: regardez comment de nos jours les gens découragent activement l'utilisation du mysql_* fonctions (et recommande plutôt mysqli_* et AOP). La dépréciation fonctionne. Nous pouvons l'utiliser. Nous devons l'utiliser. Si cela fonctionne pour les fonctions, pourquoi ne devrait-il pas fonctionner pour des langues entières?
Disons que je (le développeur de PHP) fais ceci:
- Lancez 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 continue de publier des mises à jour, corrigeant des problèmes de sécurité, des bugs, etc. Cela a du sens pour des raisons que je ne répertorie pas ici. C'est une pratique courante: regardez par exemple comment Oracle a continué à mettre à jour la version 5.1.x de MySQL, même si elle s'est principalement concentrée sur la version 5.5.x.
- Après environ 3 ou 4 ans, j'arrête de mettre à jour les anciennes versions de PHP et je les laisse mourir. C'est très bien, car pendant ces 3 ou 4 ans, la plupart des projets seront passés à PHP 8 de toute façon.
Ma question est: Toutes ces étapes ont-elles un sens? Serait-ce si difficile à faire? Si cela peut être fait, alors pourquoi ne l'est-il pas?
Oui, l'inconvénient est que vous brisez la compatibilité descendante. Mais n'est-ce pas un prix à payer? Par contre, dans 3 ou 4 ans, vous aurez une langue qui a 90% de ses problèmes résolus .... une langue beaucoup plus agréable à travailler. Son nom assurera sa popularité.
[~ # ~] modifier [~ # ~] : OK, donc je ne me suis pas exprimé correctement quand j'ai dit que dans 3 ou 4 ans, les gens passera à l'hypothèse PHP 8. Ce que je voulais dire était: dans 3 ou 4 ans, les gens utiliseront PHP 8 s'ils démarrent un nouveau projet).
Cela semble bien, mais fonctionne rarement dans la pratique; les gens sont extrêmement réticents à changer le code en cours d'exécution, et même pour de nouveaux projets en vert, ils sont très réticents à changer de langue/version qu'ils connaissent déjà.
Changer le code existant et en cours d'exécution qui "fonctionne bien" n'est pas quelque chose qui occupe une place de choix dans la liste des priorités d'un projet. Plutôt que d'appliquer des efforts à des choses que les responsables pensaient déjà payées, juste pour pouvoir passer à une version plus récente d'un langage ou d'une plate-forme, ils décriront que les développeurs devraient simplement rester sur l'ancienne version "pour l'instant". Vous pouvez essayer d'attirer vos utilisateurs avec de superbes fonctionnalités uniquement disponibles dans la nouvelle version, mais c'est un pari où vous risquez de diminuer votre base d'utilisateurs sans gain clair pour la langue; les fonctionnalités cool et modernes ne peuvent pas facilement être comparées au prix d'une base d'installation fragmentée dans l'opinion populaire, et vous courez le risque d'avoir la réputation d'être un "tapis roulant de mise à niveau" qui nécessite un effort constant pour continuer à fonctionner par rapport à des langues/plates-formes plus détendues .
(Évidemment, la plupart de cela ne s'applique pas aux projets écrits par des amateurs juste pour leur propre plaisir. Cependant (ici, être des appâts enflammés ...) PHP est disproportionnellement rarement choisi par les pirates parce que c'est un tel plaisir d'écrire avec en premier lieu.)
Vous sous-estimez l'impact de la rétrocompatibilité; votre estimation que tous les projets actifs migreraient dans 3 ou 4 ans est beaucoup trop optimiste.
Supposons que je suis un développeur PHP. PHP a des défauts, mais je sais comment contourner ces défauts - c'est une des raisons pour lesquelles je suis payé en tant que PHP développeur. Supposons maintenant que PHP 8 sort et corrige ces défauts, mais il n'est pas rétrocompatible. En conséquence:
- Je dois passer du temps à mettre à jour mon code pour PHP 8. C'est le temps que je pourrais passer à répondre aux demandes des clients, à mettre en œuvre de nouvelles fonctionnalités, à suivre la concurrence.
- Même après avoir fait cela , il y a de fortes chances que j'ai raté un cas de coin ou un problème de compatibilité imprévu, introduisant des bogues dans mon code.
Compte tenu de cela, il y a une forte incitation à ne jamais migrer vers PHP 8, même si c'est "mieux, plus clair, plus sûr, etc. "On estime qu'il existe encore des milliards de lignes de COBOL (!) - même s'il existe évidemment de bien meilleures technologies disponibles, le coût d'une mise à jour, combiné au risque de bugs, ne vaut pas la peine il.
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 a été publié en décembre 2008, mais Django (probablement le principal Python framework web) didn ')) Je n'ai pas de support stable, prêt pour la production Python 3 pendant presque 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 consacrer des efforts importants à changer. Pour les langages open source, les gens vont simplement fourcher l'ancienne version.
Regardez python pour un exemple. 3.x est disponible depuis quatre ans, et n'est toujours pas largement adopté. Les gens essaient de l'utiliser pour de nouveaux projets, mais je pense que vous êtes sous-estimer la quantité de travail de code nécessaire à la maintenance.
Bien sûr, la plupart des gens ne considéraient pas python 2.x comme "imparfait". Ils n'avaient pas de plaintes comme les utilisateurs de php. Php est dans une position beaucoup plus précaire, car beaucoup des gens ne s'en tiennent qu'à lui en raison de sa grande base de code existante. Si vous perdiez la compatibilité descendante, beaucoup de gens saisiraient l'occasion qu'ils attendaient pour passer à python.
Pour tout langage autre que PHP je dirais, oui, cela est absolument logique! C'est exactement ce que Python fait avec le commutateur Python 3.
Cependant, le problème avec PHP est qu'il y a trop de défauts dans la conception du langage lui-même, donc ce que vous appelez "PHP 8" serait un langage complètement différent. Et si vous devez passer à un langage différent, pourquoi voudriez-vous vous en tenir à un nouveau PHP, plutôt qu'à l'une des alternatives actuellement existantes et stables?
Aussi PHP est extrêmement lente à adapter quelque chose de nouveau. Regardez simplement combien de temps il a fallu pour se débarrasser de register_globals. Il est connu pour être un risque pour la sécurité depuis l'an 2000. Il n'a été finalement 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 une quantité significative de changements incompatibles en arrière.
Avertissement: je gère un groupe d'utilisateurs ColdFusion.
ColdFusion souffre des mêmes problèmes: aimé par beaucoup, méprisé par beaucoup. De plus, des tonnes et des tonnes de FUD basées sur des versions pré-Java. ColdFusion 10 est 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. En outre, il existe deux principales alternatives open source, dont une est soutenue par JBoss.
Il y a des TONNES de nouvelles fonctions dans CF10 que j'aimerais implémenter, mais la migration depuis CF 7 ou 8 peut être difficile en fonction de la taille de votre base de code, du nombre de projets à venir et des ressources dont vous disposez pour régresser tout tester une fois que vous suis sur la dernière version. J'ai rencontré un certain nombre de différences syntaxiques mineures entre 8 et 9, ainsi que des cas Edge où le code ne compile pas de la même manière. Une fois trouvés, je les ai documentés dans nos normes de codage afin qu'ils ne soient pas utilisés dans de futurs projets ou par de nouveaux développeurs.
Cela dit, si ColdFusion 11 (ou tout autre langage de programmation) devait complètement déprécier certaines fonctions et syntaxe, 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, QA et chefs de projet pour trouver, remplacer et tester toutes ces choses obsolètes? Douteux.
Si la dernière version d'une langue est rétrocompatible, mais introduit une amélioration des performances sans changement de code (CF9 est environ 30% plus rapide que CF8 et CF10 est beaucoup plus rapide que CF9), qui se soucie de changer les appels de fonction s'ils fonctionnent toujours?
En tant qu'entreprise, nous devons nous soucier de plaire à nos clients et de répondre à leurs besoins afin de facturer les services, de développer l'entreprise et de recruter plus de clients.
FWIW, je serais ravi de nous familiariser avec la dernière version de jQuery à un moment donné, mais comme certaines fonctions ont été déconseillées quelques versions après ce que nous utilisons, et compte tenu du 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 modifiées sans casser le code de quelqu'un quelque part. Il me semble me rappeler que quelqu'un a déclaré en tant que "règle" que chaque correction de bogue briserait le projet de quelqu'un, peu importe à quel point le bogue est obscur ou manifestement brisé, 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. Comme principe général:
- Les versions majeures sont supposées contenir des changements de rupture.
- Les versions mineures peuvent modifier légèrement le comportement.
- Les révisions devraient être à peu près compatibles entre elles.
Par exemple, si j'écris quelque chose dans la v2.3 d'une langue, je ne m'attendrais pas à remarquer de différence si je passe à la v2.3.2. Si je mets à niveau vers la v2.4, alors certaines choses pourraient changer - petits ajustements de syntaxe, certaines fonctions se comportent un peu différemment, donc je dois modifier la logique, etc. Si je mets à niveau vers la v3.0, je ne serais pas surpris s'il se cassait entièrement - fonctions obsolètes ou manquantes, opérations non prises en charge ou modifiées à tel point que je ne peux pas simplement le modifier en ligne, je dois en fait réécrire certaines fonctions pour tenir compte des nouvelles modifications.
Éditer:
L'article de Steve Vance Advanced SCM Branching Strategies a ceci à dire:
En règle générale, il existe deux à trois niveaux de publication, nommés par des nombres 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 qu'il présente des améliorations significatives en termes de fonctionnalités et de fonctionnalités par rapport à la précédente; il peut également y avoir des incompatibilités importantes qui nécessitent une migration. Le deuxième nombre représente une version mineure, qui contient des améliorations de fonctionnalités et de fonctions moindres, un nombre important de corrections de bogues et aucune incompatibilité. Le troisième chiffre fait référence à un niveau de correctif, ce qui signifie presque exclusivement une collection de corrections de bogues; aucune fonctionnalité ou amélioration de fonction et aucune incompatibilité ne sont autorisées entre les niveaux de patch.
La seule modification que j'apporterais à cela est le principe susmentionné selon lequel les programmeurs trouvent souvent des moyens "d'utiliser" les bogues, donc une version mineure avec "un nombre important de corrections de bogues et aucune incompatibilité" pourrait être difficile, car il est probable que ceux-ci les bogues vont soit casser quelque chose qui les a utilisés, soit rendre une solution de contournement inutile et commencer à causer des problèmes.
Cela dépend vraiment de ce qui est la cible de la langue - quels types d'applications sont destinés à être construits avec la par la langue.
Par exemple, en ignorant Android, Java est principalement utilisé dans les grands systèmes et middleware d'entreprise; ces types d'applications ont tendance à devenir très volumineux à la fois en taille et en temps. Cela a certaines implications; imaginez un système avec 500K + LoC sur lequel plus de 50 ingénieurs travaillent dans la phase de développement. Généralement, ce type de système entre en maintenance après cela avec, disons, 10 développeurs; maintenant, si le langage change et les changements ne sont pas rétrocompatibles, le projet ne peut pas être facilement migré vers une nouvelle version parce que les programmeurs qui ont écrit certaines parties ont disparu et que personne ne veut y toucher. C'est le plus petit problème, 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'étaient pas implémentés avec l'effacement de type et que List list = new List(); ne compilerait pas des millions de lignes de code, il faudrait les réécrire - ce qui est très coûteux.
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 en quelque sorte l'ensemble du projet assez bien peut intégrer plus facilement les changements de langue. Son but est également de construire un site très rapidement, et le plus vite sera le mieux donc si une nouvelle fonctionnalité de langue peut mieux faire cela, alors elle est implémentée même à des coûts de compatibilité descendante.
Il y a quelques problèmes différents avec la rupture de la compatibilité descendante. Certains problèmes proviennent du fait que la plupart des langages de programmation sont également des plates-formes (interprètes/runtimes), d'autres problèmes découlent d'une hypothèse de la nature humaine.
R. Le code écrit dans une ancienne version ne bénéficierait pas des nouvelles versions qui améliorent 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 cela représente un énorme drain de ressources (c'est-à-dire qu'il est coûteux ou prend beaucoup de temps et est une douleur dans le cul).
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 cela en ayant un interprète/compilateur qui peut gérer plusieurs versions principales 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 la langue plus difficile à utiliser, car vous avez plus à apprendre et à désapprendre. Les modifications apportées à une langue peuvent pousser les gens à travers Edge pour passer à une nouvelle langue, ou peuvent inciter les gens à continuer à utiliser des versions obsolètes de la langue et à ne jamais passer à la nouvelle version (comme cela s'est produit 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 tenue à jour. C'est toujours une expérience assez déroutante de rechercher des choses sur Google et de découvrir que vous lisez les documents pour une version différente de celle que vous utilisez actuellement.
En gros, si vous créez un langage de programmation où les modules externes n'ont pas à se soucier de la version que vous utilisez, rompre la compatibilité descendante pour les bonnes raisons (pour corriger les défauts majeurs du langage) est presque certainement la bonne chose à faire . Il est probable que la principale raison pour laquelle cela n'est pas fait est que les concepteurs de langage de programmation surestiment ( pour contredire la réponse de quelqu'un d'autre ) les coûts de rupture de la compatibilité, surtout au début. Le fait est que les problèmes de rupture de compatibilité peuvent être contournés ou résolus par les utilisateurs de cette langue. Et cela ne vaut pas seulement pour les langages de programmation; cela s'applique aux API, aux interfaces utilisateur - vraiment n'importe quelle interface dans n'importe quelle situation.
Facebook ennuie les gens quand il change son interface utilisateur ou ses API de développeur. Dans le passé, cela rendait la plateforme difficile à utiliser. 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 bien meilleures qu'elles ne l'étaient il y a 5 ans. Les gens se plaindront du changement, que ce soit bon ou mauvais pour eux, mais (se plaindre) n'est pas une bonne raison de renoncer à ce changement. Malheureusement, les développeurs de langage de programmation utilisent cela comme une raison pour garder les problèmes de leur langage intacts.
Donc, quelques autres raisons pour lesquelles les langues ne font pas de changements de rupture pour s'améliorer sont:
E. Les développeurs de langues pensent que leurs utilisateurs craignent le changement est une bonne raison de stagner leur langue
F. Les développeurs de langage aimaient en quelque sorte leur langue lorsqu'ils l'ont fait, et ils pensent probablement que c'est très bien avec ses défauts.
G. Les langues en vieillissant cessent généralement d'avoir un petit noyau de développeurs et se transforment en bêtes plus construites en comité. Cela signifie que les décisions concernant ces langues sont lentes et souvent conservatrices et non créatives.
H. La dernière raison est que certains changements de rupture nécessitent une réévaluation importante des décisions de conception prises pour l'interpréteur/runtime. Parfois, les améliorations de la langue 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, et donc ils ne pensent pas à de bonnes solutions à ce problème, ou ils ne les exécutent pas bien. Voici quelques solutions auxquelles je peux penser pour résoudre le problème des changements de rupture:
Dépréciez les choses bien avant leur retrait.
Fournissez un bon , outil de conversion standard. Python a fourni l'outil 2to3, mais il n'a pas été bien annoncé, n'est pas venu en standard avec python 3 si je me souviens bien, et n'a même pas fonctionné très bien (je me souviens avoir dû parcourir manuellement les programmes générés par 2to3 pour résoudre les problèmes qu'il n'a pas corrigés). 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 simple?
Il est préférable de ne jamais briser la compatibilité descendante.
Microsoft a remplacé le langage de programmation VB6 par un nouveau langage qui a totalement rompu la compatibilité. Ainsi, même aujourd'hui, le VB6 de 16 ans est toujours plus populaire que la version dotNet (indice Tiobe août 2014). Et Gartner estime qu'il y a encore 14 milliards de lignes de code VB6 en cours d'utilisation.
En 2014, Microsoft a de nouveau dû annoncer qu'il ne mettra pas à jour ou n'ouvrira pas le VB6 open source malgré les demandes de la communauté de programmation Visual Basic. Mais ils ont étendu la prise en charge de VB6 jusqu'en 'au moins' 2024, et cela fonctionne très bien sur 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?
On peut soutenir que Microsoft a effectué un changement similaire avec ASP.NET (en tant que successeur de l'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" de la langue 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 avec l'aide d'un outil de migration, il conviendra tout de suite que les outils de migration linguistique ne fonctionnent pas très bien pour les mises à jour linguistiques majeures.
Il peut être possible de faire avancer la plate-forme, mais vous devez toujours fournir une prise en charge des API "obsolètes" à travers au moins quelques révisions.
Je suggérerais que les nouvelles versions d'un langage devraient s'efforcer de garantir que 99,99999% du code qui se compile à la fois dans l'ancienne et la nouvelle version du langage devrait fonctionner de manière identique dans les deux, sauf s'il est 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 - douteux, et aurait dû être écrit d'une manière différente qui se compilerait sous l'ancien et le nouveau compilateur.
Par exemple, si je concevais un nouveau langage similaire à Java ou C #, j'interdirais les conversions de types implicites dans certains contextes où ces langages les autorisent. Comme exemple simple en C #, étant donné
int someInt;
double someDouble;
l'expression someInt.Equals(someDouble) est garantie de retourner false, quel que soit le contenu des variables. Il compile parce que double peut être converti en Object, et int a une surcharge Equals pour ce type, donc le compilateur fait la conversion et fait l'appel . Si je concevais une nouvelle version de C # et du .NET Framework, je lui interdirais la conversion de boxe car elle ne peut rien faire d'utile. Il est possible qu'il existe un programme qui effectue une telle comparaison d'une manière qui est inutile mais inoffensive, et le fait que le compilateur rejette un tel code pourrait casser ce programme, mais corriger ou supprimer un tel code inutile serait une amélioration.
À titre d'exemple un peu moins clair, supposons
float f=16777216f;
int i=16777217;
et considérez l'expression f==i. Il est possible qu'un code effectue des comparaisons flottantes/entières et fonctionne correctement, mais le code doit être réécrit sous la forme f==(float)i, (double)f==i; Ou (double)f==(double)i; [int à double la promotion est sans perte, donc les deux derniers seraient équivalents]. Un code qui compare directement les valeurs de float et integer peut toujours traiter des nombres suffisamment petits pour que les comparaisons float et double se comportent de manière identique, mais un compilateur ne peuvent généralement pas le savoir; le code devrait indiquer clairement quel type de comparaison est nécessaire, plutôt que d'espérer que les règles du langage correspondront à l'intention du programmeur.
Beaucoup de "défauts" que les gens crient dans les langages de programmation populaires ne le sont pas, ce sont les choses que le jouet préféré du crieur du jour a que ce langage manque, PAR CONSÉQUENT, ce langage est fondamentalement défectueux parce qu'il en manque.
Le battage médiatique suivant arrive, la langue est soudainement défectueuse parce qu'elle n'adhère pas à ce battage médiatique.
L'absence de fermetures dans Java est un exemple classique. Ce n'est pas du tout une faille dans la langue, et changer la langue (comme c'est malheureusement à l'ordre du jour) pour les inclure L'OMI la paralysera-t-elle fondamentalement ou du moins la rendra-t-elle 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 qu'essayer de créer quelque chose qui combine les forces de tout en évitant chaque faiblesse ne fera que créer un monstre totalement inutilisable et bon à rien, incroyablement maniable, impossible à utiliser efficacement.
Ajoutez, comme d'autres l'ont souligné, que la rétrocompatibilité est vitale 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 que vous pense que c'est "mieux" que la version du langage qu'ils utilisent depuis des années, et vous avez une multitude de très bons arguments pour laisser assez bien tranquille et si vous voulez jouer avec une nouvelle idée sur-typée qui est censée être la prochaine " Java killer "vous feriez mieux de jouer avec ce jouet plutôt que de crier que" Java iz ded "à moins qu'il" ne soit réparé "pour être un clone de ce jouet.
Je ne sais pas si c'est un problème pour le code PHP, mais dans de nombreuses langues anciennes, le code hérité n'est jamais mis à jour après des années ou, parfois, même des décennies, car il fonctionne, est essentiel pour l'entreprise qui l'exécute et est trop grand (disons des millions de SLOC), il ne serait donc pas logique de le réécrire. C'est une raison pour laquelle Java a fait de la compatibilité descendante un problème presque religieux, malgré les anciens problèmes connus, en particulier dans les bibliothèques (même s'ils sont plus faciles à mettre à jour). Je suppose que beaucoup de code du noyau Linux n'a pas été mis à jour depuis des décennies également, malgré l'adoption de normes comme C99 et C11.
Même dans les langages moins "professionnels", la rupture du vieux code fonctionnel peut être un problème. C'est ce qui s'est passé avec Python 2 -> 3. 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. Leur adaptation prend quelques années. Donc, en tant que développeur, vous ne pouvez pas nécessairement passer à python 3 si votre bibliothèque préférée n'a pas encore fait le déplacement, donc votre propre code ne fonctionnera pas non plus sous python 3, donc entraînant une fragmentation de la communauté.