J'ai eu envie hier soir de tester ce langage dont des échos résonnent très positivement depuis presque un an maintenant. Et grâce à un tutoriel exceptionnellement bien fait sur le site officiel de Groovy, j'ai pu rapidement évaluer la chose. Première impression : c'est rapide et fun de taper trois mots et de voir tout ce qu'on peut faire avec. Ca m'a immédiatement rappellé mes ébats avec la console d'Ocaml au temps béni où on est un jeune fou qui délaisse les maths pour l'info.
Je resitue juste le contexte de Groovy. Le constat est que Java a su faire la synthèse du meilleur de ce qui existait à l'époque en termes de développement objet. Or, aujourd'hui, de nombreux développeurs sont adeptes de langages dynamiques (scripting) aux syntaxes plus flexibles. C'est donc dans cette volonté que Groovy est né profitant de l'expérience acquise par la pratique de Java, Perl ou autres Python.
On découvre donc des concepts comme la closure qui considère le code comme des données. Cela m'a fait tout de suite penser au javascript “moderne” (post framworks du web 2.0 comme Ext Js voir mon précédent post qui embrace cette approche. On peut donc réaliser une affectation d'une suite d'instruction (“closure”) à une variable afin de la passer en entrée à une fonction :
square = { it * it }
square(9)
résultat: 81
[ 1, 2, 3, 4 ].collect(square)
résultat: [ 1, 4, 9, 16 ]
Comme vous pouvez le constater, la syntaxe s'en trouve grandement allégée par rapport au code java équivalent.
Avantages:
- Syntaxe allégée = augmentation de la productivité
- Mode script ou compilé : intégration forte au JDK = déploiement aisé
- Intégration des meilleures librairies open-source
Inconvénients, problèmes posés :
- La productivité est-elle vraiment améliorée si on est un minimum agile avec son IDE ?
- Flexibiliser le langage n'est-il pas une façon de rendre le code moins maintenable ? -moi j'ai toujours eu du mal avec les langages de script je préfère la programmation rigide et structuréé “à l'allemande” (avez-vous déjà lu du code open-source allemand ?), quitte à agiliser la méthode de développement, mais je m'égare-
- Est-ce toujours aussi facile de tester une classe qu'un script (oui je sais, un script Groovy est une Classe) ?
Crédits photos: treeoldships