Ow. The pain. After a month of a diet of Groovy, coming back to Java is painful. Interestingly, my Java coding style has now changed. Before you read on, it's important to consider whether the ways in which we're hurting are due to Java's very nature, or due to the conventions we impose on ourselves as Java developers. There's a fair share of both.
Just coding 10s of lines of Java code yields a rich supply of pain points for me:
- Visual clutter - generics, general code overhead, interfaces, casting
- Static typing - a false sense of security, I write a test and it shows me that my runtime casting was wrong.
- Autoboxing - it's frustratingly incomplete. I can do
new SomeObject(5)if it takes an Integer as an argument, but notassertEquals(5, someObject.getId()). - Bloat -
def list = []ordef map = [:]is readable whereasList<SomeObject> list = new ArrayList<SomeObject>()orMap<String, SomeObject> map = new HashMap<String, SomeObject>()really isn't.
Footnote: I read the much-referenced Code's Worst Enemy a while ago and I really didn't understand what he was talking about. Now it makes a lot more sense to me. "[People] view code bases much the way construction workers view dirt: they want great big machines that can move the dirt this way and that." [more]
9 comments:
I hear you on the autoboxing. I'm curious to know more about your runtime casting problems.
I don't find any readability problems with the declarations and initializations myself. With the differing mindsets toward variables in Groovy and Java I think each syntax suits each language. With Java it's a two step process, and the syntax supports this. *shrug*
Groovy is very clean-looking compared to Java, I'll agree.
Good write-up, it's interesting to hear about the experience of moving back and forth.
-Mark G.
An Infinite Number of Cats on Keyboards
Hey Mark,
My runtime casting was a coding bug pure and simple. It's just interesting to note that I needed a test to catch the mistake, as I would have in Groovy also.
This was my long way around to pointing out the obvious fact that the Java doesn't catch every typing issue at compile time.
I notice from your blog that you teach Java. Have you seen the Groovy SwingBuilder?
Cheers Mark,
Merlyn
Typo: run-time casting is _dynamic_ typing.
I haven't had a chance to check out anything more than the basics on groovy so far. I'm strongly considering teaching Groovy instead of Java in the future. I doubt I have time to put together the necessary lessons in time for the upcoming year, but once this school year gets started, I expect to start checking out groovy for real as a candidate for classes in 2009-2010 and taking a stab at putting together a lesson plan. This summer's time is largely spoken for already.
-Mark
An Infinite Number of Cats on Keyboards
I saw a blog comment somewhere on http://tapestryjava.blogspot.com/ from a university teacher saying something to the effect of:
"We chose Groovy as the first language to teach our students which worked very well. We found though that they were reluctant to move on to learning Java afterwards."
:D
These two declarations are not equivalent:
def list = []
List<SomeObject> list = new ArrayList<SomeObject>()
But more like:
// list of SomeObject
List list = new ArrayList()
It reminds me how I hated pre-generics code, as it was quite error-prone.
True. However, they are both idiomatic Java and Groovy code.
If I go the List list = new ArrayList() route I trade more readable code on that line for casting code everywhere I retrieve something from the list.
Ah, I missed the point. You're saying that because this is crazy code in Java:
List list = new ArrayList()
that this must be equally crazy in Groovy:
def list = []
The former is bad in Java because you're working against the language that wants to be able to statically type everything. The latter is good in Groovy because you're working with the language to reap the benefits of duck typing.
I know the feeling. It is interesting how quickly you get used to things like not using semi-colons or the default public modifier. Still the thing that I miss most, unless I have to parse or create XML documents, is how you can process collections in Groovy. I mean think of all the overhead when you want to iterate through a collection, find a given entry or entries and then use them to create or acquire other object types. I can do that in a single line of code in Groovy (or two if I like to add some white space for readability) and like in 20 (if I am lucky) using Java.
Post a Comment