JRuby

I landed in New York this morning, and I'll stay until Thursday. If anyone feels like taking a beer and discussing programming languages (or something else), don't hesitate to mail me or comment on this blog.

Martin Fowler writes about one language, and neatly encapsulates what I think about the subject in the way I would have written it, if I were actually a good writer. Go read.

I have been asked for the slides of my FOSCON presentation. They can be downloaded in PDF format from here: http://ologix.com/JRubyWhirlwindTour.pdf.

As you almost certainly now at this time, IronRuby was released the beginning of this week (read more here, here and here). Now, this of course begs a few question. But first things first: note that Microsoft have decided to host the project on ... [More] RubyForge, and will do so sometime next month. Not only that, it's actually a very open source license called MsPL: Microsoft Permissive License. If you look at the license, you will see that it's almost exactly a BSD license, except that the patent restrictions have been clarified. Obviously, I'm not a lawyer, but I can say that this license seems very nice and will allow good usage of IronRuby in many cases.The code base is strictly limited right now. The things that actually work is most of the core language structure, the Array and String classes and .NET Interop. Of course, that is an extremely large achievement to have this working so well. Also, the compiler seems to generate very good code and judging from microbenchmarks, it has the possibility of having very good performance. It's important to remember that many of the more important corner cases aren't supported yet, and it is these that usually drags the performance of Ruby implementations down. I'm confident that Lam and company can handle this, though.Overall, I would say that this is looking very good. I would recommend .NET people to take a look at it, and also try to contribute. Very soon, you will be able to contribute code back to everything except the core compiler and DLR.Finally, the question on everyones mind: when will IronRuby be finished? I don't know, but I think it can happen with 6-12 months. The concerns raised two months ago have been resolved internally by Microsoft, which makes IronRuby a very real and important project. [Less]

Right now we're trying to decide if JRuby should upgrade from Java 1.4.2 to Java 5. There are some compelling reasons for this, but I'm not a 100% sure it's a good idea. Any comments from my readers?In practical terms, this will mean that JRuby 1.0 ... [More] will continue to be supported on 1.4.2, but new development will only work on Java 5 or higher. There is talk about using retrotranslator for handling 1.4.2 compatibility in later versions.So. Please, comments and opinions! [Less]

I have been working on porting/replimplementing the YARV compiler and machine from Ruby over to JRuby.   I did not start from scratch, but MAN o MAN YARV is not a small piece of software.  It is taking some time to grok things let alone make a Java ... [More] version of it.  Here is a short entry about my efforts. My first swipe was to take the original JRUBY-YARVmachine that Charlie had implemented (he got enough machine working to run a recursive fib method) and then build on top of that.   The most siginificant piece was taking the exec() methods local  stack and moving it to an instance variable.  The benefit of doing this was not having to allocate a fresh stack every time exec() got called (at least once per method).   The dirty details of doing this is that if your bytecode sucks and leaves around objects on the stack then things will blow up sooner or later.  It also means one machine per thread.   Neither is a very big negative.  Anyhow, after completing this and making a few stack operations a little more efficient  the results show that the recursive fib method is just a little faster than our pure-interpreted mode.  If you combine this with the fact that our compiler really does not optimize the bytecode it generates, then I think YARV is showing a lot of promise.   Add the idea of dynamic translation from YARV bytecode to Java bytecode when the right pattern appears and my mouth water starts to water. Working on the machine is interesting, but I decided I needed to understand more about YARV bytecodes themselves.  What better way than to work on a YARV compiler.  The last week or so I have been expanding our compiler and reworking some things on it (Ola and Charlie? did a rough cut of the compiler to generate enough bytecode for a recursive fib method).   My sandbox is still riddled with errors, but I am learning a lot and hope to have something to show for it in a couple of weeks. One complication is that JRuby internally does some things differently.  This leads to head scratching.  We have no Literal Node (not to be confused with ILiteralNode which I poorly misnamed).  Or DASGN_CURR Node.  We inverted dependencies between CALL/VCALL/FCALL and ITER/BLOCKPASS nodes.   Another complication is that MRI YARV is written in C and we are written in Java.  It is easy to spend time redesigning areas to work better in Java when you could just punt and just port C code directly.  I am still weighing the dis/advantages of that. Ultimately, I think JRuby needs to move the interpreter from walking the AST to a flat bytecode.  The benefits of working this way will make it easier to optimize and should also decrease our stack depth.   All the compiler books say an AST is an intermediary form.  Lets make that true in JRuby! [Less]

I am at OSCON with Roy Singham, the founder of ThoughtWorks. We're here as sponsors. If you are here too - Roy likes nothing more than an argument about anything related to a) the merits of various languages, b) Agile versus waterfall, c) the best ... [More] cell-phone. Seriously, if there is something interested that should be big for custom-app dev in the enterprise, tell Roy or the other ten ThoughtWorkers here about it and we'll help make it happen. Come by our booth at the left side of the expo hall if you want to find us. [Less]

I had a very good time at FOSCON III with the Portland Ruby Brigade yesterday. There were lots of entertaining talks too. I would say that my "lightning talk" wasn't really a lightning talk at all. Unless you count the speed of my talking... I ... [More] managed to race through all my 22 slides - all of them shock full with information - in the time alloted to me. Hopefully people learned something from it.Chad Wathington demonstrated Mingle which also was very nice.John Lam showed us a taste of IronRuby, and also talked some about the implementation particulars that made certain things faster in IronRuby than on MRI. Interesting stuff, but I'm looking forward to the full talk tomorrow.Alan McKean from GemStone showcased GemStone/JRuby - still a work in progress though. For those of you who don't know what GemStone is, think extremely powerful object persistence. And they're building a new version for Ruby, on top of JRuby. Very cool.I realized that there are a few points about JRuby that haven't been emphasized enough, though, so here is there executive summary bullet points:JRuby is totally Java compliant and runs on any Java.JRuby is 1.0JRuby supports RailsThoughtWorks offers commercial support for JRubyJRuby performance is on par with the C implementation, on average. [Less]

Yesterday was the first tutorial day at OSCON. Due to some planning mistakes, I didn't get the correct conference pass, so I missed the first tutorial. After that was sorted out I proceeded to the second tutorial of the day: Advanced Techniques for ... [More] Parsing, by Mark Dominus. Of course I knew that the code would be Perl, but that didn't disturb me so much, since I expected to see some advanced parsing techniques. This is where disappointment hit me. Maybe it was advanced Perl code used, but it was not in any way advanced parsing. The first 2 hours were spent implementing a recursive descent parser with 7 productions. After that, I decided that I wouldn't be learning anything from this presentation, and headed back to the hotel, which was good, since I got sick that afternoon and spent the rest of the evening slightly delirious in my bed.But now I'm up and going again, sitting here waiting for the tutorial "Real World Grails" to begin. I'm looking forward to see how Grails is actually used, since the presentations I've seen on it usually just show scaffolding and simpler things.I have also decided on the subject for tonights FOSCON, but the slides are not finished yet. And the topic I choose is kind of a cop out: JRuby Cavalcade is the title of the talk, and I will basically just run through loads of interesting and funny JRuby things until I run out of time or gets booed of stage. Hope to see you there! [Less]

I guess most of you have read the latest happenings in the whole NBL-story. Steve Yegge have created a Rhino on Rails; a JavaScript version of Rails. I have meant to write about this for a few weeks, but I felt I wanted to think it through before ... [More] writing about it.Of course, it's really cool that Rhino on Rails exists, and may someday be open sourced. On the other hand, the current version have no counterpart to ActiveRecord - instead it works against internal Google data systems. This may make very good sense from the pov of Google, but will make it hard to gain traction outside of Google when/if the open sourcing happens. At that point, a ActiveRecord version written using JDBC and Rails should happen. I'm personally looking forward to it, because such an undertaking would be able to take more advantage of JDBC than for example ActiveRecord-JDBC can do. ActiveRecord done "right" so to speak, but in JavaScript.But is JavaScript the language of the future? What does it have that separates it from other current languages - most notably Ruby? Well, at first glance the big difference is in the amount of implementations. JavaScript have a multitude of implementations, while Ruby has three (Ruby, YARV? and JRuby), with many more in the works. JavaScript though, have a incredible amount of implementations, most of them bad.It's got a standard. It's got full closures and a few more neat futures. And it has prototype object orientation; a very different object model compared to the standard of inheritance based object systems like Java, Ruby and Smalltalk.On closer inspection, the prototype based object system is not really such a big deal. In fact, you already have it in Ruby. Just use Object.new and Kernel.clone. Not very practical in Ruby, but you can do it without any problem. Remember that the difference between dup and clone is that clone will actually copy the metaclass of the object, while dup just makes the duplicate use the same real class.I see some advantages that JavaScript has over Ruby, that can actually count as real advantages. The spec is arguably one. Several good implementations is another. It's easier to make JavaScript have good performance. And maybe most important: most developers already know it to some degree or other.But will it be the NBL in some form or another? No, I don't think so, for the simple reason that to many developers hate it. Not because of the language itself, but due to the connection with bad browser implementations. This is a debt that it will be very hard for JS to get away from, and I think it will tip the point against JavaScript compared any other language poised for the position of being a big language.Further, I really don't believe in the idea that there will be a next big language. Call me strange, but just because we've had this cycle two or three times doesn't mean it will continue like that. I believe development is qualitively different now compared to 15 years ago. The challenges we meet are different and demand different tools. One single language will not cut it. I think the future lies in layered languages with different properties. [Less]