Groovy needs to play Nice
by Kevin Dangoor
I came across Nice a few months ago, but continued on my way. I’m not one to get into fringe languages and Nice seemed a bit academic. Xoltar’s Groovy features in Nice made me look again at the Nice site, and there are some interesting features there. Multiple return values is something that is sorely missing from Java, and I’d like to see that in Groovy. Syntax for optional method parameters would be a bonus, and I don’t think that’s something in Groovy yet either.
A little friendly competition never hurt anyone. Nice even has an Eclipse plugin as well, so it looks like the Nice 1.0 package may actually be worth considering for high-level programming needs.
the point in nice is that it feels like a scripting language (ad hoc interfaces, open classes, multiple return values) but being extremely static.
Anyway you could try jruby. it has both blocks and multiple return values.
FWIW Groovy has had optional method parameters for many months now.
You can easily return multiple result values using lists.
doSomething() {
return [a, b, c]
}
though we don’t yet have full tuple support, which is coming soon
Regarding JRuby: Nice and Groovy are both closer in syntax to Java, which I think is a bonus if you’re using both languages. It looked like Nice also allows you to declare dynamically typed variables (I saw a “var” declaration in one of the examples).
James: I stand corrected. I don’t remember seeing people using optional parameters, which are so insanely useful that I figured they must’ve been left out if no one’s using them. I have seen people using the JavaBean constructor syntax, but I didn’t see optional parameters for methods.
You’re right that using lists in Groovy is easy enough that you can use that for multiple return values. Using a List in Java for multiple return values is much more of a pain, so I hadn’t really thought of that.
So, probably the biggest difference between Groovy and Nice, then, is Nice’s static typing ability which is superior to Java’s, and Groovy’s dynamic typing slant. As long as you have unit tests, dynamic typing is a good thing in my book. YMMV.
James, the problem with returning a list is that you can’t easily unpack the values into variables in the caller.
doSomething(){
return [a, b, c]
}
Here’s what you want to be able to do:
caller(){
x, y, z = doSomething()
}
Or failing that, something like Scheme’s `receive’ or Lisp’s `multiple-value-bind’, especially if it lets you destructure more than just a straight list, e.g.:
caller(){
[x, y], z = doSomething()
}
Instead you’re stuck with this:
caller(){
result = doSomething()
x = result[0]
y = result[1]
z = result[2]
}
Which is, alas, distinctly non-groovy.