[F] [mOved] Mon langage est mieux que le tien - Page 169

robinHood (./5039) :
sinon faire un vrai split, changer l'extension des scripts et la source des dépendances, tabula rasa

deux interpréteurs séparés, comme deux langages différents

Uther (./5038) :
Tout d'abord, avec un système d'édition, le fait qu'un programme ne soit pas migré n'est pas problématique. C'est juste les mainteneurs qui devront souffrir un fonctionnement daté, mais c'est leur propre choix, et ils ne l'imposeront pas aux autres. Par contre la séparation de l'écosystème pose de vrais problèmes : pour les développeurs qui veulent migrer mais ne le peuvent pas à cause des dépendances en amont ou en aval, et pour les utilisateurs finaux qui ont à gérer plusieurs versions de l'interpréteur en fonction du code a exécuter.

Ensuite, je reste persuadé que retirer la contrainte des dépendances aurait globalement accéléré la transition et non ralenti. Je sais que la comparaison est pas forcément pertinente sur tous les points, mais si on regarde la transition significative de l'édition 2015 à 2018 de Rust (la suivante était vraiment mineure), elle c'est faite très vite pour tous les projets maintenus, bien que ça n'aurait gêné personne si ça n'avait pas été le cas. En Python, les soucis de dépendances en cascade font que l'on avait encore des programmes significativement utilisés qui posaient problème des années après. Tu as cité le cas de Ansible, mais c'était loin d'être le seul.

Pour ce qui est de la complexité additionnelle pour l’interpréteur, je pense que ça aurait pu être être fait de manière tout à fait gérable, en tout cas si ça avait été pensé dans ce sens dès le début. Il ne s'agirait pas d'avoir deux interpréteurs très différents complétement séparés, mais une première couche qui convertit tout en une base commune tôt dans le processus d'analyse.

Là encore, la comparaison n'est peut-être pas vraiment valable, mais les développeurs du compilateur Rust sont assez d'accord pour dire qu'ils n’envisagent pas de retirer le support des vieilles éditions, même pas dans un futur éloigné vu que la complexité ajoutée par le système d'édition est vraiment minime. Le gros de la complexité du compilateur (système de type, analyse de la durée de vie des variable, optimisations, génération du binaire, ...) a lieu en aval.

Digital Guangdong, known as DigitalGD, published an apology last week after it was revealed that its CEC-IDE software application, which helps programmers write code, was based on Microsoft’s Visual Studio Code (VS Code), with just minor modifications and certain functions added.

VS Code is available under the Massachusetts Institute of Technology licence, a permissive open source licence allowing for reuse even for commercial purposes.

DigitalGD said this fact was not disclosed due to “negligence”, and admitted that its description of its software as “self-developed” has met scrutiny and doubt from Chinese programmers. “We are deeply sorry and humiliated for this, and relevant teams have been ordered to make rectifications,” the company said.

robinHood (./5042) :
carrément changer de nom et oublier 40 ans de renom, chaud ^^

flanker (./5041) :
Perl a exactement fait ça. Mais le langage est mort au passage…

flanker (./5041) :
Globalement, il n'y avait pas tellement de dépendances en cascade qui bloquaient, c'était quelques grosses dépendances (activement maintenues) et des dépendances non maintenues.

flanker (./5041) :
Sauf que ce n'est pas possible en pratique, le fonctionnement est bien trop différent. Dans beaucoup de cas, il est impossible de manipuler la même variable en Python2 et en Python3.

flanker (./5041) :
Et à nouveau, ça aurait supprimé une incitation à migrer.