Python for air traffic control?

[Peter Milliken]

Hi Alex,
Thanks for sharing that information. Have a look at
http://www.rational.com/products/whitepapers/337.jsp for the productivity
paper I was referencing.

As for the productivity data, I apologise, my original comment was in the
very narrow and strict proviso of real-time applications and using a
"normal" real-time language. So I am venturing out of my experience depth
somewhat here in some of my comments :-). Please correct me where you feel
the urge :-).

I wouldn't use/choose Python in a true real-time application because
(usually) interpreted languages just can't compare in terms of speed
performance with languages that have been designed with lower level
capabilities in mind i.e. C. (Another interesting URL is this one:
http://dblp.uni-trier.de/db/conf/sigada/triada92.html#LawlisE92 - sorry, you
will need an ACM membership to get access to the paper though, it used to be
freely available but I couldn't find any valid references other than this).
Now, I know that computers are "faster than light" now and "this is nolonger
a consideration" in this day and age. But it still is for large scale
systems. The problem domain almost invariably stretches the current hardware
(remember, at some stage you have to choose the hardware platform and commit
yourself to it, you can't develop an application over the course of several
years without making that commitment relatively early in the piece - it used
to be a lot worse in the "good old days", you bought the target hardware at
the start of the project and drooled over what the current state of the art
was by the end of the project but were forced to watch your dream creation
running on a, by then, dinosaur :-)).

Python shines at manipulation of things like strings, dictionary searches,
list manipulation etc etc but these are rarely requirements or useful
features in a real-time problem domain (I have worked on projects that
lasted years where most of the programmers didn't know how to do basic IO or
manipulate strings in the language because the portions of the system
architecture they were in didn't require any interface to the user!).  I
believe that Python is being used in some high performance areas, so don't
get me wrong, I wouldn't necessarily rule it out for those reasons but any
interpreted language *automatically* becomes less of a consideration when I
think of what language to do a real-time application in. The mere fact that
you can drop into an underlying language (C or whatever) when you require
speed is one of Pythons strengths, but also supports my idea that it is one
of its weaknesses when it comes to real-time. Most real-time systems don't
have a lot of data handling required ie read string processing, Python (and
such languages) are optimised for this kind of situation. So, any situation
that requires manipulation of data in these forms are going to benefit from
using Python. But surprisingly, the majority of real-time systems aren't
called on to manipulate these kind of data structures.

As for "have only the BEST programmers.  How to insure THAT is left as an
exercise for the reader:-)." Well, that's not possible when you have to
staff a project with large numbers of programmers. Most managers get so
desparate to have "bums on seats" that they take what they can get and tell
the team leads to "make the most of it" :-). There is no doubt, that if you
are lucky enough to work with a small, good group of people then you can do
very good work. But generally, even when I have worked in teams as small as
4 people, the 25%-50% rule has still been evident i.e. at least one of those
4 was a "waste of space", another was only "so-so" the other two did all the
real work and helped pull the others across the finish line through plan old
hard work :-). This has to be an important factor (IMO :-)) when choosing a
language/development environment i.e. you need "tools" to help *force* that
25%-50% to produce better quality work - but even that is only an *aid*
there is no "silver bullet" that will solve the problem. One of Pythons
strengths is the freedom it offers - with poor programmers this becomes one
of its greatest *weaknesses* (I can hear the howls of outrage from here in
Sydney :-)). With this element of your work force (and you have to plan for
them as well, because you will have them, no doubt about it! :-)) then
something (language, process, whatever) that will "funnel" them down the
right path is what you have to aim for.

As for the "superstar" concept - don't believe it to the extent you imply
:-) Yes, research *can* show productivity factors like that and I can tell
you stories of people who were placed on third shift where they were "out of
sight" - all they did was get their sleep and did *no* work (one that comes
to mind was they couldn't sack her because she would have cried racial
discrimination - and so when her work was due they just reassigned it to
another programmer). So productivity when compared to these people *can*
achieve factors of 1000:1. But in a normal world, I believe very much in the
lower published figures (languages aside here) of  anywhere from 2:1 to
15-20:1 (which is still pretty high and is a direct result of my 25%-50%
rule i.e. they shouldn't *even* be in the industry! :-)). That is not to say
that companies shouldn't reward the high performers but how do you measure
that performance? :-) The minute you talk about metric gathering (code
review, bugs per KLOC, resubmittal rate etc etc) you hear the howls of
outrage - "how  dare you measure my performance", "how dare you criticise my
code" - it's almost like when we leave University we somehow drop the mantle
of engineer/computer scientist and take up the mantle of artist/prima donna
:-)

Anyway, thanks for sharing the reference, hope you enjoy mine :-). BTW, they
give away the hint of what language I *would* use to program an ATC :-)

Peter

"Alex Martelli" <aleaxit at yahoo.com> wrote in message
news:9huo4n01jfl at enews1.newsguy.com...
> "Peter Milliken" <peter.milliken at gtech.com> wrote in message
> news:9htgsb$ck3 at news1.gtech.com...
>     ...
> > 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.
>
> I'll appreciate some URL's, thanks.  In exchange, please look at
> Lutz Prechelt et al's 1999 "phonecode" study -- e.g. at
> http://wwwipd.ira.uka.de/~prechelt/documents/jccpp_tr.pdf.
>
> 80 implementations of the same specs, some in "scripting languages"
> (Perl, Python, Tcl, Rexx), some in "system languages" (Java, C,
> C++).  As it happens, Python was the only language for which NONE
> of the submitted programs was 'unusable' (11 of the original 91
> were not further evaluated, being completely unusable).  Overall
> results (my biased summary): programmer productivity is highest
> (by far) in Perl or Python (no statistically significant
> differences between Perl and Python).  Program performance is
> highest in C and C++, followed by Perl and Python, followed
> by Java, with Tcl and Rexx far slower yet.  Many of Prechelt's
> conclusions are invalidated by grouping Tcl and Rexx together
> with Perl and Python, but fortunately he also supplies raw data
> so you can redo the analysis.
>
>
> > Agreed, but one of my original points was about programmer ability. A
>
> The difference between the best and worst programmers in any single
> given language is far larger than any difference among languages,
> as evidenced in Prechelt's study -- in both productivity, and in
> correctness and performance of the resulting programs.  E.g.,
> the fastest Python and Perl programs are *HUNDREDS* of times
> faster than the slowest C and C++ ones, incredible as that may
> seem for what was a rather simple overall task.
>
> > 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
>
> Oh yes there is -- have only the BEST programmers.  How to insure
> THAT is left as an exercise for the reader:-).
>
> > 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" :-).
>
> The latter is a perfectly-rational factor.  If you want to swing
> programmers' motivations towards "doing the best we possibly can
> on THIS one product", you have to make that compatible with their
> overall motivation of "have an interesting and financially rewarding
> career".  Stock options, cash prizes for specific targets, whatever.
> Non-financial forms of recognition can also be very important...!
>
> If you want/need to treat your programmers as interchangeable parts,
> don't be surprised if they treat your project as just one short step
> within a long career.  My impression is that most development shops
> underestimate the importance of keeping their best programmers and
> attracting other super-performers -- because it's not acknowledged
> yet that the individual performance variation between the best
> programmer in the best environment, and a mediocre programmer in
> a mediocre environment, is MANY orders of magnitude (easily a
> factor of 1,000 -- look at those *hundreds of times performance
> ratios* above-quoted for best-Python vs worst-C...!!!).  Once this
> little fact does start to be realized, we may move into a kind of
> "superstar economy" for developers, as is currently in force in
> sports, show-business, CEO's, traders, and some professions (lawyers,
> doctors), where top performers earn _disproportionately_ more than
> mediocre counterparts -- which will have its own problems (and how!),
> but very different ones from today's relative "flattening" (where a
> performance that's 1,000 times better is only rewarded 10 or 20
> times better, if that).
>
>
> Alex
>
>
>