Comment by raganwald | Hacker News Reader

Comment by raganwald | Hacker News Reader

Parent Full thread

Ruby is well-organized and well thought-out.

O RLY?

Just kidding. I think Ruby is well thought-out. Just for a chuckle, what does this snippet of code do?

  p = Proc.new { return :to_sender };  
  p.call

What about this one?

  l = lambda { return :to_sender };  
  l.call

Why and how do they differ? And given that they differ in behaviour, what do you think this should return? False, right?

  c.class == l.class

As for my criticisms, my main point has to do with Ruby not being implemented in terms of itself. Almost everything else that troubles me can be traced back to that issue.

http://weblog.raganwald.com/2006/11/significance-of-meta-cir...

http://weblog.raganwald.com/2007/12/why-rubinius-matters-to-...

http://weblog.raganwald.com/2008/02/turtles-all-way-down-ple...

p.s. Please remember that the post was not titled "What's wrong with Ruby," it was titled "My Mixed Feelings about Ruby." So it can well be that I have a viewpoint which does not reflect how intelligent people feel about t he language.

The main point is that Ruby is not implemented in terms of itself? That surely doesn't come across as the main point of the article, as it is only mentioned in a short 3 sentence paragraph that mostly consists of links to other articles.

I felt the article was a bit content-free. The main point I got out of it was that Ruby isn't elegant like Scheme or Smalltalk. This is the same sort of thing that has been repeated ad nauseum since the dawn of internet discussion. If Ruby is too gauche, Scheme and Smalltalk already exist and provide actual implementations of this strange symmetrical, consistent, mathemagical "elegance" that certain programmers get a boner over. (substitute "OOP" for "mathemagical" in the case of Smalltalk)

Now, I'll derail this thread with some opinions of my own. I used to love Perl. The inconsistency, crypticness, ability to make incomprehensible one-liners that actually did something useful - I truly felt like a wizard. Perl golf was a big hobby of mine. Unfortunately as soon as Java became the next big thing, Perl became totally not cool. To be honest, Perl was never "cool" anyway. The good Perl guys were all old systems administratiors who still posted "rants" to alt.kibology and only had sex when dressed in giant furry chipmunk suits. However, at least they were free-thinking, anything goes weirdos. In contrast, the Java droids who replaced them had the spirit of soviet city planners dressed in khakis and a SUN logo polo shirt... Ugh.

I'm completely indebted to Matz, (and DHH, because ruby wouldn't have taken off as it has without Rails) because he's invented a Perl that is "cool." No longer do I have to make the choice between working with guys still into "the Church of the Subgenius" or guys who actually wear their blackberry in a holster on the outside of their pants. I can now work on fun startup things with cool people who I can actually relate to. There's just enough "WTF" in Ruby to keep me happy, and just enough "OBJECT ORIENTED DESIGN PATTERNZ" stuff to keep those types of people happy. There's even enough Lispy stuff in there to keep those types happy for about 30 minutes until they go back to their real avocation, posting long diatribes to mailing lists about how things aren't as elegant as Lisp.

No, the main point of my personal blog post was that I am personally wrestling with the idea that Ruby as a whole might be more than the sum of its inelegant parts.

The main point of the criticism within the point of the post was about Ruby not being implemented in itself, but that is not the point of the post.

Ah, well that is a good point. However, many (most?) good things in software have a bit of insanity going on somewhere in the mix. For instance, any computer game is definitely "more than the sum of its inelegant parts."

My main beefs with Ruby are that it is slow, and there is a weird reality distortion field within the community that makes a lot of people respond to legitimate criticisms with tribal defensiveness. However, I won't go into either point as Zed Shaw seems to have covered them quite well.

> makes a lot of people respond to legitimate criticisms with tribal defensiveness.

That's true for pretty much any computer system, whether it's Tcl, Emacs, Ubuntu, Postgres or whatever.

BTW, I loved the descriptions of Perl and Java users - it's not often that I get that good a laugh when reading something. And I agree with you completely about Ruby hitting a 'sweet spot'.

I should also mention that part of what I like about Ruby is its diversity.

I'm completely indebted to Matz, (and DHH, because ruby wouldn't have taken off as it has without Rails) because he's invented a Perl that is "cool."

See now, I am completely indebted to Matz because he's invented a Lisp that is "cool." I think Ruby truly has it both ways.

    irb(main):002:0> p = Proc.new { return :to_sender }        
    => #<Proc:0x0035a050@(irb):2>
    irb(main):003:0> p.call
    LocalJumpError: unexpected return
            from (irb):2
            from (irb):3
            from :0
    irb(main):007:0> l = lambda { return :to_sender } 
    => #<Proc:0x0033b86c@(irb):7>
    irb(main):008:0> l.call
    => :to_sender

I had no idea it would do that - is a 'return' statement illegal in a Proc?

A return statement is not illegal, however it returns from the method call where it was defined... if that method call is still valid.

So this works:

  def valid_method_call
    pp = Proc.new { return :to_method_caller }
    pp.call
  end

  valid_method_call

But this does not:

  ll = lambda {
    pp = Proc.new { return :to_lambda_caller }
    pp.call
  }

  ll.call

If you do something like save the proc for later, you are in trouble:

  def temporary_method_call
    Proc.new { return :where_shall_i_return? }
  end

  pp = temporary_method_call
  pp.call

Because the method call where the proc was defined no longer exists. So Ruby closes over local variable bindings, saving them for later, but not over control flow.

If it did, the return keyword would end up acting like a continuation.

now try this on for size. I'm sure you know how this works:

  > def a
  >   yield
  > end
  => nil
  > a { 42 }
  => 42

But did you know this?

  > def b
  >  Proc.new.call
  > end
  => nil
  > b { 42 }
  => 42

Proc.new without any arguments works the same as yield. tripped me out when I found this the other day.

So what is the point of using Proc instead of lambda then? I can't see a case where the behavior of proc is the desired behavior (although now that with the difference in my mind I might end up using it one day...)

Its nice that we can choose how we want return to behave in a block. It doesnt make any sense that the two ways be called "lambda" and "Proc.new". Maybe you have to be Japanese to understand it?

Reply on news.ycombinator.com