Unsure if this is worthwhile

[Robert Konigsberg]

I'm sure this question comes up alot -- I'm just not sure if it's worth spending time with Groovy. It looks great, sure, but I've heard two things:

1. It's not getting the favorable attention from Sun that jruby enjoys.
2. It's a dead-end scripting language.

Who can tell me why this is better to use than beanshell or jruby?

[Tug Wilson]

Groovy is most certainly not a dead end language

There are two Groovy books and a Grails book being published in the next month.

At least on Fortune 500 company has been using Groovy im mission critical system for over 12 months.

It have a large, growing and very vibrant user and developer community.

It's great fun to use!

If you choose Groovy you will be using a language which is designed from the ground up to run on the JVM and to interface seamlessly with Java.

If you choose Ruby you will be using a language which is available on the JVM and elswhere. You will not, however, have quite as easy a time in using Java libraries (the JRuby team are very good and are working hard to improve this situation but I think there will always be some element of difficulty here).

You will see that there is no single answer to your question - it depends on what you want to do.

[Scott Hickey]

Since we're on *Java* Ranch and assuming you want to integrate Groovy into a Java application or deploy in Java shop, for me Groovy really stood apart from the other language is several respects. It was really designed for the Java environment from the ground up in the sense that 1) syntactically it is was much easier to start coding in and 2) it integrates into Java in ways that I was already familiar with.

For my project, I got started quickly using a simple editor and Ant. I could use my exising JDBC libraries, write tests and run JUnit, compiled the Groovy source into .class files and jar them up. For me coming from the Java world and knowing I was going to have to integrate with other Java components, the barrier for entry was really, really low.

[Gregg Bolinger]

I could use my exising JDBC libraries, write tests and run JUnit, compiled the Groovy source into .class files and jar them up.

My question to this is, then why use Groovy? If you are going to compile to bytecode anyway, and jar them up, why not just stick with Java. When I think of using a scripting language, I think of it as an on-the-fly type of use. For example, I have an application written in Java. I would like users of my application to be able to extend it without having to recompile my code. Pretty much a plugin architecture, but with zero compiling. If that makes sense at all.

Aside from that, I'd assume a scripting language like Groovy to make a few things simpler with a simpler syntax. But again, my biggest problem is finding the niche for any scripting language.

[Clifton Craig]

Robert,

You would use Groovy instead of JRuby because it plugs into the average Java developer's brain easier since it doesn't require you learn a whole new library, API, syntax, and new way of doing things. Assuming you know Java (because you're posting here) you could pick up Groovy and be productive in minutes whereas JRuby would have you reaching for documentation every hour. (To be fair you would do your fair share of doc browsing with Groovy, but only to learn the enhancements over Java, not to learn the language or API in general.)

You would use Groovy instead of Beanshell because you need features above and beyond what Beanshell provides. Maybe you want to use the SwingBuilder from Groovy. Maybe your interested in Rails like development. Maybe you want to take advantage of mixins, operator overloading, or closure curry syntax. You would also choose groovy over beanshell if you need scripting features but also need to deploy a product without including source as Groovy compiles where Beanshell must be interpreted.

You would choose Beanshell over groovy if you wanted something that gave greater Java syntax compatibility, with a smaller footprint. (In this case maybe you're not as interested in the extended dynamic language features). Maybe you also are interested in using a stable and released product rather than a release candidate. Maybe the project you're working on already has a BEanshell interpreter present and adding yet another runtime is obnoxious.

You would choose JRuby over Groovy if you had existing Ruby experience and needed to integrate or run with existing Java code.

You would use Ruby over Groovy and JRuby if you were not experienced in or tied to any of the languages or runtimes and wanted to pick up the latest programming toy. In this case Groovy could still be a viable option as would Python or Javascript any other popular scripting language.

It all depends on the context.

[Clifton Craig]

Gregg,

My question to this is, then why use Groovy? If you are going to compile to bytecode anyway, and jar them up, why not just stick with Java.

Because Groovy has advantages other than being a scripting language. Groovy is a dynamic language. That is it adds dynamic features to your programming experience. People typically choose a scripting language not just because it doesn't require compilation but because of the features the language brings. The lack of a compile step is most often just a welcome side effect just like regreesion tests are a side effect of using TDD. Contrast the capabilities of Groovy with that of Java. To get a good picture of what I'm talking about do a Google search on "Ruby vs. Java" and do a mental scan and replace of the word Ruby with the word Groovy. All of the arguments you'll find apply to Groovy as well. Groovy has the advantage of being able to be compiled and deployed right along side of Java.

In short Groovy has all the advantages of Ruby without Ruby's main disadvantages. (runtime interpretation, Java impedance mismatch.) It's a cak-and-eat-it-too deal.

[Tug Wilson]

Greg,

I think you are thinking of a scripting language as something which allows you to do quick and dirty one off scripts.

We think of a dynamic language (not a scripting language, though it can be used as that) as something which lets you implement your algorithem with less noise and in a shorter time than using a static language like Java.

Sometimes you need the verbosity and the strict typeing of Java. Sometimes you need the terseness and the flexibility of Groovy.

Ten or so years ago I gladly left the vert static world of C++ and embraced the more dynamic world of Java. I haven't completely left the world of Java but I mostly live in the even more dynamic world of Groovy

[Gregg Bolinger]

It's a cak-and-eat-it-too deal.

Do caks taste good? I've never tried one.

Thanks for the info. Note that I am not arguing against Groovy. I am intrigued with scripting languages in general. I'm just leery to invest a lot of time in them without being able to justify the means (although there would obviously be less investment time with Groovy since I know Java). Conceding also that many people find good uses for them and that is great. Also conceding that I tend to want to know if my code is going to break before I run it, which proves difficult with dynamic languages.

[Clifton Craig]

Never had cak before huh? You've lived a sheltered life! Since Groovy is the next best thing to cak I'd suggest you try it too.

Also conceding that I tend to want to know if my code is going to break before I run it, which proves difficult with dynamic languages.

You should know that can be just as difficult with traditional compiled languages as well. That's why there are things such as Unit testing and TDD that go along way towards ensuring you write the right code the first time around. (You should check out the unit testing support built natively into Groovy as well!) Type checking imposed by the compiler is a dagger baked in a cake. (Or a dagger baked in a cak!) It's one of those risk vs. reward things. (I did spell that correctly right?) What I'm saying is consider the tradeoffs before praising your compiler.

[Scott Hickey]

Originally posted by Gregg Bolinger:
I could use my exising JDBC libraries, write tests and run JUnit, compiled the Groovy source into .class files and jar them up.

My question to this is, then why use Groovy? If you are going to compile to bytecode anyway, and jar them up, why not just stick with Java. When I think of using a scripting language, I think of it as an on-the-fly type of use. For example, I have an application written in Java. I would like users of my application to be able to extend it without having to recompile my code. Pretty much a plugin architecture, but with zero compiling. If that makes sense at all.

Aside from that, I'd assume a scripting language like Groovy to make a few things simpler with a simpler syntax. But again, my biggest problem is finding the niche for any scripting language.

How to use Grovy really depends on your application. For a large, real world Java J2EE app, the readability of the simpler syntax was huge in two important areas - collections and decimal math. Imagine a sales system where there may be more than one proposal, where each proposal consists of products that have configurable features. To calculate the costs, using BigDecimal, Groovy code literally looks like the following.

 
proposals.each { proposal ->
  proposal.products.each { product->
    product.features.each { feature
      proposal.totalCost += lookupCost(feature)
    }
  }
  // apply discount
  if (propsoal.totalCost > discountThreshold) 
      proposal.totalCost *= 0.90
  }
} 

This is something that I can (and do) review with a business subject matter expert and it is relatively painless. With Java, you have to use the BigDecimal method calls such as add() and multiply() which make the code unreadable for anything non-trivial, even for expert Java programmers. Trying coding something like ((a * b) - (c * d)) / e in using Java BigDecimal and you find one Groovy's sweetspots. Notice in the code above, there setters and getters are implied in all of the calls and there are no type declarations, exeception handling or type casting this code.
[ December 13, 2006: Message edited by: Jim Yingst ]

[Gregg Bolinger]

Pretty cool Scott. Thanks for the example.

[Jim Yingst]

Scott, I added code tags to your post. You can use them yourself to preserve indentation of code. Cheers.

[Guy Allard]

Originally posted by Gregg Bolinger:
... But again, my biggest problem is finding the niche for any scripting language....

Greg - I'll stick my nose in here, and go a little off topic.

My experience is that the niche for scripting languages is primarily in the System Administration side of things, not applications programming.

Having said that, there *are* exceptions to that rule.

In general the number 1 rule of SA work is: automate everything.

The number 2 rule is: automate what you missed when you implemented rule #1.

Those jobs will eat you alive if you do not.

I have worked, and continue to work on both sides of that particular fence.

Regards, Guy