Fighting words on Ruby

Is anyone but me dismayed by the current state of Ruby? It's a great language, and it has a lot of promise--but there are also major issues that make Ruby and related efforts seem more like a set of academic projects than serious production-quality programming tools.

The main thing that prevents me from using Ruby is that the 1.8 interpreter is too weak, and the other alternatives are too immature. I can use Ruby for scripting in the same way that I'd use Perl or PHP, but I wouldn't want to write a major application using a technology that doesn't support native threads, Unicode, or some kind of GUI. Yes, I know that you can roll some primitive Unicode support into Ruby, and I know that there are several GUI toolkits out there, but overall, Ruby's support for anything beyond basic scripting is spotty.

So what are the alternatives? I guess the front-runner is JRuby, but JRuby is really just a scripting language that works with Java, not something that you'd use to write an application. And compared to MRI, it's really, really slow.

And anyway, why would I want to write something using Ruby 1.8, when I'd just have to change it as soon as Ruby 2.0 comes along? I'm skeptical that Ruby 2.0 will ever arrive; the Ruby 1.9 branch seems like a free-for-all experiment with language features that's not converging on anything coherent. I've seen posts from Matz about Ruby 2.0 on comp.lang.ruby from as far back as 2001. But the fact that Ruby 2.0 is out there puts the the wisdom of developing Ruby 1.8 code into question. I can't even develop Ruby 1.9 code with any confidence, because there are features in 1.9 that might not make it into 2.0.

My feeling about Ruby is that it will never enjoy the success of C, C++, Java, Perl, or even PHP. But I am hopeful that someone will take some of the concepts and syntax from Ruby and use it to create a viable post-Java application development langauge.

Comments

Editor said…
Regarding the sluggish progress moving from Ruby 1.8 to 2.0, you could certainly level the same argument against Perl 5.8 to 6.0, which also seems like it will never happen and involves major changes...

I think Ruby's fine as a scripting language, and it beats the pants off Perl or Python. For programs large/complex enough to need threads, I'd tend to shy away from any scripting language, as the "duck typed" feature that makes them so fast to write makes them such a pain to refactor as the code base grows and changes.
6:21 PM
Post a Comment

Popular posts from this blog

UUIDs as primary keys

I wrote in my last post that I preferred to let the database just store data and and implement all the business logic in my Java code but that I usually let the database handle primary key generation. After thinking about it for a few days, I decided to experiment with using UUIDs as primary keys. Java 5 has a convenient java.util.UUID class that I used to replace the integer identifiers in my entity classes. I found a bunch of blog entries about using UUID versus integer primary keys. UUIDs do have some disadvantages: UUIDs are larger than integer IDs. A UUID, when stored in its most compact form, consumes 128 bits, or 16 bytes. That's four times larger than a regular 32-bit integer. UUIDs are binary. While they fit in a 16-byte binary column, when expanded into a string, they typically consume 32 or 36 characters, depending on whether the string is the human-friendly 00112233-4455-6677-8899-aabbccddeeff format. UUIDs are computationally harder to generate than integers. The disad
Read more

Scala and Kotlin

I've been spending the last three years writing code in Scala. In general I've been pretty happy with the language. It's much more compact than Java, and its higher-level features, such as closures (which have been around forever but which were popularized, I think, by Ruby), enable me to discard several of the Java tools and frameworks that I've had to drag around. Scala also comes with a very powerful collection library that I use on just about every line of code. Lately I've been following Kotlin, which looks very promising. I'm old enough to realize that this may just be a case of the grass looking greener on the other side of the fence. Every programming language has its flaws, and Scala is no exception. There's always the sense that maybe the next language will be The One. The One that does everything perfectly. The One that incorporates all that is good about Java and Scala and C# and C and C++ ( well okay, maybe not C++ ), introduces exciti
Read more

Generating thumbnail images: AffineTransformOp gotchas

AffineTransformOp is a Java 2D filter that can scale (resize), rotate, and/or skew an image. Since I was generating thumbnails, I was only interested in its scaling ability. To scale an image using AffineTransformOp, all you need to do is generate a new AffineTransform using the static method AffineTransform.getScaleInstance, then use it to construct an AffineTransformOp. When constructing an AffineTransformOp, you also need to pass a constant theat identifies the type of interpolation to use, either nearest neighbor, bilinear, or bicubic. Once you have the AffineTransformOp, you just call the filter method, passing in the original image and the destination image, which can be null, in which case AffineTransformOp will create a destination image for you. After generating my first thumbnail image and saving it as a JPEG, I was able to view my generated thumbnail image in Preview, but it looked like crap. It looked blocky, as if AffineTransformOp was using the nearest neighbor interp
Read more