Quickie: An Excellent List of Ruby Idioms

Posted: 4 years ago (2007-11-30 18:47:32 UTC ) / Updated: 2 years ago (2009-11-07 01:10:29 UTC )

Imported from WordPress

Originally posted on 2007-11-30 18:47:32

Some time ago, I wrote about language idioms and why they're interesting and important to me. RubyGarden has published a quite nice list of idioms in the Ruby language (original link). Some of them will be familiar to you from other languages, especially Perl and Python.

Reading through the list, and thinking about language idioms and how they show valuable mindsets, I'm struck by something... A list like this is not a good way to search Ruby for the kind of language idioms I'm talking about, unless you already have a pretty fair grasp of Ruby. That's because the idioms in a list like this assume you already know the really interesting basic idioms like, "iteration in Ruby is usually done by calling 'each' on a Range object and passing a block" and "Ruby API functions usually take blocks for configuration." While these idioms may refine such points, and may point out interesting further things about them, an idiom like that won't usually wind up on the list of idioms, because it's obvious to somebody who learned Ruby from one of the normal sources. Which means that such a list doesn't help you if you're a non-Rubyist trying to mine the Ruby language for interesting idioms to use elsewhere.

Several places in the idiom list, the term 'Rubyish' is bandied about. You'll see equivalent words for other languages as well -- there are often specifically Pythonish ways to do things, for example. The word 'Rubyish' means two different things, and I think it's worth teasing the two definitions apart. A Rubyish solution sometimes means "elegant when expressed in Ruby," or equivalently "plays to Ruby's strengths." Those are the same meaning of "Rubyish." Creating classes at runtime is very Rubyish because, while Python allows it, Ruby has excellent syntax for it and other features that play into such things - it is very Rubyish because Ruby does it quite well. Boolean bit-twiddling is very C-ish because while C's bitwise operators have been copied in many other languages, C provides an efficiency in using them that is rarely matched, combined with an ability to get at the internal bit-by-bit representation of each data type that modern languages rarely provide.

A subtly different, second meaning of "Rubyish" is, "something most other languages do badly." For instance, procedural macros are extremely LISPish, simply because so few other languages implement them at all, and none do so very elegantly. In that sense, passing blocks to functions like "each" and "grep" is very Rubyish. Many languages don't allow it at all, and those that allow it tend to have inconvenient syntax (Python and LISP come to mind).

The second meaning varies from the first when you have features that exist in few languages, but work questionably even where they exist. Procedural macros in LISP are again a good example -- they work far better in LISP than elsewhere, but they're still a tremendous pain to use in LISP. But they exist, and sometimes that makes all the difference. DGD provides full transactional rollback in all variables accesses in any function tagged 'atomic' and everything it calls... In essence, it provides database-like rollback, but straight from the language itself. On the one hand, this can be very painful. Try getting error logs out of a bad request when all your variables and files are rolled back to starting state, for instance. On the other hand, that is an extremely DGD-ish facility because no other programming language except SQL has a facility even vaguely like it.

I think it's worth teasing these definitions apart because in these Dark Ages of programming languages, it's easy to lose sight of how things could be done better. There is always, always a difference between a good idea done in a good, usable way and the same idea with no competition. Contrast Ruby on Rails with solutions like ASP.net. Contrast the internet and HTML with previous services like AOL (pre-internet) and CompuServe. In each case, the previous solutions wasn't exactly good... But it was all there was.

So watch yourself, and try hard not to conflate definition two with definition one. When you judge a thing, try to judge it on its merits separately from judging it against its competition. Sometimes you must choose the best thing available whether it's actually good or not. But never lose sight of what it is.