Python vs C for a mail server

[Alex Martelli]

Jay Parlar <jparlar at cogeco.ca> wrote:
   ...
> Because in all of my own industry experience, it's been MUCH easier to
> jump into someone else's Python code than someone else's C++ code (and
> at my last job, I had to do a lot of both). I find Python to be much 
> more self-documenting, because there's not so much scaffolding all over
> the place obfuscating the true intention of the code.

In the average, you're right.  However, if you can rely on ALL the code
in question being brilliantly well designed, written by programmers of
unbelievably high quality, in full and strict adherence to rigorous
coding-style guides (which absolutely forbid the use of LARGE slices of
each language) and a reasonably thorough process (mandatory code reviews
before anything is committed, mandatory testing, the works), the issue
is substantially ameliorated.  It does remain true that the amount of
Python code needed to implement any given functionality X is smaller
than the amount of C++ code needed for the same purpose, of course; the
amount of effort to understand a codebase of uniformly high quality
being roughly proportional to the size of that codebase, Python will
still be advantageous.  But by, oh, some small factor (maybe a factor of
2? surely not as high as 5), NOT orders of magnitude.

If the design, the programmers, the coding-style, and-or the process are
of lesser quality, then you're in trouble either way, and I will concede
that the situation degrades faster for C++ -- not only does it offer
people more ways to get themselves into trouble, but unless you can
count on uniformly high quality the effort is not just linearly
proportional to the size of the codebase, it grows much faster than
that, so the "lack of scaffolding" and other factors making Python more
expressive do matter more.

Still, if I was back to working as a freelance consultant and got hired
to fix a problem situation, I wouldn't _start_ by recommending a switch
from Java or C++ to Python as the highest-urgency issue: I would first
focus on people (both as individual and teams), process, design, and
tack language (including style) and other technological issues
(including choice of tools, frameworks, libraries, etc) as being, while
undoubtedly important, of slightly lesser urgency.  Don't get me wrong:
using the most appropriate technologies does make a big difference; but
it's too easy a temptation to focus on technological "silver bullets"
and assume they can "just fix things" if ``softer'' but at least as
crucial problems are left to keep festering in the background.


Alex