

Java.next() - The Groovy Programming Language - bozhidar
http://batsov.com/2011/05/06/jvm-langs-groovy.html
A brief analysis of the Groovy Programming Language
======
johnwatson11218
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:

table{ myMap.each{k,v-> tr{ td k; td v;}}}

that turned myMap into a HTML table.

~~~
mgkimsal
That's pretty slick. I've pretty much always stuck to Grails when doing Java
web stuff, but Groovelets may get in my bag of tricks some day.

------
stephen
(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).

------
Spines11
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).

------
i386
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.

~~~
Flow
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. :-/

~~~
pufuwozu
I don't think that's quite true. F# is very different to C# and VB but still
very well supported.

~~~
Flow
It's mostly because of the effort the F# team put in.

It's not inherent to the run-time and libraries. IMHO.

------
kefs
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)

Screenshot: <http://i.imgur.com/6lKfw.png>

~~~
socillion
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.

~~~
JeremyBanks
It identifies itself as UTF-8 in the XML header, but is sent without the XHTML
content-type so that's ignored and the encoding is ambiguous. (If it were sent
as XHTML it wouldn't render at all, since it has an XML error.) The author
should probably correct this.

------
BonoboBoner
If only there was a language at Java's tooling and speed with Groovy's syntax
and the perceived startup-time of Ruby and Python.

~~~
masklinn
Instead you get a language at Java's startup time with Groovy's syntax, Ruby's
speed and Go's tooling.

~~~
zmmmmm
Why so snarky?

Groovy's syntax is so close to Ruby's you can barely tell them apart
sometimes, and its tooling as pretty good, certainly way better than what I
believe is available for Go.

------
dillona
I can't help but be weary of anything advertised as "Enterprise ready"

------
ggchappell
> 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.)

~~~
indy
I think he's talking about the issues that JSR-292 (the invokedynamic
bytecode) addresses.

------
msluyter
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.

~~~
jancona
Any reason you didn't just increase the permgen size on your JVM? It's hardly
just a Groovy issue.

------
udoprog
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.

------
drivebyacct2
I'm sorry if this is ignorant, but why Groovy and not sure other language that
can run in the JVM? (Also, how much longer will the name "JVM" stick?)

~~~
pufuwozu
It's not just Java and Groovy. I've managed to write a "Hello World" app using
6 different JVM languages:

[https://bitbucket.org/puffnfresh/hello-
jvm/src/f78a6a2312ae/...](https://bitbucket.org/puffnfresh/hello-
jvm/src/f78a6a2312ae/src/)

Interoperability is actually very nice for most languages.

~~~
drivebyacct2
Right, that's my point. Why is Groovy "java.next()" and not one of the other
many languages that run in the JVM?

edit: Maybe I've misinterpreted the headline to mean more than it should.

~~~
vorg
Groovy is different to Scala and Clojure, the other two languages in that blog
series, in that Groovy uses the Java classes whenever possible, and isn't
intended to run on the CLR. Scala and Clojure were both intended to be dual VM
from the start. Rich Hickey says the 'C' in Clojure is for CLR and the 'j' is
for JVM. Scala and Clojure have their own collection classes runnable on
either VM, while Groovy is JVM-bound.

And of course Python and Ruby do it differently, having J- and Iron-
implementations, each at different versions to the primary implement and each
other.

~~~
rtaycher
I believe the .net versions of both scala and clojure are rarely used and not
a main focus.

