It's amazing how you can badly reinvent 40 years old wheels. Meaning: it's amazing how all those shaky scripting languages can badly reinvent what Lisp already had invented 40 years ago.

Although Ruby certainly is a winner compared to other (older) scripting languages like Python, Perl (good Lord!), and even PHP since with erb, you can embed Ruby code into web pages, one still has to realize that it is yet another shaky language repeating well known errors from the past.

I was browsing the Ruby "Pragmatic Programmer's Guide" in order to get a taste of the language, and the following thoughts occured to me:

"What's great in Ruby is that almost everything that can return a value actually does."

Well, great. I particularly like the "almost". Now if you find it great that everything returns a value, not only almost everything, why not using a real functional language? There's one such language, invented more than 40 years ago, in which everything is an expression, so everything has a value. This language is called Lisp.

"Ruby has this incredibly powerful feature known as blocks."

Incredibly powerful? C'mon people. Ruby's blocks are just a miserable crutch for a language in which functions are not first class objects. If you find code blocks useful, why not use a language in which functions have just the same status as any kind of data (you can pass them as function parameters, you can get them as return values from functions etc)? There's one such language, invented more than 40 years ago, in which so-called "lambda expressions" (anonymous functions) are just another kind of data. This language is called Lisp.

"Ruby is a fully Object Oriented language" thing."

Well, who said that was a good thing? Where's the gain? OO is not the panacea. Not every program, every way of thinking or expressing a process is suited to OO (BTW, in the "pragmatic" as in far too much computer science literature, there is a constant amalgam between data abstraction and object orientation). If that's just for the fun of writing things like "1.times", I don't see the point. Actually, that's not object orientation at all: it's just a form of namespace. It has more to do with syntax actually.

Admittedly, support for OO is probably better in Ruby than in any of its competitors because it was designed from the beginning and not added a-posteriori as a dirty kludge. However, this changes nothing to the fact that I'd like to be able to use OO when it feels right, while not being overburdened with it when it's not needed.

Guess what, there's one such language, invented more than 40 years ago, in which you have OO support if you wish, and not if you don't. This language is called Lisp. And don't tell me that OO support didn't exist when Lisp was invented. You don't have to modify Lisp to add OO support. It can be written directly in Lisp itself (actually, it takes less than a dozen lines of code to get basic OO support) so it could have been done the very day Lisp was out.

On this matter, let me add that real-life OO systems for Lisp such as CLOS do much better in this respect than many other languages. For instance, you have real multimethods, contrary to C++ in which methods are only polymorphic on their first argument.

"Reflection and ObjectSpace"

One claimed advantage of (included, but not limited to) Ruby is its ability to introspect: examine dynamically the contents of a classes, data structures in general, what functions do etc. OK, but to do that you need a new bunch of structure in your language: special data types, new methods to access the internals of other objects etc.

Again, guess what? There's a language, invented more than 40 years ago, in which you can do just that, only in a simpler way. In Lisp, the only structure is the "list". Everything is either an atom, or a list. So as long as you can handle lists (that's what Lisp was invented for), you can access and manipulate everything in your programs: data, function prototypes, function bodies, everything. And you don't need any additional syntax or feature in the language itself. You access all of Lisp from Lisp, that's all. That's pure introspection, for good. No need for a specific mechanism to the work. I consider it abusive to call Ruby a reflexive language, or even just introspective. BTW, it seems that the authors of the "pragmatic" are mixing up reflection and introspection (I don't know if Ruby has intersession capabilities).

Which brings us to the syntax problem. Part of the power of Lisp is also part of the reason why people won't use it: it has almost no syntax, so it sucks (meaning: to write all those silly parenthesis).

The syntax problem

Well, it's a matter of taste, but personally, I don't think so. You actually get used to it (as probably you get used to Ruby's syntax as well) pretty quickly. Moereover, the problems you might have with Lisp syntax actually depend more on the editor you use than on Lisp itself: a proper use of fontification and indentation makes Lisp code just about as readable as any other language. You can even forget about the parenthesis (darken them, let the editor insert them for you etc).

On the other hand, maybe it's indeed pleasant to have elegant syntax like Ruby's. But is it really that elegant? Let's have a look. Okay. Instances variables. Ah, yes, they start with an '@'. And what's the story about globals? Ah yeah, a dollar sign. And then, there are the constants which must start with an uppercase. Good. I probably could get used to all this mess after a while. But wait! There's this problem with so-called "attribute writers": you have to call them explicitely with "self." in front. Otherwise, Ruby would take them for local variables!

Well, is that what having syntax brings you? Is that elegant? Thanks, but no. I'd rather stick with my parenthesis.

Blank characters

Blank characters have syntactic values in some languages: in Python for instance, code indentation gives information about block structures (maybe it forces you to write properly indented code, but you know, I have a sufficiently clever editor that does it for me. No need to clutter up the language). In Ruby, it actually gets worse: blank characters have semantic values! While "a+b" is an addition, "a +b" is an application.

So it's probably not that hard to remember after all, but what does it really bring you, apart from more ambiguity?



No, really, it's amazing how you can reinvent 40 years old wheels, and what's more do it the wrong way.