Je suis au courant d'implémentations alternatives de Python (je les mentionne dans mon message ci-dessus), mais je conteste le fait qu'on puisse parler de standard multi-implémentation dans ce cas. Quand tu demandes au gens dans la communauté, la définition de Python c'est "ce que fait CPython". Tu n'as pas:
une masse critique qui utilise une autre implémentation que CPython pour lui assurer la longévité en pratique (à part peut-être Jython ?)
une tentative d'évolution de l'écosystème pour rendre la vie plus facile aux implémentations alternatives (tout le boulot sur une FFI efficace par exemple doit être tiré à bout de bras par Pypy et Pyston)
de discussion saine entre les différents implémentations sur comment faire évoluer le langage (comme c'est le cas pour Javascript ou C++ ou Ada par exemple)
ou même une façon raisonnable pour les implémentations alternatives de tester leur conformance comme "une implémentation de Python" (Java, Javascript...)
Pour moi pour pouvoir parler d'un standard, il faut une définition/description du langage qui soit assez précise pour servir de base à une implémentation (une implémentation n'est pas une description, c'est plutôt un seau de cambouis qui parfois fait des trucs), et que les différents acteurs font des efforts pour respecter. Ce n'est pas une question formelle de normalisation ISO/Oasis/machin (on vu avec ooxml que c'est ouvert aux abus et ça suffit pas), mais une question sociale de la façon dont fonctionne une communauté autour d'un langage. Python (ou Ruby, Perl) n'atteint pas ce niveau; c'est un langage défini par une seule implémentation, avec quelques implémentations alternatives qui courent derrière.
Et je trouve que mentionner IronPython enlève du poids à ton argument au lieu d'en ajouter. Sérieusement, connais-tu quelqu'un qui a utilisé IronPython pour de vrai, sans avoir été payé par Microsoft pour cela ?
Quand ils ont lancé .NET, Microsoft avait tout intérêt à montrer sa technologie et à donner l'image d'une plateforme ouverte aux langages qui ne sont pas sous son contrôle direct. Du coup ils ont fait le choix intelligent de financer le développement d'implémentations alternatives de langages à la mode, genre IronPython, ou un backend Scala qui a été mentionné pendant un temps (avant d'être abandonné parce que tout le monde s'en fichait et que ça faisait de la maintenance), etc. (Pour F# c'est différent, les chercheurs avaient envie de se faire plaisir en faisant du ML, ensuite ils ont eu l'idée de faire un clone de OCaml qui était utilisé en interne à MS sur des projets intéressants, et enfin l'équipe Caml leur a conseillé de partir sur un vrai langage à part entière, ce qui a très bien marché.)
Mais ces backends .NET de langages plus ou moins à la mode (IronPython, IronRuby, IronLisp->IronScheme...) étaient mort-nés: pas de vraie communauté derrière (en plus à l'époque MS ne savait pas vraiment faire du libre), des difficultés sur la compatibilité (pour Python, pas de vrai standard tout ça, trop de code C à porter) ou sur les performances (IronRuby: en fait une VM pensée pour des langages pas trop follement dynamiques a du mal à faire tourner le monkey-patching de façon efficace, etc.). Dans les années 2010, Microsoft a décidé de laisser tomber ces projets qui n'avaient jamais percé, et je ne crois pas qu'ils aient jamais eu une vraie adoption entre temps—les gens mettent du temps à migrer vers des implémentations alternatives, ça va souvent plus vite mais ça marche aussi parfois moins bien, et ça c'est grave.
[^] # Re: Merci pour cette annonce
Posté par gasche . En réponse à la dépêche Le compilateur GHC Haskell en version 8.0.1. Évalué à 3.
Je suis au courant d'implémentations alternatives de Python (je les mentionne dans mon message ci-dessus), mais je conteste le fait qu'on puisse parler de standard multi-implémentation dans ce cas. Quand tu demandes au gens dans la communauté, la définition de Python c'est "ce que fait CPython". Tu n'as pas:
Pour moi pour pouvoir parler d'un standard, il faut une définition/description du langage qui soit assez précise pour servir de base à une implémentation (une implémentation n'est pas une description, c'est plutôt un seau de cambouis qui parfois fait des trucs), et que les différents acteurs font des efforts pour respecter. Ce n'est pas une question formelle de normalisation ISO/Oasis/machin (on vu avec ooxml que c'est ouvert aux abus et ça suffit pas), mais une question sociale de la façon dont fonctionne une communauté autour d'un langage. Python (ou Ruby, Perl) n'atteint pas ce niveau; c'est un langage défini par une seule implémentation, avec quelques implémentations alternatives qui courent derrière.
Et je trouve que mentionner IronPython enlève du poids à ton argument au lieu d'en ajouter. Sérieusement, connais-tu quelqu'un qui a utilisé IronPython pour de vrai, sans avoir été payé par Microsoft pour cela ?
Quand ils ont lancé .NET, Microsoft avait tout intérêt à montrer sa technologie et à donner l'image d'une plateforme ouverte aux langages qui ne sont pas sous son contrôle direct. Du coup ils ont fait le choix intelligent de financer le développement d'implémentations alternatives de langages à la mode, genre IronPython, ou un backend Scala qui a été mentionné pendant un temps (avant d'être abandonné parce que tout le monde s'en fichait et que ça faisait de la maintenance), etc. (Pour F# c'est différent, les chercheurs avaient envie de se faire plaisir en faisant du ML, ensuite ils ont eu l'idée de faire un clone de OCaml qui était utilisé en interne à MS sur des projets intéressants, et enfin l'équipe Caml leur a conseillé de partir sur un vrai langage à part entière, ce qui a très bien marché.)
Mais ces backends .NET de langages plus ou moins à la mode (IronPython, IronRuby, IronLisp->IronScheme...) étaient mort-nés: pas de vraie communauté derrière (en plus à l'époque MS ne savait pas vraiment faire du libre), des difficultés sur la compatibilité (pour Python, pas de vrai standard tout ça, trop de code C à porter) ou sur les performances (IronRuby: en fait une VM pensée pour des langages pas trop follement dynamiques a du mal à faire tourner le monkey-patching de façon efficace, etc.). Dans les années 2010, Microsoft a décidé de laisser tomber ces projets qui n'avaient jamais percé, et je ne crois pas qu'ils aient jamais eu une vraie adoption entre temps—les gens mettent du temps à migrer vers des implémentations alternatives, ça va souvent plus vite mais ça marche aussi parfois moins bien, et ça c'est grave.