Article of interest: Python pros/cons for the enterprise
jeff at schwabcenter.com
Sun Feb 24 06:09:58 CET 2008
Paul Rubin wrote:
> Jeff Schwab <jeff at schwabcenter.com> writes:
>>> there's actually a published book specifically about C++ pitfalls.
>> Mercy, a whole book?
>>> 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
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."
More information about the Python-list