Ruby is my work language
I realised something today: Ruby is my work language. I remember years ago when a group of people were discussing, I think on RubyInside (or maybe just ruby-talk), how to get Ruby into the workplace. There was Ruby Insurgency by Andy Hunt—when I review it now, it’s more or less exactly how I introduced Ruby at my workplace. It started off being used by me to do quick little hacks here and there, prototypes and the like; then I introduced it in more mission-critical places one-by-one until it formed a keystone of many of the pieces of architecture.
We have a sizable amount of code that works in production (our testing framework) entirely written in Ruby—its size is of equal magnitude with the software it’s testing. Preprocessors running over all our production code are written in Ruby. The glue that holds our pieces of architecture together are written in Ruby. We’re at the last stage, “Ruby Rules”, of the Ruby Insurgency.
And I can’t enjoy it anymore. Sad, but true. I love OCaml—I don’t think I can actually code in any other language, any more, and have the same feeling of joy that I get with ML, because it’s a very specific one, and Ruby and other dynamic languages can’t deliver it. I don’t think Ruby will be replaced anytime soon as my desktop calculator and ultra-fast script for batch processing and other text analysis, but this basically reduces it to a glorified Perl. Which, I suppose, it is.
I’ve been known to espouse the various joys and delights of Ruby’s object model, but the reality of the matter is that I rarely use it in the use-cases for Ruby that I have left—when I do, it tends to be only because the script is explicitly for one-time use or insular use, and thus will feel no restriction in appending a dozen instances to String or Class or so on. The supposedly great things that I tout the language for are the ones I use least in larger-scale projects.
Of course, this is somewhat a lie—I do use them in larger-scale projects, such as swiftest—but it’s exactly my point that it’s a work thing. While I’ll admit that I don’t have the ML nous to write anything of the complexity or size of swiftest in ML, I’m working my way very readily there in my own spare time (latest achievement: fairly complete (though minimal) lisp interpreter!), and it was only because I had the requisite knowledge on Ruby that I was able to contribute swiftest in Ruby.
That may sound obvious, but the revelation behind it is this: Ruby didn’t let me build swiftest—I did. Anyone could build a similar system in their language of choice, and while naturally the instrumentation of the resulting system and how it would look and feel would sure differ, their end result would be the same, and I daresay a lot of the architecture in any one system would map more-or-less directly onto the architecture in another. I feel the need to draw a parallel with convergent evolution here, though I think one would be neither necessary nor correct, but perhaps you can feel what I’m trying to say: even with a different set of primitives and ideals or motivations at the language level, once you start building greater levels of complexity, you tend to end up with similar abstractions, even if they’re composed in different ways.
You might wonder what draws me to OCaml. It can’t escape all the points made above, right? Well, probably not. But it jives with me even more than Ruby did when I first encountered it—and that’s not to say that Ruby jives with me any ‘less’, per se, but rather I’ve realised that I can jive with a programming language a lot more than I’ve been assuming for a long time. Jive.
I’d like to elaborate on this some more, soon