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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,411186037d1bc912 X-Google-Attributes: gid103376,public From: spencer@ERA.COM (Spencer Allain) Subject: Re: Some questions about Ada. Date: 1996/05/03 Message-ID: X-Deja-AN: 152821533 sender: news@ERA.COM references: <3188F63D.3325@io.com> organization: Engineering Research Associates, Vienna, VA 03: 57:10 GMT newsgroups: comp.lang.ada Date: 1996-05-03T00:00:00+00:00 List-Id: In article clgonsal@undergrad.math.uwaterloo.ca (Carl Laurence Gonsalves) writes: In article <3188F63D.3325@io.com>, Dave Jones wrote: >Carl Laurence Gonsalves wrote: >> I've got a couple of questions about Ada. I have to confess that >> I've never written a single line of Ada code. I've got >> experience in C, C++, Modula-3, Java, and Scheme, and several >> other languages. I've recently become interested in finding out >> about Ada, partly because I've noticed that both Java and >> Modula-3 seem to have been influenced by Ada's design, and I >> think both languages are very good. > > My opinion: Ada95 is the best all-around language for software > engineering. C++ is awful. Nevertheless, if I were starting a > project today, I would probably choose to use C++. Why?: More > (and better and cheaper) tools are > available for C++, more programmers are trained to program in > C++, et cetera. I'm aware of the awfulness of C++. It's a lot more widespread though, which is one of the primary reasons I use it. It isn't the only language I use though, and I take every chance I get to gripe about the various nasties in C++. >> One thing I'm wondering about is packages. I've heard that >> packages are "better" than than the way C++ uses classes. I'm >> curious as to why this is. Modula-3 has modules (which are >> similar, AFAIK, to Ada's packages) and "object types" (classes) >> as two distinct entities. I'v always thought that C++'s way of >> allowing just about anything to be nested in a class much >> cleaner and simpler. (and for the record, I was programming in >> Modula-3 before I was programming in C++) So are packages >> better? Why? > > I would not say that packages are necessarily better. They are, > however, easier to read and maintain than C++ classes. (Of > course, if you switched from a well designed language like > Modula-3 to C++, maintainability and ease of reading are > probably secondary concerns for you.) I didn't "switch" to C++. I still use Modula-3 when appropriate to the task. Of course, this limits it to UNIX only stuff, since that's pretty well the only kind of platform Modula-3 really works on. Modula-3's also got it's own share of problems that make my skin crawl. I wouldn't say that Modula-3 only _really_ works on UNIX platforms. Sure it works best on UNIX platforms, but there are some good DOS ports, and the SRC-M3 Windows NT/95 port is almost to the point of being as good as the UNIX port. Anyway, that's not the issue, nor is the fact that every language contains design decisions that make your skin want to crawl. As for the "ease of reading thing", I don't find Ada or Modula-3 code especially easy to read. Yes, C++ can be heavily obfuscated, which is a problem with it. But well written C++ code is quite readable. It wouldn't be too hard to imagine a derivative of C++ which disallows many of the constructs in C++ that lead to classic unreadable code. I'm also not going to touch readability because I've also used Ada, Modula-3, C++, Perl, etc. and have formed opinions that probably don't apply to other people. In any case, I'm not here to argue about subjective issues like readability. Why would you say that packages are easier to maintain than C++ classes? From what I can tell they seem quite a lot like Modula-3's modules & interfaces. My main gripe about C++ (here) would be that the public and private parts are kept together. It would be nice if they could be placed, for example, in separate files. I'm sure there are people who will claim that one or the other is always superior to the other, but I believe they simply make different trade-offs. Classes make it easy to encapsulate most if not all of the operations on an object type. Packages make it easier to group different object types and their operations together. Some camps will claim that all object types should be completely independent and wholly partioned from any other object type (excluding inheritance of course), and others will argue that there is cross-over between different object types in the real world that cannot be modelled through inheritance alone. These associations have always been difficult to model, but classes make you want to partition the world by almost forgetting about them because it becomes a significant chore to by-pass the general class concepts in a clean manner. As to your concern about why the public and private parts need to be specified together in C++, the best you can do to use different files is: class A { public: // stuff private: #include "A_private.hh" }; Whenever a change to the private section of a C++ class changes, every other file dependent upon that class needs to know that, unlike in Modula-3, Java, Smalltalk, etc. The reason for this is because C++ allows objects to exist on the stack, where the size has to be known at compile time. The other languages use a "pointer" to a block of memory for their objects, and therefore don't have to require that all modules have access to the private sections at compile time. -- Carl Laurence Gonsalves - clgonsal@undergrad.math.uwaterloo.ca Computer Science, University of Waterloo http://www.undergrad.math.uwaterloo.ca/~clgonsal/ http://www.csclub.uwaterloo.ca/~clgonsal/ -Spencer ---------------------------------------------------------------------- Spencer Allain E-mail: spencer@era.com Engineering Research Associates Phone : (703) 734-8800 x1414 1595 Spring Hill Road Fax : (703) 827-9411 Vienna, VA 22182-2235 Modula-3 Home Page DEC SRC Modula-3 FAQ, etc. ----------------------------------------------------------------------