Ian Bicking: the old part of his blog

Comment

In my limited experience, the people who obsess about performance and therefore only wrote things in C/C++ have been the ones who were most likely to write bad and inefficient C/C++ code. Usually most of their bad coding was done in the name of up-front optimization.

For example, they would decide to use a 3MB two-D array of structs because "it would be faster than using STL containers and classes." It didn't matter to them that their data could be represented in other ways (even in plain C) that would be faster and more memory efficient, and it didn't matter that it might be easier to code if you let a library juggle some of the details for you. I think the real issue was that they didn't know how to do anything other than use two for-loops to iterate over a static array. And I guess that's my point - these arguments usually get made because someone is slightly ignorant of their "favorite fast language" and completely ignorant of what you gain by using a higher level language.

This is just my experience; I'm not extrapolating it to say all performance-minded arguments are motivated by ignorance. There are cases where C/C++ might be necessary, but I think they are few and far between.
Comment on Speed is a Process, not an Attribute
by Alan McIntyre