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 //
mnm@hpcupt3.cup.hp.com (Michey Mehta) (06/14/91)
> 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. The real cost of a virtual function call in C++ is not the cost of the dispatch, but rather the cost of not being able to inline small time-critical virtual functions. A paper by Tektronix at the 1991 Usenix C++ conference described a "flattening" tool which provided speedups of three times by making all virtual functions in leaf classes into non virtual functions. There is some literature about link time inlining, but such linkers are not yet widely available. Michey Mehta Hewlett-Packard California Language Lab
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
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 # # #######################################################################
alanb@sdl.mdcbbs.com (06/24/91)
In article <1991Jun20.220947.23970@sctc.com>, stachour@sctc.com (Paul Stachour) writes: > 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 My ADA experience is limited to reading a couple of books and having an ex-girlfriend swearing at how often the compiler she was using crashed her machine, but C++ provides a lot more than C in terms of the discipline required to enforce use of function prototypes - if it's a member function, and you haven't included the class definition, you can't call it. And you get inheritance as well - I've seen a few papers/articles on using inheritance in ADA, and they all involved significant overhead, or loss of some of the type safety, or using the discipline that it's claimed ADA frees you from - writing in a language designed to support inheritance seems a lot easier. Of those, C++ seems the best compromise for a lot of work - I've not seen modula-3 though - anybody out there able to comment on it? (Of course the fact that it isn't widely known is one reason not to use it, but not overwhelming). alanb@sdl.mdcbbs.com Alan Braggins My own opinions etc.
pierson@encore.com (Dan L. Pierson) (06/25/91)
Regarding Re: c++ vs ada results; alanb@sdl.mdcbbs.com adds: > Of those, C++ seems the best compromise for a lot of work - I've not seen > modula-3 though - anybody out there able to comment on it? (Of course the fact > that it isn't widely known is one reason not to use it, but not overwhelming). Very Roughly: To make Modula-3, take Modula-2 and: + Add single inheritance objects (MI interaction with modules is not well understood). - Remove varient records (no longer needed). + Add garbage collection. + Add exception handling. + Add Safe/Unsafe module distinction. o Change name equivalence to structural equivalence. + Support concurrent threads with a required module. + Add generics (in "Twelve Change to Modula-3" mail of 12/19/90). The result is a language with roughly the same power as C++ but a good deal more safety and simplicity. The total definition is actually much smaller. IMHO, it's a much better language than C++. As usual with Pascal family language there will be some runtime penalty for things like array bounds and arithmetic overflow checking. As usual, good compilers will let you turn these checks off if you want to. Other than that, there's no reason why a decent compiler should produce code that's any worse that C or C++. For an example of Modula-3 in use, get Digital System Research Center report 53, "IO Streams: Abstract Types, Real Programs". The language definition is also available as report 52. Last I knew, both of these were available free by requesting them from the SRC librarian. A book, "Systems Programming in Modula-3", may be available by now. You're right that current implementation status is a major handicap to adoption. The only current implementation is the free, mostly portable, Modula-3 to C compiler from SRC. A group at UMass Amherst is working on a gcc-based compiler, but hasn't announced an availability date. -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@encore.com
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++. *
alanb@sdl.mdcbbs.com (06/25/91)
In article <1991Jun24.201111.13742@netcom.COM>, jls@netcom.COM (Jim Showalter) writes: >>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. > -- Not necessarily. I believe there is a lot more C, COBOL, Fortran experience "out there" than Pascal. Certainly I've never noticed a job advert asking for Pascal experience. Lots of people use it for teaching, which is what is was designed for - but problems like no facilities for seperate compilation mean that there is no support for organising large projects - structuring large/complex projects is supposed to be something object-orientation is good at. (I am aware many Pascal compilers do support modules - I hadn't heard there was any standard for these extensions - if there is I retract the last statement.) I'd say the relevent comparison is C to C++ vs. C to ADA if you work in C, Fortran to C++ vs. Fortran to ADA if you work in Fortran, etc. If you want a "next step" from Pascal, the description of Modula-3 recently posted in this thread sounds nice (we don't get comp.lang.modula3 here). I have seen it claimed that the "short learning curve" is actually a _disadvantage_ - it encourages people to go on writing C, thinking that they are now using an object-oriented language, so that's all there is to it. Hence the comment that C++ is (in contrast to ++C), increment C, and use the old value :-). Alan Braggins alanb@sdl.mdcbbs.com `cat ~/.disclaimer`
philip@pescadero.Stanford.EDU (Philip Machanick) (06/26/91)
In article <1991Jun25.112956.1@sdl.mdcbbs.com>, alanb@sdl.mdcbbs.com writes: |> (I am aware many Pascal compilers do support modules - I hadn't heard there |> was any standard for these extensions - if there is I retract the last |> statement.) The UCSD extension to Pascal introduced a Unit feature, which is close to a "standard" on Mac and PC Pascals. A few years back, I saw a proposed ISO (I think?) extension to the existing standard which would have added modules, but with completely different syntax. It seems some people out there still don't think PCs and Macs are real computers, despite the fact that installed units must be in the 10s of millions by now, and the high end versions of these things can run bigger programs than mainframes could a few years ago. (And run into equivalent project management problems - if not worse, because designing for the mass market must be harder than doing it for a specific customer.) Pascal is gradually being superseded on the Mac by C++, since this is the way Apple is going, and no doubt the application developers will have to follow to avoid interface problems. There is a huge number of PC / Mac programmers who have grown up on compilers like Turbo Pascal (PC) and Think Pascal (Mac). I wonder if these people outnumber FORTRAN and COBOL programmers on mainframes. (I would be interested if anyone has figures for this.) So much for the COBOL/Fortran to Ada learning curve. What of the Pascal to C++ learning curve? -- Philip Machanick philip@pescadero.stanford.edu
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.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