Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!igor!rutabaga!jls From: jls@rutabaga.Rational.COM (Jim Showalter) Newsgroups: comp.object Subject: Re: Readability of Ada Message-ID: Date: 24 Apr 91 20:36:44 GMT References: <3878@ssc-bee.ssc-vax.UUCP> <20245@alice.att.com> <1991Apr23.170144.22538@neon.Stanford.EDU> Sender: news@Rational.COM Lines: 86 >All this example says is that object-oriented programming doesn't solve >the design problem. Everyone knows that designing general class libraries >is non-trivial. This is not news. The example I've given is of something that comes up often enough I don't regard it as a design problem--I regard it as a LANGUAGE design problem. The example I've given is of inheritance-with-addition: in other words, supersetting. I inherit, but I add new capabilities. Seems to me this is fairly obviously the way things often work in the real world. If the expressed intent of adding inheritance to a language is to make it more effectively model the real world, and if the inheritance model is so weak in its capabilities that it can only model strict inheritance WITHOUT supersetting, then I argue that not that much has really been accomplished. I have a similar argument for subsetting. Consider a few simple cases: Supersetting (the example I gave previously): not all shapes have a meaningful answer for Radius, but Circles do, and circles are indeed shapes Subsetting: most birds fly, but Ostriches do not, yet Ostriches are birds. While the subsetting case is fairly simple in C++ (although slightly knobby), the supersetting case is a bitch--so much so, in fact, that I argue it is just as clean to do it in Ada: and Ada doesn't HAVE inheritance. >I need an object-oriented >language, and Ada isn't one. 1) WHY do you need an object-oriented language? I'm serious: what are you working on? Is it big? Is it complex? Perhaps what you ACTUALLY need is a software-engineering language (Ada qualifies). Just curious. 2) Ada IS object oriented--it supports objects and classes quite well. It just isn't INHERITANCE oriented. The nomenclature for what is and is not an object has been debased for marketing reasons: shit man, a Boolean variable is an object. Precision in language is a desirable thing. >Maybe C++ is a messy compromise, which >attempts to patch over a lot of outdated design decisions, but its >object-oriented features are a lot better than Ada's. Well, let's look at this. C++ adds the following to C: strong typing opaque (private) types separation of specification from implementation The latest-greatest revision of C++ (C++++?) has added: exceptions templates (generics) All five of the things I listed above are major improvements from the standpoint of software engineering. They also, by the way, have nothing to do with inheritance. Interestingly enough, those five things are also available in Ada, and have been for years. Great minds think alike. In addition, in Ada, you get concurrency (tasking) which is only a distant gleam in the POSIX.4.a effort, and you get compiler standardization and validation. You also get tools that scale to the largest software projects in the world. So it boils down to inheritance. What I ask is--what are you working on that makes inheritance the dominant factor? Do you really need inheritance, or do you need industrial-strength software engineering capability? I'm quite serious in this: like a lot of other snake oil, I think inheritance has been grossly oversold. I mean, it's not as if inheritance is the thing that is going to make or break the FAA rewrite of all U.S. flight control software, or the software for the space station, or the 2 mega-sloc rewrite of the Army's financial systems. -- * "Beyond 100,000 lines of code, you should probably be coding in Ada." * * - P.G. Plauger, Convener and Secretary of the ANSI C Committee * * * * The opinions expressed herein are my own. *