What is Python good for?

[Courageous]

>> I can only suppose you believe this true because you believe
>> that "the mass of programmers who 'hand-tune C code'" do so
>> blindly. Those of us who use profiling tools, however, ...

>Not speaking for Cameron, but I would say that the phrase
>"hand-tune" implies specifically *not* using tools such as
>profilers in the process.  I think most programmers who
>spend time optimizing C code do it rather blindly, along 
>the lines of "it isn't fast enough, so I'll try to speed
>up this loop here so it will be faster".  

Such attempts at optimization are entirely foolish. The
first instinct -- even in the best of programmers -- for
where program time might be going is almost always entirely
wrong. While a good programmer won't generally make their
program slower, the waste of labor is enormous, and often
the effect is nearly nil.

Only over many years using profilers have I even begun to
get it right very frequently even still, today, with 9
years of professional experience under my belt, my guesses
are frequently wrong. Of course, this is academic. I usually
review the code to see what it's about, form an opinion while
I'm reading it, attempt no changes, and then profile. I'm
surprised over half the time (hint: this is quite a bit
better than 100% of the time, which it was when I started).

>The definition of "fast enough" is probably nowhere to be 
>found, ...

*Shrug*. Part of my job includes optimizing programs which
run too slowly. All of these programs are of the type that
take hours to execute, usually. But the answer to the
question is: "fast enough to get the job done so that whoever
is doing the job views it as being 'fast'". (1)

Almost always, the problem is one of the following:

1. Inapproriate use of synchronous/unbuffered I/O.
2. Poor algorithmic complexity.

It's very rare indeed that I ever have to (or even will
permit myself to) tune a section of program that doesn't
have one of the above 2 problems. Frequently, I
encounter covert variants of these problem where the
programmers didn't really appreciate what kind of and
what intensity of work some API level call had to
perform.

C//

(1) hence modern scripted gui environments, horribly
innefficient, because "fast enough" that all operations
appear to be instantaneous even though they are monstrous
hogs.