Why I love python.

[Nick Patavalis]

On 2004-08-13, Dave Brueck <dave at pythonapocrypha.com> wrote:
>
> Yes. Apache is not that fast, and web servers are often more network 
> bound than CPU bound.
>

We 're obviously interested in cases where the problem is
CPU-bound. In a network-bound server, there is no *meaning* in
speaking about performance (with respect to the implementation
language).

> Nobody is arguing that Python is as fast as C. But being slower does
> not imply that Python is unsuitable for those tasks. I'd consider
> your list to be pretty atypical of normal development (how many TCP
> stacks and relational databases need to get written each year?),

I also mentioned web-browsers, ray-tracers, circuit-simulators. I
could add word-processor, spreadsheets, video editing programs, and
GUI toolkits to the list. Are they still too exotic? To cut the thread
short, what I mean is that an application that has to do something
like:

   for i in range(N):
       a[i] = b[i] + c[i]

is bound to be 10 to 100 times slower than the equivalent coded in
C. Which means that the cost of doing *computation* in Python is
prohibitively high! Have you ever seen, say, an AVL-tree
implementation in production Python code? Probably not. Have you ever
seen someone implementing some sort of string-lookup algorithm in
Python (instead of using the build-in dictionaries)? Again no. Is it
because Python has found the "one-size-fits-all",
"best-algorithm-ever-devised" solution? Or is it because the weight of
the language itself is such that even a suboptimal algorithm
implemented in C will never be matched by a python implementation?

The very fact that the python interpreter itself in implemented in C
(and not in Python) is indicative.

>
> Note also that all or most of those programs on your last at one time 
> had to be partially implemented in assembly language even if the main 
> language was C or C++, and yet that didn't make C or C++ unsuitable 
> development languages for the task (nor did it make them only "glue 
> languages").
>

No, but the performance difference between C and Assembly was
*small*. And at some point the C compilers became so good, that you
couldn't beat them by hand coding something (of considerable length)
in assembly. As for C++, one of its primary design-goals were "zero
unneeded overhead"; so it *is* possible to write a C++ program that is
as fast as a C program, if you want to do it.

> The same can hold true for Python in many cases - if a small portion
> needs to be developed in a lower-level language you can still derive
> great benefit from doing the rest of the application in Python.

Of course you can! Nobody argued that Python is useless. Python is one
of the cleanest, most pleasant, and most productive languages one
could wish for. For me it would not be an exaggeration to say that
Python has brought a lot of fun back in programming (and in many
ways). The reason I'm writing this is that *I also* hate to see it
pigeon-holed as a "glue" or "scripting" language. Our difference, I
guess, is that I believe that there is *some* truth in such missives;
and this has to do with the current, immature, state of the Python
*environments*. So my point is that we should not relax in the cozy
feeling that "Python is great for most applications, even if it's a
little slow, but who cares". I want to be able to write signal
processing functions in Python, or implement that optimized
special-case search algorithm, and I want to be sure that---by guiding
the compiler properly---it will produce code that is as efficient as a
well-written C program, or hand-coded assembly (or at least close to
that). I want the next GUI toolkit I use to be written in Python
(instead of written in C++ and simply wrapped in Python). And I
believe that this *is* possible, provided that we don't ignore all the
years that have been spent advancing compiler technology, and that we
don't treat the current Python environments as the "end of the
line". CPython is a good proof that Python works, and that it is a
great language. For Python to become a "primary" language, there's
still much work to be done. Most of this work, as I said before, has
to do with the environments (interpreters, AOT/JIT compilers,
optimizers, runtime modules, etc). But some of it has to do with
ensuring---at the language level---that efficient environments are
possible. Considering CPython and Python one and the same leads
straight to a Perl-ish hell!

/npat