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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,953e1a6689d791f6 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,953e1a6689d791f6 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Eiffel and Java Date: 1996/11/02 Message-ID: X-Deja-AN: 193863330 sender: news@organon.com (news) references: <550sm2$sn1@buggy.news.easynet.net> organization: Organon Motives, Inc. newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1996-11-02T00:00:00+00:00 List-Id: 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