Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Paul Rubin wrote:
> Jeff Schwab <jeff at schwabcenter.com> writes:
>>> there's actually a published book specifically about C++ pitfalls.
>> Mercy, a whole book?
> 
> http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?EAN=9780201179286
> 
>>> C and C++ should practically be outlawed at this point.
>> On what grounds?  "I don't approve of the programming language you're
>> using.  Cease and desist.  Nyah!"
> 
> Well, "outlawed" of course is a figure of speech; however use of those
> 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?


> Think of all
> the buffer overflow exploits against Microsoft Windows programs that
> couldn't have happened if Microsoft had used safer languages.  There
> was clearly a failure to use best engineering practices.

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; the C++ bounds checks, unlike the Python 
checks, are done in-language.  If C++ were marketed like Java, people 
might advertise that the C++ standard containers are "pure C++," or that 
"C++ is written in C++".

Secondly, you're going to have a hard time writing an operating system 
kernel without fixed-size buffers.  You have to read data in chunks of 
some size.  It's fine to say that buffer access should be checked to 
make sure indexes should be in range, but somebody actually has to write 
the code to do the checking, and then programmers have to use it. 
Buffer overflows are the result of developers deliberately choosing not 
to use bounds-checking.

In Python, somebody could still define a monolithic array, use different 
parts of it to represent different things, and then "oops" lose track of 
their index, thereby overwriting one part of the array with data that 
should have stayed in the other part.  If you're thinking "Yeah, they 
*could*, but only a dodo would do that, and it's not Python's fault that 
the programmer did something bone-headed," then you're beginning to get 
the picture.  If you somehow wrote an OS kernel in Python, and the 
above-mentioned bone-headedness took place, then there would be no 
"lower level" to save your OS from having a dangerous security hole. 
Even if the hardware supported checked access for large quantities of 
arbitrarily sized arrays, somebody would have 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?

Thirdly, you mentioned a "failure to use best engineering practices." 
If you mean there was a failure to design and implement a bug-free 
operating system, then by Jiminy, you're right.  "Best practices," 
though, is usually just what managers say when they mean "what everybody 
else is doing."  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.

Server-side Python is now, at this very moment, becoming acceptable as 
"best practice."  It's no better or worse for this; it's just that a lot 
more uninspired, uncreative programmers are about to start using it.  Do 
not underestimate their ability to make any programming language look 
bad.  If you make it fool-proof, they'll build a better fool.  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.  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."