5 ms·

The creator of Ruby explains why Ruby sucks

43 points by nreece 18y ago

nreece 18y ago
Although the slides date back to 2003, I wonder how much of it is still relevant?
- jotto 18y ago
  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
  - 9oliYQjP 18y ago
    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.
    - zenspider 18y ago
      not true anymore... disregard
      - khafra 18y ago
        How many ground-up rebuilds of large, highly popular projects succeeded in the 3 hours between those two comments, to change the ratio?
  - kschrader 18y ago
    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 http://eigenclass.org/hiki/Changes+in+Ruby+1.9 for some of the changes that are coming up.
    - zenspider 18y ago
      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.
    - ntoshev 18y ago
      It is not a start from scratch, but it is incompatible with previous versions of Ruby in significant ways.
    - jotto 18y ago
      "start from scratch" is a quote off of matz's slides.
iloveyouocean 18y ago
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.
- Husafan 18y ago
  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.
  - iloveyouocean 18y ago
    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.
    - timr 18y ago
      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.
      - gunderson 18y ago
        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.
systems 18y ago
The latest relevant update I found was this talk he gave at google http://www.youtube.com/watch?v=oEkJvvGEtB4 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
Tichy 18y ago
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...
- fendale 18y ago
  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!
  - Tichy 18y ago
    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?
    - fendale 18y ago
      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 ...
    - KirinDave 18y ago
      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).
  - 18y ago

43 points by nreece 18y ago

nreece 18y ago

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

jotto 18y ago
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
- 9oliYQjP 18y ago
  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.
  - zenspider 18y ago
    not true anymore... disregard
    - khafra 18y ago
      How many ground-up rebuilds of large, highly popular projects succeeded in the 3 hours between those two comments, to change the ratio?
- kschrader 18y ago
  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 http://eigenclass.org/hiki/Changes+in+Ruby+1.9 for some of the changes that are coming up.
  - zenspider 18y ago
    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.
  - ntoshev 18y ago
    It is not a start from scratch, but it is incompatible with previous versions of Ruby in significant ways.
  - jotto 18y ago
    "start from scratch" is a quote off of matz's slides.

iloveyouocean 18y ago

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.

Husafan 18y ago
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.
- iloveyouocean 18y ago
  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.
  - timr 18y ago
    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.
    - gunderson 18y ago
      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.

systems 18y ago

The latest relevant update I found was this talk he gave at google http://www.youtube.com/watch?v=oEkJvvGEtB4 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

Tichy 18y ago

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

fendale 18y ago
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!
- Tichy 18y ago
  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?
  - fendale 18y ago
    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 ...
  - KirinDave 18y ago
    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).
- 18y ago