status of Programming by Contract (PEP 316)?

[Russ]

On Aug 30, 7:20 pm, al... at mac.com (Alex Martelli) wrote:
> Russ <uymqlp... at sneakemail.com> wrote:
>
>    ...
>
> > programs." Any idea how much Python is used for flight control systems
> > in commercial
> > transport aircraft or jet fighters?


Hi Alex. I've always enjoyed your Piggies talks at
Google (although I missed he last one because I was out
of town). I'm disappointed to see that you seem to have
taken personal offense from remarks I made to someone else who
attacked
me first. I will take issue with some of your remarks,
bit none of it is intended to be personal, and I sincerely hope
you don't take it that way.


> Are there differences in reliability requirements between the parts of
> such control systems that run on aircraft themselves, and those that run
> in airports' control towers?  Because Python *IS* used in the latter
> case, cfr <http://www.python.org/about/success/frequentis/> ... if
> on-plane control SW requires hard-real-time response, that might be a
> more credible reason why Python would be inappropriate (any garbage
> collected language is NOT a candidate for hard-real-time SW!) than your
> implied aspersions against Python's reliability.


I've seen that site before. They have a nice product
that was developed in Python, but it is not clear to me
that is actually safety-critical. It appears to be a
GUI designer for displays at air traffic control towers.
I can't tell if this is "just" a development tool, or if it
the python-based product is actually used directly by
controllers. Also, this product does not seem to actually
display aircraft to controllers. It seems to be more of
a semi-static display of runway conditions. Not to
minimize its importance, but I don't know if this product
actually qualifies as safety critical, and if it does,
it probably does so only marginally.


> According to
> <http://uptime.pingdom.com/site/month_summary/site_name/www.google.com>,
> Google's current uptime is around 99.99%, with many months at 100% and a
> few at 99.98% -- and that's on *cheap*, not-that-reliable commodity HW,
> and in real-world conditions where power can go away, network cables can
> accidentally get cut, etc.  I'm Uber Tech Lead for Production Systems at
> Google -- i.e., the groups I uber-lead are responsible for some software
> which (partly by automating things as much as possible) empowers our
> wondrous Site Reliability Engineers and network specialists to achieve
> that uptime in face of all the Bad Stuff the world can and does throw at
> us.  Guess what programming language I'm a well-known expert of...?


I certainly cannot deny the success of Google, but I
don't think that a high uptime with thousands of servers
is comparable to reliable safety-critical software. You
can't put thousands of flight management computers on
an airplane and just switch over to another as they go
fail. And if a web server gives bogus results nobody
worries much, but if a flight computer gives bogus
outputs, some people worry a lot.

By the way, I use Google Groups, and it has a few
annoying glitches. For example, I couldn't read your
post without scrolling horizontally. With all the money
and manpower at Google's disposal, couldn't you fix that
problem? Another problem I have had for months is that
when I write a message to post, I get no auto scrolling,
so I have to add manual line breaks to keep the text from
running out of the window -- then the reader sees all
those ugly misplaced line breaks in the output. These are
just annoyances, but why hasn't Google fixed them yet?

The point I am trying to make is that, while Google does
great things, and is very successful commercially, the
quality of its code could certainly use some improvement.
Microsoft is also very successful commercially, but
certainly you wouldn't argue that is is a result of the
quality of its software, I hope.

I may have a simplistic view, but I have always thought
that the requirements of most Google code are the very
antithesis of the requirements of safety critical code.
When I do a search, I
fully expect most of the results to be crap. It's a
scattershot approach. If I get one good result, I am
usually happy. Safety critical software is exactly the
opposite: if you get one *bad* result, you could be in
a heap of something nasty.



> > The important question is this: why do I waste my time with bozos like
> > you?
>
> Yeah, good question indeed, and I'm asking myself that -- somebody who
> posts to this group in order to attack the reliability of the language
> the group is about (and appears to be supremely ignorant about its use


I am sorry that you took offense at my pointing out the
weaknesses of Python. It's a great language for certain
kinds of applications, but it is not necessarily
appropriate for everything. I am personally using it for
prototyping a safety critical system that, if it is
ultimately fielded, will affect the safety of
millions of people, including you. However, my Python
prototype is for research and design purposes. The
ultimate implementation is very unlikely to be in Python.
Even so, I would like to make my prototype as reliable
as possible, and that is why I am interested in the
idea of self-testing code or "programming by contract."


> in air-traffic control and for high-reliability mission-critical
> applications such as Google's "Production Systems" software) might well
> be considered not worth responding to.  OTOH, you _did_ irritate me
> enough that I feel happier for venting in response;-)
>
> Oh, FYI -- among the many tasks I undertook in my quarter-century long
> career was leading and coordinating pilot projects in Eiffel for one
> employer, many years ago.  The result of the pilot was that Eiffel and
> its DbC features didn't really let us save any of the extensive testing
> we performed for C++-coded components, and the overall reliability of
> such extensively tested components was not different in a statistically
> significant way whether they were coded in C++ or Eiffel; Eiffel did let
> us catch a few bugs marginally earlier (but then, I'm now convinced
> that, at that distant time, we used by far too few unit-tests for early
> bug catching and relied too much on regression and acceptance tests),
> but that definitely was _not_ enough to pay for itself.  DbC and
> allegedly rigorous compile-time typechecking (regularly too weak due to
> Eiffel's covariant vs countervariant approach, btw...), based on those
> empirical results, appear to be way overhyped.


First of all, I am having a hard time reading your post
because Google is forcing me to scroll horizontally to
read each line. But all I can say is that your experience
with self-testing code doesn't seem to be consistent
with the experience of many others who have used it. Is it
possible that you didn't use it to its fullest extent?


> A small decorator library supporting DbC would probably be a nice
> addition to Python, but it should first prove itself in the field by
> being released and supported as an add-on and gaining wide acceptance:
> "arguments" such as yours are definitely NOT going to change that.


I'm sorry to see that you are so closed-minded about the
idea. I get the impression that you are close to the
Benevelent Dictator, but I can only hope that he remains
more open minded than you. I already explained why I don't like
the "decorator" approach (it puts the conditions outside
of the body of the function, for one thing).

I can only say that I am happy that I can always use
the implementation described in PEP 316. That's the
beauty of open source, isn't it.