Python for air traffic control?

[Mike Silva]

"Peter Milliken" <peter.milliken at gtech.com> wrote in message news:<9i0cjt$ck9 at news1.gtech.com>...

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

I too immediately thought that Ada (Ada 95) would be the right tool
for this job.  It is the primary ATC language in much of the world
(don't know about the U.S.).  I think strong static typing is a must
in a safety-critical application such as ATC -- throwing an exception
at runtime is a Very Bad Thing in such applications (once out of
testing), so it is extremely desireable to catch errors at compile
time.  As has been suggested in this thread, strong typing (as opposed
to the C/C++ "it's all buckets of bits" approach) is an excellent tool
to force the designer/programmer to model the problem correctly,
rather than just funnelling bits here and there.  It also usually
results in reducing errors by an order of magnitude vs. C/C++ (and the
Ada runtime checking makes it much easier to catch most of the ones
that slip through).

While Python (from the little I know of it) is clearly stronger than
Ada in certain types of applications this wouldn't seem to be one of
them.  I can see this project benefitting from Ada features such as
fixed-point math, reduced reliance on heap memory (dynamic heap
allocation is also a Very Bad Thing in such applications), concurrency
(if allowed -- safety-critical projects often prohibit it), and ease
of interface with code written in other languages.  Take a look at Ada
(e.g. the GNAT compiler) for this job (and -don't- yield to the C/C++
temptation!).

Mike