Hacker News Reader

Comment by lsb | Hacker News Reader

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.

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.

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.

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"?

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.

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

Reply on news.ycombinator.com