Re: Eiffel and Java

[jsa@alexandria (Jon S Anthony)]

In article <6Jw2q2$-3RB@herold.franken.de> jhd@herold.franken.de (Joachim Durchholz) writes:

> jsa@alexandria wrote 30.10.96:
> 
> > > All the concepts are there, but they're dispatched in lots of
> > > places, you have several ways of doing the same thing, and the
> > > readibility of the code suffer from that
> >
> > The concepts are just a couple and listed in only a couple of places.
> > They are actually very simple.  I could list overall basic (what you
> > need in most cases) stuff in just a list with 3 or 4 items in it, each
> > only a couple three sentences long.
> 
> I saw the original Ada definition, and the language struck me as  
> interesting and elegant in some places, but somewhat complicated and  
> convoluted in others.

You mean Ada83?

> From that standpoint, I'd really like to see such a short list of
> how Ada 95 is intended to work.

Not all of Ada (I'm not that crazy!), that wasn't the context - just
the OO part (that is what the concepts in "All the concepts" refers
to...).  I can send you such a list or post it here if you wish.


> > > I prefer Eiffel's ideology : "One thing in one way". I would add
> > > that Ada's syntax is quite redundant and complicated. For all that
> > > reasons, I founded Ada was heavy.
> >
> > Fine.  Those are value judgements.  Shrug.
> 
> Not really. A single way to do things can be a great advantage, if that  
> single way is well done. Just compare the type systems of some RAD  

Sure.  Sometimes.  As I pointed out once before, being a mathematician
(a pure one at that) I like this "pure" aspect in theory.  It just
doesn't apply very well as software is not mathematics.  It's a lot
closer to engineering (and can't even seem to adhere to the principles
there...)


> > I find the Eiffel way
> > restrictive and based on a rather dubious formalism (the only way to
> > organize knowledge is with a classification system and (even worse) it
> > must have MI).
> 
> I don't quite follow you here. MI is complicated and a semantic mess in  
> C++. It imposes efficiency problems in most languages. None of this  

I am talking formally.  Not as an expediency in hacking out software.
So, here *I* am playing the theoretical "purist" role.  Classification
systems are _one_ way to organize knowledge and MI gums up (breaks)
formal treatments of them.  As an implementation strategy for code
reuse it can have its place - and Eiffel (and Sather) are about the
only things which present an "acceptable" version.


> I agree basing a program's structure on classes only is somewhat dogmatic.  
> Clusters retrofit some structure on the Eiffel classes, but I don't see  
> anything fundamentally wrong with them.

There isn't anything wrong with them.  People shoe-horning
inappropriate cases into them are the problem.


> > Yes, this is "simpler", but it is also inaccurate.
> 
> Please clarify. "Inaccurate" in what way?

There are many sorts of models which are not classification schemes.
If all you have to represent these is a classification scheme you are
going to wind up pounding square pegs in round holes (at best) or with
outright inaccuracies.  The former simply results in inefficiency of
design and probably the resulting artifact.  The latter just gives
wrong results.

I'm not sure where people have got it in there head that class based
inheritance schemes are the only representation (let alone the best) for
everything.


> > Packages are "merely" containers which can be arranged into extensible
> > hierarchical structures.  What they are is not the important bit about
> > them (well maybe a little).  It was what you can _do_ with this sort
> > of flexable capability when it is orthogonal to other aspects.
> 
> Hmm - in computer science, you usually define the essence of a thing by  
> describing what you can do with it :)

Hmmm, maybe that is a reason why I've never thought much of CS... :-)


> > dream up your own for that matter.  All this with just one simple
> > construct - not several with mushed together semantic confusions.
> 
> On the same grounds, one could say an Eiffel class is a simple and pure  
> construct, though it happens to be versatile. I think I see a tendency to  

You could.  But it isn't.  It has at least the semantics of modules
and types combined as well as providing for things like information
hiding.


> consider one's pet concepts as simple (seeing the underlying ideas), and  
> to consider the opponent's pet concepts as complicated and tricky (seeing  

I suppose.  By simple I mean (at the language level) has a single
semantic and which is orthogonal to other constructs so as to allow
side effect free combination with these other constructs.  A good set
of flexible "primitives".  This supports the direct creation of a more
diverse set of possible end constructs.  Of course, the price is you
don't have some of the more typical things as out of the box "single
units".

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com