The creator of Ruby explains why Ruby sucks | Hacker News Reader

The creator of Ruby explains why Ruby sucks

rubyist.net

43 pointsnreece28 comments

Having the creator of Ruby give a presentation outlining the shortcomings and planning for future fixes points more to something 'good' about Ruby than to something sucky.

How so? Aren't presentations about a current project's shortcomings/roadmap for improvements pretty standard?

I do agree that it speaks well about the developer, but your opinion about whether Ruby currently sucks or not should be informed by the content of the slides.

[edit] I can show you a shoe box and call it a car. I can candidly explain to you how it falls short of current cars, and how I will remedy these problems. All of that does not hide the fact that my shoe box is currently a sucky car.

You are incorrect to assume my opinion of Ruby wasn't informed by the content of the slides.

The slides and the issues they outline were from 2003. Many of those issues have been/are being fixed.

The development outlined has taken and is taking place. I view that as a success of the Ruby community and I also believe Ruby to be a good language now that many of these issues are fixed.

Therefore, I believe these slides point to good things about Ruby.

I'll view it as a success of the Ruby community when the issues are fixed.

Judging from the list on these slides, I think you're being a bit sanguine about the state of Ruby; at least four of the seven issues are still outstanding.

Most of them have been fixed, friend.

What do you want, someone to act like George W. Bush and claim that everything is going perfectly? Matz is at least willing to see the good and the bad and to openly acknowledge it.

Unlike GWB's rhetoric (which you seem to prefer) this is not a religious war. Just use the right tool for the job.

I'm sorry, but what the hell are you talking about? How did we go from talking about what's been fixed or not fixed in Ruby to accusing someone of being a Bush propagandist?

The comparison was intended to highlight that by giving that presentation, Matz is not simply propagandizing Ruby, he's trying to distribute accurate information. The parent of my post seemed to be critical of Matz's approach because it was humble and honest. The implication of that is either that he expects Matz and Ruby to be perfect (an impossible feat) or that he would perfer Matz to simply evangelize Ruby blindly.

I personally do not find it distasteful when someone is honest about the shortcomings of their project. It takes humility to do this, and it's totally uncool to rip on someone when they do it.

"Aren't presentations about a current project's shortcomings/roadmap for improvements pretty standard?"

no. for instance, presentations about Rails are often about why other things suck (PHP, Java, VC-funded startups, etc.)

That's because most of the Rails fanbois are just that, fanbois. They like Rails, so that means that it's obviously the best thing in the world, and is totally unflawed.

But, in reality, all software sucks. If they can't see the suckage, it's just because of their ignorance.

That would be a false dichotomy... A project with shortcomings is not necessarily sucky. It could be a very good project with still more room for improvement if it is to become a brilliant project.

The latest relevant update I found was this talk he gave at google

http://www.youtube.com/watch?v=oEkJvvGEtB4

I think most of you stumbled upon it, I also believe it was even mentioned on hacker news before

Although the slides date back to 2003, I wonder how much of it is still relevant?

read the slides, its still relevant.

1.8.x and 1.9 are just experimentation and intermediate steps to ruby 2.0 which is a "start from scratch" project

Uh oh. I did not know that version 2.0 will be such a project. Any bets on whether it'll succeed at its goals by starting from scratch? The track record on that sort of thing in technology is notoriously lopsided in favour of failure.

not true anymore... disregard

How many ground-up rebuilds of large, highly popular projects succeeded in the 3 hours between those two comments, to change the ratio?

Ruby 2.0 is a not a "start from scratch" project. It's an evolution of the language (which will be done mostly in the experimental 1.9 releases) with a new interpreter. Once 1.9 is stable it will turn into the 2.0 release. The actual effect on Ruby users will be noticeable, but minimal.

See http://eigenclass.org/hiki/Changes+in+Ruby+1.9 for some of the changes that are coming up.

with one clarification... (last I checked) 1.9.1 will be the stable, it won't be incremented to 2.0. Matz decided against the even/odd = stable/dev versioning scheme.

It is not a start from scratch, but it is incompatible with previous versions of Ruby in significant ways.

"start from scratch" is a quote off of matz's slides.

I only looked at the first few slides. Don't understand the problem with the block variables? The current version seems clearer to me than the new proposal. Variables are visible in the block they have been defined in, what could be easier to understand? Probably I am missing something, though...

The major problem with block variables in ruby is that if you do something like

    x = 4
    1.upto(5) do |x|
      puts x
    end
    puts "after the block x is #{x}"

It will print:

    1
    2
    3
    4
    5
   after the block x is 5

That is probably not what you would expect!

true, but for this it would be fine(?):

    x = 4
    1.upto(5) do |y|
      x = y
      puts x
    end
    puts "after the block x is #{x}

So the problem is only the parameter to the block?

Yes I think so - your example will still print "after the block x is 5", but in that case that probably is what you would expect.

Maybe my head has just gone blank, but I cannot think of a way to get a local called 'x' inside that block that is in scope only within the block.

In Perl you would have done

    my $x = 5;
    foreach my $i in (1..5) {
      my $x = $i;
      ...
    }

And it would have given you a new 'block local' and left your original x alone, but I cannot think of how you can do the equivalent of 'my' in Ruby ...

The problem is that Ruby's scoping rules aren't consistent. Sometimes it appears lexically scoped, but sometimes it acts dynamically scoped.

Sometimes this leads to funny looking code (if you know to avoid it) or truly inscrutable bugs (if you don't).

That is what I'd expect.

1.upto implies starting at 1... otherwise why would upto be called on 1?

If you want the behavior you expect, type:

  x = 4
  5.times do 
    x += 1
  end

Normally you'd expect the parameter of a block to be a new variable, not to grab a variable from another scope and use that instead. So the "expected" value is 4, since x = 4 on the first line.

You'd expect these two examples to output the same number:

  x = 1
  my_fun do |x|
    x = 5
  end
  puts x # => 5

and

  x = 1
  my_fun do |y|
    y = 5
  end
  puts x # => 1

where my_fun could be defined as:

  def my_fun 
    yield 2
  end

You're right, and that is the behavior in Ruby 1.9.

I posted the example I did so that those unfamiliar with Ruby would see that the parent was a contrived example to use upto in that context. Sure it's awkward b/c it's not the intended semantics of the upto method, hence the ambiguity.

Maybe an ideal language would not introduce that sort of ambiguity... I personally slightly perfer the 1.9 syntax.

Reply on news.ycombinator.com