Python for air traffic control?

James_Althoff at James_Althoff at
Thu Jul 5 20:08:31 CEST 2001

Having built and managed programming organizations comprising hundreds of
software engineers, I completely agree with Alex's observations below.
In fact, I await the day when Leigh Steinberg takes on his first programmer
as a client!

(Or will it be the William Morris Agency?  :-)


"Peter Milliken" <peter.milliken at> wrote in message
news:9htgsb$ck3 at
> 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
> same application in two different languages to get meaningful
comparisions -
> but it has been done and that was the result) than loosely typed

I'll appreciate some URL's, thanks.  In exchange, please look at
Lutz Prechelt et al's 1999 "phonecode" study -- e.g. at

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
> "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
> like it" or "this is the newest, popular language, if I learn that one
> 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).



More information about the Python-list mailing list