I used groovy to build an internal app that worked with subversion, jira, and a local sqlite db this week and it was so much fun. It was so productive that I decided to put a web ui on top of the core app. Rather than use grails I used groovlets with the built in HTML builder. My favorite line of code had to be:
(Also posted as a comment on the blog:) Groovy would have won the "Java.next" title by now if they weren't so stubborn about being a dynamic language. If they invested half the effort they've put into "IDE-time" static type inference/type checking in Eclipse/IntelliJ (so that programmers can still get the warm fuzzies of auto completion) into building static type inference/checking into the language itself, I think they'd have seen much wider adoption.
This is basically what the guy behind groovy++ has done, but, from what I've heard, they basically told him several years ago that they had no interest in taking the language in a static direction.
This sucks because, in IMO, 90%+ of the calls in a Groovy program can be statically dispatched just like regular Java. Sure, duck typing is useful in a few places, but those few places shouldn't mean my entire program has to be dynamic.
Groovy has an awesome syntax, awesome compile-time AST transformations, etc.--but a dynamic language, in enterprise environments at least, will not be Java.next. Scala is maturing, and Groovy's window of opportunity is quickly closing (or already gone).
I've been building the web app I'm working on completely in Groovy, and running it on Google App Engine. I'm quite happy with my choice to switch over to Groovy from Java. There are 3 main features of Groovy that greatly speed up my productivity as compared to coding with Java.
1. Closures - items.find { it.name == 'groovy' } is much easier than looping.
2. Language support for collections - Maps can be declared like: [key:'value'], and lists can be declared like: [1,2,3].
3. Easier handling of nulls - The "Elvis Operator" can be used to specify defaults like: (item ?: "defaultvalue") and the safe navigation operator will return null rather than throwing a NullPointerException when doing something like this: (item?.address?.street).
As much as I've enjoyed writing Grails apps and Groovy scripts, what I don't like about groovy is that it comes with a large runtime jar and its binaries are not really usable from java projects without API uglyness.
I wish Java had been designed with the same multi-language philosophy that .NET has had from the get go. Binaries produced in any language in .NET don't give any clues to what the language the binary was implemented in. For example, if your writing something using VB.NET and working with a library that was implemented in C# there really isn't any evidence that this is the case and the signatures look the same.
But that's mostly because VB.Net and C# are isomorphic, it's the same language with different syntax.
I remember reading about the first versions of Eiffel on .Net. That gave the impression that unless you put a lot of effort into your language, it will probably be just a variant of C#/VB. The first versions of Eiffel for .Net lacked multi-inheritance and I think DBC was crippled somehow too. :-/
Unrelated, but something is up with the encoding on your site (or the quotes used), and it makes it terribly hard to read and comprehend anything. (win7/ff4)
The article is using unicode quotes (\x92 and \x93.) You can just switch the character encoding used by Firefox in view > char encoding to UTF-8 and it renders fine.
Chrome reads it as UTF-8 without prompting, I'm curious why that isn't the same in Firefox.
> There is also the fact that the JVM(currently) doesn’t have support for dynamic memory dispatching which is feature vital for dynamically typed languages to get a decent performance.
Can someone explain what "dynamic memory dispatching" is? Is it perhaps better known under a different name? (Google is no help.)
The company I work for tried incorporating Groovy into several of our projects, but we started getting random permgen JVM crashes as a result. I believe this is due to the large number of classes it creates behind the scenes. This left a bad taste in peoples' mouths and unfortunately groovy will now be a hard sell.
Edit: Yes, we increased the permgen size and whatnot, but the outages it caused just left people with an unfavorable view of groovy. Which, as I said, is unfortunate, because I think it's pretty cool.
My favorite approach to using groovy in projects is with the groovy compiler plugin for maven. Compile and bundle the resulting byte code. All you have to remember is too bundle the groovy runtime and remember how groovy interacts with Java natively.
The one thing that disturbs me about groovy is that overloaded methods seems to only be signature checked at runtime, which results in an exception when invoked with the wrong parameters - not a compiler error.
Are you asking why the article was about Groovy, or "why groovy?" in a broader sense?
On the 'broader sense' angle, Groovy is a good for certain people/teams who are looking to get more out of Java development without giving up too much of what they have invested in. Pretty much all Java code will run in Groovy unchanged, and you can update existing working Java code with some Groovy decorations in the same file without issue. Moving to JRuby or Jython, for example, require you to make larger changes to rethink entire classes in the new syntax.
Admittedly some people consider this a small point, but it's certainly nice for some people to be able to reuse existing Java syntax without needing to learn a lot of new syntax up front - with Groovy you can try out new syntax as you go, but always drop back to raw Java when you want (again, in the same file - you can use existing Java classes in JRuby and Jython IIRC).
* Groovy is easy to develop in - it's dynamically typed and far less verbose than Java
* It's mature and stable
* It's easy for Java programmers to learn
* It's easy for Python and Ruby developers to learn
* Grails, groovy.sql.Sql, XmlSlurper and a host of other Groovy libraries
* Documentation is good and support forums are very active
* Groovy is actively developed. Version 1.8 was just released. I haven't had the time to look at the new features but glancing at the changelog they look pretty good.
* And last but not least, Java shops with a heavy investment in Java and Java servers can easily integrate Groovy as opposed to rewrite things in Python and Ruby (For green field development I still prefer Ruby)
[+] [-] johnwatson11218|15 years ago|reply
table{ myMap.each{k,v-> tr{ td k; td v;}}}
that turned myMap into a HTML table.
[+] [-] mgkimsal|15 years ago|reply
[+] [-] stephen|15 years ago|reply
This is basically what the guy behind groovy++ has done, but, from what I've heard, they basically told him several years ago that they had no interest in taking the language in a static direction.
This sucks because, in IMO, 90%+ of the calls in a Groovy program can be statically dispatched just like regular Java. Sure, duck typing is useful in a few places, but those few places shouldn't mean my entire program has to be dynamic.
Groovy has an awesome syntax, awesome compile-time AST transformations, etc.--but a dynamic language, in enterprise environments at least, will not be Java.next. Scala is maturing, and Groovy's window of opportunity is quickly closing (or already gone).
[+] [-] Spines11|15 years ago|reply
1. Closures - items.find { it.name == 'groovy' } is much easier than looping.
2. Language support for collections - Maps can be declared like: [key:'value'], and lists can be declared like: [1,2,3].
3. Easier handling of nulls - The "Elvis Operator" can be used to specify defaults like: (item ?: "defaultvalue") and the safe navigation operator will return null rather than throwing a NullPointerException when doing something like this: (item?.address?.street).
[+] [-] i386|15 years ago|reply
I wish Java had been designed with the same multi-language philosophy that .NET has had from the get go. Binaries produced in any language in .NET don't give any clues to what the language the binary was implemented in. For example, if your writing something using VB.NET and working with a library that was implemented in C# there really isn't any evidence that this is the case and the signatures look the same.
[+] [-] Flow|15 years ago|reply
I remember reading about the first versions of Eiffel on .Net. That gave the impression that unless you put a lot of effort into your language, it will probably be just a variant of C#/VB. The first versions of Eiffel for .Net lacked multi-inheritance and I think DBC was crippled somehow too. :-/
[+] [-] tszming|15 years ago|reply
[+] [-] kefs|15 years ago|reply
Screenshot: http://i.imgur.com/6lKfw.png
[+] [-] socillion|15 years ago|reply
Chrome reads it as UTF-8 without prompting, I'm curious why that isn't the same in Firefox.
[+] [-] BonoboBoner|15 years ago|reply
[+] [-] masklinn|15 years ago|reply
[+] [-] dillona|15 years ago|reply
[+] [-] ggchappell|15 years ago|reply
Can someone explain what "dynamic memory dispatching" is? Is it perhaps better known under a different name? (Google is no help.)
[+] [-] indy|15 years ago|reply
[+] [-] jpr|15 years ago|reply
[+] [-] msluyter|15 years ago|reply
Edit: Yes, we increased the permgen size and whatnot, but the outages it caused just left people with an unfavorable view of groovy. Which, as I said, is unfortunate, because I think it's pretty cool.
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] jancona|15 years ago|reply
[+] [-] udoprog|15 years ago|reply
The one thing that disturbs me about groovy is that overloaded methods seems to only be signature checked at runtime, which results in an exception when invoked with the wrong parameters - not a compiler error.
[+] [-] drivebyacct2|15 years ago|reply
[+] [-] mgkimsal|15 years ago|reply
On the 'broader sense' angle, Groovy is a good for certain people/teams who are looking to get more out of Java development without giving up too much of what they have invested in. Pretty much all Java code will run in Groovy unchanged, and you can update existing working Java code with some Groovy decorations in the same file without issue. Moving to JRuby or Jython, for example, require you to make larger changes to rethink entire classes in the new syntax.
Admittedly some people consider this a small point, but it's certainly nice for some people to be able to reuse existing Java syntax without needing to learn a lot of new syntax up front - with Groovy you can try out new syntax as you go, but always drop back to raw Java when you want (again, in the same file - you can use existing Java classes in JRuby and Jython IIRC).
[+] [-] terinjokes|15 years ago|reply
He also mentions Clojure (probably the next in the series after Scala), in addition to Jython and JRuby.
I, personally, have nothing against the name "JVM". Describes which VM we're talking about (even if more than just Java use it)
[+] [-] va_coder|15 years ago|reply
* Groovy is easy to develop in - it's dynamically typed and far less verbose than Java
* It's mature and stable
* It's easy for Java programmers to learn
* It's easy for Python and Ruby developers to learn
* Grails, groovy.sql.Sql, XmlSlurper and a host of other Groovy libraries
* Documentation is good and support forums are very active
* Groovy is actively developed. Version 1.8 was just released. I haven't had the time to look at the new features but glancing at the changelog they look pretty good.
* And last but not least, Java shops with a heavy investment in Java and Java servers can easily integrate Groovy as opposed to rewrite things in Python and Ruby (For green field development I still prefer Ruby)
[+] [-] pufuwozu|15 years ago|reply
https://bitbucket.org/puffnfresh/hello-jvm/src/f78a6a2312ae/...
Interoperability is actually very nice for most languages.