Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
The moose likes Groovy and the fly likes Trade-Offs of Groovy...? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Languages » Groovy
Bookmark "Trade-Offs of Groovy...?" Watch "Trade-Offs of Groovy...?" New topic
Author

Trade-Offs of Groovy...?

David Hibbs
Ranch Hand

Joined: Dec 19, 2002
Posts: 374
One of the reasons I have been hesitant to invest the time and effort required to really pick up Groovy is the fact it remains a scripting language at its heart. (Obviously, this is one of the strengths so often touted as well.)

Traditionally, scripting languages have a number of weaknesses. For example, it is very easy to get them to run (due to their simple, concise syntax) --yet it is often very difficult to get them to run correctly. You very likely have to test and test and test and test to find out what went wrong. Java you can run a debugger. Is there a full-featured Groovy debugger? Can it attach to a running server and help debug?

Also, it is very easy to write some highly esoteric--or even cryptic--code in scripting languages! I think most everyone has heard of the various obfuscated Perl competitions! Admittedly, it is easy to write some bizarre code in base Java, too--but my experience has been that if you can whip out a script quickly it is much more likely to be unintelligible except to the author.

In pure Java, you have various paradigms to help with these problems. Where does the line end? Find the semicolon. What keeps me from passing the wrong object in? It won't compile! What happens when a file can't be found? It throws an exception -- handle it!

Sure, you don't have to write a try/catch block in Groovy... but can you write one? What is the argument supporting the ability to ignore these errors?

So, with all that said... What are some of the trade-offs/risks involved with selecting Groovy? Why is it worth it? Or is it just another scripting language--albeit one that runs on a JVM...?

--David


"Write beautiful code; then profile that beautiful code and make little bits of it uglier but faster." --The JavaPerformanceTuning.com team, Newsletter 039.
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

Traditionally, scripting languages have a number of weaknesses. For example, it is very easy to get them to run (due to their simple, concise syntax) --yet it is often very difficult to get them to run correctly. You very likely have to test and test and test and test to find out what went wrong. Java you can run a debugger. Is there a full-featured Groovy debugger? Can it attach to a running server and help debug?

A debugger isn't a very good testing methodology. Unit tests typically work much better.

Also, it is very easy to write some highly esoteric--or even cryptic--code in scripting languages! I think most everyone has heard of the various obfuscated Perl competitions! Admittedly, it is easy to write some bizarre code in base Java, too--but my experience has been that if you can whip out a script quickly it is much more likely to be unintelligible except to the author.

Would a professional seamstress use safety scissors to make a wedding dress? No, a professional will use the most efficient tools. A programmer writing unreadable code is like a seamstress cutting off a finger, it's a sign of someone that doesn't really know their trade well or, in the case of software, possibly someone that's too inconsiderate to care about quality.

In pure Java, you have various paradigms to help with these problems. Where does the line end? Find the semicolon. What keeps me from passing the wrong object in? It won't compile! What happens when a file can't be found? It throws an exception -- handle it!
Sure, you don't have to write a try/catch block in Groovy... but can you write one? What is the argument supporting the ability to ignore these errors?

There's paradigms in Groovy. Where does the line end? Find the end of the line. Do you prefer semicolons? You can use those if you really want to.

You can revert to Java's static typing in Groovy if you wish. But programming by simply expecting behavior can have its advantages. Suppose my method takes an object and calls each on the object. Now I can pass in any object with an each method. I could pass in a String without having to convert it into an ArrayList or whatever type the method expects. In Java I'd have an extra couple lines of code to change my object just to appease the compiler. That means writing extra code that adds no functionality and thus effects readability.

Venkat once explained to me (paraphrasing): "If I want you to move a table for me, I don't care if you're a Human or a Forklift. I just want you to move the table." In Java, you'd end up with an TableMover interface that has a moveTable method and both Human and Forklift would implement it. Then your method would only accept type TableMover. That's a lot of overhead and adds unnecessary complication to the codebase for such a simple behavior... all to appease a compiler.

You can write a try/catch in Groovy. You can also avoid having to write it over and over and over again by pulling all that template code into a closure. There's a lot of this boiler-plate code avoidance in Java frameworks like Spring but it usually forces you to use anonymous "callback" objects which are far more verbose than Groovy.

So, with all that said... What are some of the trade-offs/risks involved with selecting Groovy? Why is it worth it? Or is it just another scripting language--albeit one that runs on a JVM...?

A lot of these have been mentioned in other recent threads in the forum.


A good workman is known by his tools.
David Hibbs
Ranch Hand

Joined: Dec 19, 2002
Posts: 374

A debugger isn't a very good testing methodology. Unit tests typically work much better.


I'll admit that I crossed idioms in my first question between "Testing" and "debugging." Obviously unit tests work better for testing than debugging -- they're not (usually) for the same goal!

So I'll break this into two questions:
1) how do you write unit tests for Groovy?
2) how do you debug when something goes awry?


Would a professional seamstress use safety scissors to make a wedding dress? No, a professional will use the most efficient tools. A programmer writing unreadable code is like a seamstress cutting off a finger, it's a sign of someone that doesn't really know their trade well or, in the case of software, possibly someone that's too inconsiderate to care about quality.


There's a big difference here to me. A seamstress makes a dress to be worn by a specific person. A developer needs to keep in mind that whatever gets built will spend the majority of its life in maintenance, not development. Who maintains the code? Usually a junior person. Were I a seamstress, I would not hand my apprentice the sharpest shears.


Venkat once explained to me (paraphrasing): "If I want you to move a table for me, I don't care if you're a Human or a Forklift. I just want you to move the table." In Java, you'd end up with an TableMover interface that has a moveTable method and both Human and Forklift would implement it. Then your method would only accept type TableMover. That's a lot of overhead and adds unnecessary complication to the codebase for such a simple behavior... all to appease a compiler.


Thanks for the interesting information on the syntax; I hadn't seen anyone remark about the option to use semicolons elsewhere.

I quoted the forklift example to raise another question: what happens if you pass in some other object (say "chair") that does not have a moveTable method? What does Groovy do?

I will note here that the interface serves another purpose besides appeasing the compiler--it lets developers know what is expected of the object passed into the method. Certainly you are correct that an interface implies a lot of overhead in this basic case. What then does Groovy provide for a more complicated case?

Say the TableMover interface also had a couple other methods like disassembleTable, reassembleTable, packTable, and unpackTable.

Say my method is shipTableTo(TableMover mover, Location location).
How does the person invoking shipTableTo() know which methods are required to be implemented? Certainly you can document it, but what other mechanisms are provided?

On a completely different note, what's a closure? I gather it has something to do with with error handling...?
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[David]: On a completely different note, what's a closure? I gather it has something to do with with error handling...?

There's not really a good short answer to that. A good place to learn is the Informal Guide to Closures. Closures can be used in error handling, but also many other things. Probably they deserve a separate thread rather than being shoehorned into this thread.


"I'm not back." - Bill Harding, Twister
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[David]: How does the person invoking shipTableTo() know which methods are required to be implemented? Certainly you can document it, but what other mechanisms are provided?

Well, you can still declare a TableMover interface, and any class that implements the interface must implement those methods, just like Java. And if you declare a type for a variable rather than leaving it untyped, then you know that that variable can only refer to an object of the appropriate type, or null. Again, just like Java. It's only when you omit type declarations that you don't really know for sure what methods are available.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[David]: I quoted the forklift example to raise another question: what happens if you pass in some other object (say "chair") that does not have a moveTable method? What does Groovy do?

It throws a groovy.lang.MissingMethodException. In general, Groovy will often give you runtime exceptions for things that would be compile-time errors in Java.
[ April 08, 2008: Message edited by: Jim Yingst ]
David Hibbs
Ranch Hand

Joined: Dec 19, 2002
Posts: 374
Thanks for the notes, Jim! Those were particularly helpful as I just couldn't see how the Groovy and Java could work together to build a more layered solution. Now I can see that you can use Groovy where you don't need the full weight of the core Java, and fall back to those when you need it.

The link to the closures page was particularly helpful at putting a number of things in perspective. I hadn't gotten that far because... well, I couldn't get past that first hurdle. :roll:
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Trade-Offs of Groovy...?
 
Similar Threads
Unit Testing with Groovy?
difference between exe file and batch file
Advantages of Groovy over other scripting languages ?
Is Ruby a scripting or a programming Language?
Benefits of Learning Clojure?