From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,5add429c86f59001
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!backlog2.nntp.dca.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 26 May 2009 10:07:15 -0500
Date: Tue, 26 May 2009 16:07:06 +0100
From: Tim Rowe <spamtrap@tgrowe.plus.net>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Ada vs Eiffel - Ada programmer approach
References: 
 <405b5054-4c8f-4e16-9ea8-503a9b9f976e@t21g2000yqi.googlegroups.com>
 	<4A19765C.608@obry.net>
 <8105b65f-4de9-4653-b43a-d55ee33f072d@k2g2000yql.googlegroups.com>
In-Reply-To: 
 <8105b65f-4de9-4653-b43a-d55ee33f072d@k2g2000yql.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <4vCdnRo6At8-mIHXnZ2dnUVZ8n2dnZ2d@brightview.co.uk>
X-Usenet-Provider: http://www.giganews.com
X-Trace: 
 sv3-GFKoxxfqL/d+GWtIynm4sMdF9T0zh+cP16cYZK8iyBvhKZ2yWNd7kARxBeFrUqG8EF43a4YugQBSqqq!c80pCH8TwAwtYpAQOJwfAme993kedw4DY8RJSbjnTWwEuT4IMbZqUT3T1XbU7jhMdzVV8eAmOO+B!yXnco2QMClGkOl27lJBUgnoqNFw=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint
 properly
X-Postfilter: 1.3.39
X-Original-Bytes: 3346
Xref: g2news2.google.com comp.lang.ada:6020
Date: 2009-05-26T16:07:06+01:00
List-Id: <comp.lang.ada>

Ludovic Brenta wrote:
> When I read Bertrand Meyer's "Object-Oriented Software Construction",
> I too thought that DbC was a brilliant idea. Now I'm less convinced. I
> see two major drawbacks to DbC:
> 
> - pre/post conditions and invariants involve run-time checks most of
> the time (if not all the time). They slow the program down if enabled,
> or become useless when disabled for performance. I like static
> checking much better; Ada provides a lot of that out of the box (much
> more than Eiffel) and Spark goes way beyond even that.
> 
> - in most of the examples I saw in the literature, only very simple
> subprograms would have a contract and the contract would mostly repeat
> the body of the subprogram. This redundancy is counter-productive. For
> more complex subprograms, it can be very difficult to write pre and
> postconditions and invariants; Ada's pragma Assert provides what I
> need in these (rare) cases  because I can put such pragmas in the
> middle of a subprogram, for example.


I still think it's a brilliant idea, but suffers from *Design* by 
Contract getting confused with *Programming* by Contract; not least 
because "Design by Contract" is a trademark, so people needed a 
different name to refer to the approach, but I'm not sure Bertrand Meyer 
always kept the distinction clear either.

Both of the problems you describe are programming issues, not design 
issues.  There's nothing about the *design* process that mandates any 
run-time checks or that requires you to have pre- and post-conditions 
expressed in the target language. That's a matter for coding standards. 
To me, Design by Contract simply means working out and documenting in 
advance under what circumstances a section of code can legitimately be 
entered, and, if that is satisfied, what we can guarantee on exit. 
Learning to do that rigorously and diligently has certainly improved my 
own design.

We had that before Meyer coined the term "Design by Contract" of course. 
We used to call it "specification" ;-)