7 ms·

"One comment that seemed particularly uncontroversial to me was at the core of this nerd firestorm: Ruby is slow. For the next several days, I could think of on

"One comment that seemed particularly uncontroversial to me was at the core of this nerd firestorm: Ruby is slow. For the next several days, I could think of only one thing: why is something you can measure controversial?" This is exactly what needed to be said, and repeated until it is fully and widely understood. Cognitive dissonance should not be assuaged at the cost of the rational and empirical.

lsb 18y ago
The regexp engine isn't slow. The bignum support isn't slow. The development time isn't slow. If you wonder why there's a firestorm, it might be because of sweeping generalizations.
- shrughes 18y ago
  No, you're completely dodging the issue by saying some library functions, not written in Ruby, are not slow, and then talking about development time, which has nothing to do with the slowness people are talking about. The last time I checked, we're talking about the speed of code written in Ruby, and in particular, the speed of code as it's typically written.
- ankhmoop 18y ago
  The regular expression engine and large number support are simply not broadly representative of Ruby performance, and do little to refute empirical observations of properly representative benchmarks and the many educated critiques of Ruby's implementation. Your final example of development time is wholly unrelated to runtime implementation performance, and its use as a justification to assuage cognitive dissonance is predicated on a false dilemma -- that a language can not both support rapid development and a well performing runtime. It is not necessary to introduce a false dilemma to justify an individual preference for Ruby development, in spite of its measured performance.
- tptacek 18y ago
  Isn't that a lot like saying that despite the VM system, OpenBSD 2.1 wasn't slow because it had a pretty good "gzip"?
  - kragen 18y ago
    Python is slow. For loops containing arithmetic, array indexing, function calls, and similar primitive operations that also exist in C, it's maybe 100× slower than C. But programs written in Python are usually not 100× slower than C programs with similar functionality. They may be 10× slower or 3× slower or, very rarely, faster; that's because their inner loops tend to be in operations like regexp matching, array arithmetic, data compression, string hashing, and the like, and Python's implementations of those things aren't themselves written in Python — they're the things you're likening to "gzip" here. There's a selection bias here. If you write your compiler or interpreter or pathfinding algorithm in Python, it's going to be a lot more than 10× slower than if you wrote it in C (or Java or OCaml or whatever). So people don't write those programs in Python, so we don't get to compare them. I've been writing about Python because I know more about it than I do about Ruby, but I think most of the same things are true of Ruby, as well.
    - swolchok 18y ago
      Sure -- minimizing the number of Python statements is a decent optimization heuristic in Python (and, as a bonus, that can help you optimize for human readers as well when not taken to extremes).
gleb 18y ago
PR, marketing and politics are facts of life. The reasons that Ruby/Rails community ridiculed (obviously accurate) "ruby is slow" are exact same reasons the community was such a success in the first place. Consider what would have happened if "ruby is slow" meme took off. Forget the RoR itself, but it would have actually been a disservice to users who don't understand the details and wouldn't have been able to make the right choices. If you actually want to affect a change with communication it's useful to think through what, where and how you say it. But mostly, don't just complain, include a patch. E.g. our Ruby and RoR patches were accepted the same day with gratitude: http://blog.pluron.com/2008/01/ruby-on-rails-i.html http://blog.pluron.com/2008/01/ruby-on-rails-i.html We (Pluron/Acunote team) are going to be presenting @ RailsConf 2009 ( http://en.oreilly.com/rails2009/public/schedule/detail/8615 http://en.oreilly.com/rails2009/public/schedule/detail/8615 - Advanced Performance Optimization of Rails Applications ) and it's going to take some work to frame the presentation in a useful fashion. As tempting as it is just to point out how bad every single part of the stack is, from our hosting to Firefox, it would be highly misleading; they are still the best available options. Having said that, it's a pleasure to have HN where these sensitive topics can be discussed in a rational fashion.
- ankhmoop 18y ago
  I do not believe that forthright explanations of genuinely complex topics can ever be a disservice to users -- accurate and complete information is critical to "make[ing] the right choices". The suggestion to provide patches is a simple displacement mechanism. A correct, reasoned evaluation is not predicated on also including patches, and a reasoned evaluator may have significant cause to not invest further effort in providing improvements to the evaluated software.
  - ewjordan 18y ago
    I agree with you, but I think the gp has a point: look at Java as an example. Here we are, at a point where Java code runs extremely fast, but because of the "Java is slow" meme that took off at the turn of the century, any time Java comes up you _still_ see uninformed people on (for instance) Slashdot insisting that Java is unusable for important code because it's so slow. That said, I don't think the right solution to avoiding problems like this is a "head in the sand" approach. If there are real performance issues, they should be acknowledged and addressed. I definitely get the sense that a lot of Ruby zealots are trying to pretend that there is no problem, which is something that Java zealots tried to do years ago (and something that the people in control of feature requests still do quite a bit, using the "Nobody can microbenchmark the JVM, it's too smart!" excuse). I don't know why this stuff gets people so emotional, though. You don't see carpenters have heated arguments about whether a screwdriver is better than a hammer; why do programmers get so emotionally attached to their tools, refusing to acknowledge the limitations and strengths of each particular one?
carbon8 18y ago
until it is fully and widely understood. Cognitive dissonance By accusing people of "cognitive dissonance" and apparently believing that's the primary issue here, you are contributing to the drama. See the comments on the original: http://www.radicalbehavior.com/5-question-interview-with-twitter-developer-alex-payne/ http://www.radicalbehavior.com/5-question-interview-with-twi... The aggressive and insulting remarks directed at Ruby, Rails and people associated with them are exactly the source of the problem here.
- deleted 18y ago
  [deleted]
trapper 18y ago
Ruby is slow. Fast, good, easy - pick 2.
- ankhmoop 18y ago
  A false dilemma.
  - trapper 18y ago
    Explain with examples?
    - ankhmoop 18y ago
      What technical limitation prevents a language from being fast, easy to use, and well designed? Alex seems to argue that Scala is 'fast, good, and easy', and I would tend to concur. What I've seen of C# 3.0 and F# also implies that those languages could meet this criteria, but my experience with them is limited.
      - trapper 18y ago
        Software engineering is about tradeoffs. I'll take that a step further: everything is about tradeoffs. You can always optimise for one use case to the exclusion of the others. Are you saying that fortran isn't faster than scala/jvm based languages? That APL isn't better for matrice's? That lisp macros aren't more powerful? Or that php isn't simpler than scala? Being good at all three may be possible, but being optimal at all three is probably impossible.
        ankhmoop 18y ago
        "Being good at all three may be possible, but being optimal at all three is probably impossible." Why?
        trapper 18y ago
        http://en.wikipedia.org/wiki/Optimization_(mathematics)#Multi-objective_optimization http://en.wikipedia.org/wiki/Optimization_(mathematics)#Mult...

lsb 18y ago

The regexp engine isn't slow. The bignum support isn't slow. The development time isn't slow. If you wonder why there's a firestorm, it might be because of sweeping generalizations.

shrughes 18y ago
No, you're completely dodging the issue by saying some library functions, not written in Ruby, are not slow, and then talking about development time, which has nothing to do with the slowness people are talking about. The last time I checked, we're talking about the speed of code written in Ruby, and in particular, the speed of code as it's typically written.
ankhmoop 18y ago
The regular expression engine and large number support are simply not broadly representative of Ruby performance, and do little to refute empirical observations of properly representative benchmarks and the many educated critiques of Ruby's implementation. Your final example of development time is wholly unrelated to runtime implementation performance, and its use as a justification to assuage cognitive dissonance is predicated on a false dilemma -- that a language can not both support rapid development and a well performing runtime. It is not necessary to introduce a false dilemma to justify an individual preference for Ruby development, in spite of its measured performance.
tptacek 18y ago
Isn't that a lot like saying that despite the VM system, OpenBSD 2.1 wasn't slow because it had a pretty good "gzip"?
- kragen 18y ago
  Python is slow. For loops containing arithmetic, array indexing, function calls, and similar primitive operations that also exist in C, it's maybe 100× slower than C. But programs written in Python are usually not 100× slower than C programs with similar functionality. They may be 10× slower or 3× slower or, very rarely, faster; that's because their inner loops tend to be in operations like regexp matching, array arithmetic, data compression, string hashing, and the like, and Python's implementations of those things aren't themselves written in Python — they're the things you're likening to "gzip" here. There's a selection bias here. If you write your compiler or interpreter or pathfinding algorithm in Python, it's going to be a lot more than 10× slower than if you wrote it in C (or Java or OCaml or whatever). So people don't write those programs in Python, so we don't get to compare them. I've been writing about Python because I know more about it than I do about Ruby, but I think most of the same things are true of Ruby, as well.
  - swolchok 18y ago
    Sure -- minimizing the number of Python statements is a decent optimization heuristic in Python (and, as a bonus, that can help you optimize for human readers as well when not taken to extremes).

gleb 18y ago

PR, marketing and politics are facts of life. The reasons that Ruby/Rails community ridiculed (obviously accurate) "ruby is slow" are exact same reasons the community was such a success in the first place. Consider what would have happened if "ruby is slow" meme took off. Forget the RoR itself, but it would have actually been a disservice to users who don't understand the details and wouldn't have been able to make the right choices. If you actually want to affect a change with communication it's useful to think through what, where and how you say it. But mostly, don't just complain, include a patch. E.g. our Ruby and RoR patches were accepted the same day with gratitude: http://blog.pluron.com/2008/01/ruby-on-rails-i.html http://blog.pluron.com/2008/01/ruby-on-rails-i.html We (Pluron/Acunote team) are going to be presenting @ RailsConf 2009 ( http://en.oreilly.com/rails2009/public/schedule/detail/8615 http://en.oreilly.com/rails2009/public/schedule/detail/8615 - Advanced Performance Optimization of Rails Applications ) and it's going to take some work to frame the presentation in a useful fashion. As tempting as it is just to point out how bad every single part of the stack is, from our hosting to Firefox, it would be highly misleading; they are still the best available options. Having said that, it's a pleasure to have HN where these sensitive topics can be discussed in a rational fashion.

ankhmoop 18y ago
I do not believe that forthright explanations of genuinely complex topics can ever be a disservice to users -- accurate and complete information is critical to "make[ing] the right choices". The suggestion to provide patches is a simple displacement mechanism. A correct, reasoned evaluation is not predicated on also including patches, and a reasoned evaluator may have significant cause to not invest further effort in providing improvements to the evaluated software.
- ewjordan 18y ago
  I agree with you, but I think the gp has a point: look at Java as an example. Here we are, at a point where Java code runs extremely fast, but because of the "Java is slow" meme that took off at the turn of the century, any time Java comes up you _still_ see uninformed people on (for instance) Slashdot insisting that Java is unusable for important code because it's so slow. That said, I don't think the right solution to avoiding problems like this is a "head in the sand" approach. If there are real performance issues, they should be acknowledged and addressed. I definitely get the sense that a lot of Ruby zealots are trying to pretend that there is no problem, which is something that Java zealots tried to do years ago (and something that the people in control of feature requests still do quite a bit, using the "Nobody can microbenchmark the JVM, it's too smart!" excuse). I don't know why this stuff gets people so emotional, though. You don't see carpenters have heated arguments about whether a screwdriver is better than a hammer; why do programmers get so emotionally attached to their tools, refusing to acknowledge the limitations and strengths of each particular one?

carbon8 18y ago

until it is fully and widely understood. Cognitive dissonance By accusing people of "cognitive dissonance" and apparently believing that's the primary issue here, you are contributing to the drama. See the comments on the original: http://www.radicalbehavior.com/5-question-interview-with-twitter-developer-alex-payne/ http://www.radicalbehavior.com/5-question-interview-with-twi... The aggressive and insulting remarks directed at Ruby, Rails and people associated with them are exactly the source of the problem here.

deleted 18y ago
[deleted]

trapper 18y ago

Ruby is slow. Fast, good, easy - pick 2.

ankhmoop 18y ago
A false dilemma.
- trapper 18y ago
  Explain with examples?
  - ankhmoop 18y ago
    What technical limitation prevents a language from being fast, easy to use, and well designed? Alex seems to argue that Scala is 'fast, good, and easy', and I would tend to concur. What I've seen of C# 3.0 and F# also implies that those languages could meet this criteria, but my experience with them is limited.
    - trapper 18y ago
      Software engineering is about tradeoffs. I'll take that a step further: everything is about tradeoffs. You can always optimise for one use case to the exclusion of the others. Are you saying that fortran isn't faster than scala/jvm based languages? That APL isn't better for matrice's? That lisp macros aren't more powerful? Or that php isn't simpler than scala? Being good at all three may be possible, but being optimal at all three is probably impossible.
      - ankhmoop 18y ago
        "Being good at all three may be possible, but being optimal at all three is probably impossible." Why?
        trapper 18y ago
        http://en.wikipedia.org/wiki/Optimization_(mathematics)#Multi-objective_optimization http://en.wikipedia.org/wiki/Optimization_(mathematics)#Mult...