Python for air traffic control?

[Peter Milliken]

"Russ" <18k11tm001 at sneakemail.com> wrote in message
news:bebbba07.0107031040.593143f8 at posting.google.com...
> "Peter Milliken" <peter.milliken at gtech.com> wrote in message
news:<9hrj3q$cj1 at news1.gtech.com>...
> > Funny, I thought all of the April Fool jokes were out on the 1st April,
did
> > this one get delayed (badly) somewhere along the line?
> >
> > Python is a fine language for quick and dirty prototyping. For banging
out
> > applications that are going to run in an environment where it isn't
going to
> > matter if the program crashes, but it is certainly not something I would
put
> > forward for something like Air Traffic Control.
> >
> > This is a joke, right?
>
> If that's your idea of a joke, you have a strange sense of humor, but
> I appreciate your post anyway. If your claims about Python are even
> close to the truth, I need to know.
>
Well, I indicated that I was hoping it wasn't a joke, so I think it is safe
to assume that I don't think the idea of an ATC written in Python funny, I
think the rest of my post bore that out, so if you still think I thought it
was then I would like you say that you have misunderstoof me :-).

Perhaps if you are seriously looking into possible languages to use for
writing an ATC then you might be better off looking for some research
information about the relative merits of different languages rather than
asking a fairly obvious question in a news group that will only be read by
adherents of a particular language :-). I say "obvious" here because you
will find only Python lovers here. I love Python but I wouldn't use it to
write an ATC.

The choice of languages for implementing various applications is sometimes
extremely suspect. I suspect that often it comes down to something like one
or more of the following reasons:

"I know X, it is a good language"
"I can get programmers more easily in language X than language Y"
"We currently have programmers who know language X"

I am not necessarily saying that choosing a language based upon the above
reasons is wrong, but it is hardly approaching the problem from an
engineering standpoint. There is literature available that compares the
relative merits of languages. To make an informed decision you really should
do some research and find out what information is available to help you make
the decision. The more information the better informed the decision. I am
sure as an aerospace engineer, you do studies into the various alternatives
for your design, why should choosing a programming language be any
different?

> <cut>
>
> > Based upon Gerrit's observations, which I fully endorse, anybody who
doesn't
> > use the most strongly typed language they can find for an application
like
> > Air Traffic Control, has to put it mildly, rocks in their head :-).
>
> As I indicated in my original post, the lack of type checking does
> concern me. However, as I wrote in a later post, I also suspect that
> this concern is overblown. I am not a computer scientist or even a
> full-time programmer, so I don't pretend to be an expert in this area.
> I am an aerospace engineer, and I do some programming in support of my
> own research (but I am a Python beginner).
>

There are studies that indicate that productivity in strongly typed
languages is higher (2:1 in one study I read - unfortunately, they are
"thin" on the ground because you need two identical ability teams doing the
same application in two different languages to get meaningful comparisions -
but it has been done and that was the result) than loosely typed languages.

> Consider the type checking in C or C++, for example. Suppose that a
> function takes several ints (or any other type) as arguments, and
> suppose the calls of the function all pass ints in the correct slots.
> The compiler will be perfectly happy. Does that assure that the
> arguments are passed correctly? Of course not. It is a necessary but
> not sufficient condition for correctness. The arguments could be
> completely out of order, and the compiler wouldn't have a clue.

Agreed, but one of my original points was about programmer ability. A
strongly typed language will only *help*, there is no sure fire cure to
generate a correct and workable program. Any *help* that you can get from
your development environment (strongly type compilers vs loosely typed etc)
will at the end of the day provide more chance that your application will be
successful. There is no one single factor that anyone can point to and say
"if you do that or use this" then you will be successful in your
application. Witness the efforts in quality control/CMM around the world.
These are all attempts at providing an infrastructure that will increase a
projects chances of being successful, nothing else.

Unfortunately, language choice is a very sensitive issue, and generally
doesn't come down to any rational factors - a lot of times it is "because I
like it" or "this is the newest, popular language, if I learn that one then
I can enhance my employment prospects" :-).

Of course, you *could* write an ATC in Python. You could write one in
assembler too, but nobody is offering that up! So, I beleive the same reason
you wouldn't write an ATC in assembler applies to why you would write one in
Python - there are better tools for the job. That's all I'm trying to say
here. Python is a good language. All languages have their strengths and
weaknesses. Some are better than others for different application domains.
Python is not a good choice for an ATC :-).

>
> Now consider argument passing by keyword in Python. The order of the
> arguments no longer matters. Sure, the wrong type of arguments could
> still be passed in, but it seems to me the probability is less than
> getting the wrong object of the right type in C++. In C++, the
> complier only checks the type of the argument, but Python checks the
> actual NAME of the argument. The name is more specific than the type.
>
This assumes that your coding standing inforces passing arguments by name -
just try staffing an ATC project and enforcing a coding standard. There will
be many programmers who "don't like the standard" and will do anything to
get around it. You generally catch these people through code review only and
often too late! :-). Python doesn't enforce this, personally I believe it is
a good feature and I use it frequently - but not all of the time :-)

> In C++, the function calls all get checked automatically at compile
> time, but Python doesn't check them until run time. That is a valid
> concern, but hardly a show-stopper. I understand that PyChecker can be
> used for static checking. I actually think the core Python language
> should have an option to do static checking, but as long as some
> product is available to do it, the issue is not major.
>

PyChecker is still very imature and some things it will never (poor word to
use, since if someone wants to put in the effort, nothing is impossible :-))
be checked by it. It will only ever be an aid. The ability of Python to
dynamically "change its behaviour on the fly" is one of its strengths but
also a weakness from the point of view of ensuring correctness and
reliability in such an application domain.

> > Don't get me wrong, Python is a nice language and you could probably do
the
> > job with it with enough time and effort. But as an earlier respondent
said,
> > you would literally have to test it to death and then some! i.e. because
of
> > the lack of type checking  there could be a single line of code
somewhere
> > that has never been run that could cause catastrophic failure of the
> > application (architectural design *might* mitigate this but it gets back
to
> > the people factor - something I don't trust :-)). At least with a
strongly
> > typed language, even if a line of code has never been run, you are
> > reasonably assured that when it does run it won't crash due to a
variable
> > being mispelled or mis-used.
>
> As I said, static type checking is a must, but it can already be done
> in Python. So I think your concerns, although valid, are way
> overblown. By the way, people in the commercial software industry have
> no idea about the amount of testing that will go into the ATC
> application we are talking about. Their concerns are completely
> different, of course. If they tested their software even one-tenth as
> much as this application will be tested, they'd go out of business. I
> get a kick out of people who think that a few programmers can hack out
> some code and just slap it into an operational ATC system (not to
> imply you think that, of course).

As I said above, static checking is not possible (unless I missed something?
always happy to be corrected :-)), so my concerns are not "overblown", but
as you say, "valid".

I have worked in the defence industry for almost my entire career (many of
our "commercial" friends just blew big raspberries here :-)), so I am under
no allusions as to the amount of testing done in either the commercial world
(where I am now) or the aerospace world :-) Personally I am happy with the
amount testing done in the commercial world - good job security, they need
legions of maintenance programmers :-). The defence companies have been
leaving my local area, so rather than move with them I looked for the place
with the highest prospects of job security - found it in maintaining a
system that was written in C - lots of work! :-)

>
> > Of course, I could at this point say I would never venture into air
space
> > controlled by such as system, but I know it would never get off the
ground
> > (so to speak :-)) because to do it in Python would mean it would never
pass
> > acceptance testing - sure you could code it just as fast (if not faster)
> > than most other languages used for this application area but you would
be in
> > the test phase forever - or at least until the customer cancelled the
> > contract :-). So keep dreaming :-)
>
> You may be right that Python is not the right language, but I don't
> think you've made a convincing case.
>
> Russ

Well, if you need more information, email me directly Russ - I'm more than
happy to help. The issue can be confusing with all of the Python lovers on
the list :-)

Goodluck,
Peter