Oui, faut quand même dire que c'est plus performant que la majorité des interpréteurs Python...
De même, JRuby est notablement plus performant que les interpréteurs habituels Ruby MRI ou même YARV.
Les JVMs, et notamment HotSpot, sont très performantes, même si un certain nombre d'amateurs en informatique sont restés sur l'idée que Java n'a pas changé depuis 98 et est toujours aussi lent. Il y a eu une série d'optimisations hallucinantes qui en font sans aucun doute la VM *ouverte* et dont il existe une implémentation *libre* la plus performante.
Ce qui est lent avant tout, c'est le lancement de la JVM (toujours moins lent que le lancement de Ruby MRI ou PyPy), et il est négligeable car sur n'importe quelle machine qui utilise du Java de nos jours, on la lance au démarrage du système et elle se pose en mode serveur.
Le rejet par une grande part de la communauté libre du monde Java c'est un tir dans son propre pied. Je comprends les raisons : Sun a fait l'erreur de ne pas libérer son implémentation avant ce qui a complètement tué l'engouement pour la VM. Et le langage Java n'est pas sexy du tout, donc ça ne motive pas les libristes qui codent en bonne partie pour le fun. D'un autre côté,certaines communautés n'ont pas de problème avec le monde Java (notamment Apache).
Le problème, c'est qu'il n'y a rien en face :
Le C ? Oui, il est toujours là, il est performant mais le temps de développement est décuplé comparé à un langage de haut niveau (je parle pas particulièrement de Java). Alors il y aura bien un très bon développeur C qui me lira et qui pensera qu'il peut programmer ce qu'il veut super vite, je lui affirme qu'il développerait encore plus vite dans un langage next-gen.
Le C++ ? Un monstre à 18 têtes, toujours là aussi, mais les programmeurs C++ se rendent compte de la perte de vitesse du langage : moins de libs maintenues, la nécessité d'utiliser des libs C et soit de les appeler "low-level" soit de faire leurs wrappers. Et (consultez Google si vous ne me croyez pas), C++ compilé avec gcc n'est que modérément plus rapide que du Java HotSpot. Parfois, Java est plus rapide. Mais c'est normal, avec la compilation JIT, votre code Java aussi tourne nativement.... (ceci n'est pas vrai si vous codez en C++ comme en C, avec des optimisations en assembleur, etc. Aussi, les templates sont moins couteuses en C++, mais aussi moins bien conçues).
Le Python ? Le langage est sympa, et il y a une véritable communauté de développeurs Python dans le monde libre. C pour la perf, Python pour l'UI / le développement rapide. Malheureusement, il faut écrire des bindings explicites pour lier les deux -- même si c'est fait automatiquement avec de nombreux outils qui marchent plutôt bien je dois l'avouer, mais c'est pas *pratique*. En plus l'interpréteur Python est vraiment lent. Si on fait son Python dans Jython (qui a un peu de retard malheureusement), on accède immédiatement à une immense bibliothèque standard supplémentaire, celle de Java, et des milliers de bibliothèques alternatives, notamment tout ce qui est Apache, Eclipse, Spring...
Le Ruby ? Même chose que Python, en plus lent et plus haut-niveau. Il existe JRuby.
Le problème principal, c'est que les langages haut niveau permettent d'écrire des bibliothèques/frameworks de façon plus maintenable (par exemple Plone) et plus intéressante qu'en C, mais que dans ce cas, les développeurs ne veulent pas faire des bindings high-level -> C pour ne pas avoir de dépendance sur un interpréteur (compréhensible mais pète-couille). On se retrouve donc bloqué sur un langage pour un framework.
Chez la concurrence, il y a .NET. C'est Managed C++, C# (Java, le langage, en mieux), ASP.NET (PHP en mieux), VB.NET (la première dose est gratuite), IronPython, F#.NET (OCaml)... Et l'avantage de ces environnements, immense en pratique, c'est l'intérop complète et automatique de tout ce qui est défini dans un langage, dans tous les autres. Il n'est besoin de définir une fonctionnalité qu'une fois. Il n'existe qu'une seule bibliothèque standard. Le langage utilisé dépend des goûts du développeur et de la tâche à effectuer, pas de l'existence de bindings, de la performance de la VM (même si les différents langages ont différentes performances), etc. Evidemment il existe toujours des wrappers pour rendre le style de programmation plus cohérent avec le langage host, mais c'est un problème moindre. À ça, on ajoute des environnements de développement rapide bien plus complets puisqu'ils gèrent un ensemble uniforme et compatible.
Le libriste anti-Java créée un rift entre le confort de développement GNU/Linux (multi-plateforme en fait) et Windows. Et pour faire venir de nouveaux développeurs, pour avoir des jeux par exemple, il faut un environnement de développement sexy.
À vrai dire, les distributions GNU sont plutôt sexy niveau environnement de développement, on a beaucoup d'outils libres et faciles à obtenir. Le toolchain est intéressant pour beaucoup de choses. Mais l'esprit trollesque anti-Java qui reste présent (pas que dans les communautés francophones) dessert la communauté.
Que faire ?
* Continuer comme aujourd'hui, avec des langages indépendants qui ont chacun leur ABI et qui ont besoin de bindings lourds à mettre en place ; avec des solutions pas toutes performantes et surtout, le lockin : un framework = un langage
* Passer sur un runtime/VM générique....
** Utiliser la JVM (projet JCR Da Vinci pour rendre la JVM plus générique) et profiter de nouveaux frameworks, langages, améliorer l'intégration avec les utilitaires usuels sous GNU/Linux (meilleurs bindings GNOME / GTK, etc)
** Passer à .NET avec Mono et être à la botte d'un environnement créé par une société qui, à travers ses actions passées, a montré qu'elle ne veut pas partager et qu'elle ne désire que Windows comme système, que ce soit sur les bureaux ou dans les racks.
Dans la pratique, .NET a des avantages sur Java, car il a été prévu directement pour être un environnement générique. Java essaie de rattraper le retard, et la stratégie d'Oracle/Sun est incertaine. D'un autre côté on a pas de doutes sur l'objectif final de Microsoft :)
Programmer sur la JVM, ça ne veut pas dire programmer en Java tout pourri.
Il y a Scala, un langage fonctionnel objet fortement typé très novateur qui rencontre un succès phénoménal. Il a les mêmes performances que Java (si vous suivez, ça veut dire qu'il est performant), et le feeling de Ruby !
Il y a Clojure, un autre langage fonctionnel dyamiquement typé, un Lisp-1, conçu directement pour la JVM qui rencontre aussi beaucoup de succès parmi les fans de Lisp, et les autres. Très performant pour un langage dynamique.
Il y a Groovy, plutôt lent, un langage objet dynamiquement typé, inspiré de Ruby mais directement conçu pour la JVM.
Et enfin il y a Jython et JRuby, les ports, plus performants que les originaux de Python et Ruby. Pas de risque d'être dépaysé.
Il est temps d'euthanasier le troll Java qui sommeille en vous.
[^] # Ça passe très bien :)
Posté par smc . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 10.
De même, JRuby est notablement plus performant que les interpréteurs habituels Ruby MRI ou même YARV.
Les JVMs, et notamment HotSpot, sont très performantes, même si un certain nombre d'amateurs en informatique sont restés sur l'idée que Java n'a pas changé depuis 98 et est toujours aussi lent. Il y a eu une série d'optimisations hallucinantes qui en font sans aucun doute la VM *ouverte* et dont il existe une implémentation *libre* la plus performante.
Ce qui est lent avant tout, c'est le lancement de la JVM (toujours moins lent que le lancement de Ruby MRI ou PyPy), et il est négligeable car sur n'importe quelle machine qui utilise du Java de nos jours, on la lance au démarrage du système et elle se pose en mode serveur.
Le rejet par une grande part de la communauté libre du monde Java c'est un tir dans son propre pied. Je comprends les raisons : Sun a fait l'erreur de ne pas libérer son implémentation avant ce qui a complètement tué l'engouement pour la VM. Et le langage Java n'est pas sexy du tout, donc ça ne motive pas les libristes qui codent en bonne partie pour le fun. D'un autre côté,certaines communautés n'ont pas de problème avec le monde Java (notamment Apache).
Le problème, c'est qu'il n'y a rien en face :
Le C ? Oui, il est toujours là, il est performant mais le temps de développement est décuplé comparé à un langage de haut niveau (je parle pas particulièrement de Java). Alors il y aura bien un très bon développeur C qui me lira et qui pensera qu'il peut programmer ce qu'il veut super vite, je lui affirme qu'il développerait encore plus vite dans un langage next-gen.
Le C++ ? Un monstre à 18 têtes, toujours là aussi, mais les programmeurs C++ se rendent compte de la perte de vitesse du langage : moins de libs maintenues, la nécessité d'utiliser des libs C et soit de les appeler "low-level" soit de faire leurs wrappers. Et (consultez Google si vous ne me croyez pas), C++ compilé avec gcc n'est que modérément plus rapide que du Java HotSpot. Parfois, Java est plus rapide. Mais c'est normal, avec la compilation JIT, votre code Java aussi tourne nativement.... (ceci n'est pas vrai si vous codez en C++ comme en C, avec des optimisations en assembleur, etc. Aussi, les templates sont moins couteuses en C++, mais aussi moins bien conçues).
Le Python ? Le langage est sympa, et il y a une véritable communauté de développeurs Python dans le monde libre. C pour la perf, Python pour l'UI / le développement rapide. Malheureusement, il faut écrire des bindings explicites pour lier les deux -- même si c'est fait automatiquement avec de nombreux outils qui marchent plutôt bien je dois l'avouer, mais c'est pas *pratique*. En plus l'interpréteur Python est vraiment lent. Si on fait son Python dans Jython (qui a un peu de retard malheureusement), on accède immédiatement à une immense bibliothèque standard supplémentaire, celle de Java, et des milliers de bibliothèques alternatives, notamment tout ce qui est Apache, Eclipse, Spring...
Le Ruby ? Même chose que Python, en plus lent et plus haut-niveau. Il existe JRuby.
Le problème principal, c'est que les langages haut niveau permettent d'écrire des bibliothèques/frameworks de façon plus maintenable (par exemple Plone) et plus intéressante qu'en C, mais que dans ce cas, les développeurs ne veulent pas faire des bindings high-level -> C pour ne pas avoir de dépendance sur un interpréteur (compréhensible mais pète-couille). On se retrouve donc bloqué sur un langage pour un framework.
Chez la concurrence, il y a .NET. C'est Managed C++, C# (Java, le langage, en mieux), ASP.NET (PHP en mieux), VB.NET (la première dose est gratuite), IronPython, F#.NET (OCaml)... Et l'avantage de ces environnements, immense en pratique, c'est l'intérop complète et automatique de tout ce qui est défini dans un langage, dans tous les autres. Il n'est besoin de définir une fonctionnalité qu'une fois. Il n'existe qu'une seule bibliothèque standard. Le langage utilisé dépend des goûts du développeur et de la tâche à effectuer, pas de l'existence de bindings, de la performance de la VM (même si les différents langages ont différentes performances), etc. Evidemment il existe toujours des wrappers pour rendre le style de programmation plus cohérent avec le langage host, mais c'est un problème moindre. À ça, on ajoute des environnements de développement rapide bien plus complets puisqu'ils gèrent un ensemble uniforme et compatible.
Le libriste anti-Java créée un rift entre le confort de développement GNU/Linux (multi-plateforme en fait) et Windows. Et pour faire venir de nouveaux développeurs, pour avoir des jeux par exemple, il faut un environnement de développement sexy.
À vrai dire, les distributions GNU sont plutôt sexy niveau environnement de développement, on a beaucoup d'outils libres et faciles à obtenir. Le toolchain est intéressant pour beaucoup de choses. Mais l'esprit trollesque anti-Java qui reste présent (pas que dans les communautés francophones) dessert la communauté.
Que faire ?
* Continuer comme aujourd'hui, avec des langages indépendants qui ont chacun leur ABI et qui ont besoin de bindings lourds à mettre en place ; avec des solutions pas toutes performantes et surtout, le lockin : un framework = un langage
* Passer sur un runtime/VM générique....
** Utiliser la JVM (projet JCR Da Vinci pour rendre la JVM plus générique) et profiter de nouveaux frameworks, langages, améliorer l'intégration avec les utilitaires usuels sous GNU/Linux (meilleurs bindings GNOME / GTK, etc)
** Passer à .NET avec Mono et être à la botte d'un environnement créé par une société qui, à travers ses actions passées, a montré qu'elle ne veut pas partager et qu'elle ne désire que Windows comme système, que ce soit sur les bureaux ou dans les racks.
Dans la pratique, .NET a des avantages sur Java, car il a été prévu directement pour être un environnement générique. Java essaie de rattraper le retard, et la stratégie d'Oracle/Sun est incertaine. D'un autre côté on a pas de doutes sur l'objectif final de Microsoft :)
Programmer sur la JVM, ça ne veut pas dire programmer en Java tout pourri.
Il y a Scala, un langage fonctionnel objet fortement typé très novateur qui rencontre un succès phénoménal. Il a les mêmes performances que Java (si vous suivez, ça veut dire qu'il est performant), et le feeling de Ruby !
Il y a Clojure, un autre langage fonctionnel dyamiquement typé, un Lisp-1, conçu directement pour la JVM qui rencontre aussi beaucoup de succès parmi les fans de Lisp, et les autres. Très performant pour un langage dynamique.
Il y a Groovy, plutôt lent, un langage objet dynamiquement typé, inspiré de Ruby mais directement conçu pour la JVM.
Et enfin il y a Jython et JRuby, les ports, plus performants que les originaux de Python et Ruby. Pas de risque d'être dépaysé.
Il est temps d'euthanasier le troll Java qui sommeille en vous.