Groovy – An Open Source Success Story(sitepoint.com)
sitepoint.com
Groovy – An Open Source Success Story
https://www.sitepoint.com/groovy-open-source-success-story/
2 comments
> code that would be 5 to 10 times longer in Java
I wonder if that's Java 8 with its lambdas? Most sites just use Apache Groovy for the scripty dynamically-typed stuff only (e.g. testing, build config, grails MOP) and leave the statically-typed stuff for Java or some other JVM language. Of course, those variables in global scope will still be a problem.
I wonder if that's Java 8 with its lambdas? Most sites just use Apache Groovy for the scripty dynamically-typed stuff only (e.g. testing, build config, grails MOP) and leave the statically-typed stuff for Java or some other JVM language. Of course, those variables in global scope will still be a problem.
I was speaking specifically to Java 7 but can offer the Java 8 perspective as well. Java 8 with lambdas makes it better - but you still have to bake your own on top of the system in a lot of cases. The real joy of Groovy is having the powerful manipulation functions just there for you without any external library.
A good analogy would be anonymous functions in Vanilla JS being like Java 8 lambdas vs the expressive power the baked in goodness Lodash offers being like what Groovy closures supplement to the JVM environment. You don't always need it, but the general purpose tooling makes your life a lot easier in certain specific cases.
With that being said in our use case Groovy was very pointed - serving a specific, directed purpose in a monitored environment. When developers were left to their own devices to design general scripting and tooling that they were comfortable with, nearly everyone chose Python and to a lesser extent Ruby.
I think Groovy is great to create some JVM specific glue and support for an enterprise system - but as a general purpose language it still has a long way to go. As an example, try and make a tool in Groovy for interacting with a REST API and compare your effort for doing so to Python - One of these is significantly less painful than the other.
A good analogy would be anonymous functions in Vanilla JS being like Java 8 lambdas vs the expressive power the baked in goodness Lodash offers being like what Groovy closures supplement to the JVM environment. You don't always need it, but the general purpose tooling makes your life a lot easier in certain specific cases.
With that being said in our use case Groovy was very pointed - serving a specific, directed purpose in a monitored environment. When developers were left to their own devices to design general scripting and tooling that they were comfortable with, nearly everyone chose Python and to a lesser extent Ruby.
I think Groovy is great to create some JVM specific glue and support for an enterprise system - but as a general purpose language it still has a long way to go. As an example, try and make a tool in Groovy for interacting with a REST API and compare your effort for doing so to Python - One of these is significantly less painful than the other.
it probably has the open source success as the only thing going for it, probably the ugliest non-intuitive language I've ever come across
Works well:
Extensible type checking. Groovy can do quite a bit of things with type checking and you can turn it into "pretty much Java" if you need to and even take it a step further and enforce even stricter typing than Java with relative ease
Closures. The Groovy built in closures are quite extensive and allow you to build some really beautifully expressive pieces of code that would be 5 to 10 times longer in Java. The implementation lends itself well to a functional approach.
Questionable:
Not defining a variable with a type or the def keyword creates a variable in the global scope, just like JavaScript. This creates problems, as you can imagine. One of the more infamous bugs we ran into was when someone had named a variable "id" in the global scope of a script and the identifier of its parent, the script runner, was modified. Brought the whole runner down.
Groovy doesn't respect privacy. You can literally declare something as private variable in a Java or Groovy class and Groovy will happily access it with no qualms. The only thing that private helps you for is preventing the variable from showing up in a decent IDE's autocomplete alongside your getters and setters