status of Programming by Contract (PEP 316)?
steve at holdenweb.com
Sat Sep 1 14:38:12 CEST 2007
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
>> 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.
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 -------------
More information about the Python-list