Existe-t-il des raisons impérieuses de ne pas utiliser Groovy?

Question

Je suis le développement d'une application Métier en Java après une longue absence de la plate-forme (après avoir passé les 8 dernières années ou si ancrées en Fortran, C, un smidgin de C++, et récemment .Net).

Java, le langage, n'est pas beaucoup changé de la façon dont je m'en souviens. J'aime les atouts et je peux travailler autour de ses faiblesses - la plate-forme a grandi et il se prononce sur la myriade de différents cadres qui semblent faire la même chose que l'autre est une autre histoire; mais que peut attendre un autre jour - tout-en-tout ce que je suis à l'aise avec Java. Cependant, au cours des deux dernières semaines, je suis devenu amoureux avec Groovy, et uniquement à partir d'un égoïste point de vue: mais pas seulement, car il rend le développement contre la JVM d'une présentation succincte et divertissante (et, ainsi, "groovy") proposition de Java (le langage).

Ce qui me frappe le plus à propos de Groovy est inhérente à sa maintenabilité. Nous avons tous (j'espère!) s'efforcer d'écrire bien documenté, facile à comprendre le code. Parfois, cependant, les langues que nous utilisons eux-mêmes nous vaincre. Un exemple: en 2001, j'ai écrit une bibliothèque en C pour traduire des messages EDI EDIFACT en ANSI X12 messages. Ce n'est pas particulièrement compliqué, si peu impliqués, et j'ai pensé à l'époque, j'avais documenté le code correctement et je me suis probablement - mais six ans plus tard, quand j'ai revu le projet (et après avoir acclimaté à C#) je me suis retrouvé perdu dans tellement C standard (mallocs, pointeurs, etc. etc.) qu'il a fallu trois jours d'analyse réfléchie avant j'ai finalement compris ce que j'avais fait il y a six ans.

Ce soir, j'ai écrit environ 2000 lignes de Java (c'est le jour de repos, après tout!). J'ai documenté du mieux que je sais faire, mais, mais, de ceux de 2000 lignes de Java, une proportion importante est de Java plaque de la chaudière.

C'est là que je vois Groovy et d'autres langages dynamiques de réussite à travers la maintenabilité et, plus tard, de la compréhension. Groovy vous permet de vous concentrer sur votre objectif sans s'embourber sur la plate-forme de mise en œuvre spécifiques; c'est presque, mais pas tout à fait de soi à la documentation. Je vois cela comme un immense bienfait pour moi quand je revoir mon projet actuel (que je vais le port de Groovy asap), dans plusieurs années, et à mes successeurs qui va en hériter et de poursuivre le bon travail.

Donc, il y a aucune raisons de ne pas utiliser Groovy?

Answer 1

Il y a deux raisons, je pense, de ne pas utiliser Groovy (ou Jython, ou JRuby):

• Si vous avez vraiment, vraiment besoin de la performance
• Si vous manquez de vérifier le type statique

Ceux sont les deux grands ifs. La Performance est probablement un facteur moins important dans la plupart des applications que les gens pensent, et de vérifier le type statique est un problème religieux. Cela dit, l'une des forces de l'ensemble de ces langues, c'est leur capacité de mélanger et assortir avec du code Java natif. Meilleur des deux mondes et de tous les que.

Depuis que je ne suis pas responsable de vos affaires, je dis "Allez-y".

Answer 2

Si vous utilisez Groovy, vous êtes essentiellement de jeter des informations utiles sur les types. Cela laisse votre code "groovy": belle et concise.

Bird b 

devient

def b

Plus vous obtenez de jouer avec toutes les méta-classes et dynamique des appels de méthode qui sont une torture en Java.

Cependant-et oui , j'ai essayé l'Ide, Netbeans et Eclipse largement -- graves refactorisation automatique n'est pas possible en Groovy. Ce n'est pas l'Ide de la faute: le type d'informations n'est pas là. Les développeurs vont dire, "mais si vous avez des tests unitaires pour chaque chemin d'accès du code (hmmmm), alors vous pouvez restructurer plus facilement." Mais ne croyez pas le battage: ajout de code (tests unitaires) à ajouter à la sécurité de massive refactoring, mais ils ne font pas le travail plus facile. Maintenant, vous avez à portée de main corriger le code d'origine et les tests unitaires.

Cela signifie donc que vous n'avez pas refactoriser comme souvent en Groovy, surtout quand un projet est arrivé à maturité. Alors que votre code sera concis et facile à lire, il ne sera pas aussi brillante que le code qui a été automatiquement refait tous les jours, horaire et hebdomadaire.

Lorsque vous vous rendez compte qu'un concept représenté par une classe en Java n'est plus nécessaire, vous pouvez simplement le supprimer. Dans Eclipse ou Netbeans ou que ce soit, de la hiérarchie du projet s'allume comme un sapin de Noël, vous dire exactement ce que vous avez foutu avec ce changement. def thing indique au compilateur (et donc de votre IDE) rien sur la manière dont une variable sera utilisée, si la méthode existe, etc. Et IDEs ne peut faire beaucoup de devinettes.

En fin de compte, le code Java est rempli de "passe-partout", mais il a été pétri dans sa forme finale après de nombreuses refactorings. Et pour moi, c'est la seule façon d'obtenir de haute qualité, un code lisible pour les futurs programmeurs, y compris lorsque ces futurs programmeurs sont vous-dans-le-futur.

Answer 3

Deux raisons pour lesquelles Scala pourrait constituer une alternative convaincante à Groovy:

• Performance à égalité avec Java
• Dactylographie statique sans fouillis

Answer 4

L'une des choses les plus importantes que vous perdez lorsque vous utilisez dynamique des langues, surtout dans une grande base de code est la capacité à utiliser un IDE pour re-facteur. Les langues qui permettent l'ajout dynamique de code pour les objets ne peuvent tout simplement pas être analysé par aujourd'hui IDEs pour permettre le genre de facile refactoring méthodes que vous pouvez obtenir à partir d'Eclipse, etc. pour Java, C++, etc.

Ce n'est pas vraiment un cas de "langages Dynamiques sont mieux que Statique". Utiliser ce qui est le mieux pour vous. La chose vraiment cool à propos de Groovy, en particulier, est que vous pouvez mélanger et assortir Java et Groovy dans le même projet, et tout s'exécute sur l'ordinateur virtuel. Oui, la Scala est un autre exemple.

Answer 5

Je pense que le plus gros problème est le manque de support de l'IDE par rapport à Java, mais les plugins pour Eclipse et Netbeans s'améliorent constamment. De plus, si mes souvenirs sont bons, Groovy ne prend pas en charge les classes internes anonymes si vous en avez réellement besoin pour une raison quelconque. Personnellement, je choisirais quand même Groovy.