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?"

Groovy Falls Behind True Scripting Languages

[Anonymous Coward]

I've used Java a long time, and when I got tired of the hoopla about how scripting languages are so much better than strongly typed languages, I thought Groovy would be a good choice, since "Groovy is an agile dynamic language for the Java Platform with many features that inspired languages like Python, Ruby and Smalltalk, making them available to Java developers using a Java-like syntax." So, I set out to develop a small (internal) project, but after a couple weeks I got tired of the clunky syntax (not to mention the sparse documentation) -- I just couldn't express myself. A few months later I came back and reimplemented the project in Ruby in a fraction of the time, much more clearly and concisely. Now I 'get' what scripting languages are all about.

My (anonymous) $0.02: go with the real scripting languages (Perl, Ruby, PHP, Python, etc.).

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

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.

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