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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no 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: jhd@herold.franken.de (Joachim Durchholz) Subject: Re: Eiffel and Java Date: 1996/10/31 Message-ID: <6Jw2q2$-3RB@herold.franken.de>#1/1 X-Deja-AN: 193701068 references: <550sm2$sn1@buggy.news.easynet.net> newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1996-10-31T00:00:00+00:00 List-Id: 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. >From that standpoint, I'd really like to see such a short list of how Ada 95 is intended to work. > > 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 languages with the simplicity and elegance of Pascal's and (modulo the syntactic mess) C. The Eiffel followers maintain Eiffel does most things right. (I agree to the point that I don't have a good solution to the few deficiencies that I can make out.) > 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 applies to Eiffel, so there is no reason to use the benefits of MI to their full extent. 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. > Yes, this is "simpler", but it is also inaccurate. Please clarify. "Inaccurate" in what way? > 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 :) > 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 consider one's pet concepts as simple (seeing the underlying ideas), and to consider the opponent's pet concepts as complicated and tricky (seeing the various and wildly varying applications the concepts can be used for). A good basis for non-productive language wars :( (Other than that, I tend to agree with the previous post. These are just the points that I disagree with.) Regards, -Joachim -- Looking for a new job. Resume available on request. WWW version of resume available under http://www.franken.de/users/herold/jhd/resume/index.html