Python for air traffic control?

Peter Milliken peter.milliken at gtech.com
Thu Jul 5 18:04:26 EDT 2001


"Russ" <18k11tm001 at sneakemail.com> wrote in message
news:bebbba07.0107042341.4283ca43 at posting.google.com...
> "Peter Milliken" <peter.milliken at gtech.com> wrote in message
news:<9htgsb$ck3 at news1.gtech.com>...
>
> > 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.
>
> Perhaps I should clarify that I am not proposing to use Python for a
> complete ATC system but rather for a relatively small, albeit key,
> component of a very large system.

Well, that makes it a completely different ballgame :-). I can't comment in
this case because I would need more information about the proposed area
prior to making any informed (or thought to be informed :-)) opinions. The
only thing to bear in mind in this case is there are other languages which
offer the same (nice) features of Python but they would probably be a
*safer* choice. Especially if the area you have in mind is in any way
central or critical to the operation of the ATC as a whole. If it is small
enough, then you can employ good testing, defensive programming techniques
etc to the point where you can assure and reassure yourself and others that
it is a good fit and solution. But even then I would (assuming I was your
manager :-)) be looking for some good, definitive reason for using Python
over some other language i.e. I would be looking for a business case of some
form. A comparision of language features, a comparision of available
libraries, that kind of thing. Many times (in my opinion :-)) the selection
of language for a project comes down to "well, I like it" or vague hand
waving and statements like "well, it's a popular language therefore it must
be the best" - neither of which are good engineering bases for decision
making :-)

>
> > 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?
>
> I agree. However, I wouldn't know where to start with the formal
> literature, and even if I did I don't have enough time to pursue it in
> depth. My management is already worried that I am even considering
> Python (they'd never even heard of it), and they may well shoot it
> down even if it's my choice. (You'd no doubt praise them for that. :-)
>

No, you have me wrong there :-), if you could place a sound, reasoned case
in front of me that I couldn't pick holes in then I would OK the choice. So
far all you have said in this thread is you are thinking about using Python
because you have been dabbling with it at a personal level - this is not a
good basis for choosing a language! Although, as I said previously, I
suspect it has been done for these reasons many times in the past - a sad
reflection on the professionalism of our industry.

> > > <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.
>
> Let's cut right to the chase here. I like strong typing almost as much
> as you do, but I don't understand why I can't get it in Python,
> perhaps by specialized code-analysis tools. Is the problem just that
> the development tools are underdeveloped, or is there a fundamental
> technical reason that type-checking cannot be done? If it's the
> former, then I suggest that the tools be given a very high priority.
> If it's the latter, then perhaps type checking can be done under
> certain reasonable restrictions. Whatever the case, I want to have my
> cake and eat it too. :-)
>

Well, sometimes I make my son do something he doesn't want to because I
believe it is in his best interests - even when he doesn't :-).

The design of Python was to incorporate the "freedoms" of dynamic typing -
it is a fundamental feature of the language. You can't work around it (well,
another "absolute" in a land where there are none if you are prepared to
spend the rest of your life achieving your goal, but as I said elsewhere, by
the time you work around it it is nolonger Python :-)). So producing code
analysis tools would be a big job and still prone to error/misinformation
(witness other posting in this portion of the thread about the reliability
of PyChecker). The nature of dynamic typing would make it almost impossible
for PyChecker to give accurate results, it would basically have to "run" the
program through all possible permutations to even come close and when the
program takes input from outside itself and runs certain Python features
then you would NEVER be able to get PyChecker to predict whether something
is correct or not :-).

So, sorry, I can understand and sympathise with the desire to have your cake
and eat it but it is a forelorn hope in this case :-).

> <cut>
> > 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.
>
> Do you think PyChecker could ever be sophisticated enough to do static
> type checking?
>

See above, with commands like exec,eval etc PyChecker could never be
sophisticated enough to provide *full* static checking. For example, I use
Python right at the moment to write a client/server application - to ease
the changes on the server side I send Python executable code through the
socket connection where it is executed by a Python thread (that way I don't
have to come up with a protocol for the command syntax, create a new case
statement each time a new command is added to the server etc etc). PyChecker
would not provide full coverage in this case........

Goodluck with your desires but please (for those of us who will fly in
future) base your decisions on sound engineering practice and not wishful
thinking :-)

Peter





More information about the Python-list mailing list