Python for air traffic control?

[Thomas Wouters]

On Wed, Jul 04, 2001 at 07:42:51AM +1000, Peter Milliken wrote:

> > The only way to make sure a program works is by testing each and every
> > line in each and every circumstance, regardless of which programming
> > language you use. For something like ATC, you *do not* want to rely on
> > anything else. Using Python would at least allow you to find and fix
> > problems a lot faster -- you won't be carrying around NULL or undef
> > values without noticing it.

> > Do you check the return value of every fprintf()/fclose() function call
> > you make ? You should!

> Well, you show your inexperience/ignorance in two places here Thomas :-)

Neither, actually. My innocence, maybe, and my faith in numbers, but not
inexperience (I'm not) and not ignorance (at least, not that I know.)

> 1. No program EVER has 100% coverage during testing (unless it is trivial -
> this for the nitpickers :-)). The bigger the program the less likely full
> coverage has been achieved, ATC's are big programs. Anyone who claims they
> have 100% tested an ATC are either fools or liars - "every line and every
> circumstance" are NOT POSSIBLE, if you think they are then I don't have
> anything more to say other than get a few more years real world experience
> :-). So, if you plan to 100% test a python ATC "each line and every
> circumstance" then my original confidence that it would never be put into
> production holds (that's one of the reason languages have exception
> handlers - to catch the error that the programmer didn't foresee) :-).

You should try to re-read my message: I didn't say it was possible, or even
plausible (I happen think it's possible but implausible) just that it is the
only way it'll work. It also depends on what you call 'testing': open source
software, especially popular open source software, is continuously tested,
in the real world. Most bugs in Python nowadays are bugs in new features, or
on new platforms, because a lot of the possible combinations of what/when
have been covered. The real world is the testing, and proving, grounds
<wink>.

If you read the rest of the thread, you'll note that the ATC software runs
in acceptance testing for *years*. That's a lot of testing time. If you're
that deep into testing, you'll be done catching the 'typical' Python bug,
and just catch algorithm errors. Peter v/d Linden's excellent and highly
entertaining "Deep C Secrets" has some good examples of that (and no, they
aren't about C or C++.) Nothing, and I do mean *nothing*, in the language
could have prevented those errors.

> 2. Strongly typed languages don't include C/C++, so your example is
> meaningless i.e. a strongly typed language would at least FORCE you to
> assign/test the return value of an function - not like C/C++ which allows
> you to ignore any return values. This is not to say that an application
> written in a such a language wouldn't still ignore the return value after
> the assignment - that is a function of programmer ability (another point in
> my original email) - to fix that is up to testing and code review.

I didn't say C was strongly typed, nor did I say Perl was strongly typed.
Those two, and Python, are just my 'main' languages, and I just used them to
express what I meant: programmers can ignore error codes, and catch
exceptions and ignore them. There isn't much a language can do about that.
But that still doesn't mean that strongly typed languages are the best for
reliable code.

How does a strongly (and statically, I presume you mean) typed language
FORCE you to assign/test the return value of a function, by the way ? I
don't think I ever heard of a language that did that... My experience with
true strongly, statically typed languages must be smaller than I thought.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!