Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Jeff Schwab <jeff at schwabcenter.com> writes:
> > languages should be a red flag in a design review, and a factor in
> > determining product liability if a program misbehaves.
> 
> Your product gets the benefit of the doubt if it was written in
> Python, but not if written in C?  What if the Python interpreter
> screws up?

The Python interpreter has been run in production for over a decade
modulo comparatively small incremental changes, heavily reviewed and
tested by multiple people, between versions.  It's likely to be more
reliable than any one-off C program of comparable size.  Further, for
a C application, the analogous situation to the Python interpreter
screwing up would be the C compiler screwing up (generating wrong
code).  They have that possibility in common.  But for the C
application, the screwup can be in two places (the compiler or the
application) while Python limits it to one place.  The principle here
is to minimize the size of the so-called trusted codebase.

Either way, the ongoing effort (PyPy) to write Python in Python will
probably improve Python's reliability.

> In the first place, you're not distinguishing C from C++.  I know you
> think they're the same.  They're not.  Python's array bounds checking
> is done in C, as is the case for traditional OS kernels.  C++, like
> Python, offers you container types that "smell" like arrays, but do
> safety checking under the hood; 

Not as long as you can have pointers to those objects that contain
naked memory addresses which can be invalid.

> Buffer overflows are the result of developers deliberately
> choosing not to use bounds-checking.

Yes, the most common way that choice is expressed is by choosing to
code in C or C++ in the first place.

> to enable that access. Even then you're trusting the hardware
> developers to check for invalid indexes (bus errors and seg faults).
> Should we outlaw computer hardware, too?

Again, the concept is "best practices" which is an engineering term,
not a mathematical one.  Best practices are not infallible, they're
just the best normal practices observed in real-world projects of
similar scope.

> "Best practices," though, is usually just what managers say when
> they mean "what everybody else is doing."  

No really, among other things it includes following standards that
are designed by people who know what they're doing.  That actually
means something.  

> The idea is that if you're a manager who sticks to "best practices,"
> then if everything goes to hell, the problem can't be linked
> specifically to you.

That is a very valuable aspect.  If I'm writing an encryption program,
best practice is to use a standard algorithm like AES instead of
concocting my own algorithm.  If something does turn out to be wrong
wtih AES that makes my program fail, I'm very glad to be able to point
to the rigorous standardization process that AES went through and say
that I made the best choice I could with available information.  If
for some reason I think there's an 0.002% chance that something is
wrong with AES but only an 0.001% chance that something is wrong with
my home-cooked algorithm, AES is still the obvious choice.

Same thing with internet applications, I'm much better off writing in
a type-safe language than relying on the intricacies of my unique
application code to behave properly in a language without type-safety.

> The only way to keep them from writing code that will blow up
> at run-time is to impose formal verification of their program, every
> time they change it; that's what the C++ static type system lets you
> do, in a limited and easily subverted way. 

Why not get rid of the limitations and easy subversions?  And I can't
agree that using a basic type like "int x[10];" is somehow a
subversion.  Subversion means you have to go to some lengths to break
the type safety.

> Even if you could somehow remove every feature open to potential
> abuse, and thereby dodo-proof the language, the result would be a
> slow, weak, ugly language that non-dodos would not want to use.  But
> hey, at least it would still be "best practice."

Enforcing type safety is certainly an enormous step towards
dodo-proofing a language, it hugely helps the reliability of real
programs, and is one of the reasons Python and Java are displacing C++.