[ Go back to normal view ]
BW2 :: the bitwise supplement :: http://www.bitwisemag.com/2
What’s Right With Ruby?
Can Ruby succeed where other languages have failed…?1 April 2007
by Matthew Huntbach
Last month Matthew Huntbach took a sceptical look at the Ruby phenomenon which caused anger and outrage among many dedicated Ruby programmers. Undaunted, Huntbach says that only time will tell if Ruby is capable of realising its full potential…
It seemed to be my remark on Why’s Poignant Guide which did it. For a community which makes a big thing about being "cool" and "fun" I was surprised at how hot under the collar and serious Ruby fans got about what was meant to be a light-hearted comment about styles of tutorials. To be charitable, there may have been a transatlantic translation problem here, as noted in what was one of the more sensible comments in Why’s blog on this article. My (British) use of the childish word "horrid" was an indication that I wasn’t being too serious, Americans, however, do not seem to have this ironical use of the word. I really did not expect my short article to attract the response it did.
However, the Poignant Guide in some ways symbolised my problem with Ruby. Underneath, there is something worthwhile though not earth-shattering. But look what you have to dig through to get to it: irrelevant verbiage which is really just striking a pose, which gives a superficial image of cleverness and "cool" but adds nothing if you just want to get a job done. Given that the community atmosphere of Ruby fandom is often given as a major factor in its favour, I don’t think it entirely underhand to criticise aspects of it. You cannot both sell something by its packaging and then say it’s unfair to criticise it for its packaging.
Down From The Ivory Tower
The strange thing about the replies and web comment elsewhere on my article was how many people seem not to have read the article for what it was and, instead, jumped to assumptions, in some cases personal ones about me. Most of them completely wrong. The person who guessed my politics must be USA Republican was particularly amusingly wrong. But mostly it divided into those who thought I was corporate man, wanting to churn out Java programmers to fit what industry demands, unable to appreciate those cool Ruby programmers who were into fun not business-thinking, and those who thought I was academic man, locked away in my ivory tower, unable to appreciate those busy Ruby programmers rapidly churning out real world applications. Nearly all assumed I had some vindictive grudge against Ruby and wanted to kick it down.
” Academic research into programming languages has for quite a few years now been sterile… Part of the reason for this sterility was the dominance of Java.”
A particularly common assumption was that I was a sour academic who thought everyone should be using academically-derived languages like Haskell, and was angered by the rise of Ruby and similar languages. Did those who made this assumption read my point about the failure of Prolog, and Haskell being "infuriating"? The point I was actually making was that the rise of new languages which do not have any obvious corporate backing should be a source of inspiration to those of us researching into developing new programming languages, but we also have a lesson to learn from the fact that in recent years these languages have not been coming from academia. Elegance and a strong theoretical background are fine things, but they don’t necessarily coincide with ease of use and practical needs.
In fact, I am concerned that academic research into programming languages has for quite a few years now been sterile. When I first became a researcher in this area, academic conferences and journals on the subject were fun, plenty of new ideas which spoke to me as a coder. Now they seem to be dominated by mathematical papers on proof or semantics, which say nothing about the practical issue that concerns me: what are the practical features of a programming language that make it easy to use for ordinary people, productive, safe and efficient? Part of the reason for this sterility was the dominance of Java, and the failure of the academic push for declarative languages. It seemed that the language wars had ended and Java won.
The widespread adoption of Java as a teaching language has led many to suppose it is the language favoured by academics, but the rise of the object-oriented paradigm put into practice by C++ and then enhanced by Java, was industry pushed. The academic obsession of the 1980s, when C++ first arose, was logic programming, adopted by the Japanese Fifth Generation Project. There was a real concern that this would lead to the Japanese coming to dominate the computer industry, and millions were put into research projects elsewhere in the world to try and keep up with them.
I date the academic loss of confidence in the development of new programming languages to the failure of the Fifth Generation Project.
The Roots Of Ruby
Academics should not lose heart, however. Much of what is productive in new programming languages which aren’t derived from research institutions nevertheless owes its origin to ideas that first came from these institutions. The object-oriented paradigm owes its origin to the programming language Simula, designed at the Norwegian Computing Centre. Reflective metaprogramming (the idea of a computational system which can inspect and manipulate its own internal structures), owes its origin to work on 3-Lisp at MIT. These are at the heart of Ruby, which also shows obvious influences from the pure functional programming which developed into Haskell. Interestingly, one of the fall-outs of the research inspired by the Fifth Generation Project is the now widely admired concurrent language Erlang.
”I am actually interested to see ideas which were once abstruse academic concepts taken and put into practical use in a language like Ruby…”
Thus it was particularly sad to see abusive comments from Rubyists aimed at me, which seemed to assume that, as I am an academic, I should be treated as a worthless hate object. I am actually interested to see ideas which were once abstruse academic concepts taken and put into practical use in a language like Ruby. The idea that there is some huge gulf between myself as an academic who likes exploring new programming language concepts, and hackers who like putting them into practice is nonsense; we have different roles but we should be working together.
As an academic, however, it is my duty to be sceptical and to ask awkward questions. That is why I reacted against the Ruby hype and asked, in particular, for further evidence for some of its claims. This concern was take up further by Hacknot who was rather more rude about Rubyists than I was. In fact, my comments on the language as opposed to the hype around it were fairly balanced. I noted there was a case for the much looser typing mechanisms of Ruby, though I expressed my concern that this might cause problems if Ruby became established as a general purpose language for writing large-scale long-lived code. Why is it that so many Rubyists read that as expressing "hatred for dynamic typing"? I raised similar concerns with metaprogramming. If the language is to develop, there must, of course, be open debate in which concerns are raised and answered.
I made no pretence over the fact that what I wrote reflected my initial experiences with Ruby. But part of the argument used by its supporters is that you need only a short period of experience with Ruby to appreciate its superiority. I am fully aware that to know a language properly one must have long experience with it. It took me several years of teaching using the Java language, exploring it by writing code in it, before I felt I had a really deep grasp of it. As someone who teaches programming I have different insights into it than those who work in commercial development and I reflected these in my article. I would ask that, just as those who work in commercial programming want their experience and comments on that basis be respected, my experience in teaching programming also be respected.
Those for whom programming comes naturally may not have the feel for how difficult it is for most ordinary people. If you have not had long experience of trying to teach programming, do not jump to the conclusion that difficulties experienced are due to "bad teaching". My own experience is that in a class of a hundred in a middle-ranking university Computer Science department, less than ten are true hackers, in the old sense of the word of people who have a natural flair for programming and grasp it right away. I can see that the intricate nature of Ruby has a particular appeal for such people, but if you are one of them, do not assume everyone else is like yourself.
Ruby: The Next Generation…?
There is a concern, which was reflected in a previous Bitwise article Ruby Off the Rails, that with Ruby having come to prominence due to its conjunction with Rails, many people are not making sufficient distinction between the two. Ruby is not even that "new" in strict calendar terms, but what is new about it and similar languages is that having previously been seen as having a use only in limited domains, and Rails is an example, there is a growing movement to push them forward as general purpose languages. Ruby has been explicitly noted as a post-Java language in that sense. If the quicker development time using Ruby is actually due to Rails, then that’s not actually an argument for Ruby on its own.
My point about maintainability of code, which was actually my main criticism of the language itself, seems to have been answered by no-one. We will not know for sure until the first generation of Ruby-developed systems has entered the second generation and it’s the updates that people are working on. I think there actually are answers to my points, in particular that more sophisticated programming environments reduce the need for built-in checks in the language itself. It may well be that the mathematical work of my academic colleagues I was so disparaging about above will lead to more sophisticated tools which manage the complexity of languages designed for ease of practical use rather than theoretical elegance.
” Ruby has led the way into what is required, in particular the ease of interaction with other components in a practical system such as a web application. This is what makes it work within Rails and is, I think, is the key feature lacking from the old declarative languages.”
I still think, however, that something similar to Ruby but with a stronger theoretical basis could be developed. Ruby has led the way into what is required, in particular the ease of interaction with other components in a practical system such as a web application. This is what makes it work within Rails and is, I think, is the key feature lacking from the old declarative languages. The traditional functional and logic languages were designed on the basis that they would manage the entire computation and straight input/output, let alone any more complex interaction, was a minor "dirty" issue. So what I require is a language which is both interactive and has the clear and clean operational definition of the sort first proposed by Peter Landin in his landmark paper The Next 700 Programming Languages. A language should be fully defined by rules which translate it to an underlying calculus and rules which say how that calculus operates. It is in not living up to this that I found Ruby ad hoc, and my judgement seems to be supported by those who have looked into these issues in more detail.
Algorithms, Arrays and Academics
On issues of syntactic trivia as opposed to deeper operational issues, it’s a mark of the lack of insight of many of my critics, that they failed to understand my point about the addition operator with arrays, and supposed that it was a major concern of mine that I thought it should work by pairwise addition rather than concatenation. In fact I expressed a personal opinion neither way. It happened that while I was writing my original article, I came across an article elsewhere where someone claimed that pairwise addition was the "obvious" way addition should work with arrays, and I happened to remember it didn’t work that way in Ruby. My real point was to express caution about the "Principle of Least Surprises", and in particular over the claim that the decisions that have been made in Ruby over syntax are somehow more natural than those in other languages. I illustrated that with this one example, I could have chosen plenty of others.
In my experience, the first hurdle at which people learning to program fall is the inability to distinguish between an example and the more general concept it was brought in to illustrate. It shows a basic inability to abstract; and then procedures and everything else that follows are never properly understood since it all involves abstraction: the ability to distinguish between the general and the particular. But such people can often get by with programming which involves just fiddling with boilerplate code, or flat calling of library routines.
It may be unfair, but I was reminded of this by my many Rubyist critics who failed to note the array addition example was just an example. As one of them put it, "I’d rather build webapps used by hundreds of thousands of users than be considered a ’good computer scientist’". I wonder if this means "I failed CS101 and I don’t care". I think I can see why these guys don’t like academics. Although, while I’m an old-fashioned computer scientist still interested in core things like programming languages, many of my colleagues are doing things in useability, social implications, and much else where they may have other things to say about your webapps than discussing how they are coded. What this discussion has also revealed is that many people’s idea of what academic computer science teaching is about is stuck on what it was several decades ago. The days when it was dominated by algorithms and obscure programming languages are long gone.
If building webapps is all you want to do, and if there’s a tool which does most of the work for you, so the only coding you have to do is fiddling with a few snippets which glue it together, that’s fine by me. The claim with Ruby is that though it does a good job here (which I don’t dispute) it has much wider capabilities. That’s what interests me, and I am genuinely interested to see a family of languages which originated from this gluing and text-processing role break out and make claims to be able to do more than this and to take over from the traditional heavyweight languages. That is why I took a long hard look at Ruby, and why, despite the negative reaction to my first comments on it, I shall continue to do so.
Matthew Huntbach is a Lecturer in Computer Science at Queen Mary, University of London. During his eighteen years working there, he has taught introductory and intermediate programming in a variety of programming languages. His research interest is in the development of practical programming languages which are inherently concurrent. He has a DPhil in Artificial Intelligence from the University of Sussex.
