[jb3689]

While the phrasing irks me, I think I agree with the sentiment: "languages that value speed tend to expose more of the details, thus when presented with a performance problem, you have more options ready at your disposable". One of the biggest barriers for me personally as a long time user of high-level languages is going down into C internals and feeling like I can safely make changes. It also sucks if you don't want something that comes out of the box with Ruby (say you want a more memory efficient array than what Ruby gives you). C extensions allow you to add these things, but the knowledge is specialized and writing C extensions can feel like a black art due to a relative lack of resources on them

There are two other alternative interpretations that I think are untrue however:

* "languages that value speed give you tools that expose more of the details and thus help you avoid adding defects in the first place" which I disagree with because (1) the average programmer will not understand what most low-level options actually do and (2) exposing more options is like trying to program with ones and zeros - at some point low-level abstractions don't scale well in a constantly evolving project

* "languages that value speed generally have fewer abstractions and thus make it easier to find bugs because there is less abstraction" which I think is untrue in projects of meaningful size. Macros are very common to find in languages like C and arguably as complex as metaprogramming in Ruby. Additionally Java is considered a relatively fast language and Java projects often have lots of abstraction