alan@hal.larc.nasa.gov (alan dare) (06/12/91)
Netlanders,
A short time ago I put a request out for information on c++ vs
Ada. I was hoping for several responses from people on both sides of the
fence that were working on graphics applications. As my primary application
is graphics. What did I receive? I received more requests to post the results
than I received mail from people using c++ or Ada. I received only two
messages from people using c++ in a graphics application and none from
anyone using Ada. There were several messages from general users of c++
and only a few from Ada users. A kind soul FAX'ed me a document "A comparison
of Experiences with the Maintenance of Object-Oriented Systems: Ada vs. C++".
I didn't try to post a summary of the article (it's to big). The comments
below were sent to me. I don't claim any responsibility for them. I don't
currently use c++ or Ada. The comments are provided as a request from many
people. Please don't use this posting to start a language war.
The first post went to the following news groups:
comp.sys.sgi
comp.graphics
alt.graphics
comp.lang.ada
comp.lang.c++
The comments below were edited only to reduce size, not content.
**************************************************
*** Graphics *************************************
**************************************************
o I use C++ for graphics work. We considered ADA.
Both have great pluses and a lot of minuses.
Mostly the minuses are finding existing graphics packages
which are compatible. They are rare with C++ and non-existent
with ADA to my knowledge.
o Ada has lots of features totally irrelevant to graphics
which cost something in compile time even on a compiler that
produces efficient code. It has no particular features to
reccommend it for graphics particularly over any of the common
block-structured languages.
**************************************************
*** PRO ADA Comments *****************************
**************************************************
o The Ada MIL-SPEC and validation suites do a
lot to insure a consistent interpretation of the
language across platforms and vendors. No such
validation or "frozen" specification exists for
C++. This causes lost time and less portability.
o Ada's Packages and Generic Packages are a
lot easier to design for than C++ classes.
o Ada has better support for embedded systems'
work than C++. C++'s OO mechanisms
(particurlarly dynamic binding) exact a performance
penalty that will not be acceptable for some
hard real-time systems. This will be less
important in the future, as hardware gets
faster and applications get more complicated
(thus requiring the complexity-management
mechanisms offered by languages like C++).
Ada 9X will probably suffer similar performance
penalties on the same kinds of mechanisms.
**************************************************
*** CON ADA Comments *****************************
**************************************************
o The language is too big for the few benefits over C++ that
it features.
o Ada is a "weaker" language than C++ in expressing
OO concepts (e.g. inheritance, polymorphism).
Packages, Generic Packages and Ada's overloaded
operators aren't enough. Ada 9X will supposedly
deal with these issues, but it will be at least a decade
before the Ada 9X environment is truly widely
available at a reasonable cost.
o ADA compilers tend to cost real money.
o ADA suffers from having way too many features -- probably
an artifact of the design-by-committee process. It's such a
huge language that a programmer may never fully "learn" it.
o Converting code to ADA from anything is a problem.
o ADA still tends to be slow, though that problem is slowly
going away.
o Ada is only object-based (it has no inheritance), while
C++ _is_ object-oriented.
**************************************************
*** PRO C++ Comments *****************************
**************************************************
o The dynamic binding, polymorphism and inheritance mechanisms
are *extremely* powerful, and very useful in graphical
applications. Future enhancements including parameterized
types (== Ada "Generic Packages") and exceptions
(== Ada exceptions) are going to be equally powerful.
o After extensive reading and personal evaluation, I came to the
conclusion the ADA implementions are far worse than the C
implementations (I use the stuff from GNU, don't see how anyone
can write better software).
o C++ compilers are cheap -- the GNU family is free, and runs
on a number of different architectures. You can get the source
code so that you can fix it if it's broken.
o C++ seems to be a reasonably clean design; the features tend to
be orthogonal and complete. A competent programmer can probably
"learn" C++ pretty well in a month.
o Converting code from C to C++ isn't a big problem. (And with
some of the Fortran-to-C translators that are publicly available,
the Fortran->C->C++ path, while a bit of a pain, isn't
completely daunting.)
o C++ runs just about as fast as C, i.e. it's plenty fast enough
to write things like volume renderers.
**************************************************
*** CON C++ Comments *****************************
**************************************************
o The tools for working with it maybe not as mature as ada tools.
o C++ is hard to master.
o C++ has reasonable OO mechanisms, but they
are difficult to learn, and more difficult to use
effectively. This is partially due to the low
quality of the documentation, which is quickly
changing.
**************************************************
*** GENERAL Comments *****************************
**************************************************
o There are a lot more Ada people out there, at
the moment, than C++ people. There will probably
be a lot more C++ people in the future than Ada
people, simply because the language is more
accessable to more people (Gnu C++ is free, for
example; "Turbo C++" costs ~$60; AT&T is
very generous in licensing to Universities).
o There will probably be a lot more C++ compilers
available on a lot more platforms than Ada
compilers in the future (the costs of validation
are high; reuse of AT&T code or GNU code
is cheap).
I would like to thank the following for responding to my post :
baker@csl.dl.nec.com
blbates@aero36.larc.nasa
brendan@illyria.wpd.sgi.com
fmhv@inesc.inesc.pt
jansm@cih.hcuge.ch
jdt@voodoo.boeing.com
jls@netcom.com
jshumate@logdis1.wr.aflc.af.mil
leisner.henr801c@xerox.com
richard@elroy.Jpl.Nasa.Gov
rsk@gynko.circ.upenn.edu
uselton@nas.nasa.gov
--
*********************************************************************
Alan Dare | Internet : alan@hal.larc.nasa.gov
NASA Langley Research Center | pmartz@undies.dsd.es.com (Paul Martz) (06/13/91)
In article <1991Jun12.164741.412@news.larc.nasa.gov>, alan@hal.larc.nasa.gov (alan dare) writes: > > > Netlanders, > > A short time ago I put a request out for information on c++ vs > Ada. [...] The comments > below were sent to me. I don't claim any responsibility for them. I don't > currently use c++ or Ada. The comments are provided as a request from many > people. Please don't use this posting to start a language war. > > [...] > > o I use C++ for graphics work. We considered ADA. > Both have great pluses and a lot of minuses. > Mostly the minuses are finding existing graphics packages > which are compatible. They are rare with C++ and non-existent > with ADA to my knowledge. Just for the record, Evans & Sutherland sells an Ada binding to PHIGS for use with our ESV graphics workstation. > [...] > > ********************************************************************* > Alan Dare | Internet : alan@hal.larc.nasa.gov > NASA Langley Research Center | -- -paul pmartz@dsd.es.com Evans & Sutherland
jls@netcom.COM (Jim Showalter) (06/13/91)
>o I use C++ for graphics work. We considered ADA. > Both have great pluses and a lot of minuses. > Mostly the minuses are finding existing graphics packages > which are compatible. They are rare with C++ and non-existent > with ADA to my knowledge. Ada bindings to X windows (including a nearly pure-Ada version donated by Rational to MIT) are available. There is at least one firm I know of that does nothing EXCEPT write X windows graphics applications in Ada. Incidentally, Ada is a name, not an acronym. So, like Pascal, it is capitalized, not uppercased like FORTRAN. >o Ada has lots of features totally irrelevant to graphics > which cost something in compile time even on a compiler that > produces efficient code. Any language has features totally irrelevant to graphics, unless that language is specifically a graphics language (which C++ is not). It is unclear to me how an Ada feature that is not used can "cost something in compile time"--could someone elaborate? >o The language is too big for the few benefits over C++ that > it features. What does "too big" mean, actually? I hear this bandied about all the time, but when I press someone to precisely explain what features of Ada they think are superfluous, they stammer about um, well, tasking or some such--and yet, if you ask someone who USES tasking, they regard it as indispensable. I am reminded of the line in "Amadeus" when the king tells Mozart that his work has "too many notes", to which Mozart replies "Well, sire, which notes exactly would you have me remove?". Really, factually, Ada has approximately the same number of keywords, control structures, and fundamental concepts as C++ or any other software engineering oriented language. Certainly it is bigger than C, but so is C++--that's the whole POINT. >o ADA compilers tend to cost real money. Indeed. And they tend to provide real functionality: they work, have few bugs, have excellent support backing them up, are validated, and scale to projects of significant size and complexity. You get what you pay for. >o ADA suffers from having way too many features -- probably > an artifact of the design-by-committee process. It's such a > huge language that a programmer may never fully "learn" it. Again--which notes would you have me remove, sire? As for the design by committee accusation, two points: 1) it wasn't a committee, really--it was actually a handful of clever people led by a particularly clever Frenchman named Ichbiah; the language was subject to extensive international review, but that doesn't constitute a committee, 2) a Lexus is a car designed by a committee; it is also one of the finest cars ever designed: perhaps the issue is not the existence of a committee but, rather, the QUALITY of the committee that should be taken into account. As for learning the entire language--why should one HAVE to? If you don't need concurrency control, then by all means ignore tasking. If you don't need fixed point types, then by all means ignore them. It is really quite simple to learn a very powerful and flexible subset of the language. >o Converting code to ADA from anything is a problem. Huh? >o ADA still tends to be slow, though that problem is slowly > going away. As with the "too many features" shibboleth, this common myth doesn't hold up under even rudimentary analysis of the facts. There are compilers available for a number of targets that produce code at least as dense and efficient as C/C++ compilers for the same target. >o C++ compilers are cheap -- the GNU family is free, and runs > on a number of different architectures. You can get the source > code so that you can fix it if it's broken. You get what you pay for. Personally, I'd much prefer to buy a validated compiler with the number of bugs approaching zero than use a free compiler so shot full of bugs the source code is provided to me to patch around problems that SHOULD have been taken care of by the vendor. >o C++ seems to be a reasonably clean design; the features tend to > be orthogonal and complete. A competent programmer can probably > "learn" C++ pretty well in a month. Funny, about every 9th posting to comp.object concerns one or another person's complaints about C++ being a kludgy, idiosyncratic, hard-to-learn language. And, in my experience, it takes more like 6 months to a year for a programmer to REALLY learn how to write well in C++ (yes, one can hack together executing code fairly quickly, but to get from there to where one can design competently in the language requires a lot of practice). >o Converting code from C to C++ isn't a big problem. (And with > some of the Fortran-to-C translators that are publicly available, > the Fortran->C->C++ path, while a bit of a pain, isn't > completely daunting.) The C++ code that results from a double translation effort as described is ugly in the fullest sense of the word. You don't gain much by translating legacy code written in an archaic language into a different language--the REAL win is in translating to a new DESIGN and then coding that new design in a more modern language. This requires human effort and ingenuity, and is NOT something that can be automated (at least not with current state of the art), but the eventual payoff is considerable. Automated translation of a bad design written in a bad language into a bad design written in a better language is a perfect example of the GIGO principle in action. Show me a translator that will convert legacy FORTRAN into a well-abstracted class hierarchy in C++ and I'll start to be impressed. Until then, spare me. >o The tools for working with it maybe not as mature as ada tools. Indeed. >o C++ is hard to master. Indeed. Note that this contradicts the claim made earlier that C++ is easy to learn. >o C++ has reasonable OO mechanisms, but they > are difficult to learn, and more difficult to use > effectively. This is partially due to the low > quality of the documentation, which is quickly > changing. It is even more due to the fact that such mechanisms, despite their billing, are actually quite tricky to master conceptually. The number of people I've encountered who'd I trust to actually design a class hierarchy of any significant complexity I can count on one hand. Sadly, hacker culture being what it is, EVERYBODY is going to want to do try their hand at building such things, and most are going to fail miserably. Not everybody is an architect, so why pretend that they are? -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
pierson@encore.com (Dan L. Pierson) (06/13/91)
Regarding c++ vs ada results; alan@hal.larc.nasa.gov (alan dare) adds: (quoting someone else; don't blame him :-)) > o Ada has better support for embedded systems' > work than C++. C++'s OO mechanisms > (particurlarly dynamic binding) exact a performance > penalty that will not be acceptable for some > hard real-time systems. This assertion contains a common misconception about dynamic binding _for languages which support both dynamic and static binding_. Such languages include C++, Common Lisp/CLOS and the current proposal for Ada 9X. The misconception is that the performance of a dynamically dispatched (bound) function call should be compared to that of a normal function call. It should not; it should be compared to the performance of a normal function call PLUS a case statement. If you don't need the case statement you should have used a statically bound call*. A good implementation of dynamic dispatch for any of these languages can be faster than static call plus case. There are several existence proofs for C++ and Common Lisp/CLOS, but I don't have the citations handy. *Of course, a poor programmer can overuse dynamic binding with greater ease than explicit case statements. IMHO, all of the cited languages have enough such options already available that this isn't a big issue when weighed against the advantages in software construction and reuse provided by dynamic binding. -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@encore.com
paul@u02.svl.cdc.com (Paul Kohlmiller) (06/14/91)
jls@netcom.COM (Jim Showalter) writes: >As with the "too many features" shibboleth, this common myth doesn't >hold up under even rudimentary analysis of the facts. There are >compilers available for a number of targets that produce code at >least as dense and efficient as C/C++ compilers for the same target. Jim, Could you specify one or more machines that have an available ADA compiler that generates code that is as efficient as a C compiler for the same machine? thnx Paul Kohlmiller CDC standard disclaimers -- // Paul H. Kohlmiller // "Cybers, Macs and Mips" // // Control Data Corporation // Internet: paul@robin.svl.cdc.com // // All comments are strictly // America Online: Paul CDC // // my own. // Compuserve: 71170,2064 //
brucej@verdix.com (Bruce Jones) (06/14/91)
In article <34128@shamash.cdc.com> paul@u02.svl.cdc.com (Paul Kohlmiller) writes: > Could you specify one or more machines that have an available ADA compiler >that generates code that is as efficient as a C compiler for the same machine? The C and Ada compilers sold by Harris CSD with their machines use the same code generation technology. It's quite good, as their SPECmark's demonstrate. The Ada compiler's code equals the C compiler's code in quality, and sometimes exceeds it, as the Ada front end has more range and constraint information available to it. Of course, the Ada runs slower when runtime checks are enabled, but nothing in life is free... Disclaimer: I have no connection with Harris other than previous employment. -- brucej
nelson@sun.soe.clarkson.edu (Russ Nelson) (06/16/91)
In article <1991Jun12.201740.16463@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >o ADA still tends to be slow, though that problem is slowly > going away. As with the "too many features" shibboleth, this common myth doesn't hold up under even rudimentary analysis of the facts. There are compilers available for a number of targets that produce code at least as dense and efficient as C/C++ compilers for the same target. >o C++ compilers are cheap -- the GNU family is free, and runs > on a number of different architectures. You can get the source > code so that you can fix it if it's broken. You get what you pay for. Personally, I'd much prefer to buy a validated compiler with the number of bugs approaching zero than use a free compiler so shot full of bugs the source code is provided to me to patch around problems that SHOULD have been taken care of by the vendor. Why is "ada is slow" a myth, but "GCC is shot full of bugs" is not? Certainly if you're an expert on GCC's bugs, you could name one of them. It's been my experience that the vendors of compilers *never* share their bug list with customers. For GCC, you just have to tune into gnu.gcc.bug. -- --russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker. I am leaving the employ of Clarkson as of June 30. Hopefully this email address will remain. If it doesn't, use nelson@gnu.ai.mit.edu.
sef@kithrup.COM (Sean Eric Fagan) (06/16/91)
In article <1991Jun12.201740.16463@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >Indeed. And they tend to provide real functionality: they work, >have few bugs, have excellent support backing them up, are validated, >and scale to projects of significant size and complexity. You get >what you pay for. And >You get what you pay for. Personally, I'd much prefer to buy a validated >compiler with the number of bugs approaching zero than use a free compiler >so shot full of bugs the source code is provided to me to patch around >problems that SHOULD have been taken care of by the vendor. 1. gcc (and g++) are among the best and least buggy compilers (especially considering their ages) that I've ever seen. 2. Real world experience: a certain software company, affiliated with my previous employer through various means, has a C compiler. We got their C compiler and resold it for our system. The compiler had more bugs than I can count on both hands (in binary, that is 8-)); when I found a bug, and asked "did you fix this?" I would almost always get a response of, "maybe, but we're working with this later version [which wasn't released until two years later, mind you] so we can't help you." My ex-housemate, working for yet another company (as a customer of said software company) eventually gave up on their software support and sent me dozens of email messages asking a) is this a real bug, and, if so, b) how can I work around it? 3. I have encountered far fewer bugs in gdb than, say, sdb. Yet sdb is a "validated debugger," for which one pays lots of money. Yep. Useful things, those proprietary development tools. >>o C++ is hard to master. >Indeed. Note that this contradicts the claim made earlier that C++ is >easy to learn. You are truly showing your foolishness here. Most people out of grade school realize there is a difference between "learning" something and "mastering" it. I guess you're just special, aren't you? -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
jls@netcom.COM (Jim Showalter) (06/18/91)
[I've cut the newsgroups down to a reasonable number.] >>>o C++ is hard to master. >>Indeed. Note that this contradicts the claim made earlier that C++ is >>easy to learn. >You are truly showing your foolishness here. Most people out of grade >school realize there is a difference between "learning" something and >"mastering" it. I guess you're just special, aren't you? The person I was responding to was talking about the difficulty of learning to write good programs in C++. He chose the term "master" to denote this. I chose the term "learn" to denote this same idea. Why this warranted a personal attack is beyond me, particularly since you seem to have not taken issue with the key point of the exchange, namely that getting good at writing programs in C++ is hard to do. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
sef@kithrup.COM (Sean Eric Fagan) (06/18/91)
In article <1991Jun18.041751.3740@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >since you seem to have not taken issue with the key point of the >exchange, namely that getting good at writing programs in C++ is hard >to do. Mainly because I disagree with you. I do agree that mastering C++ is hard; however, I use a subset of the entire language (rarely use inheiritance, for example, at least for my own code), and it only took me about three weeks to get to that level. I'm using C++, I haven't mastered it, but I'm using it, and I'm rather good at writing programs in it (even though they may be bad programs 8-)). But the same is true of almost any language. Including Ada. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
euamts@eua.ericsson.se (Mats Henricson) (06/18/91)
jls@netcom.COM (Jim Showalter) writes: >[I've cut the newsgroups down to a reasonable number.] >>>>o C++ is hard to master. >>>Indeed. Note that this contradicts the claim made earlier that C++ is >>>easy to learn. >>You are truly showing your foolishness here. Most people out of grade >>school realize there is a difference between "learning" something and >>"mastering" it. I guess you're just special, aren't you? >The person I was responding to was talking about the difficulty of >learning to write good programs in C++. He chose the term "master" >to denote this. I chose the term "learn" to denote this same idea. >Why this warranted a personal attack is beyond me, particularly >since you seem to have not taken issue with the key point of the >exchange, namely that getting good at writing programs in C++ is hard >to do. I have started to see two different kinds of programmers in C++: 1. Library designers 2. Library users The first kind of programmers is doing some tricky nasty hacking behind the scenes of the interface of the classes, to satisfy the second kind of users. I have so far only done programming as a library designer, and I think that is *VERY* difficult if you try to produce code that is: a) fast b) not wasting memory c) usable d) reusable (in terms of subclasses) e) etc f) etc g) etc If you, on the other hand, have a well designed class library to build from, I think C++ is a beautiful and easy language to use. Mats Henricson, Sweden
jls@netcom.COM (Jim Showalter) (06/19/91)
I think this discussion, like so many others on the net, eventually degenerates into an argument over semantics. You say you have learned C++ but haven't mastered it, because you are able to write decent simple programs in it that don't use the more advanced features (such as inheritance, in your example). There are others that would claim that you have NOT learned C++, any more than a person who can only multiply single digit numbers together has learned multiplication. I'm not really sure where the line between "learn" and "master" lies in this case, and I'm not sure it's worth net bandwidth to argue the point. Incidentally, I would be interested in knowing if you had already learned (or mastered, whatever) C before you learned C++. If so, then your claim that it is "easy" to learn C++ is fairly biased. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
jls@netcom.COM (Jim Showalter) (06/19/91)
>I have started to see two different kinds of programmers in C++: >1. Library designers >2. Library users >The first kind of programmers is doing some tricky nasty hacking behind the >scenes of the interface of the classes, to satisfy the second kind of users. >I have so far only done programming as a library designer, and I think that >is *VERY* difficult if you try to produce code that is: >a) fast >b) not wasting memory >c) usable >d) reusable (in terms of subclasses) >e) etc >f) etc >g) etc >If you, on the other hand, have a well designed class library to build from, >I think C++ is a beautiful and easy language to use. This is an excellent point, and mirrors my own experiences with Ada. I imagine similar things are true of Eiffel, Modula-3, and any of the other modern software engineering languages. There is nothing WRONG with this, but an organization needs to recognize that with increased language complexity comes a greatly increased ability for the average programmer to get in trouble. It is against the hacker credo of universal egalitarianism to admit this, but the simple truth is that some people are qualified to be architects and some are not--and handing power tools to people only qualified to hammer nails results both in poor construction and arterial bleeding. One of the most successful Ada projects I'm aware of organized job descriptions and responsibilities in such a way that a relatively small number of exceptionally clever people was responsible for the architecture (as captured in subsystem decomposition and subsystem interface specification), each subsystem had a talented lead in charge of its implementation (but could not alter the interfaces, which required an architectural decision), and within each subsystem there was a team consisting of designers and programmers (the designers designed package specs [class headers] and the programmers implemented the bodies). It worked great...and one of the nicest things about it was that it took the pressure OFF the folks who just wanted to go program so that they didn't have to PRETEND to be architects. Nobody felt insulted. Best of all, the staffing requirements when jobs are set up this way are such that the availability of people is inversely proportional to the expertise required--the less a person needs to know, the more of them you hire, making it pretty simple to get the team assembled (one or two hard-to-find architects, a small group of leads, a bunch of programmers [many of them entry level and just starting to learn the Ada language]). -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
dlw@odi.com (Dan Weinreb) (06/19/91)
In article <1991Jun18.122812.18190@eua.ericsson.se> euamts@eua.ericsson.se (Mats Henricson) writes:
I have so far only done programming as a library designer, and I think that
is *VERY* difficult if you try to produce code that is:
a) fast
b) not wasting memory
c) usable
d) reusable (in terms of subclasses)
e) etc
f) etc
g) etc
Certainly. But it's difficult in any language.dlw@odi.com (Dan Weinreb) (06/19/91)
In article <1991Jun18.220609.19103@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
This is an excellent point, and mirrors my own experiences with Ada. I imagine
similar things are true of Eiffel, Modula-3, and any of the other modern
software engineering languages. There is nothing WRONG with this, but an
organization needs to recognize that with increased language complexity comes
a greatly increased ability for the average programmer to get in trouble.
What he said was that he found that it was very hard to write reusable
code libraries that are very space-efficient, very time-efficient,
usable, and reusable by a wide range of applications. This is going
to be true no matter what language you write in. He offered no
evidence that writing such code would have been easier in a language
that traded off less complexity for less ability. The "increased
language complexity" issue is your point, not his point.
I do agree with your overall point about some people being much more
qualified as architects than others.smithd@software.org (Doug Smith) (06/20/91)
In article <1991Jun18.220609.19103@netcom.COM> jls@netcom.COM (Jim Showalter) writes: > One of the most successful Ada projects I'm aware of organized job > descriptions and responsibilities in such a way that a relatively small > number of exceptionally clever people was responsible for the architecture > (as captured in subsystem decomposition and subsystem interface specification), > each subsystem had a talented lead in charge of its implementation (but could > not alter the interfaces, which required an architectural decision), and > within each subsystem there was a team consisting of designers and programmers > (the designers designed package specs [class headers] and the programmers > implemented the bodies). It worked great...and one of the nicest things > about it was that it took the pressure OFF the folks who just wanted to > go program so that they didn't have to PRETEND to be architects. Nobody > felt insulted. Best of all, the staffing requirements when jobs are > set up this way are such that the availability of people is inversely > proportional to the expertise required--the less a person needs to know, > the more of them you hire, making it pretty simple to get the team > assembled (one or two hard-to-find architects, a small group of leads, > a bunch of programmers [many of them entry level and just starting to > learn the Ada language]). The simplest follow-up I have ever done. Thank you, Mr. Showalter for having also described two of the Ada projects I have worked on. They were on-schedule and produced products that satisfied requirements while achieving a level of quality well above what was needed.
jls@netcom.COM (Jim Showalter) (06/20/91)
>What he said was that he found that it was very hard to write reusable >code libraries that are very space-efficient, very time-efficient, >usable, and reusable by a wide range of applications. He also said that he saw, as a consequence, a pattern of bifurcation of programmers into two general categories: library designer and library client. My point was a reinforcement of this. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
chuck@brain.UUCP (Chuck Shotton) (06/20/91)
In article <1991Jun20.140836.24430@scrumpy@.bnr.ca>, stevej@bnrmtl.bnr.ca (Steve Juneau) writes: > Was all this achievable because you used Ada, or can have be done with > any language? IMHO it can be done with any language. > Please spare us. Automata Theory 101 teaches us that a Finite State Automaton can solve any deterministic computing problem. Let's just toss programming languages altogether. The point is that Ada provides facilities in the language that support modular design, consistent implementation, and most of all support integration and test activities. Freed from the logistics of engineering and implementing a system, Ada developers can actually concentrate more on the task at hand instead of the mechanics of integrating a system. And, you CAN'T do that with just any language. As an aside, the religous wars (discussions) here over "my language is bigger than your language" really don't appear to come to any constructive end. Do they ever die down, or is the news group actually just a place for Ada weenies to beat their chests? ----------------------------------------------------------------------- Chuck Shotton Internet: cshotton@girch1.med.uth.tmc.edu UUCP: ...!buster!brain!chuck "Your silly quote here." AppleLink: D1683 MacNet: shotton
stevej@bnrmtl.bnr.ca (Steve Juneau) (06/20/91)
In article <1991Jun19.170047.25064@software.org>, smithd@software.org (Doug Smith) writes: |> In article <1991Jun18.220609.19103@netcom.COM> jls@netcom.COM (Jim Showalter) writes: |> > One of the most successful Ada projects I'm aware of organized job |> > descriptions and responsibilities in such a way that a relatively small |> > number of exceptionally clever people was responsible for the architecture |> > (as captured in subsystem decomposition and subsystem interface specification), |> > each subsystem had a talented lead in charge of its implementation (but could |> > not alter the interfaces, which required an architectural decision), and |> > within each subsystem there was a team consisting of designers and programmers |> > (the designers designed package specs [class headers] and the programmers |> > implemented the bodies). It worked great...and one of the nicest things |> > about it was that it took the pressure OFF the folks who just wanted to |> > go program so that they didn't have to PRETEND to be architects. Nobody |> > felt insulted. Best of all, the staffing requirements when jobs are |> > set up this way are such that the availability of people is inversely |> > proportional to the expertise required--the less a person needs to know, |> > the more of them you hire, making it pretty simple to get the team |> > assembled (one or two hard-to-find architects, a small group of leads, |> > a bunch of programmers [many of them entry level and just starting to |> > learn the Ada language]). |> |> The simplest follow-up I have ever done. Thank you, Mr. Showalter for |> having also described two of the Ada projects I have worked on. They |> were on-schedule and produced products that satisfied requirements while |> achieving a level of quality well above what was needed. Was all this achievable because you used Ada, or can have be done with any language? IMHO it can be done with any language. -- Steve Juneau Recherches Bell-Northern Ltee 3, Place du Commerce phone: (514) 765-8246 Verdun, Quebec, Canada fax: (514) 876-3681 H3E 1H6 email: bnrmtl!stevej@larry.mcrcim.mcgill.edu
ryer@inmet.inmet.com (06/21/91)
At the WAdaS conference this week, Lloyd Moseman, the Air Force Ada Executive Official, announced that a comprehensive Ada vs C++ study had been done, and would be available soon. Mike "If I had more details, I would already have posted them" Ryer Intermetrics
eachus@largo.mitre.org (Robert I. Eachus) (06/21/91)
In article <1991Jun20.140836.24430@scrumpy@.bnr.ca> stevej@bnrmtl.bnr.ca (Steve Juneau) writes:
Was all this achievable because you used Ada, or can have be done with
any language? IMHO it can be done with any language.
Theoretically it can be done in any language, and I even know of
cases where it was done that way in COBOL and C. But from a
political/mangagement point of view, when using Ada it doesn't require
a group of highly qualified and committed people to make it work.
There are other languages where it can be made to work easily, such as
Modula2, but c++ is not one of them.
--
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...stachour@sctc.com (Paul Stachour) (06/21/91)
stevej@bnrmtl.bnr.ca (Steve Juneau) writes: >|> In article <1991Jun18.220609.19103@netcom.COM> jls@netcom.COM (Jim Showalter) writes: .... >|> > (as captured in subsystem decomposition and subsystem interface specification), >|> > each subsystem had a talented lead in charge of its implementation (but could >|> > not alter the interfaces, which required an architectural decision), and >|> > within each subsystem there was a team consisting of designers and programmers >|> > (the designers designed package specs [class headers] and the programmers >|> > implemented the bodies). It worked great... .... >Was all this achievable because you used Ada, or can have be done with >any language? IMHO it can be done with any language. The question is not only CAN it be done, but can it be done "reaqsonably". In Ada, the ENFORCEMENT of the specifications by the language gives me belief that when the system has been compiled and linked, the interfaces match. Sure, I could get that in FORTRAN with discipline, or in C using function prototypes (still with discipline, cause my programmers need to remember to write them and use them properly). But in Ada, the discipline comes easy: You don't write the prototypes in the specifications, you can't call the subroutine at all, let alone calling it wrong. What Ada gives me is the means to provide reasonable, enforceable, meaningful, interfaces. That's not available in any other widely distributed and available-for-software-engineering of real-problems. Thus, in practice (as opposed to theory) the answer to your question is: "No, it can't be done in 'just any language', but it can be done in Ada." Yours, ...Paul -- Paul Stachour SCTC, 1210 W. County Rd E, Suite 100 stachour@sctc.com Arden Hills, MN 55112 [1]-(612) 482-7467
dmg@ssc-vax (David M Geary) (06/22/91)
astevej@bnrmtl.bnr.ca (Steve Juneau) writes: ] In Ada, the ENFORCEMENT of the specifications by the language ] gives me belief that when the system has been compiled and linked, ] the interfaces match. Sure, I could get that in FORTRAN with ] discipline, or in C using function prototypes ... ] What Ada gives me is the means to provide reasonable, enforceable, ]meaningful, interfaces. That's not available in any other widely ]distributed and available-for-software-engineering of real-problems. What about Eiffel? -- |~~~~~~~~~~ David Geary, Boeing Aerospace, Seattle, WA. ~~~~~~~~~~| |-----------------------------------------------------------------------------| |~~~~~~ Seattle: America's most attractive city... to the *jetstream* ~~~~~~| |-----------------------------------------------------------------------------|
dmg@ssc-vax (David M Geary) (06/22/91)
In article <EACHUS.91Jun20145614@largo.mitre.org> eachus@largo.mitre.org (Robert I. Eachus) writes: ] ]In article <1991Jun20.140836.24430@scrumpy@.bnr.ca> stevej@bnrmtl.bnr.ca (Steve Juneau) writes: ] ] Was all this achievable because you used Ada, or can have be done with ] any language? IMHO it can be done with any language. ] ] Theoretically it can be done in any language, and I even know of ]cases where it was done that way in COBOL and C. But from a ]political/mangagement point of view, when using Ada it doesn't require ]a group of highly qualified and committed people to make it work. ]There are other languages where it can be made to work easily, such as ]Modula2, but c++ is not one of them. ^^^^^^^^^^^^^^^^^^^^^^ ] ] Robert I. Eachus ]use STANDARD_DISCLAIMER; ]function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is... Why not? Please elaborate. -- |~~~~~~~~~~ David Geary, Boeing Aerospace, Seattle, WA. ~~~~~~~~~~| |-----------------------------------------------------------------------------| |~~~~~~ Seattle: America's most attractive city... to the *jetstream* ~~~~~~| |-----------------------------------------------------------------------------|
jls@netcom.COM (Jim Showalter) (06/22/91)
[My summary of the job descriptions of a very successful Ada project deleted] >Was all this achievable because you used Ada, or can have be done with >any language? IMHO it can be done with any language. Indeed it can. But that's not the point, nor was it ever the point--I was responding to a post in which it was observed that C++ programmers seemed to be bifurcating into two major categories, library designer and library client. As this was a phenomenon I had observed on some Ada projects, I felt it might be of value to expand on the experience at one such project when they not only recognized the spread of talents in the team, but specifically acted to partition things up to maximize the use of such talents. Context is an important thing. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
tmb@ai.mit.edu (Thomas M. Breuel) (06/22/91)
In article <0D010010.63iouh@brain.UUCP> chuck@brain.UUCP (Chuck Shotton) writes:
The point is that Ada provides facilities in the language that support modular
design, consistent implementation, and most of all support integration and
test activities. Freed from the logistics of engineering and implementing
a system, Ada developers can actually concentrate more on the task at hand
instead of the mechanics of integrating a system. And, you CAN'T do that with
just any language.
Both C++ and Ada provide the facilities necessary for "modular design,
consistent implementation, ...". The difference is that Ada enforces
them more strongly, while C++ does not.
Depending on your applications, this can be an advantage or a
disadvantage. In many settings, it is probably the case that the
increase in time required to write some program because of the
inconvenient restrictions that Ada imposes (compared with C++) is
more than made up for by the fact that it enforces consistency
and has better error detection. However, to claim that Ada
"frees you" of anything is probably wrong. Scheme "frees" you,
anything else restricts you in various ways that may or may
not be good for you.
Thomas.jls@netcom.COM (Jim Showalter) (06/23/91)
>] What Ada gives me is the means to provide reasonable, enforceable, >]meaningful, interfaces. That's not available in any other widely >]distributed and available-for-software-engineering of real-problems. >What about Eiffel? I'm taking a wait-and-see attitude toward Eiffel, because, while it is a swell language definition, it also is still suffering from definitional volatility and from compiler immaturity. IS it widely distributed? I've heard otherwise. Do such tools as are available for it scale to real problems? I've heard otherwise (you might ask the folks at Cognos about that one!). Do I hope it succeeds? You bet!--it's a great design. I'm quite interested in any success stories you DO have for Eiffel, as well as information about availability, tool maturity, etc. I'm in the process of adding Modula-3 to my bag of tricks, and I should probably add Eiffel to round things out. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
cbw@grebyn.com (CBW Consulting) (06/24/91)
Those of you who missed Don Reifer's presentation at WAdaS last week should be sure to try and get a copy of his report. It shows that c++ is cheaper than Ada. There are a few other factors that need to be examined. First the results of the study are derrived from a small number of c++ project and most of them are in the telecommunications domain. Second, the learning curve to go from c to c++ is much shorter and easier than that for COBOL, Fortran, etc. to Ada. Chuck Williams CBW Consulting
andrewd@chook.adelaide.edu.au (Andrew Dunstan) (06/24/91)
In article <1991Jun18.122812.18190@eua.ericsson.se>, euamts@eua.ericsson.se (Mats Henricson) writes: |> I have started to see two different kinds of programmers in C++: |> 1. Library designers |> 2. Library users |> |> The first kind of programmers is doing some tricky nasty hacking behind the |> scenes of the interface of the classes, to satisfy the second kind of users. |> |> I have so far only done programming as a library designer, and I think that |> is *VERY* difficult if you try to produce code that is: |> a) fast |> b) not wasting memory |> c) usable |> d) reusable (in terms of subclasses) |> e) etc |> f) etc |> g) etc |> |> If you, on the other hand, have a well designed class library to build from, |> I think C++ is a beautiful and easy language to use. Yes, but writing libraries should not be so hard. It isn't in Ada. You've really made a point in Ada's favour. ####################################################################### # Andrew Dunstan # There's nothing good or bad # # Department of Computer Science # but thinking makes it so. # # University of Adelaide # # # South Australia # - Shakespeare # # net: andrewd@cs.adelaide.edu.au # # #######################################################################
emery@Dr_No.mitre.org (David Emery) (06/24/91)
Ada makes the _Expression_ of a library design easier (packages are such a nice mechanism for combining related things), but the _Intellectual_ work of deciding what to include, what to exclude, how to represent it, etc, is a (language-independent) hard problem. It takes a lot of experience and thought to get it right. For instance, it's taken us 4 years of hard work to specify the IEEE standard Ada Binding to POSIX (a very well constrained problem). Much of that time has been spent in "iterative prototyping" mode, where we develop a proposal, and then analyze it from the perspective of the various users, in an attempt to see if the semantics of the interface are correct. One thing that we all knew, but our POSIX/Ada experience reinforced, is that there's no substitute for practical experience when designing interfaces. You really have to have a good idea of how software is written and how software goes together in order to write a good interface/binding definition. And, as we have also observed, once you get the interface right, the implementation is _MUCH_ easier (often it's simple). dave
euamts@eua.ericsson.se (Mats Henricson) (06/24/91)
andrewd@chook.adelaide.edu.au (Andrew Dunstan) writes: >In article <1991Jun18.122812.18190@eua.ericsson.se>, >euamts@eua.ericsson.se (Mats Henricson) writes: >|> I have started to see two different kinds of programmers in C++: >|> 1. Library designers >|> 2. Library users >|> >|> The first kind of programmers is doing some tricky nasty hacking behind the >|> scenes of the interface of the classes, to satisfy the second kind of users. >|> >|> I have so far only done programming as a library designer, and I think that >|> is *VERY* difficult if you try to produce code that is: >|> a) fast >|> b) not wasting memory >|> c) usable >|> d) reusable (in terms of subclasses) >|> e) etc >|> f) etc >|> g) etc >|> >|> If you, on the other hand, have a well designed class library to build from, >|> I think C++ is a beautiful and easy language to use. >Yes, but writing libraries should not be so hard. It isn't in Ada. >You've really made a point in Ada's favour. To start with, I must admit that I haven't even seen one line of Ada code in my entire life. I know that is a weak point if you are discussing the pros and cons of C++ and Ada, but the thing is that I jumped into this discussion just to make a statement on what *I* think on the difficulties of writing code in C++. I think that depends on what kind of programmer you are (see above). I have written a string class consisting of 70 pages of code (including test code). I do not think that the actual writing was difficult, even though I of course had several bugs that was hard to find. After writing this class (it's actually two classes, along the main route of NIH, libg++ and the others) I learned more about library design from Mike Vilot, Jonathan Shopiro and Martin Carroll (courses). I now realize that just writing OK code is no big deal. Writing code that is optimal for many different users (see above) is HARD! If you claim that writing optimal component libraries in Ada is easy, I think you're wrong. I say this just from intuition, since I have no Ada experience. From what I have learned from programming, there is NO way you can make a language that makes it easy to do libraries. This is because library design is much a matter of design, i.e.: 1. What trade-offs are you taking (space/time) ? 2. Which kind of error-handling mechanism are you taking ? 3. Which features do you include in your code library ? 4. Which "class" is in charge in a complex UI-application ? 5. How do you avoid redundant code in your library ? 6. How do you achieve localized cost (you only pay for what you use) ? 7. How do you avoid complexity ? 8. How do you structure the library documentation ? Unless Ada is godsent (Something I doubt ;-) you have to wrestle with these questions when you write packages in Ada as well. Well, I suppose this is what I had to say... Mats Henricson
ryer@inmet.inmet.com (06/24/91)
Further Information on DOD Ada vs. C++ report: The Air Force says they will hold a press conference and announce the availability of the Ada/C++ report within the next 30 days; the Ogden Air Logistics Center STSC's CROSSTALK will describe how to get a copy. Mike Ryer Intermetrics
jls@netcom.COM (Jim Showalter) (06/25/91)
>Second, the learning curve to go from c to >c++ is much shorter and easier than that for COBOL, Fortran, etc. to >Ada. A much more valid comparison, I think, would be the learning curve to go from C to C++ vs the learning curve to go from Pascal to Ada. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
tmcclory@eve.wright.edu (Tom McClory) (06/25/91)
In article <3776@sirius.ucs.adelaide.edu.au> andrewd@chook.adelaide.edu.au (Andrew Dunstan) writes: >In article <1991Jun18.122812.18190@eua.ericsson.se>, >euamts@eua.ericsson.se (Mats Henricson) writes: > >|> I have so far only done programming as a library designer, and I think that >|> is *VERY* difficult if you try to produce code that is: >|> a) fast >|> b) not wasting memory >|> c) usable >|> d) reusable (in terms of subclasses) >|> e) etc >|> f) etc >|> g) etc >|> > >Yes, but writing libraries should not be so hard. It isn't in Ada. >You've really made a point in Ada's favour. > I strongly disagree with Andrew Dunstan that "writing" reusable libraries is any easier in Ada than other languages. The issue isn't the coding, but the designing. Writing truly reusable libraries that balance the conflicting tradeoffs Mats Henricson describes is a very difficult design problem that is independent of the programming language used. Grady Booch in his recent book _Object_Oriented_Design_ does a very nice job explaining why. As an example of how difficult writing such libraries are, even in Ada, check out the book _Software_Components_with_Ada_ also written by Booch. It is very evident that much thought, talent, and experience went into designing a collection of reusable data structures and common utilities. The data structures in his book, linked lists, queues, stacks, trees, graphs, etc. are the stuff most data structures course are made of. But designing for introduces many more important design decisions as Mats Henricson notes. In fact, it can be argued that since it is optional for compiler vendors to implement garbage collection in the compiler runtime support, designing reusable components for Ada is *more* difficult. Any component that creates and destroys many instances during execution must itself perform the garbage collection. The designer of such a component must take this into account during design and during implementation. All "object oriented" languages I'm familiar with (Smalltalk, C++, Eiffel) provide garbage collection to remove this burden from the programmer. Regards, Tom McClory
jls@netcom.COM (Jim Showalter) (06/26/91)
Some years ago, Grady Booch wrote a library of 501 reusable components in Ada (and documented it in his second book, "Software Components with Ada: Structures, Tools, and Subsystems", Benjamin-Cummings). It didn't take him all that long to do, and they are widely used in industry. They work SO well, in fact, that a C++ version is in the works (it may already be available by now...how quickly one loses touch). I can answer some of the questions you ask, at least for this particular Ada library: >1. What trade-offs are you taking (space/time) ? Booch finessed this by writing different flavors of his components for different combinations of space/time tradeoffs. Thus, you have both bounded (typically array) and unbounded (typically linked list) versions of the components. Incidentally, Booch says (and I agree) that this was an area where inheritance would have played a legitimate role, if Ada had inheritance. >2. Which kind of error-handling mechanism are you taking ? Exceptions. >3. Which features do you include in your code library ? Unclear what this question is asking. >4. Which "class" is in charge in a complex UI-application ? N/A >5. How do you avoid redundant code in your library ? By building higher level abstractions up from lower level abstractions. >6. How do you achieve localized cost (you only pay for what you use) ? If buy "pay" you mean money (as in dollars), this is N/A, since there is a single cost for the entire library. If by "pay" you mean the cost of compiling in the code, this just exploits the Ada compilation rules, in which only those units in the DAG of compilation dependencies (via 'with'ing) are included in the resulting executable. >7. How do you avoid complexity ? By running as fast as possible in the other direction. :-) I'm not sure what you're asking here. Do you mean complexity within the implementation, complexity from the standpoint of the library client, or what? From the library client standpoint, the Booch components are very easy to use. >8. How do you structure the library documentation ? Well, Booch chose to write a book. This seems to have worked out quite well, since the book is so detailed that it answers almost any question anybody would ever care to ask about how to use the components. (It is also suitable for use as a text on data structures.) -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
jls@netcom.COM (Jim Showalter) (06/26/91)
>In fact, it can be argued that since it is >optional for compiler vendors to implement garbage collection in the >compiler runtime support, designing reusable components for Ada is *more* >difficult. Any component that creates and destroys many instances during >execution must itself perform the garbage collection. The designer of >such a component must take this into account during design and during >implementation. All "object oriented" languages I'm familiar with >(Smalltalk, C++, Eiffel) provide garbage collection to remove this >burden from the programmer. Is this really true for C++? I believe one of the reasons for providing constructors and destructors was to supply the programmer with explicit control over initialization and finalization, so that memory-safe non- leaky implementations could be constructed. I've never heard anybody claim before that without any effort on the programmer's part, garbage collection is automatically taken care of in C++ (I've heard of it being taken care of automatically in LISP, and not well...). Sure, on a UNIX box one can semi-safely ignore garbage issues, but that's just because the problem is swept under the carpet of job control--at some level the kernel is still having to deal with garbage collection, memory fragmentation, etc. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
andrewd@chook.adelaide.edu.au (Andrew Dunstan) (06/26/91)
In article <1991Jun25.002928.16897@eve.wright.edu>, tmcclory@eve.wright.edu (Tom McClory) writes: |> In article <3776@sirius.ucs.adelaide.edu.au> andrewd@chook.adelaide.edu.au (Andrew Dunstan) writes: |> >In article <1991Jun18.122812.18190@eua.ericsson.se>, |> >euamts@eua.ericsson.se (Mats Henricson) writes: |> > |> >|> I have so far only done programming as a library designer, and I think that |> >|> is *VERY* difficult if you try to produce code that is: |> >|> a) fast |> >|> b) not wasting memory |> >|> c) usable |> >|> d) reusable (in terms of subclasses) |> >|> e) etc |> >|> f) etc |> >|> g) etc |> >|> |> > |> >Yes, but writing libraries should not be so hard. It isn't in Ada. |> >You've really made a point in Ada's favour. |> > |> |> I strongly disagree with Andrew Dunstan that "writing" reusable |> libraries is any easier in Ada than other languages. The issue isn't |> the coding, but the designing. |> I looked again and saw that Mats was talking about "producing code", not design. Of course, there are language-independent aspects of programming, particularly in abstract design. These are often very difficult, but the issue in this discussion has been C++ vs. Ada. That was what I was dealing with. |> Writing truly reusable libraries that balance the conflicting tradeoffs |> Mats Henricson describes is a very difficult design problem that is |> independent of the programming language used. Grady Booch in his |> recent book _Object_Oriented_Design_ does a very nice job explaining why. |> See above. I haven't read the book, but I will try to get a copy! |> As an example of how difficult writing such libraries are, even in Ada, |> check out the book _Software_Components_with_Ada_ also written by Booch. |> It is very evident that much thought, talent, and experience went into |> designing a collection of reusable data structures and common utilities. |> The data structures in his book, linked lists, queues, stacks, trees, |> graphs, etc. are the stuff most data structures course are made of. I have read this and used a few of the tools. It has a useful set of tools, but there is just something about it that occasionally annoys me. Maybe it's just that I don't like identifiers like the_small_brown_dog_with_a_broken_left_front_leg! :-) Seriously, what I find disconcerting is that his abstractions have a strange feel to them. They don't reflect the way I think about objects, so using them is a bit too much of an effort. (This is an important issue in program/library design!) |> But designing for introduces many more important design decisions as |> Mats Henricson notes. In fact, it can be argued that since it is |> optional for compiler vendors to implement garbage collection in the |> compiler runtime support, designing reusable components for Ada is *more* |> difficult. Any component that creates and destroys many instances during |> execution must itself perform the garbage collection. The designer of |> such a component must take this into account during design and during |> implementation. All "object oriented" languages I'm familiar with |> (Smalltalk, C++, Eiffel) provide garbage collection to remove this |> burden from the programmer. I agree that garbage collection is a serious issue, and must be dealt with promptly and effectively by compiler vendors. It is not good enough any more to have vendors taking advantage of the "option" in the standard. This is an example of a fundamental issue in language design. How much, and what, do we leave up to the programmer, and how much and what do we take care of in the run-time system of the language. Which seems to get us back to where we started! ####################################################################### # Andrew Dunstan # There's nothing good or bad # # Department of Computer Science # but thinking makes it so. # # University of Adelaide # # # South Australia # - Shakespeare # # net: andrewd@cs.adelaide.edu.au # # #######################################################################
dlw@odi.com (Dan Weinreb) (06/27/91)
In article <1991Jun20.220947.23970@sctc.com> stachour@sctc.com (Paul Stachour) writes:
Thus, in practice (as opposed to theory) the answer to your question
is: "No, it can't be done in 'just any language', but it can be done
in Ada."
However, anecdotal data such as "We did some projects, and we did them
in Ada, and they went very well" does not provide experimental
evidence that those same projects would have gone significantly less
well had they been done in some other language, with everything else
being equal.
It's very difficult, in general, to produce real evidence that would
help to significantly support or deny claims about how choice of
language affects the course of a software project, mainly because it's
so hard to assure that all else is equal, and because it would be so
expensive.jls@netcom.COM (Jim Showalter) (06/27/91)
>I have read this and used a few of the tools. It has a useful set of >tools, but there is just something about it that occasionally annoys me. >Maybe it's just that I don't like identifiers like >the_small_brown_dog_with_a_broken_left_front_leg! :-) These names arose because Booch needed/wanted a way to unambiguously specify the chief attributes of each abstraction (because of the semi- combinatorial nature of the ways in which these attributes can be mingled, there are cases where you have over a hundred flavors of a particular fundamental kind of component, such as a queue). This is, he'd be the first to admit, one of the places where inheritance would be a natural match, since one could use it to specialize--his C++ version of these same components exploits inheritance. >Seriously, what I find disconcerting is that his abstractions have a >strange feel to them. They don't reflect the way I think about objects, >so using them is a bit too much of an effort. (This is an important >issue in program/library design!) I would be interested in an elaboration of this point, since I am hard pressed to imagine what you find disconcerting or strange about the components--they're just things like lists and queues and rings and stacks. Pretty mundane, really. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
chuck@brain.UUCP (Chuck Shotton) (06/27/91)
In article <1991Jun26.221313.5872@odi.com>, dlw@odi.com (Dan Weinreb) writes: > However, anecdotal data such as "We did some projects, and we did them > in Ada, and they went very well" does not provide experimental > evidence that those same projects would have gone significantly less > well had they been done in some other language, with everything else > being equal. > > Likewise, yours is not an argument for doing the projects in a language other than Ada. > It's very difficult, in general, to produce real evidence that would > help to significantly support or deny claims about how choice of > language affects the course of a software project, mainly because it's > so hard to assure that all else is equal, and because it would be so > expensive. I can give you plenty of "evidence" relating the difference between a C project and Ada project, both of which addressed the same problem space, resulted in similar solutions, and were staffed by similar numbers of experienced people. I can tell you from first hand experience that in every measure, the Ada task outperformed the C task. If you'd like more details, please reply in e-mail, as this topic has veered far astray from comp.lang.ada. ----------------------------------------------------------------------- Chuck Shotton Internet: cshotton@girch1.med.uth.tmc.edu BIAP Systems UUCP: ...!buster!brain!chuck "Your silly quote here." AppleLink: D1683 MacNet: shotton
blakemor@software.org (Alex Blakemore) (06/27/91)
Somebody said (sorry I lost the name :( >>Seriously, what I find disconcerting is that his abstractions have a >>strange feel to them. They don't reflect the way I think about objects, >>so using them is a bit too much of an effort. (This is an important >>issue in program/library design!) Jim Showalter replied >I would be interested in an elaboration of this point, since I am hard >pressed to imagine what you find disconcerting or strange about the >components--they're just things like lists and queues and rings and I agree with the first poster. After using them on and off for a couple years, I have lost enthusiasm. The simple things like lists and sets add more complexity to the client code than they take away in many cases. The complex structures have a very strange interface that makes using them very awkward and in some cases error prone. The tree packages are a prime example, try explaining set_child or swap_child sometime. They're a nice attempt but I cant believe this is the end ot the rainbow. -- --------------------------------------------------------------------- Alex Blakemore blakemore@software.org (703) 742-7125 Software Productivity Consortium 2214 Rock Hill Rd, Herndon VA 22070
diederich_r_%ncsd.dnet@GTE.COM (Ray Diederich, 301-294-8400) (06/28/91)
In INFO-ADA Vol.91, #181, pyrdc!grebyn!cbw@uunet.uu.net (Chuck Williams) writes: >It shows that c++ is cheaper than Ada. There are a few other factors >that need to be examined. First the results of the study are derrived >from a small number of c++ project and most of them are in the >telecommunications domain. Second, the learning curve to go from c to >c++ is much shorter and easier than that for COBOL, Fortran, etc. to >Ada. and in INFO-ADA, Vol. 91, #183, netcomsv!jls@decwrl.dec.com (Jim Showalter) replies: >A much more valid comparison, I think, would be the learning curve to >go from C to C++ vs the learning curve to go from Pascal to Ada. I disagree. Sure it's easy to go from Pascal to Ada, but is anyone really doing any Pascal programming? If the future Ada programmers are the current Pascal programmers, there won't be many Ada programmers in the future. On the other hand, the future C++ programmers are _likely_ to be the current C programmers, and there seems to be an awful lot of C programmers. So the valid consideration is still between C->C++ and COBOL/FORTRAN->Ada, and I think that Chuck's original point is that this comparison unfairly favors C++. The results of the original report are skewed, because it only shows short-term gains. Ray Diederich GTE Government Systems Corporation Electronic Defense Sector National Center Systems Organization ======================================== My employer would prefer that I had no opinions to express, especially any that may have been expressed here. ========================================
jls@netcom.COM (Jim Showalter) (06/28/91)
>After using them [Booch components] >on and off for a couple years, I have lost enthusiasm. >The simple things like lists and sets add more complexity >to the client code than they take away in many cases. Can you be more specific? Not trying to be difficult, just truly confused. The lists and sets and stuff seem quite simple to me. >The complex structures >have a very strange interface that makes using them very awkward and >in some cases error prone. The tree packages are a prime example, >try explaining set_child or swap_child sometime. Ah, now this is interesting. Lots of people have complained that the swap operations, etc are not the way they'd have written the interface. However, the more common way to write it creates a lot more garbage and runs slower--I received a paper a while back from a person on the net who advocates structural swapping as the basis of almost all data structure design because it is so much faster; the Booch components use this same approach. You can build a more abstracted interface on top if you are willing to sacrifice space/speed. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *