pwd@computer-lab.cambridge.ac.uk (03/16/89)
[Warning: This may provoke a religious war] In article <118@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: > One way to summarize this discussion is to say that I do not know of any > good way to reconcile the following three language traits: > > 1. Routine arguments (in the above sense, ie routine arguments to routines) > 2. Static type checking > 3. A language design that makes separate compilation of modules possible CLU supports all of these, as does CCLU (the concurrent CLU with RPC used in Cambridge). CCLU doesn't have inheritance, we simply use generic clusters (a bit like ADA packages) instead, that might be why its possible to combine the three features above in this language. However we find that there is no difficulty in writing large multi-user distributed programs in CCLU and suspect that inheritance is more complicating than can be justified, given our areas of interest. It might be worth saying that we have _never_ met anyone who has written a large program in CLU or CCLU who has later chosen to switch to another language of their own free will (except for low-level systems work). The only language we've ever encountered that seems to be easier to work with and which maintains a balance between functionality and simplicity is DPL (from the ANSA project in Cambridge), but they are still developing their compilers. Eiffel looks very interesting, but we feel that if something cannot be written easily using genericity then the problem can only be solved using inheritence by relying on deep knowledge of the inherited classes and this is likely to prove dangerous in anything other than single user systems. 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! +-----------------------------------------------------------------------------+ | Phone: +44 223 33 4718 Fax: +44 223 33 4678 E-Mail: pwd@cl.cam.ac.uk | | Phone: +44 223 33 4718 Fax: +44 223 33 4678 E-Mail: smvh@cl.cam.ac.uk | +-----------------------------------------------------------------------------+ | Post: Computer Lab, New Museums Site, Pembroke St, Cambridge, CB2 3QG UK | +-----------------------------------------------------------------------------+
awn@computing-maths.cardiff.ac.uk (Andrew Wilson) (03/21/89)
With reference to: >Organization: U of Cambridge Comp Lab, UK >Senders: Peter Dickman & Stephen Hailes <pwd@uk.ac.cam.cl> > >[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.