Python for air traffic control?

[Peter Milliken]

"Thomas Wouters" <thomas at xs4all.net> wrote in message
news:mailman.994263608.9373.python-list at python.org...
> 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.)
>

Well, sorry Thomas, my command of the English language isn't the best, I'm a
fairly typical engineer i.e. I almost failed English in highschool :-). But
I thought that was a reasonable definition for inexperience/ignorance i.e.
"innocence" is generally present until experience takes it away (through
pain and suffering, most times :-)) and "ignorance" is the lack of "knowing"
about something. So, you seem to be confirming my original statement :-).
Through your innocence you are inexperienced and you admit to (possibility
of) your lack of your own knowledge :-). No offence intended here, BTW :-).

> > 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>.
>

Once again, English/semantics could be causing a misunderstanding here (you
speak American, I speak Australian :-)) but I thought that a reasonable
interpretation of "by testing each and every line in each and every
circumstance" equated to "100% coverage of a program". At least, my
experience as a test engineer says that 100% coverage was "each and every
line in each and every circumstance" :-). Anyway, at least we agree that
whatever terminology we want to use, it is not possible/plausable to test to
that level. You make the point that Python would help you find NULLs and
undef's - well, the language of choice that I would use has this capacity as
well :-). It "dumps" information the same way Python does i.e. if the
programmer didn't foresee something then run-time checks will provide
diagnostic information as to the problem area. It also provides "run-time"
checks on the use of variables/values in a similar manner to Python.

> 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.

Actually, a "strongly typed" language would get all of the bugs you are
refering to out at compile time - and save you several years of testing :-).
A strongly typed language will *only* leave the algorithimic type errors
(there are probably a few errors that are exceptions but I am making a point
through very minor exaggeration). This is personal, real experience here
:-).

I have also worked on a large(ish) C project in the '90's. 40+ programmers,
It went for 7.5 years before the customer cancelled it. It was in acceptance
testing for 4 of those years - they never got all of the bugs out of it.
There was in the vicinity of 14,000+ problem reports (some portions of the
application were completely re-written, so they didn't count towards this
number :-)). So, I doubt seriously that you would catch all of the "typical"
Python bugs :-). This was an example where the 25%-50% rule was exceeded
:-).

>
> > 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.
>

Sorry, since the context of my post was about typing, I assumed in your
response implied something in that area that it obviously didn't. Yes, I
agree, no matter what the language, a programmer is the source of any bugs
in the code :-). There is nothing you can do about that. What you can do
though (keep in mind the environment here, we are talking potentially
hundreds of programmers - remember also the 25%-50% rule :-)) is provide a
development environment that will "force" or "funnel" the programmers in
producing *more* reliable code i.e. a strongly typed language will not allow
a programmer to compile a truly incorrect program - so they couldn't even
get to unit testing! :-). Programming teams have produced failures despite
using a strongly typed language, there is no cure for the inherent weakness
of the people factor. A language and a compiler is only a tool, some tools
are better than others at particular aspects of the job.


> 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.
>

Strong type checking means that when you tell a compiler that a function
will return a value then the compiler will not allow a program to compile
that doesn't have that return value assigned to *something* (of the
appropriate type, as well :-)) i.e. a program variable or just used in a
test case e.g if statement. The language that I have in mind is Ada - it is
used primarily in the defence industry and therefore has the stigma of being
a "defence language" and therefore not worth considering in the "real world"
of commercial programming :-) (their loss :-)). It was designed to/using
some strict computer science principles (please, no boffins jumping in here
with corrections thanks :-)) of the day and encourages, through the language
definition and operation of the compiler some very handy heuristics. It is a
very "readable" language (uses keywords in the same style as Pascal and
Modula). By default (you can turn it off when generating binaries for the
live system), it generates automatic run-time checking of code i.e. if you
define a data type that should only ever have a range of values of 0 - 255
then if you try and assign 256 to a variable of that type then it will raise
an exception at runt-ime (this assumes that the compiler wasn't able to
detect that at compile time though! a statement line like byte_var := 256;
would raise an error from the compiler) - the application will either handle
the exception via an exception handler (has to be programmed though, just
like Python :-)) or it will abort the program and display diagnostic data
(just like Python :-)).

Many programmers, when they first meet a strongly typed language (such as
Ada, but there are others) have a great deal of difficulty, because they are
used to having a lot more "freedom" from the languages they are used to. But
once you get past the barrier of producing correct code then it offers a
great freedom - 90% of your "typical" bugs are found by the compiler at
compile time rather than during unit testing :-). In my experience (I wrote
code using Ada for about 4-5 years, I have about 10-12 years of coding in C,
I have used C++ but not any any extent worth mentioning), the only bugs left
after a successful compile are "algorithimic" - a truly great aid to
productivity! :-). Most programmers can't get past that first hurdle though,
they "hate" the language because it "won't let them do what they want" - but
if they examined their code, they are always forced to admit that what they
"wanted" wasn't "correct" :-).

But Ada is like C or C++ - it doesn't "shine"  in the areas of data
manipulation that Python does. It doesn't have a huge array of support
libraries, like Python, Perl and Java do etc. So productivity can be down
purely because you have to write a lot of basic things from the ground up.
Again, different languages have different applications areas. Python is not
my choice for an ATC (as anyone may have guessed by now :-)), C/C++ would be
a disaster! Of those mentioned, I believe Ada is a better choice, there may
be others but I have no experience with those languages so I can't comment.
Caveat: ANY LANGUAGE can produce working code for an application, it is just
the amount or work and effort required to get there. Python *could* be used
for an ATC application, so can assembler - but I haven't heard anyone
advocating that one :-).

Hope you have a good day,
Peter