Bryan Olson wrote: > Steve Holden wrote: > [...] >> If I can blow my own trumpet briefly, two customers (each using over 25 >> kLOC I have delivered over the years) ran for two years while I was away >> in the UK without having to make a single support call. One of the >> systems was actually locked in a cupboard all that time (though I have >> since advised that client to at least apply OS patches to bring it up to >> date). > >> This was achieved by defensive programming, understanding the user >> requirements and just generally knowing what I was doing. > > On the one hand, nice work. Made your customers happy and kept > them happy. Can't argue with success. On the other hand, 25K lines > is tiny by software engineering standards. If a support call would > have to go to you, then the project must be small. Software > engineering is only a little about an engineer knowing or not > knowing what he or she is doing; the bigger problem is that > hundreds or thousand of engineers cannot possibly all know what > all the others are doing. > I agree that programming-in-the-large brings with it problems that aren't experienced in smaller scale projects such as the ones I mentioned.
> I work on large and complex systems. If I screw up -- O.K., face > facts: *when* I screw up -- the chance of the issue being assigned > to me is small. Other engineers will own the problems I cause, > while I work on defects in code I've never touched. I wish I could > own all my own bugs, but that's not how large and complex systems > work. Root-cause analysis is the hard part. By the time we know > what went wrong, 99.99% of the work is done. > This is the kind of realism I like to see in engineering. I am always suspicious when any method is promoted as capable of reducing the error rate to zero. > > Design-by-contract (or programming-by-contract) shines in large > and complex projects, though it is not a radical new idea in > software engineering. We pretty much generally agree that we want > strong interfaces to encapsulate implementation complexity. > That's what design-by-contract is really about. > > There is no strong case for adding new features to Python > specifically for design-by-contract. The language is flexible > enough to support optionally-executed pre-condition and > post-condition checks, without any extension. The good and bad > features of Python for realizing reliable abstraction are set > and unlikely to change. Python's consistency and flexibility > are laudable, while duck-typing is a convenience that will > always make it less reliable than more type-strict languages. > Python's dynamic nature certainly makes it more difficult to reason about programs in any formal sense. I've always thought of it as a pragmatist's language, and we need to be pragmatic about the downside as well as the upside. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --------------- Asciimercial ------------------ Get on the web: Blog, lens and tag the Internet Many services currently offer free registration ----------- Thank You for Reading ------------- -- http://mail.python.org/mailman/listinfo/python-list
