My RSS Feeds
Groovy... what?
Well... the Codehaus site tells me a lot about what I guess I need to know about the language... but I'm still wondering why I'd want to use it. The home page says:
Groovy is a new agile dynamic language for the JVM combining lots of great features from languages like Python, Ruby and Smalltalk and making them available to the Java developers using a Java-like syntax.
Okay... great features, I guess, except I don't know what the great features from Python, Ruby, and Smalltalk are that I'm looking forward to. Agile and dynamic here look like buzzwords, although they both have real meaning.
The next paragraph:
Groovy is designed to help you get things done on the Java platform in a quicker, more concise and fun way - bringing the power of Python and Ruby inside the Java platform.
Um. A quicker, more concise, and fun way... when I don't really have a problem doing quick, concise things in Java as it is. (Maybe my definitions are poor.) The power of Python and Ruby still don't do much for me.
So far, Groovy looks like something for Java programmers with Python envy. I don't know Python yet (I know, I'm a Luddite, etc.) so I don't sit around wishing Java had features that I don't know how to use, nor do I routinely encounter problems in Java that distress me over their lack of solution.
It's usually my knowledge that's at fault, after all, not Java's lack of solution. Why would I blame the language?
I'm going to keep looking, just out of interest - apparently Groovy has some bright people working on it, so there has to be some tangible benefit to it somewhere. My first reaction to the JSR issuance was, "What? Why?" because I didn't see where a JSR did anything but claim legitimacy for it - without legitimacy being valid - whereas other languages for the JVM immediately became second-class citizens comparatively.
I appreciate taking the bull by the horns, but sometimes doing that says that the bull is for your use only, and THAT's a little strange.
I'm hoping there's a real benefit here beyond what the home page offers.
Here is an example of conciseness.
Let's say we have an array of integers A, we want an array B containing the square of the elements of A. so b[i] = (a[i])^2.
In Java 1.4, you may write this as:
int[] a = {1, 14,
987645};
int[] b = new int[a.length];
for (int i = 0 ; i < a.length ;
i++) {
b[i] = (a[i] * a[i]);
}
In Smalltalk it would be:
a :=
#(1 14 987645).
b := a collect: [:i | i squared].
In Python 2.3:
a =
[1, 14, 987645]
b = [x*x for x in a]
In Ruby 1.8:
a = [1, 14,
987645]
b = a.collect { i | i.squared }
Giovanni Corriga
The example given above is fine, but it doesn't look like much to a Java
programmer. Here's another example that I hope is more convincing.
Let's
assume that we have a collection of Employee objects.
Employee objects have a two properties: name, salary. Now, how
would you sort that collection of Employee by salary? In Smalltalk, the
code looks like this:
myCollection sort: [ :a :b | a salary <= b salary ].
Of course, the object returned by #salary must implement <=, but if we assume it's a number, then it does. If we wanted to sort by name, we'd just change the method call from salary to name.
I'm no expert on Java, but I believe that you would need to implement a different method for the salary and for the name because they are of different types. Dynamic typing allows you to do what is right, not what the compiler thinks is right.
Vincent Foley
Dynamic typing just allows you to perpetuate errors in your assumptions
(like "myCollection only contains Employees or subclasses") further into
your code, making it difficult to impossible to get correct behavior from
large enough programs. There's a reason why less than 0.1% of the industry
uses Smalltalk. Programmers aren't stupid, they choose the right tool for
the job.
If you want to state that an object has certain methods, you make it explicitly implement an interface. Explicit is better than implicit.
The Java version of that salary sort is unattractive, but simple enough, and will immediately reveal any errors in your assumptions:
Collections.sort( myCollection, new Comparator() {
public int compare(Object a, Object b) {
return (int)(
((Employee)a).getSalary() - ((Employee)b).getSalary() );
}
}
);
An interesting point is that sort() is not defined for List, because List is just an interface. Any class that implements the List interface can be passed to the Collections.sort() static method.
Mark Hughes [kamikaze.mark@gmail.com]
Mark, what if b.getSalary() returns a negative number? This would create an
error that static typing wouldn't catch.
Giovanni Corriga
What if b.getSalary() returns a negative number?
Since b is an Employee (that's what static typing lets me express explicitly) Employee.getSalary() should not return negative salaries if that's inappropriate for Employees.
Of course neither static typing nor any other language feature can know what's appropriate for Employees. But that's the same for all OO languages: It's your task as a developer to design your Employee class properly.
martinval
no text
Doh... no comment w/o eMail disclosure :-(
Sorry, please ignore the comment above.
I missed my text at first since
I'm used to entries with posters' names preceding comments. But it's all
there and the eMail is really optional :-)
martinval