Bools and explicitness [was Re: PyWart: The problem with "print"]

Steven D'Aprano steve+comp.lang.python at pearwood.info
Wed Jun 5 21:37:20 EDT 2013


On Wed, 05 Jun 2013 09:15:01 -0700, Russ P. wrote:

> On Wednesday, June 5, 2013 1:59:01 AM UTC-7, Mark Lawrence wrote:
>> On 05/06/2013 07:11, Russ P. wrote:
>> 
>> > But then, what would you expect of a language that allows you to
>> > write
>> >
>> > x = 1
>> > x = "Hello"
>> >
>> > It's all loosey goosey -- which is fine for many applications but
>> > certainly not for critical ones.
>> >
>> 
>> 
>> I want to launch this rocket with an expensive satellite on top.  I
>> know it's safe as the code is written in ADA.  Whoops :(
> 
> 
> So Python would have been a better choice? Yeah, right. 

Putting issues of efficiency aside, yes, it probably would have. Had the 
programmers not been so sure that the compiler was protecting them from 
bugs, a misplaced hope if there ever was one, they might have written 
some tests and noticed that their simulated rocket launch ended up going 
boom instead of into orbit.

I'm referring to the first test flight of the Ariane 5, which failed due 
to a software bug. There was no actual satellite on this flight. The 
failure Mark refers to was due to a leak in coolant pipes, which of 
course is a hardware problem and cannot be blamed on the software.

http://en.wikipedia.org/wiki/Ariane_5#Notable_launches



> If you know
> anything about that rocket mishap, you should know that Ada was not the
> source of the problem. Ada won't keep airplane wings from breaking
> either, by the way. It's not magic.

Again, referring to the infamous 64-bit float to 16-bit integer bug, Ada 
may not have been the *source* of the problem, but neither did it prevent 
it.

What prevents bugs is the skill of the people writing the code, not the 
compiler. Compile-time static type checking is merely a tool, which has 
costs and benefits. It is ludicrous to think that any one single tool, or 
the lack of that tool, will make all the difference between working code 
and non-working code.

Static type-checking is no better, or worse, for "critical code" than 
dynamic type-checking. One language chooses to deal with some errors at 
compile-time, others deal with them at run-time. Either way, the 
programmer has to deal with them in some way.

A static type system forces you to deal with a limited subset of errors, 
"type errors", in one way only: by removing any execution paths in the 
software which would assign data of type X to a variable of type Y. For 
reasons of machine efficiency, that is often a good was to deal with such 
errors. But a dynamic type system makes different trade-offs.

And of course, type errors are such a vanishingly small subset of all the 
possible errors that might be made that, frankly, the difference in code 
quality between those with static typing and those without is essentially 
indistinguishable. There's no evidence that code written in static typed 
languages is less buggy than code written in dynamic languages.


-- 
Steven



More information about the Python-list mailing list