"Ruby, for example, shoots out from the bottom right - to me, this says, ... if you know what you're doing, you can get reasonably good performance" Sorry, but it does not say you can get reasonably good performance, it says this version of Ruby is slow, one of the slowest languages in the Shootout. And the graph itself says nothing about the skill level required to obtain the exhibited performance.
> And the graph itself says nothing about the skill level required to obtain the exhibited performance.
In all fairness, neither do most people promoting C++'s performance-at-any-cost design.
I think a large spread in the performance correlates with requiring skill level, though -- it means that some people using the language get good results, but that many also get very bad ones. Ruby is a really slow language ("reasonably good" < great), but it's still good enough for many purposes, provided your algorithms are reasonable.
Ruby is not a really slow language. It's got some really slow implementations. Ruby has a high cost to entry for a VM/tool developer because it has a relatively byzantine syntax which has been hard to standardize. You can write code that has the same tokens yield entirely different syntactic elements, based on something random, like, say, what day of the week it is, which you can do in Python or Smalltalk, but in Ruby you can do this by accident with statements that look very innocent. (This is covered right in the Practical Programmer's Ruby book.)
If dealing with Ruby's syntax were easier, Ruby implementations would progress faster.
That sounds more like, "its design interferes with fast implementation" to me. If there's a major difference between that and "it's slow language", I'm really curious what it is.
You missed a meta-level. The design doesn't interfere with having a fast implementation. It interferes with implementing a fast implementation.
"It's a slow language," implies that there's something special about Ruby that precludes (relatively) fast implementation. There's nothing special about Ruby like this. Ruby is a very nice remix of language features that existed before. Getting a language to be fast can require many iterations. Ruby's syntax is a high barrier to entry to implementers, so fewer eyeballs have been looking at the problem.
Smalltalk was designed to be quickly implemented by a single programmer. Implementing a "Bluebook VM" was treated as a rite of passage for support engineers for at least one of the vendors. As a result, people have implemented many, many variations on Smalltalk. (Including an VM with built-in OODB, another that can compile down to a C++ compatible DLL indistinguishable from one written in C++, another that ran on the old Palms, one with optional typing, and many others.)
I think it's fair to say that writing a Ruby VM is probably an order of magnitude harder.
