Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!odi!dlw From: dlw@odi.com (Dan Weinreb) Newsgroups: comp.object Subject: Re: Readability of Ada Message-ID: <1991Apr28.053640.1650@odi.com> Date: 28 Apr 91 05:36:40 GMT References: <3878@ssc-bee.ssc-vax.UUCP> <20245@alice.att.com> <1991Apr23.193715.23815@odin.diku.dk> <1991Apr25.170356.21237@odin.diku.dk> Reply-To: dlw@odi.com Organization: Object Design, Inc. Lines: 89 In-Reply-To: jls@rutabaga.Rational.COM's message of 26 Apr 91 20:39:12 GMT In article jls@rutabaga.Rational.COM (Jim Showalter) writes: I did no such thing. I merely asked how to do a simple thing in C++. The answer, so far, is "Uh, well, that's not one of the things you can do easily in C++." Considering that my original question was motivated by Bjarne Stroustrup's somewhat self-serving comparison of the ease with which he can express inheritance in C++ vs Ada, I think pointing out that I can find a large number of quite simple couterexamples in which it is no cleaner in C++ than Ada (and Ada doesn't HAVE inheritance...) is fair. It's true that this is something that isn't supported in a good way in C++. You have now demonstrated one (not "a large number of") example of a problem with C++. In fact, in my discussions with other people, like myself, who have used both Flavors/CLOS and C++, the example that you brought up is the single typical thing that we most often point to when we want to show something that Flavors/CLOS does better than C++. We have not found "a large number" of things of this type. There are, of course, many variations on your example, that all boil down to the same problem. (By the way, the way that this is solved in Flavors/CLOS does not in any way depend on "type tags", on "what is my class" methods, or anything like that. The key to the solution in Flavors/CLOS is that you can add a "radius-of" method to the class from which all classes inherit, dynamically, at any time, without having the sources of the shape library and without needing to compile it. I am not an expert on Smalltalk but I believe that the solution would be the same in Smalltalk as well. Note that the real problem here has to do with the question of which sources need to be modified and recompiled. C++, as language, can do what we want; the real problem arises when you try to distribute binaries without sources. So I would argue that this is more an issue of implementation and/or programming environment. Those are very important things, to be sure.) So, what you have shown is that C++'s OOP is not perfect. It's still a whole lot better than not having OOP at all. You have not demonstrated that "Ada's OOP is just as good as C++'s" or anything like that. Frankly, yes. since I was responding to Bjarne Stroustrup's claim that inheritance was a paradigm not well-supported by Ada, in contrast to C++. So it seems QUITE fair to me to come up with what I consider simple examples of places where C++ support for inheritance degenerates into the exact same solution you'd use in a language that doesn't even claim to HAVE inheritance. Does this seem unfair to you? If so, WHY? So you have shown that C++'s OOPS doesn't do everything that it ought to be able to do in all cases. It's still true that C++ supports inheritance far more than Ada does. >I don't have time for writing examples tens of thousands of lines long. Right, and neither, I've noticed, does anybody else. What they do instead is write dinky toy examples a few hundred lines long, if that, write a book, and sell snake oil to the masses. People who actually then try to take the mechanism demonstrated in the toy example and apply it to the real world soon discover that things are a lot nastier than they'd been led to believe. The company I work for produces and sells an object-oriented database system written in C++. I just counted the amount of code in it. This is a based on a Unix "wc" count of only those files that we wrote from scratch in C++, not counting any code we got from anywhere else even if we modified it. The database system is currently at least 185,700 lines of code, and the user interface tools and our C++-coded portable user interface layer are about another 65,600 lines. I am personally responsible for about 33,000 of those lines. Naturally, at this point we have a great deal of experience with C++. On the whole, while it has a number of problems, it has satisfied our needs well. The problem that you're talking about hasn't arisen; in fact, we don't have any binary-only C++ libraries at all, so it's not surprising that the problem hasn't come up in our particular circumstance. But your claim that nobody has written large programs successfully in C++ will not stand up to real world evidence. We do use object-oriented programming and virtual functions and inheritance, quite a lot. It's very useful in practice, all over the software system in many different ways. If we didn't have it, we'd certainly need to write it out "longhand" in order to obtain the same effect, which would make our code a lot harder to read and maintain, if nothing else. I would really hate to write these programs in a language that didn't provide some kind of object-oriented programming. C++ certainly isn't perfect, and I've certainly spent time being miffed at its limitations now and then, but in most cases it does the job just fine.