A better self

[Alex Martelli]

Michael Chermside wrote:
        ...
> shouldn't be using Python. Yes, Python is a nice language, and yes, it
> can be sped up by recoding key portions of an application in C/C++, but
> it is never going to be as fast as an algorithm hand coded in assembly.

It may happen to be just as fast (that would be a rare coincidence)
and it may well be (more likely:-) *much faster*.

That's because more often than not you won't be coding the SAME
algorithm in Python or assembly.  In the time it takes you to code
and debug the one algorithm in assembly, you've been able to invent
and try a dozen different ones in Python, and quite likely come up
with one that beats the pants off the one you first thought of.

The fallacy of thinking that "coded in Python" means "slower than
if coded in assembly" comes from the unspoken assumption that the
program will have exactly the same structure in both cases.  Most
often, it won't.

A similar fallacy is frequent in laypeople's economics thoughts, and known 
for example as "the fallacy of the lump of labor" -- where some people 
intuitively think that (e.g.) immigrants "steal jobs from natives".  The 
fallacy here comes from imagining that there's a predefinite, fixed, total
amount of things to do, a pie of a fixed size, and all that matters is
how the pie is sliced up.

Reality just doesn't work that way.  The pie can grow (or shrink due
to restrictive protectionist legislation), better algorithms can be
and are devised and deployed.

Only when you're SURE you have the best possible algorithms (and the
most perfect, developed economy) and you're STILL too slow (or, still
too poor) should coding in lower levels be considered (on the other
hand, protectionist legislation shouldn't be considered even then,
but that's another issue:-).


Alex