Xblog: Ruby On Nails Scratching a Chalkboard

Ruby On Nails Scratching a Chalkboard

Christopher Smith — Tue, 12 Sep 2006 10:59:00 -0700

So, as I explore how Ruby works, I’m discovering some bits of ugliness. It’s syntax is increasingly reminding me more of Perl than Smalltalk. A case in point: blocks.

I’d heard so much about Ruby’s Smalltalkishness that I was a bit taken aback when I saw control statements in the language grammar. In Smalltalk, control flow is managed using methods and blocks, and I knew Ruby had blocks (this is one of the things that you hear so much about in Beyond Java), so why did they need these control statements? In Smalltalk, control flow looks like this:

1 + 1 = 2
  ifTrue: ['it is true']
  ifFalse: ['it is false']

Now, I can’t claim that this provides any real productivity boost over Ruby’s approach:

if (1 + 1 == 2) then
  'it is true'
else
  'it is false'
end

But I was kind of surprised, given Ruby’s ties to Smalltalk, that someone hadn’t hacked it in. So, I went about hacking it in myself. That’s when I found out why.

It turns out that blocks in Ruby have a very high level of syntactic sugariness. Not only do they have their own special literal form (which is a key advantage over say Java’s Inner Classes, or C++ functors without boost::lambda), but they also have their own special status which really makes them non-objects. (I found it amusing to discover that the most non-object entity in Ruby is a block).

Here’s the magic: blocks aren’t passed as normal parameters to functions. They are passed through an implicit variable (showcasing Ruby’s Perlishness here). So, if, for example, I wanted to add something like Smalltalk’s ifTrue: to Ruby, I’d do the following:

class TrueClass
  def ifTrue
      yield
  end
end

class FalseClass
  def ifTrue
  end
end

(1 + 1 == 2).ifTrue { puts 'Math works' }
(1 + 3 == 2).ifTrue { puts 'Math is broken' }

Notice that ifTrue doesn’t appear to take any parameters, and neither does the “yield” method. In reality, the block is an implicit parameter. One Ruby tutorial claimed this is a good thing, because it means that all Ruby methods can take a block as a parameter…. even if they don’t use it. Me, I’m a big fan of explicitness, but I can see that in a scripting world, sometimes these kind of shortcuts are nice to have. What’s bad about this is that not only does it mean that all Ruby methods can take a block as a parameter, it also means all Ruby methods can only take exactly one block as a parameter, and it has to be the last one.

Now, it turns out that Ruby has a wrapper around blocks called Proc, which lets you treat a block like a real object, Of course, it has all the syntactic beauty of Java’s Inner Classes. Here’s how you can do ifTrueifFalse in Ruby:

class TrueClass
  def ifTrueIfFalse(trueProc, falseProc)
    trueProc.call
  end
end

class FalseClass
  def ifTrueIfFalse(trueProc, falseProc)
    falseProc.call
  end
end

(1 + 1 == 2).ifTrueIfFalse(Proc.new { puts 'Math works' },Proc.new {puts 'Math is broken'})

But wait! There’s more! Since Proc’s are proper objects, you can query them for meta-information, which is really handy for various dynamic programming tricks. Only… Ruby’s interface is kind of weird. Proc’s have this method “arity” which tells you how many arguments the block takes… sort of. For reasons passing understanding, if a block takes zero arguments, the function returns “-1” intead of “0”, and if it takes 1 argument, it returns “-2” instead of “1”. So, now we’ve established that it can never return 0 or 1, and that you can’t always use the return value as an collection size for your argument list. Here’s where it gets really crazy though: if your function takes a variable argument list with it’s last parameter, arity returns “0 - # of args”. So, quick question for you: if arity returns back -2, does that mean it’s argumetn list is one argument long, or that it takes one argument followed by a variable list of arguments? I’m not sure how Bruce Tate can claim that Ruby doesn’t have some weird anachronisms that get in the way of doing metaprogramming with a straight face.

In fairness, the case where you want to pass a single block as your last argument seems like the common case, and Ruby is a scripting language after all. I’m mostly annoyed because I’ve heard so many people talk about Ruby’s elegance, comparing it favourably with Smalltalk (which admittedly is not entirely without warts). Upon inspection it seems to have warts just like other languages (well, some languages have a few more warts than others). Still, there is hope. Ruby does seem to have some genuinely nice features, and it is open source, so there is always the possibility that some of these idiosyncracies will get cleaned up in the future.

UPDATE: So, someone with some real Ruby experience has clarified for me that nobody actually does “Proc.new” in Ruby. Instead they use Lambda. So, invoking my ifTrueIfFalse method would normally be done like so:

(1 + 1 == 2).ifTrueIfFalse(lambda { 'Math Works' },lambda {'Math Doesn't Work' })

Which I have to admit does seem a lot prettier for some reason.

ANOTHER UPDATE: I’ve gotten some great comments to this article, and I thought I should incorporate their content. First, people have suggested that you can break up ifTrueIfFalse in to two calls that are chained together, and then get back some of the elegance. I thought about this when I first looked in to it, but you lose the ability to pick up a return object cleanly.

Antti Tarvainen provided some excellent points. In particular he clarified the difference between a Proc that takes no arguments (arity returns 0) and a Proc that doesn’t define any arguments returns -1. Furthermore, arity has been updated for Ruby 1.9 to what seems like a more sensible behavior. I noticed that even in 1.8

puts lambda {|a|}.arity

returns 1, which suggests the Ruby documentation is a wee bit out of date.

I still think it’d be far more sensible to not overload the arity method and instead have numArgs? which gets you the number of required arguments”, hasOptional? which gets you back a boolean as to whether there are optional arguments, and argsDefined? which gets you back a boolean as to whether the Proc has defined arguments at all. Overloading the meaning of the return value just results in more code that needs to check for special cases and cases where you can’t actually know which of two states is correct.

Also, there seems to be confusion about my point in comparing it to Smalltalk’s ifTrue:ifFalse:. Of course one should use Ruby idioms when doing Ruby. The ifTrue:ifFalse: example is just a simple and well understood example of having more than one block in your parameter list. I will say that there is a certain kind of semantic elegance that comes from having all your control flow done through methods and objects. Ruby advocates always say that in Ruby “everything is an object”, but it appears that blocks and control flow expressions are not, and in this regard Ruby doesn’t quite live up to expectations set by Smalltalk and LISP.

"Ruby On Nails Scratching a Chalkboard" by Jeremy Leader

Fri, 22 Sep 2006 12:38:42 -0700

Algol -> Fortran -> C -> C++ -> Java ->() C# is a pretty logical progression of languages, and that *is the progression in the mainstream.

I don’t think I’d describe Algol as “mainstream” in the same sense as the others in that list. While Algol had a lot of influence in academia and on the design of other languages, the only commercial software development I know of using Algol was on Burroughs/Unisys “Large Systems” (aka B6xxx series) mainframes, and the Algol they used was very non-standard.

I’d say the mainstream predecessor to Fortran was various kinds of assembly language (for particular IBM mainframes, but I know little about that world).

"Ruby On Nails Scratching a Chalkboard" by Dave Newton

Wed, 20 Sep 2006 18:18:08 -0700

Dammit! Sorry. Server musta been slow and there’s no indicator to say something is happening; I thought Firefox had locked up.

"Ruby On Nails Scratching a Chalkboard" by Dave Newton

Wed, 20 Sep 2006 18:17:08 -0700

There are also a number of reasonable books that discuss development in Squeak which help out a lot.

I’ll have to try the Cincom, though; it would probably generate less resistence to management just because of the way it looks.

"Ruby On Nails Scratching a Chalkboard" by Christopher Smith

Tue, 19 Sep 2006 20:31:55 -0700

I used to use Smalltalk professionally in days gone by (over a decade ago). I was using Visual Smalltalk which I believe has been discountinued. These days I mostly use Squeak (and I agree that it’s UI is quite foreign, there is a project to bind it to wxWindows which I watch with great interest) and Seaside for personal web projects, but I’m experimenting with Cincom (which I’ve used in the past) and Vista Smalltalk.

For getting started I usually recommend people use one of Cincom or Squeak. Squeak’s environment is more foreign, but it does a fantastic job of getting you started. Cincom’s stuff is more standard fare, but it’s a more commerical grade experience (well, except for my pain with Linux).

"Ruby On Nails Scratching a Chalkboard" by Dave Newton

Tue, 19 Sep 2006 09:22:35 -0700

@Elise:

1) There are lots of reasons; a lot of it boils down to inertia… Algol -> Fortran -> C -> C++ -> Java ->() C# is a pretty logical progression of languages, and that *is the progression in the mainstream. There’s a few others thrown in there (COBOL, Basic); I’m speaking in general terms.

2) Lisp and Smalltalk syntax isn’t difficult to grasp at all; like Christopher said, minutes. Wrapping your head around the languages’ concepts is what takes the effort.

As you’ve discovered, Ruby combines things a bit (with a couple of warts :) and may make entry in to one of its “parents” easier.

"Ruby On Nails Scratching a Chalkboard" by Elise

Mon, 18 Sep 2006 21:12:07 -0700

Christopher:

Your simple explanation has prompted me to dig a bit further this time and try some Smalltalk coding. Thank you.

The Cincom primer is great (thanks for the link) and the free VisualWorks environment looks appealing (first impression) compared to the open source Squeak Smalltalk environment I’ve tried in the past. To be fair I haven’t used either in any depth whatsoever. This comment is purely based on asthetics and my past IDE experience.

Which Smalltalk do you use and do you use Smalltalk in any professional capacity?

"Ruby On Nails Scratching a Chalkboard" by Christopher Smith

Sat, 16 Sep 2006 12:13:15 -0700

Elise:

Why hasn’t Lisp or Smalltalk become as mainstream as Java or C++ if they are so powerful

Well, there is long and tortured history behind each of them, but it’s worth noting that both of them were mainstream at various points in time. I think one thing to keep in mind though is that a more powerful language isn’t always an asset.

Why is the syntax so difficult to grasp for the uninitiated yet so beautiful to the practicing?

The beauty comes from the consistency. and simplicity. Honestly, I’ve always been able to explain the syntax of either to someone in a matter of minutes. The catch is that their syntaxes are both quite different from the BCPL family of languages, which seems to intimidate people. They look alien but I assure you the syntax is far more approachable than most languages. LISP’s infix notation is a bit weird for arithmetic, but otherwise is pretty similar to procedural code. Smalltalk’s syntax is different, but it is incredibly simple. You basically only have three different bits of syntax to learn to get started, and there’s maybe five or six syntactic structures in total. Cincom pretty much sums up the key bits of the syntax on one page..

"Ruby On Nails Scratching a Chalkboard" by Elise

Sat, 16 Sep 2006 11:11:30 -0700

I admit to not having any Smalltalk or Lisp experience.

Having experienced Logo, Forth, C, C# Python and Ruby, looking at languages like Lisp and Smalltalk, the syntax often looks alien and unapproachable, hence my lack of progress with them.

Ruby caused me to look at Smalltalk and Lisp. Yet despite the overwhelming love the proponents have for them, The value is difficult to comprehend. As one commented above, it is highly likely my experience with procedural languages blinds me to the benefits of Lisp, Smalltalk and other non procedural languages although Ruby is now my favorite which mixes these and other programming paradynes.

So, I have two difficult questions:

1) Why hasn’t Lisp or Smalltalk become as mainstream as Java or C++ if they are so powerful?

2) Why is the syntax so difficult to grasp for the uninitiated yet so beautiful to the practicing?

"Ruby On Nails Scratching a Chalkboard" by justin

Sat, 16 Sep 2006 07:56:26 -0700

@Mike B:

thanks to our good friend whytheluckystiff, one is never without ruby when there is an internet connection available: http://tryruby.hobix.com/

"Ruby On Nails Scratching a Chalkboard" by Dave Newton

Fri, 15 Sep 2006 21:55:39 -0700

I was all excited about learning the secret handshake then you said you were kidding.

snibble

@Christopher: I don’t think anybody ever said there was anything wrong with the different approaches, just that you had expected something else and discovered one of Ruby’s Little Uglies :)

"Ruby On Nails Scratching a Chalkboard" by Tero

Fri, 15 Sep 2006 18:44:55 -0700

This whole discussion reminds me of something that went on for months and years in the C++ circles: “how to build an auto pointer”. I think the final level in elegance was reached after many articles and rounds of critics and suggestions. Hurrah, we managed to create an auto-pointer class.

“Ten different ways to write one line of code that does the same thing in Ruby” is probably even more hilarious than the auto pointer. No wonder programmers are again drooling over a chance to spend their time on endless niftiness and cool programming tricks which approaches cryptography.

You could start secret societies that share their wildest Ruby tricks. The sheer obscurity of all the tricks would truely make such societies a hit.

…just kidding, of course.

"Ruby On Nails Scratching a Chalkboard" by Christopher Smith

Fri, 15 Sep 2006 17:31:24 -0700

Dave Newton: If you look at the language grammar for Scheme, say at http://www.htdp.org/2001-01-18/Book/node43.htm (which doesn’t use ‘if’ but that’s not important) see how orthagonal it is? See how the keywords simply occupy the same space as non-keywords? Regardless of implementation the syntax doesn’t change.

Okay, let’s some this up:

Ruby has special syntax for control flow statements, not that there is anything wrong with that.
Smalltalk just uses methods and blocks to do all of it’s control flow statements. Aside from the class library, there is no need to mention them at all in the definition of the language, not that there is anything wrong with that.
LISP requires special primitives in order to implement control flow (and if you think that’s wrong, try to implement cond from car and cdr ;-), but the syntax for this primitives is logically consistent with its normal function syntax, so you only bump in to this if in specific cases where you try to treat those primitives like regular functions/symbols, not that there is anything wrong with that.

Can we all pretty much agree on that?

"Ruby On Nails Scratching a Chalkboard" by Dave Newton

Fri, 15 Sep 2006 17:22:29 -0700

That simply isn’t a syntactic construct in the same way if/then/else etc. are, it’s a special form that takes two expressions as arguments. That’s just not how languages with more syntactic noise operate, but whatever. How it’s implemented (a special form, in this case) still isn’t relevent.

If you look at the language grammar for Scheme, say at http://www.htdp.org/2001-01-18/Book/node43.htm (which doesn’t use ‘if’ but that’s not important) see how orthagonal it is? See how the keywords simply occupy the same space as non-keywords? Regardless of implementation the syntax doesn’t change.

"Ruby On Nails Scratching a Chalkboard" by Simen

Fri, 15 Sep 2006 15:13:03 -0700

It does have its own syntax. Here’s the part that describes it in R5RS. The fact that it all looks the same, and that code is data in Lisp, is irrelevant. This isn’t implementation-specific.

The Lisp “if” special form can’t be implemented as a procedure, because Lisp semantics are strict, meaning a value is computed even if there’s no need for it, contrasting with lazy languages such as Haskell. It can be implemented by macros, though.

This contrasts with Smalltalk, where ifTrue:ifFalse is a method, used with standard method calling syntax.

Bottom line, Ruby isn’t Smalltalk, or Lisp, or Perl, and it doesn’t try to be, but that block thing sure is annoying.

"Ruby On Nails Scratching a Chalkboard" by Dave Newton

Fri, 15 Sep 2006 14:02:28 -0700

Its Iimplementation* is irrelevent; it does not have its own syntax, like if/then/else in Ruby and similar languages.

"Ruby On Nails Scratching a Chalkboard" by Simen

Fri, 15 Sep 2006 11:21:20 -0700

Dave: no it’s not. If is a syntactic construct. It just looks like a function because everything in Lisp is a list. Watch, Scheme and Common Lisp:

$ csi
   ________    _      __
  / ____/ /_  (_)____/ /_____  ____
 / /   / __ / / ___/ //_/ _ / __ / /___/ / / / / /__/ ,< /  __/ / / /
____/_/ /_/_/___/_/|_|___/_/ /_/

Version 1, Build 63 - linux-unix-gnu-x86
(c)2000-2004 Felix L. Winkelmann
#;> (define my-if if)
Error: unbound variable: if

$ clisp
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I   `+' /  I      8         8           8     8        8    8
     `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006

[1]> (defvar my-if #'if)

*** - FUNCTION: undefined function IF

Christopher: yes, you’re right, the block thing is stupid, and it has bugged the hell out of me before.

"Ruby On Nails Scratching a Chalkboard" by Dave Newton

Fri, 15 Sep 2006 10:55:14 -0700

I’m not sure how you’d implement put:at: like that.

"Ruby On Nails Scratching a Chalkboard" by Peter Cooper

Fri, 15 Sep 2006 10:16:23 -0700

Just because I’m enjoying this thread so much, I thought I’d throw in another pointless, though far more pragmatic, example:

puts case (1 + 1 == 2)
        when true: "True"
        when false: "False"
end

"Ruby On Nails Scratching a Chalkboard" by Dave Newton

Fri, 15 Sep 2006 08:09:02 -0700

@Simen: The difference is that if/then/else in Ruby is an additional syntactic construct. In Lisp it’s just another function.

Nobody said Ruby shouldn’t have it. The OP was merely trying to compare a particular subset of claims of Ruby’s Smalltalkiness vs. its implementation, which obviously don’t match.

Personally, I don’t find Ruby to be overly Smalltalky: things were inspired by Smalltalk (things like .each, etc.) This isn’t bad, this just *is*.

Purists are offended by this (and rightfully so) because it isn’t pure. That’s why they’re called purists. This doesn’t make Ruby bad. I am a purist, some of the warts are very irritating, and I still prefer Smalltalk and Lisp. But I still find Ruby a very productive environment, because it combines two modes of programming I’m very familiar with.

KenM quoted Matz as freely admitting it’s a bad ripoff of Smalltalk and Lisp. I actually think it’s a GOOD ripoff of Smalltalk and Lisp, not because it’s “pure”, but because it’s productive and as Matz says, it’s “nicer to ordinary people.”

Perhaps it’s a bridge language to bring people into the fold of Smalltalky, Lispy languages. Or maybe it’s Just Plain Good Enough(tm).

Either way, pure or not, syntactic warts and all, it has shaken things up, and this can only be a Good Thing.

"Ruby On Nails Scratching a Chalkboard" by Christopher Smith

Fri, 15 Sep 2006 08:03:07 -0700

Simen wrote:

Also, about the main post: even Lisp, which has virtually no syntax at all, has if/else in its grammar. Why shouldn’t Ruby?

Because Smalltalk doesn’t. ;-)

Seriously, I’ve tried to make this clear several times, but I seem to be failing: I’m not suggesting that Ruby needs to do if/else the way Smalltalk does. if/else was selected because it’s a well understood case where two blocks are passed to a function, which is what I am suggesting Ruby should be able to do well. Lambda helps paper over some of the syntactic ugliness, but it’s still not as clean as LISP or Smalltalk.

"Ruby On Nails Scratching a Chalkboard" by Simen

Fri, 15 Sep 2006 05:13:38 -0700

In a prototype based language, every object is both a class and an instance. There are only instance variables, and you make a new object by cloning an existing one. The cloned object is linked to as the prototype, like an instance links to a class.

Also, about the main post: even Lisp, which has virtually no syntax at all, has if/else in its grammar. Why shouldn’t Ruby?

"Ruby On Nails Scratching a Chalkboard" by Kirit

Fri, 15 Sep 2006 04:44:05 -0700

A bit wooly I know, but I was sort of considering the prototype to be the closest thing to a class that the language has.

I admit to not having thought through too deeply on the difference between prototype languages and other language types, especially about the similarity/differences between the prototypes and classes.

"Ruby On Nails Scratching a Chalkboard" by Simen

Fri, 15 Sep 2006 00:18:37 -0700

Kirit:

Javascript has only instance methods, because it is prototype based, which means there are no classes. An object’s prototype is its parent, etc. Self, Slate and Io are examples of prototype based languages.

"Ruby On Nails Scratching a Chalkboard" by Kirit

Thu, 14 Sep 2006 21:23:47 -0700

…feature of Smalltalk Method’s syntax (or did they call them Messages?)

From a terminology perspective Smalltalk has both messages and methods.

When you write:

obj para1: some para2: thing

You are sending a message called para1: para2: to the object. The message dispatcher then matches this with the para1: para2: method on the object that receives the message.

In short the message is at the call end and the method is the code that is executed in response to it.

This message/method distinction is built into all OO languages and constructs. How the message dispatcher works is one of the things that distinguishes OO languages.

Smalltalk’s message dispatcher is always dynamic and class based. I’ve heard that the dispatcher can be upgraded to allow instance methods, but I never got it to work.

Javascript’s dispatcher allows both class and instance methods whilst C++’s also adds in static binding (bypassing any dispatcher, or doing the dipatching at compile time depending on how you think about it).

"Ruby On Nails Scratching a Chalkboard" by Peter Cooper

Thu, 14 Sep 2006 18:05:24 -0700

The real downside of this technique is that operators like =~ and cute methods like _ may already be overridden to perform cute syntax hacks like those in my code. Still, just wanted to prove you can kinda contort Ruby into doing whatever you want, even if it’s not practical for real world use ;-)