Re: Design by Contract

[Bertrand Meyer <Bertrand.Meyer@eiffel.com>]

on S Anthony writes:
 
> Isn't this simply amazing?  I mean, really - what do these people
> think they are saying anyway?  To me this has long since pushed my
> "boggo-meter" off the scale and crossed into the mind-numbingly
> fatuous.
 
where "these people", if I understand properly, means advocates
of Design by Contract.

Insulting the other side is not a substitute for rational argument
(but tends to suggest fragility of one's case).

In a related message, W. Wesley Groleau writes

 >       I say again: If [Design by Contract]
 >       is defined as "Associating specifications 
 >       with software elements", then Eiffel indeed directly
 >       supports a SUBSET of DBC.  Ada directly supports another
 >       subset of DBC. C++ (shudder) directly supports yet
 >       another subset of DBC.  And  with a little extra work,
 >       the user of any of these languages can  handle a larger
 >       subset.  But none of them can completely support 
 >       the whole thing.  And the intersection of the subsets
 >       is not empty.

which the 3 or 4 Ada advocates in this thread now
repeat in all tunes to assert that, after all, Ada supports
Design by Contract just as much as Eiffel, only differently.

This is a sophism. Of course in any typed language you
can express some specification elements;
e.g. by declaring f (x: INTEGER) in
Pascal or the equivalent in Fortran, C, Ada etc. you are
placing some restrictions on what kind of argument f admits.
But this is a far cry from what you need to express useful
specifications:

        - Routine preconditions -- semantic conditions
          (not just type constraints).

        - Routine postconditions (how do you state that
          at the end of the procedure `withdraw' the balance
          must have been decreased by `sum'?).

        - Class invariants, expressing general integrity
          constraints.

        - The relationship with inheritance (precondition weakening
          and postcondition strengthening in redeclaration;
          invariant accumulation).

        - The relationship with documentation tools.

        - The relationship with exception handling.

Common languages support at most a minute subset of the 1st
and 3rd items. To use this observation to justify a Turing-tarpit
kind of argument -- "all languages support Design by Contract,
only in various ways" -- is a fallacy. So huge a "difference of
degree" becomes a difference of nature.

Just take any of the assertions of the classes of EiffelBase
and try to express them in C, Ada, C++ or Java. You will be
able to write almost nothing.

What *is* true is that in such languages without assertions
you can and should still apply Design by Contract purely as
a methodological discipline. Although you won't get the
language and tool support, you will still get some of the benefits.
But, no, declaring variables with interval types as in Pascal
or Ada is not Design by Contract.

The rear-guard battle waged by a few people against Design
by Contract on comp.lang.ada and comp.lang.eiffel --
oscillating between "it's useless", "it can all be done in Ada",
"it's nothing new", "it's irrelevant to the real problems",
"it's not enough", "it's snake oil" and other endless
if often contradictory variations -- is saddening.
Saddening because as soon as Design by Contract is applied
systematically (whether as pure methodology, or better
yet in a language like Eiffel that directly supports them)
the benefits in reliability are immediate and huge.
We constantly hear from our customers and our own work
of major potential bugs that are caught before they
have had time to strike, simply thanks to contracts.
And bug avoidance is only one of the applications.
The ability to do serious object-oriented analysis,
for example, is just as important.

All the rhetoric in the world fades away when assessed
against the potential for dramatic improvements in
software quality. That's what counts  -- not who shouts
louder. 
-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with instructions for download