How Ruby Borrowed a Decades Old Idea From Lisp

Except when they don't, but if you can't build multi-block methods (or methods on blocks) because it looks like shit, you don't think about them. It's a form of blub, nothing more. There are numerous multi-block methods, Ruby's syntactic limitations just makes them unwieldy and thus avoided. Just as Python's or Java's syntactic limitations make higher-order methods unwieldy and thus avoided.

> By having custom syntax for "method that takes a single block" you get a certain simplicity that makes methods look like built-in keywords

Smalltalk stands in stark disproval of this assertion.

> It does make multi-block methods look ugly, but frankly, I think they look ugly in any language.

Eh?

    aCondition ifTrue: [ "true block" ] ifFalse: [ "false block" ]

    [ "some code" ]
        ensure: [ "recovery code" ]

    [ someObject aMessage ]
        on: aSignal
        do: [:sig | "action" ]

> Compared to JavaScript/Perl/Python-lambas, Ruby's blocks don't introduce another scope.

They do, if you define a variable within the block it'll be local to the block. Ruby 1.9 even allowed shadowing variables from the parent method (which isn't possible in 1.8)

> "self" [...] still refer to the method's scope

So does it with the vast majority of languages. Certainly does in Python. Javascript behaves strangely with its somewhat-dynamically-scoped-but-not-really `this` but it's a peculiarity of JS, not Ruby.

> and "return" still refer to the method's scope (I'm not sure what this type of scope is called)

It's a non-local return, not really a scope.

Frankly this turned me off from Ruby when Matz presented it at LL2 in 2002. My reaction was “this is an ugly hack that won't work with more than one funarg, by someone who doesn't really understand functional programming”. [I was coming from years of hardcore programming in Smalltalk and Common Lisp.] It was only years later that I realized this special case was so overwhelmingly the common case that it was reasonable to give it a nice syntax, and that there's a (big) place for programming that isn't in a “functional” style, but still makes liberally use of funargs. (Most Smalltalk and Lisp that I've seen occupies this middle ground too.)

It reminds me of my first reaction to Python: “Meaningful indentation is a terrible idea!” Only a year or two later when I was writing Lisp pseudocode in a notebook [late '90's — no parenthesis highlighting or syntax-directed editor on my analog notepad] did I realize that what I was sketching used whitespace as shorthand, and was practically Python as it stood.

That Ruby blocks have a weird scope, and that the syntax for creating and invoking closures outside of the block syntax is so cluttered, are unfortunate and seem mostly independent of having a compact notation for single-funarg function calls. Except that if, like Lisp and Smalltalk, all use of closures used the same syntax, this syntax would probably have become more polished.

  # ruby
  double = [1..10].map { |x| x * 2 }

  # perl
  my @double = map { $_ * 2 } 1..10;

And it's easy create new ones as well:

  sub loop (&) {
    my $block = shift;
    $block->() while 1;
  }

  loop { say "Nuts" };

  sub ifTrue (&@) {
    my ($block, $cond) = @_;
    $block->() if $cond;
    $cond;
  }

  sub ifFalse (&@) {
    my ($block, $cond) = @_;
    $block->() unless $cond;
    $cond;
  }

  ifTrue { say "True" } ifFalse { say "False" } 1 == 1;

[1] - Not sure what the proper name for this syntax is!

Indeed, smalltalk seems a better example, as it uses methods and blocks to implement all control structures, even the "built-in" ones.

    if { $something } {
        do this
    } else {
        do something else
    }

'self' in Python still refers to the method's scope too (if the lambda is inside one).

  class A(object):
    def b(self):
      self.name = "John"
      c = lambda: "Hello, %s" % self.name
      print c()
  A().b() #prints "Hello, John"

Tcl... builtin 'for'

    for {set i 0) {$i < 10} {incr i} {
        puts $i
    }

    myfor {set i 0) {$i < 10} {incr i} {
        puts $i
    }

Programming in Lisp is like programming in assembler. Reading it is worse. The learning curve is tremendous.

Languages serve lots of demographics, not just comp-sci wonks.