Slashdot Mirror
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?"
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.
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.
The ratio of people to cake is too big
There is JScheme, and Kawa.
Weapons of Mass Analysis
Fyi, I have also used Jpype with success, which allows bidirectional operation between Java and CPython.
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.
http://www.welton.it/davidw/
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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/
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.
/dwmo, which reflects our internal name, "Dude, Where's My Order." :)
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
jason
Have a good day?! Impossible! I'm at work!
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.
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.