When Python outruns C++ ...

[Roy Smith]

I wrote:
>>> the more you can push down into the libraries and interpreter core,
>>> the better off you are most of the time.

"Dave Benjamin" <ramen at lackingtalent.com> wrote:
>> This has been my experience as well. It is a very gratifying discovery,
>> IMHO, because it encourages a less-is-more style of programming where you
>> say what you mean, and little else.

Anders J. Munch <andersjm at inbound.dk> wrote:
> The downside is that sometimes code is contorted to fit whatever has a
> fast high-level implementation in the current interpreter, instead of
> adapting to the nature of the problem.
> [...]
> That coding style tends to adapt to performance accidents of the
> implementation, happens in all interpreted languages.

People have been commiting crimes against good design in the name of
efficiency since punchcard days.  When I first learned C, it was on a
pdp-11, where the compiler could put three variables per function in
fast registers.  My major goal in refactoring (although we didn't call
it that in those days) was to design functions that made extensive use
of no more than three integers or pointers.

Just a couple of weeks ago, I let the efficiency bug bite me and spent
two days totally tearing apart a C++ class to make it use a different
set of STL containers.  The savings?  I turned a rarely-used linear
operation (where N <= 24 most of the time) into a constant-time
operation.  Totally meaningless to overall performance, but once the
bug bit, it was hard to stop myself :-)

The dark side of the force is seductive.  It tries to make us
efficient, even at the cost of clarity and maintainability.  In that
way lies bit-twiddling and assembler language and soldering irons.  We
must be diligent in our fight against it.