Petite mise en contexte: je travaille dans un département d'infrastructure et on a du code par ci par là, principalement en perl et en ksh. Il existe aussi d'autres département TI qui eux code en Java sous Websphere. Un de ses collègues est venu me parler de Groovy un peu aujourd'hui, comme quoi y'a des bons outils de débug, c'est du scripting, ca parle direct avec d'autres applications java, possibilité de faire des programmes très cours, etc.
 
Je regarde vite vite et jusqu'à présent... je cherche les avantages que ca l'aurait pour un sysadmin comparativement à du perl, du ksh, du python ou autre language plus orienté sysadmin / unix

aucun

 
en plus d'un mot?
 
dans quel cas le groovy a-t-il des avantages?

Ben pour un systadmin, aucun justement.Les intérêts de groovy c'est d'être dynamiquement typé et sur la JVM (ce qu'il partage avec Jython, JRuby et une foultitude d'autres) et d'avoir une syntaxe proche de celle du java, ce qui n'a aucun intérêt pour un sysadmin (ou un programmeur en général, autre que javateux)

Salut,
 
La lecture de cet article pourrait peut être t'éclairer : Introduction au langage de script Groovy

j'ai fait un hello world aujourd'hui
 
au command prompt ou à partir d'un fichier, même combat: ca lance une jvm et ca prend 5-6 secondes alors qu'un perl/ksh prend 0.01 seconde
 
on m'avait dit que ca se compilait: groovyc me chit un .class et jvois pas en quoi ca va m'aider à avoir quelque chose qui roule sans jvm
 
Je vais essayer de comparer un programme avec un minimum de business logic, mais jusqu'à présent... je vois pas pourquoi je le placerais aux cotés de perl/python dans le choix d'un language pour du code sysadmin

Ben oui, c'est un langage qui tourne sur la JVM  
 
Et je t'ai dit que ça n'avait aucun intérêt pour un sysadmin (c'est pas comme si ça en avait un pour les autres, mais c'est un autre débat)

Tu ne connais pas le sens du mot "compilé".

En même temps si tu lis pas les réponses des gens...

je lis les réponses des gens, mais les gens en question c'est seulement toi pour le moment. Je ne veux pas généraliser ma justification à la personne étant venu me proposer le tout à partir d'un seul commentaire ou sans avoir au moins essayer le language pour 1-2 petits trucs

La réponse qui t'a été faite est correcte. Groovy n'est pas adapté a ce que tu souhaite faire, ne serait-ce que par le chargement systématique de la jvm.
 
Reste à python ou ruby, si le shell ou perl sont trop 'primitifs'.

Dans groovy ils ont pas fait un système pour garder une JVM en arrière plan et lui passer les commandes à chaud ?

C'est le même principe que Python, Perl et autres : il s'agit de langages 100 % interprétés ou, qui, lorsqu'ils sont compilés, ne produisent pas du code natif. Donc il faut de toute façon un interpréteur (ou assimilé) pour les exécuter. Même les scripts shell sont interprétés, et un shell doit être lancé pour pouvoir ensuite les exécuter. Groovy ou Java ne sont donc pas si extraordinaires que cela.
 
Dans l'absolu, pourquoi passer des langages de script type Perl à des langages objet type Java ou Groovy ? Clairement, la réponse est dans les détails : les programmes sont généralement beaucoup plus lisibles, la complexité des programmes un peu gros est bien plus facile à maîtriser, les bibliothèques fournies en standard sont incroyablement nombreuses, etc. Et les environnements de développement sont souvent beaucoup plus puissants, et rendent le programmeur nettement plus productif. Pourquoi ne pas passer à ces langages ? En fait, c'est souvent l'apprentissage de ces langages qui est le principal frein (et aussi la manière de raisonner, car l'objet, ça ne se pense pas comme le procédural).
 
On pourrait penser que dans le cas de Java, il y a aussi le temps de démarrage de la machine virtuelle. Mais comme je le disais plus haut, c'est oublier que tous les langages de script requièrent un interpréteur. Sun a beaucoup travaillé ces aspects de démarrage (et ils continuent encore à optimiser la chose), et aujourd'hui, le temps de démarrage d'une JVM est devenu raisonnable. Et une fois la JVM démarrée, on dispose de la rapidité d'exécution du code Java (qui est proche de celle du code C/C++).
 
Maintenant, il faut savoir que Java est effectivement de plus en plus utilisé dans le monde des sysadmins, et même souvent, sans passer par la case Python. Ce qui tend à prouver que lancer un programme Java n'est effectivement pas si coûteux que cela. Dans ton cas, tu as mesuré le temps d'exécution de ton programme Groovy, et le temps de démarrage de la VM ? Te paraît-il inacceptable ?

Sauf que la JVM met plusieurs seconde à démarrer. Les runtimes de Perl ou Python, non.

Mais ouais, le Python ou le Ruby c'est pas clair, c'est pas lisible, c'est pas utilisable et ya pas de stdlib
 
   

En java oui, et ça fait tout just regagner la productivité perdue en se tapant un langage typé statiquement (avec un type system pourri), verbeux au possible, malpratique et extrèmement moche.
 
En groovy, non.

Bonjour, apprends à lire, il parle de l'utilisation de Groovy (pas java) dans le cadre d'un boulot d'admin sys, pas dans le cadre de la création d'un serveur web qui va tourner pendant des jours/semaines/mois. Et dans ce cadre, le temps de démarrage du runtime est critique, et le temps de démarrage du runtime java (avec java6, et en -server) est un ordre de grandeur plus grand que celui de python, et 2 ordres plus grand que celui de Perl.

Source demandée, parce que java pour le scripting c'est le truc le plus risible que j'ai jamais lu depuis C++ & templates pour le scripting.

Pas sur les machines que j'utilise (inférieur à la seconde, même si ça reste mesurable).

T'as pas l'impression de faire du flame, là... J'ai parlé de Perl et de script shell, que j'ai opposé aux langages objet. Mais c'est vrai, je suis bête ! Python et Ruby, c'est pas des langages objet...      
 
Quant aux bibliothèques standard, je n'ai pas dit que Python et Ruby en avaient aucune, j'ai juste dit que les bibliothèques Java sont connues pour être particulièrement riches (autrement dit, de ce côté-là, Java ne pêche pas ; subtile différence d'interprétation de ma phrase...).

La principale critique faite à Groovy dans les posts précédents, c'est le démarrage de la JVM. Dans ce cas, c'est quoi, la difference entre Java et Groovy ? Que Java soit statiquement typé et Groovy le soit dynamiquement, pour répondre à cette question, on s'en tape, non ?
 

En même temps, quand tu lances une appli cliente sur une JVM, il faut être sacrément vicieux pour la lancer en mode serveur... qui va mettre plus de temps à démarrer et consommer beaucou plus de mémoire.
 
Je suis d'accord qu'un temps de démarrage de 5 secondes est absolument réddhibitoire. Par contre, 1/2 seconde, ça l'est ? Pour certains, oui, pour d'autres, non. C'est pour cela que j'ai fini mon post en proposant à Burgergold de faire des mesures réelles, dans son environnement. Il sera seul juge pour savoir s'il trouve le temps de démarrage insupportable ou non.
 

Je n'ai pas d'article à te donner : c'est le retour d'expérience récent de formateurs qui passent toute l'année à donner des formations d'administration Unix (commerciaux/Linux) niveau avancé et expert. Je reconnais que ça m'a aussi beaucoup surpris quand ils m'ont dit ça, car jusqu'alors, je pensais qu'un langage comme Python était bien plus adapté aux besoins des admins.

Sauf que Python et Ruby sont des langages relativement standard pour sysadmin et que Burgergold les a explicitement cités (en tout cas Python). Tout pitch the Groovy doit donc se faire en relation avec eux, pas en les ignorant

Je sais pas par qui elle est connue pour être "particulièrement riche", mais franchement la stdlib Java n'est pas vraiment impressionnante comparé à celle de Python, et même si Java  pas mal de lib "externes", il n'a pas le nombre et la qualité des libs de CPAN, ou la facilité d'installation de libs Ruby (via gems).

Oh non, il y a aussi le fait qu'il n'ait, dans l'absolu, strictement aucun avantage sur Ruby, Python ou même Perl pour un sysadmin. Auxquels on peut ajouter une intégration inférieure au shell, et le fait que Ruby, Python et Perl -- étant déjà largement utilisés par les sysadmins -- ont nombre de ressources sur ce sujet.

J'ai dit la principale, j'ai pas dit la seule !  
Tu critiques les autres en disant qu'ils faudraient qu'ils apprennent à lire, mais franchement, commence par le faire toi-même !

Et je dit que ce n'est pas la principale, et que les autres sont à mon sens au moins aussi importantes sinon plus.

huh oui la JVM prend plusieurs secondes (5-6) à démarrer pour un simple hello world et c'est sur une architecture IBM PPC Power4 de l'ordre de 32cpu 1.9ghz 80go de ram... on parle ici d'un java5, les jre 1.6 d'ibm viennent tout juste de sortir j'ai pas eu le temps d'en installer une. Par contre c'est pas la principale raison, mais je vois plusieurs cas de programme perl que j'ai qui roule en moins de 100ms et qui doivent rester ainsi
 
sinon le language j'ai aucun problème. J'ai déjà codé pas mal à l'université en Java et je supporte une application websphere utilisant struts. Mais je trouvais justement pas beaucoup d'avantage à coder à Groovy plutot qu'en perl ou plutôt qu'en Java. Si j'ai à faire du code de sysadmin qui sera régulièrement modifier, Perl fait tout en quelques minutes pour moi. Si j'ai besoin d'un gros truc clean qui doit interagir avec d'autres applications Java, j'aime autant mieux codé direct Java que de faire du groovy il me semble...