Commentaires sur : Groovy++, une version typée statiquement de Groovy

Par : Nicolas Martignole

Nicolas Martignole — Mon, 08 Feb 2010 22:16:07 +0000

Guys (comme disent les américains), Guys, n’oubliez pas que tout ceci est basé sur un micro-benchmark, qui fait essentiellement de l’accès disque, du traitement de collection et de l’écriture de 2 fichiers. Ce n’est pas révélateur et il ne faut pas conclure rapidement que Groovy est plus lent que Java. D’autres tests seront plus intéressants à vous montrer, où vous verrez que les performances sont identiques, pour cependant une quantité de lignes de codes et une clarté clairement en faveur de Groovy.
Restez dans le coin, on reparlera du sujet bientôt.

Par : HollyDays

HollyDays — Mon, 08 Feb 2010 17:16:28 +0000

A Stéphane Vanacker

Le besoin d’un langage comme Groovy se ferait considérablement moins sentir si, en Java, on disposait d’une puissance d’expression équivalente. Si, pour exprimer 16 lignes de code Groovy en Java, il ne faut pas moins de 67 lignes de code (sans commentaires), et que, malgré cela, le code n’est pas beaucoup plus facile à lire, c’est bien que Groovy répond effectivement à un réel besoin…

Je suis d’accord avec vous sur le fait qu’essayer d’introduire du typage statique (sans changer la syntaxe !) dans un langage qui n’est pas du tout fait pour cela, c’est sans doute une usine à gaz… surtout quand on ne rapproche pas vraiment des performances d’un vrai langage typé statiquement (puisqu’on reste 40 fois plus lent que Java au lieu de 60 fois : si on se retrouvait à être 2 ou 3 fois plus lent que Java, là ça vaudrait clairement le coup).

Bref, tout ça ne répond pas au besoin précédemment exprimé. Et est-ce qu’introduire ces fameuses closures dans Java, qui sont à l’origine de la puissance d’expression de Groovy (c’est particulièrement visible dans cet exemple), ça ne serait pas plutôt ça, la solution ?

Par : Jean-Baptiste L.

Jean-Baptiste L. — Mon, 08 Feb 2010 16:08:40 +0000

Comment expliquer que Groovy++ soit moins rapide que Java ? N\’est ce pas simplement lié à la jeunesse du compilateur ? Théoriquement, le code écrit en Groovy++ et en Java, ne devrait il pas se traduire en un ByteCode *semblable*, et donc en des performances proche, *comme en Scala* (notez les étoiles ) ?

A partir du moment où le langage est typé pareil que Java, il n\’y a pas vraiment de raison que les performances soient à ce point plus mauvaise, on pourrait d\’ailleurs imaginer compiler n\’importe quoi en ByteCode (Du C++, du Haskell …)

Par : Les tweets qui mentionnent Le Touilleur Express » Blog Archive » Groovy++, une version typée statiquement de Groovy -- Topsy.com

Mon, 08 Feb 2010 12:33:01 +0000

[...] Ce billet était mentionné sur Twitter par Nicolas Martignole, Nicolas Chambrier. Nicolas Chambrier a dit: RT @Letouilleur: Nouvel article publié http://www.touilleur-express.fr/2010/02/08/grovvy-plus-plus/ a propos de Groovy booster, une… [...]

Par : arnaud

arnaud — Mon, 08 Feb 2010 11:00:27 +0000

J’aurais mis sortByCount/sortByElement en static final, et avec des « ? extends Comparable » plutôt que de préciser String-Integer.

Par : Stéphane Vanacker

Stéphane Vanacker — Mon, 08 Feb 2010 10:41:20 +0000

J’ai du mal à comprendre la motivation de tant de complications à utiliser un langage dynamique pour revenir finalement à un aspect statique, après avoir gagné certes 34%, mais perdu quasiment un facteur 30 en vitesse par rapport à Java !!! Entre temps, on a créé une usine à gaz, pour un gain qui me semble de plus en plus faible.

Cela me fait un peu penser aux problèmes qu’on rencontre avec Maven parfois : J’ai l’impression que ça plaît à certaines personnes de résoudre des problèmes qu’ils se sont créés avec des outils inadaptés et où ils passent finalement plus de temps à résoudre les problèmes de l’outil plutôt qu’en gagner avec celui-ci. Je pense que de temps en temps, un bon vieux retour à l’Analyse de la Valeur s’imposerait à tous.

Par : Nicolas Martignole

Nicolas Martignole — Mon, 08 Feb 2010 10:08:34 +0000

@Waddle : attention j’ai mis à jour l’article suite à ta remarque. J’ai fait la distinction entre la version multi-threadée et la version normale. Le 34% de gain de vitesse concerne bien la version classique, pas la version 4 Threads. Je suis d’accord que son test de départ était biaisé, c’est pour cela que je les ai tous refait.

Par : waddle

waddle — Mon, 08 Feb 2010 10:01:05 +0000

@Typed ça me rappel le option explicit en VB XD

Mais plus sérieusement, je trouve ça un peu biaisé comme test. La version groovy++ est multi-threadée, donc ce n’est pas comparable. Clairement Java est plus rapide (oh ! surprise !), mais il faudrait comparer Groovy++ et Groovy « normal » sans introduire de MT, non ?