Alan Knight wrote:
> 
> ... definitely not wanting to start one of the interminable
> discussions, but here's my two cents

Well, too late - I've got another cent to throw in ;)

Though I agree to most of what you said, despite being firmly on the
static typing side. I'm trying to combine the rigor of static typing
with the flexiblity of message passing, and I *think* it can be done.
(Don't worry: I'm not out to proselytize for any new-fangled ideas. In
fact I just want to set the record straight regarding Design by Contract
and some other concepts mentioned here.)

> Other ideas, while important at the higher levels don't push down
> nearly so well, and in my opinion many of the formalisms fall in this
> category (proving program correctness, design by contract, etc.).
> Contracts are an important idea in the real world as in software, but
> in both of those there's a reason we don't have fully-specified
> contracts for every little thing we do. I just don't want the proof
> that my program is working to take more time and get in the way of the
> program actually doing its job, especially when that job changes
> constantly. It smacks too much of cathedral-building.

Design by Contract actually doesn't add to the workload - provided you
are in need of an "engineering" approach, in the sense that you first
want to make sure what you're out to build before you do the actual
building. Stuff that needs more prototyping than engineering doesn't
benefit from DbC, but stuff that needs engineering benefits
*tremendously*.
Personally, I haven't had the opportunity to do any serious programming
in Eiffel (which, to my knowledge, is the only language that really
supports it). I can only go by experience reports. Of the half dozen or
so insider reports that have appeared on comp.lang.eiffel in the last
two years, all were raves about the advantages, most highlighted that
doing the contracts before doing the program was an immense work saver,
and that doing it that way was actually fun. *None* found a single
downside. Make of this what you want, but from this coverage I conclude
it's the best invention since sliced bread.

DbC isn't really cathedral-building. The advantage of DbC is that you
have a precondition and a postcondition for each routine, meaning that
the routine promises to deliver the postcondition if it is given the
precondition. This has nothing to do with the cathedral and the bazaar.

Adapting DbC to Smalltalk could even be fun. The notion of Protocol is
already rather persistent (though I'm not aware that it was ever
formalized). Say "Type" instead of "Protocol" and "Subtype" instead of
"conforms to at least that Protocol", and you can transcribe the DbC
rules on a one-on-one basis. (*Don't* use Smalltalk's Class/Subclass
concept for the DbC notion. Smalltalk subclasses are not subtypes, and
DbC rules say "class" but mean "type" resp. "protocol".)
To make the run-time checks of DbC operative it would be necessary to
add a Protocol (or Type) class to Smalltalk, with a isDerivedFrom (or
isSubtypeOf) relationship between Protocols/Types.
Ah well, I see I'm getting carried away with technical details. But it's
all feasible (well, as I said above, I *think* it's feasible).

> P.S. A couple of technicality rants.
>    - I don't see why I should have to specify the exceptions. Given a
> static type system, the environment should be able to figure out which
> exceptions were raised dynamically, but that would require it to do
> global searching, which doesn't fit in well with the mindset of files,
> separate compilation, and lack of tools.

There are several flavors of exceptions. C++ exceptions are very
powerful (and rather unstructured). Java exceptions aren't very
different. Eiffel/DbC exceptions are very simple: They are raised if and
only if a precondition or postcondition is violated. The reasoning is
that the routine failed, and there is nothing that could be done about
it, so there's no point in anybody higher up the chain doing anything
about it except (maybe) trying a different approach.

>    - More powerful exception handling also makes this kind of thing
> less necessary. e.g. In Java an exception unwinds the stack before it
> hits the handler, a "feature I could go on about at length". In
> Smalltalk it doesn't (and I assume in Squeak, though I've never
> checked), so you can do much more complex things at a higher-level
> handler, like reconnect to the database and resume from where it was
> thrown (or anywhere else in between).

That's not a very good idea. It means that the high-level handler must
have a very good idea of what's going on at the low levels of the system
- hardly a very modular approach. In practice, such approaches don't
work very well exept in cases where you specify a handler that will
always step in at the low levels (but if you know what has to happen at
a low level you can catch the problematic situation at the low level
without bothering the high levels of the system, so there's no point in
having an exception mechanism for that).

Regards,
Joachim
-- 
Please don't send unsolicited ads.