[EMAIL PROTECTED] (Alex Martelli) writes: > If what you wonder about, and the theory mentioned by Clemmer and > detailed by the AQF, are both true, then this may help explain why some > programmers are fiercely innovative why other, equally intelligent ones, > prefer to stick with some plodding, innovation-killing process that only > works well for repetitive tasks: the latter group may be the ones who > "dread errors", and therefore miss the "making mistakes, experiencing > failures, and learning from them" that is "how we improve".
The idea of designing languages with more and more support for ensuring program correctness is to put the established, repetitive processes into the computer where it belongs, freeing the programmer to be innovative while still providing high assurance of that the program will be right the first time. And some of the most innovative work in software is going into this area today. Also, taking a learn-from-mistakes approach is fine and dandy if the consequences of the mistakes stay contained to those who make them. It's completely different if the consequences are imposed on other people who weren't part of the process. Vast amounts of software today (and I mean the stuff that clpy denizens write for random web servers or desktop apps, not just scary stuff like nuclear reactor code) has the potential to screw people who had nothing to do with the development process. It's unreassuring to hear the the developers say "oh cool, we learned from the mistake" when that happens. So, it's irresponsible to deliberately choose development processes that externalize risks onto outsiders that way. -- http://mail.python.org/mailman/listinfo/python-list
