La différence entre Scala/Clojure et IronPython est que la JVM est leur environnement "natif" (de naissance): tout le monde les utilise sur ça. Pour IronPython, le runtime dotnet est un port alternatif, et il n'a pas beaucoup d'utilisateurs à ma connaissance. Dans l'absolu je suis prêt à acheter que les gens qui ont un soft sur .NET et qui veulent ajouter du scripting en python utiliseraient IronPython: ça semble raisonnable comme choix technique. Mais as-tu des exemples concrets d'adoption ? Pour aller dans ton sens, j'imagine que le fait que c'est le seul des Iron* encore maintenu après que Microsoft ait coupé les fonds est plutôt bon signe. Mais, encore une fois, pour moi il n'y aura un statut d'implémentation alternative "viable" quand quand les gens qui font évoluer le langage prendront en compte aussi les besoins et propositions d'IronPython. (Et à mon avis c'est plus près d'arriver pour Pypy, mais on verra). En tout cas ce n'est pas le cas aujourd'hui.
La grande majorité des langages réellement utilisés n'ont pas de norme associée à ma connaissance [..] Par contre, il existe des spécifications pour le langage et ce qui doit être considéré comme la bibliothèque standard associée.
Je suis d'accord, c'est ce que j'ai écrit dans mes messages précédents. Mais est-ce que la référence Python est assez complète pour implémenter une autre implémentation conforme en pratique ? Il me semble que la réponse est non à cause de la dépendance très forte de l'écosystème sur l'interface FFI de CPython, qui n'est pas spécifiée à ce niveau et qui est trop spécifique pour permettre des vraies différences d'implémentation. (Au contraire le travail sur la FFI du projet Pypy a vocation à être portable sur d'autres implémentations, il n'est pas Pypy-spécifique.)
La plupart de ces langages n'ont qu'une implémentation de référence.
Encore une fois, tout le monde est d'accord là-dessus. C'est pour ça que j'explique (dans mes messages ci-dessus) qu'il existe des langages vraiment multi-implémentations, mais que Haskell ne l'est plus aujourd'hui—Python ne l'a jamais été, mais ce n'est pas une critique,.
Notons que dans le cas de IronPython, comme c'est la VM de .Net qui est utilisée, l'implémentation n'est pas forcément mauvaise en termes de perf...
Ça c'est la théorie. En pratique les VMs pensées pour des langages statiques ont du mal à avoir de vraiment bonnes perfs pour des langages trop dynamiques comme Python ou Ruby (c'est pour ça que MS et Oracle investissent dans le Dynamic Language Runtime, Truffle etc., mais ça reste difficile d'être compétitif). En plus de ça, les programmes Python utilisés en pratique sont plombés par un grand nombre d'appel à C en utilisant une FFI spécifique à CPython et peu portable; dès que l'implémentation alternative, même si elle marche super bien sur du code "Python pur", a un coût de conversion important pour la FFI Cpython, les performances s'écroulent en pratique.
Par exemple, a-t-on des mesures de quelqu'un ayant récemment fait tourner Django sur IronPython ? Désolé de faire le casse-pieds, mais d'une part je ne suis même pas sûr que ça marche aujourd'hui (enfin s'il y a vraiment des utilisateurs de IronPython ça doit pouvoir se trouver), et d'autre part je m'attends à ce que les performances soient plutôt décevantes.
Ça n'enlève bien-sûr rien à la potentielle niche de gens voulant ajouter du scripting en Python à leur application .NET. Là les performances sont sans doute moins importantes, et la compatibilité avec les bibliothèques Python existantes non plus. Il n'empêche que je suis sceptique sur la viabilité du pojet à terme si c'est le seul public.
[^] # 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.
La différence entre Scala/Clojure et IronPython est que la JVM est leur environnement "natif" (de naissance): tout le monde les utilise sur ça. Pour IronPython, le runtime dotnet est un port alternatif, et il n'a pas beaucoup d'utilisateurs à ma connaissance. Dans l'absolu je suis prêt à acheter que les gens qui ont un soft sur .NET et qui veulent ajouter du scripting en python utiliseraient IronPython: ça semble raisonnable comme choix technique. Mais as-tu des exemples concrets d'adoption ? Pour aller dans ton sens, j'imagine que le fait que c'est le seul des Iron* encore maintenu après que Microsoft ait coupé les fonds est plutôt bon signe. Mais, encore une fois, pour moi il n'y aura un statut d'implémentation alternative "viable" quand quand les gens qui font évoluer le langage prendront en compte aussi les besoins et propositions d'IronPython. (Et à mon avis c'est plus près d'arriver pour Pypy, mais on verra). En tout cas ce n'est pas le cas aujourd'hui.
Je suis d'accord, c'est ce que j'ai écrit dans mes messages précédents. Mais est-ce que la référence Python est assez complète pour implémenter une autre implémentation conforme en pratique ? Il me semble que la réponse est non à cause de la dépendance très forte de l'écosystème sur l'interface FFI de CPython, qui n'est pas spécifiée à ce niveau et qui est trop spécifique pour permettre des vraies différences d'implémentation. (Au contraire le travail sur la FFI du projet Pypy a vocation à être portable sur d'autres implémentations, il n'est pas Pypy-spécifique.)
Encore une fois, tout le monde est d'accord là-dessus. C'est pour ça que j'explique (dans mes messages ci-dessus) qu'il existe des langages vraiment multi-implémentations, mais que Haskell ne l'est plus aujourd'hui—Python ne l'a jamais été, mais ce n'est pas une critique,.
Ça c'est la théorie. En pratique les VMs pensées pour des langages statiques ont du mal à avoir de vraiment bonnes perfs pour des langages trop dynamiques comme Python ou Ruby (c'est pour ça que MS et Oracle investissent dans le Dynamic Language Runtime, Truffle etc., mais ça reste difficile d'être compétitif). En plus de ça, les programmes Python utilisés en pratique sont plombés par un grand nombre d'appel à C en utilisant une FFI spécifique à CPython et peu portable; dès que l'implémentation alternative, même si elle marche super bien sur du code "Python pur", a un coût de conversion important pour la FFI Cpython, les performances s'écroulent en pratique.
Par exemple, a-t-on des mesures de quelqu'un ayant récemment fait tourner Django sur IronPython ? Désolé de faire le casse-pieds, mais d'une part je ne suis même pas sûr que ça marche aujourd'hui (enfin s'il y a vraiment des utilisateurs de IronPython ça doit pouvoir se trouver), et d'autre part je m'attends à ce que les performances soient plutôt décevantes.
Ça n'enlève bien-sûr rien à la potentielle niche de gens voulant ajouter du scripting en Python à leur application .NET. Là les performances sont sans doute moins importantes, et la compatibilité avec les bibliothèques Python existantes non plus. Il n'empêche que je suis sceptique sur la viabilité du pojet à terme si c'est le seul public.