Your Thoughts on the Groovy Scripting Language?

lelitsch asks: "Does anyone have first hand experience with Groovy? I am just coming off implementing a Plone-based intranet CMS and got hooked on scripting languages and Python all over again. Since most of my projects in the near future are going to be in Java or have large Java components, I was wondering if it's time to trade Jython--which seems to be falling further behind the Python release cycle--for something else. Groovy sounds like a fun thing to look at, but it seems a bit new and thin. Also, what are other languages (JRuby and Rhino, for example) you have used to script in Java?"

Comments

Jython and CPython

[CRCulver]

I was wondering if it's time to trade Jython--which seems to be falling further behind the Python release cycle...

Who cares if Jython is a little behind CPython if it already has all the features you need at this point? When I do work with CPython, I work from a relatively old edition of O'Reilly's Python in a Nutshell as reference, and find that the language at version 2.0 already does everything I need it to. While features added at 2.2 and 2.4 are undoubtedly useful for certain audiences, the language itself was complete for most purposes some time ago, and Jython should serve most people fine.

Re:Jython and CPython

[RovingSlug]

Fyi, I have also used Jpype with success, which allows bidirectional operation between Java and CPython.

Re:Jython and CPython

[bwt]

Groovy offers significant advantages over jython and jruby because it was designed specifically to run in the JVM. In particular: a) groovy's class library is the java class library -- you do not subject development teams to two competing sets of class libraries, b) groovy compiles to bytecode which means its interoperability with java is seamless c) groovy can and does actually add syntax and functionality to existing java classes via the GDK.

The problem with groovy is that it is young. It is just starting into the release candidate phase. Some people have written articles bashing groovy for missing expected features like good parsing error feedback. These articles are unfair since they are evaluating a product that is unfinished. I do not recommend groovy for any production purpose yet, it's simply not ready.

Bean Shell Script

[Elias Ross]

From what I've seen, Groovy's a half-baked programming language and unfinished product. See this criticism for a start.

If you want to do embedded scripting in Java, I suggest Bean Shell instead. As a library, Bean Shell is about 280K, Groovy is about 1.7M. And Bean Shell has been around for a lot longer.

I'd like to see Sun add closures and better support for lists/maps in Java itself (e.g. a map function). I'm hoping that pressure from Ruby will make the language grow. C# already made them change their mind about Generics.

Re:Bean Shell Script

[Will Sargent]

Also see Mike Spille's criticism.

Why?

[zaguar]

I think you always need a reason before you try something new and unproven. If it is an enterprise app, why? Is there a feature that Python et al. does not do? If you have no experience with it, and no good reason to switch - Why bother?

Stop the groovy naming

[AubieTurtle]

I wanted to use Drools and Groovy a while back to set up the variable pricing for a tollway. But who on earth is going to put that kind of system in the hands of technology named Drools and Groovy? No one wants to sound like an idiot going to their boss to suggest using anything with those names. Digital started off as Digital Intergalatic Research but quickly realized that suits don't use products that they feel stupid saying. A pun here or there is ok but there is a limit and I think Groovy, no matter what the technical benefits, has stepped over that line and can never be taken seriously. At least the Java community for the most part has gotten over the coffee metaphors when naming new products.

Re:Stop the groovy naming

[Anonymous Coward]

I pronoune it D-rulez for that very reason. Then I throw up some gang signs.

Re:Stop the groovy naming

[jasondlee]

The rule we use around the shop is what my boss calls the Front Porch Test, which really comes from the pet world. It goes something like this: When naming a pet, imagine yourself standing on your front porch calling loudly for your pet (presumably a dog, as cats come around when they want ;). If you would feel stupid if your neighbor were to hear you yelling the proposed name, then don't pick that name. We apply the same logic to application/system names. Works pretty well for us.

There are exceptions, however. More accurately, we have our inside names and the names we tell our customers. For example, we have one web app that allows our users to search for orders in the system, which they call Order Finder, a nice, generic, informative name. The URI for the app is /dwmo, which reflects our internal name, "Dude, Where's My Order." :)

Nothing beats Lua

[Cthefuture]

for lightness and performance. At least as far as scripting languages go. I can't say I'm a fan of Java but if you insist:

There is Java/Lua integration in the form of JLua and LuaJava. Possibly other tools as well.

Re:Nothing beats Lua

[Johnso]

Seconded. Lua is the nicest scripting language I've worked with. It embeds beautifully in both Java and .Net.

http://lua-users.org/ is your friend.

Re:Nothing beats Lua

[david.given]

for lightness and performance. At least as far as scripting languages go.

*nods*

I never use anything else any more --- it's small (compiling into an 200kB binary with no dependencies on my platform), it's fast (faster than Python!), it's simple (you can easily understand the entire language), it's elegant (closures, coroutines, a superb callout interface...), and it's flexible (there's enough functionality under the surface that you can, e.g., rewrite the OO system to better suit your needs). It's also BSD licensed, which means that there are no legal hurdles to using it in your project; if you play games, you've probably already used Lua without realising it.

I will admit to not being overly enamoured with its syntax --- it uses Pascalish if...then...end style rather than C's if () {} style --- but I can easily live with that.

Testimonial: I wrote a gaim plugin not long ago for the Citadel BBS. It was easier to bolt the Lua engine onto gaim and write the logic in gaim rather than try and figure out how to do it in gaim. Lua's coroutines support allowed me to turn gaim's callback-based API into a callout-based structure, which in turn allowed me to invert all my nasty complex state machines, which made the whole thing an order of magnitude less complex. Good stuff.

If You Enjoy Scheme..

[swdunlop]

There is JScheme, and Kawa.

Re:People who like general-purpose languages

[Slack3r78]

I can't think of any reason people would choose C or Java over Ruby.

Even other scripting languages like Perl, Lua, or Python would clearly be foolish choices as well.

Seriously, Ruby's a great, well thought-out language, but if you listened to the hype you'd think that there couldn't possibly be anything better for any task at all. The fanboyism that's grown up around the language is starting to become really irritating.

Hecl

[DavidNWelton]

Hecl: http://www.hecl.org/

it is perhaps less general-purpose than the poster might want, but I have different design considerations in mind:

Small, flexible, very dynamic, and concise - in other words, I want it to be a complement to Java, rather than simply a scriptable Java, ala Beanshell. This means that perhaps you wouldn't want to write the entire app in Hecl, but on the other hand, as a language to write quick extensions with, perhaps it's a bit faster/easier to work with.

The most interesting feature at this point is that Hecl is small enough to run on Java-enabled cell phones, even pretty basic ones like my Nokia 3100, which only accepts Java stuff - no symbian. This means that you can code apps with no recompiling, and also make them very dynamic (you could make an app that downloads code, stores it and runs it as needs be).

Also, for the folks who like this stuff, Hecl is still young, so there's lots of room to fiddle with the language itself, and learn about how a scripting language is built.

Astute observers will note that Hecl is similar to Jacl, but like the poster complaining about Jython getting a little bit out of date... it always seemed like a bit of a losing proposition to me to do a copy of a language in Java, because you miss out, if nothing else, on a *lot* of libraries, and the JRuby/Python/Tcl implementations have always seemed to be playing catch-up.

Ruby/Python + Objective-C

[JPyObjC Dude]

I have looked at Groovy but it does not seem stable enough to use in enterprise apps. However GNUStep for server side development is very solid platform. Objective-C, the language of GNU Step, is very good at talking with Ruby and Python.

My money is that there will be alot of attention passed to GNUStep in the near future as a condender on server side and even client x-platform side app development.

My Ideal web/app server is Free BSD + GNUStep + Ruby and/or Python.

JsD

Java had generics before C#

[SuperKendall]

Come on, there was a beta version of Generics floating around (that worked in 1.4) before C# was even out. The guys adding Generics wanted to add it much sooner (even in 1.3 I think) but there was too much contention in the community about how best to add it.

Java was a little slower actually getting it in, but that's because they had a lot of legacy code to consider and how to make generics that would be useful even with older libraries. In no way was Java actually pressured to include Generics just becasue C# had it, they faced a lot more pressure from a world of developers wanting something like generics from 1.0 on.

SISC Scheme and Scala

[Anonymous Coward]

There is a really nice Scheme interpreter on the JVM called SISC:

http://sisc.sourceforge.net/

IMNSHO Scheme is so much nicer than Python et al that there's not even a decision to be made here as far as dynamic languages on the JVM.

There's also Scala, which is another statically typed language on the JVM. It is SORT of like Java, and can use Java classes natively, but is about 20 times more pleasant to use than Java (if you're into higher-order functions and pattern matching and that kind of thing... but then, everyone should be into that stuff). Anyway, Scala isn't a scripting language, but depending on what you're planning on doing, using it may persuade you that you didn't actually need a scripting language, you just needed a language that wasn't painful to use like Java is.

Scala:
http://scala.epfl.ch/

Indent

[Vexorian]

At least it uses brackets instead of depending on indentation .

Rhino / ecmascript.

[gedhrel]

I've used the rhino implementation of javascript as the basis for a scripting engine in a number of projects now. Javascript is lightweight, supports many useful idioms, and with rhino, integrates well with existing apps. Exposing your APIs to a scripting layer is pretty simple.

What particularly attracted me to rhino (apart from being a bit of a js nut) was the security model. That is to say, it has one, and it's pretty well worked out. It's typically nontrivial to add sandboxed scripting support to an application that integrates with the application's model of user permissions*: if you look around, you'll find lots of examples of various scripting languages being plumbed into applications, but typically the scripting layer is available to "admins only" due to these kinds of security concerns.

* even in java, which already has a semi-decent security model**

** It's a lot of work getting security providers to stack properly. Layering application-domain runtime security over an application running inside a container with its own security provider is barely doable.

Everyone overemphasizes the language

[danpsmith]

A language doesn't have to be updated every 20 seconds to be good. If you started off working in JPython, I don't understand why you would switch it out for a less supported, and less developed language. Python has been kicking around for a while, enough time that they got most of the major kinks out long ago, so I don't think "falling behind in the development cycle" is as crucial as you might think it is. Why not stay with what works unless you specifically REQUIRE the new version's functionality? People are too quick to be trendy with languages...

Re:People who like general-purpose languages

[srussell]

I can't think of any reason people would choose C or Java over Ruby.

I can.

Mind you, I'm do a lot of Ruby coding, and I love the language. However:

1. It is not fast. The speed difference shows up in non-trivial applications, or when processing large amounts of data.
2. It has no support for compile-time type checking. It doesn't have to be strongly typed, but for non-trivial applications, type checking is a big help.
3. It is interpreted, and so has a loose binding to runtime dependencies. This is a huge problem if you're writing applications that you want to distribute, or expect to have running for long periods of time. I can write an app in C and statically compile it, and odds are good that it'll still run four, five years from now. Odds are equally good that something in Ruby is going to change within the two or three years that will break existing applications. Proof of this are the running problems with YAML in Ruby. Heck, I've caused similar regressions in the Ruby standard XML parser on occasion.

Again, I love Ruby. I'd rather code in Ruby than Java or C. I'm more productive in Ruby; it is a better language than C or Java. However, I'm really nervous about using it for any large (code-base) project.

--- SER