Discussion :

[zuzuu]

Qu'en pensez vous?

[Tommy31]

Pas suffisamment mature à mon gout pour l'instant. Gros potentiel cependant, très intéressant dans un contexte industriel agile (principe de cristallisation).

[zuzuu]

D'accord. Donc pour la maturité, il va falloir que cela vienne avec le temps...
Sinon, cela veut dire quoi "principe de cristallisation"?

[Tommy31]

Tu développe en groovy les parties mouvantes de ton appli, et dès que tu atteints un seuil de stabilité, tu migre vers java. Groovy étant un super ensemble de java, ca se fait sans trop de difficulté ou de temps. Cet effort est surtout encouragé par la volonté de se retrouver dans un univers plus strict.

[zuzuu]

On peut compiler du groovy en byte code.
Donc, on migre notre code en byte code...? C'est cela que tu voulais dire?
On refait pas tout notre code groovy en java...?

[Tommy31]

Si... vois groovy comme du prototypage. Quel intérêt ? Plusieurs: revenir vers un univers connu et maîtrisé, standardiser l'application, bénéficier d'un typage statique, appliquer une démarche qualité sur le code, gagner en outillage (plus nombreux en java qu'en groovy).

Mais ce n'est qu'une opportunité offerte liée au contexte.

[zuzuu]

D'accord merci pour ton avis.
Aujourd'hui, j'ai l'impression qu'avec l'essor des langages interprétés, tous le monde va pouvoir développer, ce qui est bien, mais je me demandais ce qui ferait la différence dans les langages de programmation dans le futur. Je pensais que groovy devait aider à développer encore plus vite, comme python, etc... des choses qui sont aujourd'hui assez répétitive comme action (exemple, utilisation de groovy avec grails suivant le modèle MCV).

[MarcDeXeT]

Qu'en pensez vous?

Beaucoup de bien

Plus sérieusement, il faut penser groovy comme un outils au sein de l'écosystème java: il excelle là où java a des lacunes et pèche par ses qualités: langage à typage faible, performances moyennes.
Je l'utilise en production depuis la version 1.0 pour des automates de transformation de données en flux continus sans problème. Il me sert également beaucoup pour réaliser des opérations ponctuelles, des scripts one-shot, du prototypage, du proof of concept, avoir la date du jour (sisi)

En général mon cheminement est souvent celui-ci
* je prototype en groovy
* je consolide les parties abstraites ou les classe support en java
* je conserve les parties modifiables ou adaptatives en groovy
* je couvre tout cela avec des test unitaires
* je recette en situation
* j'adapte la partie souple conservée en groovy directement sur le serveur de recette pour les 20% d'environnement chiants à modéliser
* je répercute les modifications sur les sources
* je revalide
* je sers chaud en production et je passe à la suite

IL faut également se rendre compte de quelques éléments :
- l'écosystème est très riche
- springsource met des ressources dessus et le paquet sur la communication
- les commiters sont très réactifs
- et une fois qu'on y a goûté, revenir à du java pur et dur est pénible.

Marc

[kedare]

Je vois pas pourquoi vous voulez a tout prit migrer de Groovy vers du Java pur... ca n'apporte quasiment rien :/

Enfin personnellement j'ai regardé, et je compte bien l'utiliser pour remplacer Rails par Grails (meilleurs performances, meilleurs API, toute la puissance de Java!)