Back in the Saddle…

After a few weeks of distractions, I’m ready to get back into some technology work and along with that should be some time to post a few blog entries. I’ve been thinking a bit more about dynamic languages as of late and have decided to spin up on Groovy. Over the next few weeks, I’ll share my experience as I learn to work with Groovy and the Grails framework.

I’d like to start things off with a tribute of sorts to a good friend and co-worker I lost a year ago to cancer. The following write up is an article authored by Steve Metsker in reference to Groovy and the name chosen for the language. Enjoy!

=============================

Instead of using Java, we could all be using Vulcan today. That is, I think we’d be using Vulcan if, in the late 1970’s, the creators of the first object-oriented programming language had called their language “Vulcan.”

When techies try to introduce new technology, it helps (a lot) if the technology sounds strong, logical, and powerful. Unfortunately the creators of what I might have called “Vulcan” named their creation “Smalltalk.”

The penchant for self-destructive marketing is a subject to which I will return, when I get to the latest great innovation in programming languages, a language named “Gladiator”.

I worked as a Vulcan (well, Smalltalk) consultant for four years in the early 90’s. Other than its name, a huge difference between Vulcan and Java is that Java places a large emphasis on developers entering into their program lots of information about exactly which kind of object each object is.

To program in a “Customer” object in Java, for example, the developer must decide way up front all the details about exactly how this object will work. Can it report its name? Address? Credit limit? Java wants all these questions answered the moment you get going with Customer. Vulcan is way more relaxed, and lets developers start using Customer objects without ever specifying just how Customer objects work. Vulcan is a “dynamic” language.

It turns out that dynamic languages make developers much more productive. That is, anyway, the consensus of the speakers at the recent “No Fluff Just Stuff” conference that I recently attended. And I agree.

In my view, all that specification of Customer and other objects is like having training wheels on my bike. The training wheels can serve a purpose, but once I become expert they slow me down, and prevent certain maneuvers I’d like to make. I would also concede that all those declarations about how Customer objects work will actually eliminate about 5% of the testing I’ll need to do. But that 5% is not worth the loss of flexibility that the training wheels provide.

Dynamic languages are on the rise. “Ruby,” in particular, has been gaining market share steadily, especially since the advent of “Rails,” that gives Ruby developers an easy way to develop web pages with Ruby logic underneath.

You might, though, have a big investment in Java. Your developers might already know Java, and you might have software like “WebSphere” that makes it easy to create web services with Java. It would be really nice to have a training-wheels-free version of Java that would be super easy for Java developers to learn, and that would work with all of our existing Java applications. Such a language now exists, it’s free, it works, and it’s called “Gladiator.”

Well, unfortunately, and I hate to admit this, but the creators of Gladiator actually named it something else. They named it “Groovy.” Deep sigh. Boy, I’m afraid that will make it a lot harder for me to convince you that Fortune 500 companies should start using Gladiator. But they should.

Gladiator lets you ignore all those commitments that Java wants you to make, about how you’ll use your objects. The result is that Gladiator programs let you write, typically, about 25% of the programming code that a corresponding Java program would take. It’s fast, light, lean, mean and sits on top of your current Java technology, so it can go (and go fast) anywhere that Java takes you now.

Gladiator is the way of the future, I’m sure, which was something the developers of Vulcan also foresaw. Unfortunately – and it is hard to quantity the full loss we will endure from this self-destructive bent—Gladiator Instead of using Java, we could all be using Vulcan today. That is, I think we’d be using Vulcan if, in the late 1970’s, the creators of the first object-oriented programming language had called their language “Vulcan.”