JRuby 0.9.8 can subclass.

That was indeed it. I was using the 0.9.2 build at work and compiled from the subversion repository at home. Do the docs mention this? I did a cursory check on the wiki to try to find out if a current build could subclass but didn’t have much luck.

Hopefully if you have any issues with JRuby you’ll report them on our bug tracker, via JRuby.org.

Indeed. With this one, I wanted to make sure that it wasn’t a PEBKAC issue first.

• Groovy is no closer to LISP than Ruby. And when you consider Ruby’s dynamic through-and-through, right down to its meta-model, I’d say Ruby’s arguably closer than Groovy (and certainly much closer to Smalltalk). But I won’t argue the JavaScript point…it’s very much a functional language.
• JRuby 0.9.8 can subclass. Current trunk fixes many issues with that as well. We’re trying to tie up the loose ends on Java integration this coming month.
• Interpretation can sometimes be faster than “compile always”, especially if you’re generating a lot of code. That said, JRuby will support ahead-of-time and just-in-time compilation to Java bytecode as well.

Hopefully if you have any issues with JRuby you’ll report them on our bug tracker, via JRuby.org. Thanks for giving it a try :)

So, for right now, it is the best gateway to “other people’s code”, which admittedly, you might have little use for. ;-)

I think this gets right to it. Other people’s data? Definitely. Other people’s code? Not so much. Seems easier to just get the data via services or even files or a database than it is to tie yourself down to a particular platform.

No you haven’t. That’s even less valid than notions that Java compiles faster than C (which can be semi-true). All you’ve done is removed the compile phase out of Ant. Really all you’ve ensured is that the code gets compiled each and every time you run it, rather than just the times where you’ve changed the code.

True, although pedantic. In practical terms, it means that I don’t have put up with an explicit compile phase when running my tests. Now, in a normal setting where compiles are kept simple and they don’t demand to check 10,000 other things and download files and etc etc etc, this wouldn’t be so big a deal. For my current situation, it saves time even with the (absurdly long) time it takes for Ruby to compile down to byte code each and every time.

The reason you should look at Groovy and or Javascript is that they are both closer approximations to LISP than Ruby

Hmm. From the presentation I saw last year, Groovy was pretty much Ruby with a few convenience functions for dealing with Java objects. (Lots of “do what I mean” stuff that seemed to work pretty well, for example.) What is it that makes Groovy more like Lisp than Ruby is?

Plus Ruby’s implementation is a bit rougher around the edges than Rhino

As I unfortunately found out, JRuby’s implementation is much rougher around the edges, almost to the point where (for testing, at least. It could still be useful for automation) it’s not usable. More about that in another post. (Or not. The problem I had at work — inability to subclass — doesn’t exist at home. Interesting.)

It’s a calling.

> I still think that in general, I have little use for the Java platform. If I want to write code in something like Ruby or Python, I’ll just use Ruby or Python or whatever as they’re originally distributed. Bolting them on to the JVM really doesn’t do anything for me.

So, I think depends on context. The JVM is the closest thing we have to a universal object-oriented linker and runtime, and it has the advantage of doing dynamic binding to boot. You step away from that and you are in to evil C land with all that entails. On top of that it is a pretty fast runtime (yeah, it sucks for dynamically typed code, but that looks to be fixed in the foreseeable future). So, for right now, it is the best gateway to “other people’s code”, which admittedly, you might have little use for. ;-)

> So I took Chris up on his suggestion and gave JRuby a look for writing tests. It works surprisingly well.

I was under the impression JRuby actually works better than regular Ruby when it comes to Unicode, but I could be wrong.

> …and you’ve removed the compile phase from your test cycle.

No you haven’t. That’s even less valid than notions that Java compiles faster than C (which can be semi-true). All you’ve done is removed the compile phase out of Ant. Really all you’ve ensured is that the code gets compiled each and every time you run it, rather than just the times where you’ve changed the code. Now, I’m all for having the computer do the work and hiding it from the humans, but don’t kid yourself, there is compilation going on there.

> So thanks, Chris. That was a fine idea.

It’s all part of the service.

In answer to the: Groovy suffers from the “if I want to use Ruby, I’ll use Ruby” problem.

The reason you should look at Groovy and or Javascript is that they are both closer approximations to LISP than Ruby, so as per Greenspun’s Tenth Law, you are saving yourself a lot of work and frustration by using them instead of Ruby. Plus Ruby’s implementation is a bit rougher around the edges than Rhino (can’t speak for Groovy). What Greenspun doesn’t tell you is that if you actually were to use LISP, you’d be out of work with a Ph.D. in AI, so Groovy and Javascript are about as close as you can get without getting burned. ;-)

Some folks think Groovy is going to become a big deal, but of course, all the ones I’ve talked to also think Mac’s are due for a comeback. Me, I think Javascript looks likely to become an even bigger deal going forward, what with Adobe open sourcing their Javascript JIT and Javascript 2.0 just around the corner.

Of course, I say all this and I’ve barely looked at Groovy (just been told I should by my betters), my Javascript is pretty weak, and with my “new language” focus being on Haskell, which is kind of the polar opposite of all these dynamically typed languages.

So, I’m a hypocrite. But you already knew that.