Gardez un langage de programmation en arrière compatible par rapport à la fixation de ses défauts

Question

Tout d'abord, un contexte (des trucs 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é 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 les nouvelles API disponibles, corrige les bogues, 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 la langue (ou de la 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), soit ils 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, au fil du temps (et des numéros de version), les problèmes de ces langues disparaîtront lentement mais sûrement. Eh bien pas vraiment. Pourquoi? Compatibilité en arrière, c'est pourquoi. Mais pourquoi est-ce ainsi? Lisez ci-dessous pour une situation plus concrète.

---

La meilleure façon dont je peux 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. Vérifier Ce billet 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 qu'une grande partie de cette liste est en effet de vrais problèmes. (Pas tout, car c'est potentiellement subjectif).

Maintenant, si j'étais l'un des gars qui développe activement PHP, je voudrais sûrement résoudre ces problèmes, un par un. Cependant, si je fais cela, le code qui s'appuie sur un comportement particulier de la langue se cassera s'il s'exécute sur la nouvelle version. Le résumé en 2 mots: compatibilité en arrière.

Ce que je ne comprends pas, c'est: pourquoi devrais-je garder PHP en arrière compatible? Si je publie PHP version 8 avec tous ces problèmes résolus, je ne peux pas simplement mettre un grand avertissement en disant: "Ne pas exécuter le 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 ces jours-ci les gens découragent activement l'utilisation du mysql_* fonctions (et recommande plutôt mysqli_* et PDO). Les fonctionnalités de dépréciation. 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 fixes
• Les nouveaux projets commenceront à utiliser cette version, car c'est beaucoup mieux, plus clair, plus sécurisé, etc.
• Cependant, afin de ne pas abandonner les anciennes versions de PHP, je continue de publier des mises à jour, de résoudre les problèmes de sécurité, de bogues, etc. Cela est logique pour des raisons que je ne répertorie pas ici. C'est une pratique courante: examinez 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 d'anciennes versions de PHP et je les laisse mourir. C'est bien, car dans ces 3 ou 4 ans, la plupart des projets seront de toute façon passés à Php 8.

Ma question est: Toutes ces étapes ont-elles du sens? Serait-ce si difficile à faire? Si cela peut être fait, alors pourquoi n'est-ce pas fait?

Oui, l'inconvénient est que vous cassez la compatibilité en arrière. Mais n'est-ce pas un prix à payer? En hausse, en 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é.

ÉDITER: OK, donc je ne me suis pas exprimé correctement quand j'ai dit que dans 3 ou 4 ans, les gens passeront à l'hypothétique PHP 8. Ce que je voulais dire, c'était: dans 3 ou 4 ans, les gens utiliseront PHP 8 s'ils commencent un nouveau projet.