Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!hc!lll-winken!uunet!mcvax!ukc!reading!cf-cm!awn From: awn@computing-maths.cardiff.ac.uk (Andrew Wilson) Newsgroups: comp.lang.eiffel Subject: Re: First Class Routines [Short but controversial] Message-ID: <657@cf-cm.UUCP> Date: 21 Mar 89 10:40:11 GMT References: <114@eiffel.UUCP> <112@eiffel.UUCP> <1297@wasatch.UUCP> <118@eiffel.UUCP> <1578@etive.ed.ac.uk> <859@tucos.UUCP> Reply-To: awn@computing-maths.cardiff.ac.uk (Andrew Wilson) Organization: University of Wales College of Cardiff, Cardiff, WALES, UK. Lines: 66 With reference to: >Organization: U of Cambridge Comp Lab, UK >Senders: Peter Dickman & Stephen Hailes > >[Warning: This may provoke a religious war] [Comments about CLU, CCLU and using OOPL's for large systems deleted] >In our opinion, inheritance is likely to compound the problems inherent in >maintaining large systems, even though it superficially makes this easier >in the short term. > > -- Peter & Stephen > > PS We are now heading for our nuclear fallout shelter! This is interesting, has anyone done a comparitive study of Object Oriented and other programming methodologies for designing large systems? What advantages do OO languages bring to the process? Superficially at least, OO seems to be little more than a syntactic nicety which can reduce the amount of typing you need to do when defining a system. Closer study reveals that OO is a nice way of organising the reusability of code and other information and so might reduce the time taken to 'evolve' an existing system. At the end of the day though there seems to be no escaping the fact that for a large system somebody, somewhere, has to have the 'deep knowledge'. i.e. Some poor fellow has to know the correct usages of all the classes and methods that exist in a system. Integrity constraints such as exist in Eiffel as pre- and post-conditions may not be enough to ensure that the programmer is using those classes they protect in the correct manner. To be sure that all the components of a system are bolted together in a meaningful way requires some form of programming convention that OO on its own can't provide. I don't want to venture into program-proving territory here, mainly because I know nothing of the methods that program-provers use, but I don't think that it is enough to say that OOPL's on their own are able to solve all our problems. (I'm not suggesting that anyone has said this, just that you should be wary if they ever do!) In the short term, it seems to me that OO benefits the programmer because it makes the job of understanding the implications of doing something a particular way a little clearer. Similarly, the system designer is able to reuse previous proven work and reduce the amount of effort required in designing new systems. However I remain unconvinced that for large systems (say 200 classes or more) OO will not add to the complexity of the problem. The inheritance mechanism with all its wondeful 'rename' and 'redefine' and 'local' and 'public' is confusing, even to someone who knows what is going on and will I'm sure create an inertia of its own to the process of implementing systems. Perhaps this is the price we pay for having rational structure where previously there was none. Andrew. - For your information we've been using C++ and Eiffel on and off for over a year and I'm currently paying for my sins by implementing an Object Oriented Database Managment System in Prolog.