Russ <[EMAIL PROTECTED]> wrote: ... > programs." Any idea how much Python is used for flight control systems > in commercial > transport aircraft or jet fighters?
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. 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...? > 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 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. 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. Alex -- http://mail.python.org/mailman/listinfo/python-list
