status of Programming by Contract (PEP 316)?

[Steve Holden]

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 -------------