My Mixed Feelings about Ruby | Hacker News Reader

My Mixed Feelings about Ruby

weblog.raganwald.com

38 pointsmattculbreth22 comments

Good article raganwald.

I'm just learning RoR and I guess my biggest hangup is the prodigious use of colons.

I admire your ability to "rewrite code for Ruby"...

For me it's tough enough to learn one language. There is no way that I would ever attempt anything but a greenfield application with RoR and to finish that I will probably need some help. What attracted me to the language was the impression I got from reviewing descriptive materials from DHH and the 37 signals crew that Ruby has a great deal of elegance when it comes to interacting with databases. And, for me anyways, that's the only kind of elegance I'm really interested in because I think that's where the money is going to be. So far I'm not really good enough with the syntax to say whether it's going to live up to expectations but I haven't really seen anything yet that would cause me to say I've made a mistake in choosing this platform.

Blocks may not be able to genuinely accept blocks in Ruby, but I was able to get something pretty close: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/...

To my eyes, Ruby as a language looked a lot like an internal IT app that is built as an aggregation of features. There might be a wonderful, coherent design in the implementation that I can’t see, but the interface I use seems like a bunch on one-off features that don’t play well together.

Huh? Is this guy talking about Perl? Is he talking about the same Ruby I know? His criticisms don't make any sense. Ruby is well-organized and well thought-out. It's not without its flaws, but it has far fewer than Java or Perl. Hell, Ruby makes Perl look like Java.

(If he hates Ruby this much, I'd hate to imagine what he'd think of the gigantic featuritis-striken kludge called Java or J2EE.)

Raganwald is one of the most prominent Ruby programmers I know of, so I would say it's unlikely he hates Ruby.

And he has a point. While Ruby is certainly more coherent than Java, it's clearly less coherent than io or Lisp or smalltalk.

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.

    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.

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?

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...)

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.

Alas, one of the downsides of living in beautiful surroundings for a long time is that you adapt to them. And then you can spot the flaws.

This is a good thing for humanity in general -- criticism will help Ruby's successors to be better languages, just as criticism of Perl helped make Ruby better -- but it's occasionally painful for the individual humans who have been trained to see the holes in the carpet.

This is a good point.

Whether the successor is Ruby 2.0, Ruby 2.2 or some yet to be invented language, the warts that Ruby has now ought to be discussed and understood if we want the successor to be better.

I personally think that Matz had some great ideas that make expressing one's self in Ruby very natural (whether you like an oo style or a functional style, a meta style, etc.) There are some oddities like the Proc vs lambda return semantics differences, but those can easily be cleaned up.

So one should differentiate between "Ruby the idea" and "Ruby the legacy codebase", as the latter is not always going to live up to all of the ideals of the former.

i haven't used ruby excessively, but one example i found just by looking at it a bit is that blocks are redundant with lambdas

to me it seems the language is trying to promote higher-level programming by making what is perhaps a common usage of first-class functions more explicit. but i can't say this is necessarily the best choice

another thing is lambdas are poorly-implemented, requiring the .call thing (perhaps due to the parens-less function calls.) this matters to me because i use a lot of first-class function stuff

for personal coding i use Lua, which to me feels more powerful than Ruby (from the perspective of abstractive power,) yet is much more streamlined

blocks are redundant with lambdas

Except the semantics of the return keyword are corrupted if you get rid of blocks and procs while keeping lambdas. Makes me think return isn't worth the bother, but then again lots of people would hate a language without a return keyword.

I wouldn't say corrupted, just different. I imagine there are many cases in which the different semantics are used intentionally.

This is really not a huge issue, b/c anyone who has worked with Ruby enough knows about it. It's mainly that the difference doesn't really make logical sense -- why would a "proc" behave differently from a "lambda"? Also note that:

  lamba { foo }

means exactly the same as

  proc { foo }

which is different than:

  Proc.new { foo }

This sort of smells, but it wouldn't if there were a new keyword to represent the way Proc.new behaves... then everyone would flex their Ruby muscles by writing confusing hacks that utilized the behavior of StrongReturnProc.new ... :)

it wouldn't if there were a new keyword to represent the way Proc.new behaves

My understanding is that there is a very good chance that Ruby 1.9 (when it stabilizes) will change the proc keyword to have Proc.new semantics instead of lambda semantics, for exactly the reason your give.

Who cares? It isn't like you and ruby are getting married.

If you have a project that ruby seems like a decent fit, use it. You'll get nowhere are learn nothing without actually doing.

Reply on news.ycombinator.com