¿Cuál es su opinión sobre Groovy?

Question

Para sus proyectos, ¿tuvo una experiencia favorable con Groovy? ¿Qué tan grande fue el proyecto? ¿Hubo problemas con el lenguaje? ¿Consideras a Jython, JRuby o Clojure?

Answer 1

Mi equipo implementó recientemente un pequeño servicio AtomPub utilizando Grails (y, por implicación, Groovy). En general, fue una experiencia agradable. Brevemente consideramos Java puro y JRuby como alternativas, pero no Jython o Clojure. El equipo fue con Groovy porque era un poco más familiar, parecía que JRuby, pero ofrecía más flexibilidad que Java.

Éstos son algunos de los problemas que encontramos:

• Menos soporte de herramientas que la mayoría de nosotros se utilizaron para (lo grande que un acuerdo este es depende del desarrollador individual que está pidiendo)
• horrible rastros de pila (esto puede haber sido más culpa de Grails que Groovy)
• Con todo un equipo aprendiendo el idioma sobre la marcha, fue difícil llegar a un estilo consistente y querido
• Documentación no ideal para Grails (de nuevo, no es culpa de Groovy); los documentos cambiaron rápidamente, por lo que la situación puede haber mejorado por ahora

Answer 2

Actualmente estoy trabajando en un pequeño proyecto de exploración con Grails. No tenía experiencia previa en usar Groovy, solo Java.

Hasta el momento, estoy bastante impresionado de lo rápido que puedo hackear algo utilizable, y las características de Groovy, especialmente las expresiones Gpath, juegan un papel importante en eso. He encontrado algunos errores en Grails, pero no hay problemas fundamentales en el lado de Groovy.

La desventaja principal de Groovy es (para mí) que es considerablemente menos conveniente para depurar que Java - los rastros de pila están hinchados por la magia de reflejo que sucede debajo del capó de Groovy, y los mensajes de error pueden ser crípticos, pero eso puede parte se debe a mi falta de experiencia.

Answer 3

He hecho un proyecto pequeño/mediano en Grails (y por supuesto Groovy) y lo he disfrutado. Hubo obstáculos definidos en el camino. Ellos incluyen:

• La falta de buenas herramientas de depuración (que se instaló en el uso de Netbeans debido a su apoyo a la mayoría nativa para Grails, pero carecía de un depurador ... uf)
• Errores en las características de flujo web. Grails 1.1 tiene una versión más nueva del flujo web de Spring que solucionó muchos de estos problemas.
• Weak jquery plugin support. Me encanta jQuery, pero no fue tan bien soportado como prototipo (y cualquiera que sea la otra biblioteca de JavaScript compatible). Sin embargo, las cosas de AJAXy fue un placer escribir usando plantillas.
  • Dificultad para manejar enumeraciones y relaciones muchos a muchos en GORM. Grails 1.1 será de gran ayuda para resolver estos problemas.

En general, realmente disfruté de mi experiencia y aprendido mucho en un corto período de tiempo. Grails 1.1 es una actualización importante que preparará este framework empresarial. Realmente estoy esperando buenas herramientas de depuración. Supongo que podría dejar de ser tan barato y comprar IntelliJ. Escuché que es lo mejor para Grails.

Viniendo de un fondo de Java, el camino a Grails parecía mucho más manejable que empezar de nuevo con un lenguaje completamente nuevo y un conjunto de herramientas para Rails.

Andrew

Answer 4

Hemos implementado recientemente un proyecto de tamaño mediano con Groovy/Grails, maravilloso haber sido elegido por el resto del equipo dependen de Java. Como es universalmente el caso de Java, todo llevó más tiempo del que podría tener. Aunque Groovy proporciona un alivio muy necesario del estilo detallado de Java, sigue siendo lo suficientemente similar que uno tropieza continuamente con la sintaxis contraintuitiva. La idea detrás de HLLs es proporcionar herramientas de programación que faciliten el pensamiento humano, no requerir que los humanos piensen exactamente como las computadoras. Procedente de un contexto ligeramente diferente, aunque bastante familiarizado con Java, en mi humilde opinión, otra opción de idioma como Ruby, Python o Clojure habría proporcionado una base mejor y más expedita para el proyecto. Estoy con Thoreau, sugiriendo "Simplificar, simplificar, simplificar", en lugar del cansado mantra de Java, "Amplificar, amplificar amplificar". Esperando que Java pura, no la JVM, se una al montón de polvo de programación junto con COBOL.

Answer 5

me gusta

1. cierres
2. Los Slurpers
3. Que no hay necesidad de la declaración normalmente redundante MyType x = new MyType(), que puede reducirse simplemente a def x = MyType(). Sin embargo, el tipado es discutible en Groovy (y eso no me gusta).
4. Que puede probar rápida y fácilmente con la consola (aunque, para ser justos, podría hacer algo similar con una clase Java utilizando el método principal (...)).

no me gusta

1. Es débil con tipo. Eso afecta el rendimiento y conduce a errores. Nada de lo que se detiene, ni siquiera se advierten, de la siguiente manera:

   def x = new MyComplexClass() 
   
   // oops! accidentally made x equal to 1, that is, an integer 
   x = 1 
   
   // Many lines later ... 
   
   // big fat error. Now x is an Integer, so it doesn't know handle myComplexOperation 
   println "The result is ${x.myComplexOperation(a,b,c)}" 
   

Se producirá un error en tiempo de ejecución.

2. Es difícil mantener el código de otra persona. Teniendo en cuenta que puede inyectar atributos a los objetos, de repente se encuentra con variables que no tiene ni idea de dónde vienen ni qué tipo son.

3. El problema tipo puede ser "aliviado" con más pruebas de unidad, pero luego, el tiempo que se ahorra al escribir el siguiente método:

   def add(a, b) { a + b} 
   

   se pueden perder por otra consideración:

   • Debe decidir si será aceptable que 'a' y 'b' sean una cadena, un entero o una clase de matriz que haya creado, o alguna otra cosa.
   • Si intenta

   def add (int a, int b) {a + b}

maravilloso simplemente ignorará los tipos de los parámetros. Entonces, cualquiera puede pasar cadenas o lo que sea al método "agregar". El compilador no se quejará.

Así que ahora hay que añadir algún tipo de validación si desea asegurarse de que los parámetros son números enteros:

def (Integer a, Integer b) { 
    assert a instanceof Integer 
    assert b instanceof Integer 
    a + b 
} 

Por lo que yo puedo decir, el propósito de los compiladores de lenguaje estático era evitar errores en tiempo de compilación, no en tiempo de ejecución.

4. Si una llamada de método es capaz de "tirar" un error, el compilador no le advierte que usted tiene que poner un try-catch o añadir una "lanza" a tu método principal Si no sabe que un método puede arrojar una excepción, puede compilar sin saberlo un programa Groovy sin errores de compilación, ¡hasta que se desarrolle en tiempo de ejecución!

5. La consola no es tan buena, ya que no proporciona sugerencias como un IDE como lo hace Eclipse. Por lo tanto, debe tener su navegador o libro abierto para ver los métodos disponibles para una clase. También hay otra pequeña trampa: no es necesario usar 'def' para definir una variable en la consola, pero las necesita en un programa. Entonces, si copias y pegas a tu IDE desde la consola, pero no olvides la def.

6. En mi opinión, Groovy es grande en cantidades limitadas, pero no para grandes proyectos. Esto se debe a que muchos posibles errores se detectan solo en tiempo de ejecución, por lo que son necesarias más pruebas unitarias y afirmaciones, lo que en parte derrota la rapidez con la que puede escribir programas Groovy.

7. De forma predeterminada, las propiedades en Groovy son públicas, y los conjuntos y se crean automáticamente. Puede anular el comportamiento predeterminado, pero es simplemente otra cosa que puede olvidar y dificulta la encapsulación de sus clases. Por ejemplo:

   ​class Test { String a, b } 
   
   class Test2 { 
       def t = new Test() 
       Test2 (String s) { t.a = s } 
       ​}​​​​​​​ 
   } 
   
   def t2=new Test2("I am public") 
   println t2.t.a 
   

Answer 6

Un lenguaje muy dinámico con una sintaxis sencilla y agradable, curva de aprendizaje plana para los equipos existentes de Java, la integración de Java sin igual y aumenta el JDK existente con muchos métodos, trayendo enormes ganancias de productividad. Se podría fácilmente ser llamado Java/JDK 2.0

Neal Ford hizo un gran comparación entre Groovy y JRuby http://nealford.com/downloads/conferences/Comparing_Groovy_and_JRuby(Neal_Ford).pdf

Sobre el rendimiento, que es excelente para un lenguaje dinámico y apoyo 2.0 maravillosa compilación estática por lo que es realmente vuela .

"Con la @CompileStatic, el rendimiento de Groovy es aproximadamente 1-2 veces más lento que Java y sin maravilloso, que es aproximadamente 3-5 veces más lento. (...) Esto significa para mí que está listo para Groovy aplicaciones donde el rendimiento tiene que ser algo comparable a Java ".

Prueba de rendimiento: Groovy 2.0 vs.Java http://java.dzone.com/articles/groovy-20-performance-compared

Si nunca vio los números de rendimiento lenguajes dinámicos, antes de llegar stucked, por favor ver los puntos de referencia con otros lenguajes dinámicos y marcos web en un caso de uso real (Groovy 1.8 - Grails 1.3.7): http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/

El rendimiento siempre está relacionado con lo que desea hacer. Utilizo Groovy desde 2008 con gran éxito en grandes proyectos. Es solo hacer el trabajo a tiempo.

Espero que ayude!