Re: Design By Contract

[Ted Velkoff <velkoff@erols.com>]

W. Wesley Groleau x4923 wrote:
> 
> Question for anyone who _really_ knows both Eiffel and Ada:
> Suppose Ada added Eiffel assertions and Eiffel added separate
> compilation of specs.  Or even some sort of automated control that
> prevented changing contract without special privilege.
> 
> What remaining feature of either language (or both) would be a
> significant advantage over the other and why?
> 

In no particular order I offer my view of the remaining differences.  To 
the best of my ability I've responded with reason and judgement :-)

Concurrency.
	Ada's tasking is certainly more mature and tested in fielded 
products.  There has been a lot of research done into concurrency in Ada 
that benefited Ada95.
	I personally find the SCOOP approach to concurrency proposed for 
Eiffel to be quite elegant from the standpoint of the ordinary 
programmer building a concurrent system.  I think the jury's still out 
on how well it can be implemented.  There are some important issues 
(like priority inversion, rate-monotonic scheduling, etc., among many 
others) that need to be addressed in order to be applied to the 
some of the kinds of systems that have been done in Ada.

Constrained genericity.
	Constrained genericity is achieved in Ada typically by adding 
generic function or procedure parameters to the parameter list.  
Depending on the generic type, that list of parameters could be long.
	I think the Eiffel approach, which says an actual parameter must 
conform to (i.e. inherit from) some class, is simple and powerful, and 
typically results in shorter parameter lists.

Multiple inheritance.
	I've read the section on multiple inheritance in the Ada95 
Rationale several times and I confess I have never been able to 
understand the 2nd or 3rd examples.  At the very least, it appears that 
just emulating multiple inheritance in Ada95 is hard.
	Of course the religious question is whether you believe in MI or 
not.  After not being sure for about a year, I've come to believe it is 
extremely useful.  I think Bertrand Meyer is correct in saying that MI 
is not bad as long as it is implemented properly.  Using MI in Eiffel is 
really just no big deal.

Dynamic binding.
	Someone please correct me if I'm wrong on this one, but I think 
in Ada95, the programmer has to designate whether dynamic binding can be 
applied by making a type "classwide" with 'Class.  I think this is 
comparable to C++ "virtual", but I think I read that the Ada compiler is 
supposed to figure out which classwide calls are actually static in an 
executable.  The chief objection (if I have understood the Ada mechanism 
correctly) might be that one might forget to make a type classwide that 
a descendant would need to override, and require a change to the code.
	In Eiffel, dynamic binding is the default.  The programmer has 
to do something special ("frozen") to make it impossible for descendants 
to redefine.
	
Garbage collection.
	There are many applications being done in Ada for which garbage 
collection is not appropriate (hard real-time, etc.).  I suspect that 
there are many more applications being done in Ada that could benefit 
from garbage collection.
	Eiffel is of course garbage collected.  There are also library 
facilities for fine-grained control during execution.

Exception handling.
	Ada is fairly permissive with exceptions.  (Meyer has written 
about this in several places.)  The bad things that I have done and seen 
done in Ada are to use exceptions as gotos, and sweep problems under the 
rug.
	Eiffel is much more restrictive about what can be done in 
response to exceptions.  It significantly reduces the chances of 
programmers doing these sorts of things.

Tool environments.
	Articles have appeared in Ada Letters that questioned the wisdom 
of incorporating inheritance into Ada95, based on the fact that 
comprehension of a class interface requires manually finding and 
traversing the set of ancestors.  This problem is of course not unique 
to Ada.  As far as I know, Eiffel environments are the only I know of 
that support class flattening (i.e. generating the union of all features 
of all ancestors).  They also support push-button access to the list of 
clients, suppliers, ancestors, descendants.  I don't know how many times 
in other languages (including Ada) I have really needed to find out 
"who's calling this?" and had nothing better at my disposal than grep.  
Of course these are not language issues - I'd love to see vendors of Ada 
products add these kinds of capabilities.

Child packages.
	At a minimum, the rules about child packages are complicated.  
I'm personally unconvinced by the examples in the Ada95 Rationale for 
their use.  In particular, the example of complex numbers seems to be 
more properly addressed by inheritance (i.e. tagged types).  I would 
worry that programmers using that as a guide would attempt to solve many 
problems with child packages that should use inheritance instead.

Pointers to functions, aliases.
	I sort of got the heeby-jeebies when I saw these introduced into 
Ada95.  They didn't appear any easier or safer to use than their 
counterparts in C/C++.  In Ada83, you could sort of see the argument for 
subprogram pointers, but once inheritance and abstract subprograms were 
introduced, they seemed out of context to me.
	Eiffel doesn't have these things since they are tricky to use 
and jeopardize reliability.

-- Ted Velkoff