Jeff Schwab <[EMAIL PROTECTED]> 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++. -- http://mail.python.org/mailman/listinfo/python-list
