c++ vs ada results

c++ vs ada results

[alan dare]

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  | 

Re: c++ vs ada results

[Paul Martz]

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

Re: c++ vs ada results

[Jim Showalter]

>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++.    *

Re: c++ vs ada results

[Paul Kohlmiller]

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           // 

Re: c++ vs ada results

[Bruce Jones]

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

GNU c++ bashing (was Re: c++ vs ada results)

[Eli Brandt]

I took this out of the graphics groups cuz it's not graphics.
In article <1991Jun12.201740.16463@netcom.COM> jls@netcom.COM (Jim Showalter) writes:

[ Ada/C++ discussion axed ]

>>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.

Out of curiosity, have you actually used a GNU compiler?  If so, could you
specify some of the bugs with which it was "shot through".  Please, only note
those which directly affected you, because *commercial* compiler vendors don't
tell you about other bugfixes.  My experience has been that gcc is less buggy
than Sun cc or (smirk) Microsoft C.  I've had no problems working on a
prospective Obfuscated C entry.  Can you honestly tell me that you've never
wanted to look at, tweak, port, or tinker with your compiler?  Difficult
without source.  As for support, I suspect the net will be around longer than
most Ada vendors.

GCC sidenote:  It appears that gcc -O generates division code which is about six 
times faster than SGI's cc -O on a 4D.  Multiplication is "only" 70% faster.  Has
anybody else seen numbers like these?  A factor of six seems just a bit odd.
"You get what you pay for"?


[ C++ bashing, much of which I agree with, axed ]

>-- 
>*** 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++.    *

/     Eli Brandt      eli@gang.umass.edu       \
\     You have been disclaimed.                /

Re: c++ vs ada results

[Russ Nelson]

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.

Re: c++ vs ada results

[Sean Eric Fagan]

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.

Re: c++ vs ada results

[Jim Showalter]

[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++.    *

Re: c++ vs ada results

[Sean Eric Fagan]

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.

Re: c++ vs ada results

[Jim Showalter]

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++.    *

Re: c++ vs ada results

[Mats Henricson]

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

Re: c++ vs ada results

[Jim Showalter]

>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++.    *

Re: c++ vs ada results

[Dan Weinreb]

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.

Re: c++ vs ada results

[Doug Smith]

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.

Re: c++ vs ada results

[Steve Juneau]

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

Re: c++ vs ada results

[Robert I. Eachus]

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...

Re: c++ vs ada results

[David M Geary]

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* ~~~~~~|
|-----------------------------------------------------------------------------|

Re: c++ vs ada results

[Paul Stachour]

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

Re: c++ vs ada results

[David M Geary]

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* ~~~~~~|
|-----------------------------------------------------------------------------|

Re: c++ vs ada results

[Jim Showalter]

>]   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++.    *

Re: c++ vs ada results

[Dan Weinreb]

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.

Re: c++ vs ada results

[Jim Showalter]

[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++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[Alex Blakemore]

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]).

This makes sense and sounds like it can work well. It's really just
the chief programmer teams from the Mythical Man Month by Fred Brookes.
One obvious caveat - you really better have the right people
in the chief programmer roles or you are sunk.  This organization
alone is not sufficient.  I've been on projects at previous jobs with
such setups and the upper roles were assigned to those that had been
hired earlier, which wasn't the ideal criteria in my mind. They tended to
restrict the flow of information between team members, which was great when
they were able to create well designed independent work packages - but
was a real hindrance when there were problems.  

  I knew one very bright programmer who had unworkable designs pressed on
him by the leader of his subgroup.  He couldnt totally redesign it without 
her fighting every step of the way, even though it was absolutely necessary.  
He finally resorted to making the redesign but leaving a few obvious simple 
flaws that even she could detect, presenting the design to her for review 
and asking her help in solving those last sticky "problems".  She saved 
her ego, the software was corrected but the poor guy at the bottom had to 
suffer through this several times and the lead got the credit when it worked.
He would have done better to let the project fail if his goal was to advance in
the organization.  This project structure is not very forgiving if you place
people too high or low in the hierarchy.

If you are interested in a biting but accurate satirical treatise on
the role of incompetance and hierarchies in large organizations, see the
classic book - "The Peter Principle".




-- 
---------------------------------------------------------------------
Alex Blakemore           blakemore@software.org        (703) 742-7125
Software Productivity Consortium  2214 Rock Hill Rd, Herndon VA 22070

Re: chief programmer team organizations was (c++ vs ada results)H

[house ron]

blakemor@software.software.org (Alex Blakemore) 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),

>This makes sense and sounds like it can work well. It's really just
>the chief programmer teams from the Mythical Man Month by Fred Brookes.
>One obvious caveat - you really better have the right people
>in the chief programmer roles or you are sunk.  This organization

The book "Software that Works" by Michael Ward recommends against this for
exactly the reason you mention, among others.  He feels that the programmers
must be involved in design, and that design/programming should alternate,
rather than one coming first in a big chunk followed by the other.
That's my potted version, anyway.

--
Regards,

Ron House.   (s64421@zeus.usq.edu.au)
(By post: Info Tech, U.C.S.Q. Toowoomba. Australia. 4350)

Re: chief programmer team organizations

[Joseph Beckenbach {Adapter Software Release Engr}]

>> Alex Blakemore <blakemor@software.software.org>
> Ron House <s64421@zeus.usq.EDU.AU>


>>This makes sense and sounds like it can work well. It's really just
>>the chief programmer teams from the Mythical Man Month by Fred Brookes.
>>One obvious caveat - you really better have the right people
>>in the chief programmer roles or you are sunk.

>The book "Software that Works" by Michael Ward recommends against this for
>exactly the reason you mention, among others.  He feels that the programmers
>must be involved in design, and that design/programming should alternate,
>rather than one coming first in a big chunk followed by the other.
>That's my potted version, anyway.


	Not having read Mr. Ward's book, I cannot say how to interpret his
experience.  Having read Mr. Brooks's book, and drawing on my own experience,
I can say that Ron House seems to have fallen into a common misconception --
in a project requiring architects, once the architects are finished the design
work is done, and no-one else can do any design work.  This view is a myth,
since it extrapolates the huge-scale software effort from the small-scale
software effort.  One can as successfully extrapolate from a doghouse to a
city block in downtown Manhattan.

	The architects exist to provide a grand unifying vision for a project,
so that there is a framework for the rest of the work to proceed.  The teams
and team members who must create the darn thing have few exact specifications,
no clear idea what trade-offs will be necessary to meet high-level designs,
and no limitations on exactly how they will get there.  If going from there
to being ready to code isn't "design" in its own right, then by that usage
of the word there is NOBODY who does design in projects smaller than five
people, in any field of endeavor.

	One MUST have good people at the top.  This does not mean that all
the thinking is done at the top, just the broadest strokes of the brush.
And note that Brooks's project had several HUNDRED programmers working at any
one time;  without such a division of labor, the project would not have been
possible.

		Joseph Beckenbach
-- 
----
Joseph Beckenbach	jerbil@ultra.com	408-922-0100 x246

Re: chief programmer team organizations was (c++ vs ada results)H

[Jim Showalter]

s64421@zeus.usq.EDU.AU (house ron) writes:
>blakemor@software.software.org (Alex Blakemore) 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),
>>This makes sense and sounds like it can work well. It's really just
>>the chief programmer teams from the Mythical Man Month by Fred Brookes.
>>One obvious caveat - you really better have the right people
>>in the chief programmer roles or you are sunk.  This organization

>The book "Software that Works" by Michael Ward recommends against this for
>exactly the reason you mention, among others.  He feels that the programmers
>must be involved in design, and that design/programming should alternate,
>rather than one coming first in a big chunk followed by the other.
>That's my potted version, anyway.

Well, I certainly agree that design/programming should alternate--that's the
basis of iterative development. On the other hand, I
fail to see what this has to do with the notion that some people are better
than others at design, and that those who are the BEST at design probably
ought to be the ones making the most critical decisions on the project.
If someone can provide me with an explanation for why junior programmers
should be making architectural decisions affecting the entire project,
I'm all ears.
-- 
*** 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++.    *

Re: chief programmer team organizations was (c++ vs ada results)H

[Dan Weinreb]

In article <1991Jun21.222536.18888@netcom.COM> jls@netcom.COM (Jim Showalter) writes:

   If someone can provide me with an explanation for why junior programmers
   should be making architectural decisions affecting the entire project,
   I'm all ears.

I generally agree with the point you're making.  In my experience,
what really happens is more complex than anything described in any of
these postings.  Iterative development of software within a team is a
social interaction between people.  It's not a question of "command
and obey", but a give-and-take with conversations and discussions.  In
general, when I've been involved with this, the more senior
"architect"-type people end up having more say about design issues.
But if one of the other team members has a good idea, that idea can
certainly be used, and a good architect should pay attention to
everyone's ideas and be quick to credit and use ideas from anyone.
This is part of the process by which the more junior people become
more senior, and it helps keep everybody motivated and excited.  An
important thing about the concensus process is to establish an
atmosphere of mutual respect and trust, so that when there are
disagreements on how to proceed, people will be able to compromise,
or to willingly give up their proposals and go along with someone
else's, without resentment.

Re: chief programmer team organizations was (c++ vs ada results)

[Lars P. Fischer]

>>>>> On 20 Jun 91, blakemor@software.software.org (Alex Blakemore) said:

Alex> This makes sense and sounds like it can work well. It's really just
Alex> the chief programmer teams from the Mythical Man Month by Fred Brookes.
Alex> One obvious caveat - you really better have the right people
Alex> in the chief programmer roles or you are sunk.

Please note that the Brookes book is not exactly new -- it's a great
book, one that every serious software professional should read, but
remember that some of the advise reflects state-of-the-art in the
early 70's.

I recommend DeMarco's "PeopleWare" book as a good introduction to the
management of development and the organization of people and teams. It
reflects a more modern approach to providing teams with a good spirit
by giving each person responsibility and the opportunity to develop,
plus providing good working environments. This is much more in line
with modern management practice.

Alex> If you are interested in a biting but accurate satirical treatise on
Alex> the role of incompetance and hierarchies in large organizations, see the
Alex> classic book - "The Peter Principle".

And please, please, remember that Parkinson's books are just that -
satire. They were never intended to be textbooks or solid advise on
management. They are hilariously funny and thought provoking at the
same time, but taking them literally would be a mistake.

/Lars
--
Lars Fischer,  fischer@iesd.auc.dk   | It takes an uncommon mind to think of
CS Dept., Univ. of Aalborg, DENMARK. | these things.  -- Calvin

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

>Alex> If you are interested in a biting but accurate satirical treatise on
>Alex> the role of incompetance and hierarchies in large organizations, see the
>Alex> classic book - "The Peter Principle".

>And please, please, remember that Parkinson's books are just that -
>satire. They were never intended to be textbooks or solid advise on
>management. They are hilariously funny and thought provoking at the
>same time, but taking them literally would be a mistake.

Uh, you might want to check with Mr. Peter on that--I believe he was
quite serious. And I've certainly seen the principle he elucidates in
action in the real world (think of Dan Quayle...).
-- 
*** 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++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Hargrove]

>>>>> fischer@iesd.auc.dk (Lars P. Fischer) writes:


>>>>> On 20 Jun 91, blakemor@software.software.org (Alex Blakemore) said:


Alex> If you are interested in a biting but accurate satirical treatise on
Alex> the role of incompetance and hierarchies in large organizations, see the
Alex> classic book - "The Peter Principle".

Lars> And please, please, remember that Parkinson's books are just that -
Lars> satire. They were never intended to be textbooks or solid advise on
Lars> management. They are hilariously funny and thought provoking at the
Lars> same time, but taking them literally would be a mistake.

Well, maybe not. I notice that you are in academia. I find the Peter
Principle works pretty well in BIG BUSINESS. BTW, the book was written
by Lawrence(?) Peter, not Parkinson. On the other hand, Parkinson's
laws seem to be VERY relevant to the real world. Work really does
expand to fill time available. Extensions to disk space are also valid.
-- 

        -- jwh

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

>He finally resorted to making the redesign but leaving a few obvious simple 
>flaws that even she could detect, presenting the design to her for review 
>and asking her help in solving those last sticky "problems".  She saved 
>her ego, the software was corrected but the poor guy at the bottom had to 
>suffer through this several times and the lead got the credit when it worked.
>He would have done better to let the project fail if his goal was to advance in
>the organization.  This project structure is not very forgiving if you place
>people too high or low in the hierarchy.

"Against stupidity, the gods themselves contend in vain." Sadly, this
sounds like a fairly typical project. I swear, when I get in a bad mood
I half believe the single most effective solution to what ails most
troubled software development efforts would be to simply shoot every
third manager. Arghh.

On the other hand, the project I described in my earlier post was
QUITE atypical. They chose Ada on its merits (didn't have to use it--just
evaluated what was available and decided Ada was the only viable tool
for solving their problem). They had a superb chief architect. They
knew they were building 4 ships in a row, so they focused on reuse from
the start as a MULTI-project objective (achieving, in the end, 70% reuse
across the four projects and $117 million in savings [their numbers]).
They made optimal use of Rational's technology. They were just wonderful.
It's projects like this that make it all worthwhile...just wish there
were more like it.
-- 
*** 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++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[John Nagle]

     Real chief programmer teams are very rare.  I've never heard of one
other than in Brooks' book.  It's very different than having a lead programmer
or a system architect.  It's organized like a surgical team.  The chief
programmer personally writes most of the delivered code, and everything else
is set up to facilitate this.  There is an administrator, who reports to the
chief programmer, to take care of mundane problems.  A toolsmith creates
tools not part of the deliverable code.  A language lawyer deals with
compiler and library issues.  A tester tests everything.  A librarian 
keeps track of everything.  All these people are subordinate to the chief
programmer.

    It's too much of a culture shock for most organization.

					John Nagle
    

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

>     Real chief programmer teams are very rare. I've never heard of one
>other than in Brooks' book.

Given your description below, I don't find this surprising, since I
find it impossible. Read on.

>It's organized like a surgical team.  The chief
>programmer personally writes most of the delivered code, and everything else
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>is set up to facilitate this.

Tommyrot! How on earth is a single human being going to write "most",
or, for that matter, even a FRACTION, of the code on a project of
significant size? I'm talking here of things like the multi-MILLION
line FAA rewrite of the U.S. air traffic control system. No, what is
needed is a single architect (or at least a very small number of
architects on a tightly focused team) who set up the groundrules for
the overall system. After that, a horde of implementors can hammer
out the individual subsystems.

What you describe sounds like something that MIGHT work, but only on
a programming-in-the-small project, which I'm not particularly interested
in (I view programming-in-the-small as a solved problem).

>    It's too much of a culture shock for most organization.

As would be any unworkable scheme. ;-)
-- 
*** 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++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[David Feustel]

I think the FAA project will never be finished (except by decree).
-- 
David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631
EMAIL: feustel@netcom.com  or feustel@cvax.ipfw.indiana.edu

I voted for Bush once.  As it's turning out, once was once too often.

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

>I think the FAA project will never be finished (except by decree).

Why? I was involved with that project, and they're basically on schedule
and have written gazillions of lines of stuff that works, and are
continuing to write more. What insight into that project do you have
that I do not?
-- 
*** 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++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[Dan Weinreb]

In article <1991Jun23.185449.24818@netcom.COM> jls@netcom.COM (Jim Showalter) writes:

   >I think the FAA project will never be finished (except by decree).

   Why? I was involved with that project, and they're basically on schedule
   and have written gazillions of lines of stuff that works, and are
   continuing to write more. What insight into that project do you have
   that I do not?

"No software is ever finished until the last user is dead."
   -- Old Canturbridian Proverb

Re: chief programmer team organizations was (c++ vs ada results)

[Marco S Hyman]

In article <1991Jun23.032353.8718@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
 > Tommyrot! How on earth is a single human being going to write "most",
 > or, for that matter, even a FRACTION, of the code on a project of
 > significant size? I'm talking here of things like the multi-MILLION
 > line FAA rewrite of the U.S. air traffic control system.

If one can imagine the system then one can build the system, just a little
slower than two, or three.  But in any case faster than 100.  Every new person
adds to the communications burden and increases the chance of a
mis-communication causing something to be misunderstood.  Misunderstandings
lead to defects and system failures.  I'd guess seven would be the top end,
providing you have the right seven.  Three seems to be a good number in
practice.

Charles Moore once said at a conference (I think it was Software Development
'89) that he'd have no problem with SDI providing he was the one writing the
software.  (In forth?)  And yes, I was involved in a project where three
re-designed and wrote a system originally done by a group of 20 -- faster,
with less problems, to the customers greater satisfaction, etc.

And how many lines of code is TeX, Metafont, etc.  Do you count the
documentation?  But size isn't the issue here.  Quality is.  If the
customer wants it bad, that's how he's going to get it.

// marc
-- 
// home: marc@dumbcat.sf.ca.us		pacbell!dumbcat!marc
// work: marc@ascend.com		uunet!aria!marc

Re: chief programmer team organizations was (c++ vs ada results)

[Stanley Friesen]

In article <1066@dumbcat.sf.ca.us> marc@dumbcat.sf.ca.us (Marco S Hyman) writes:
>If one can imagine the system then one can build the system, just a little
>slower than two, or three.  But in any case faster than 100.  Every new person
>adds to the communications burden and increases the chance of a
>mis-communication causing something to be misunderstood.  Misunderstandings
>lead to defects and system failures.  I'd guess seven would be the top end,
>providing you have the right seven.  Three seems to be a good number in
>practice.

This certainly fits with my experience.

A few years ago I was working on a 'large' project (for another company).
We had a team of about 10-12 programmers on the project for most of its
run.  When we finally quit, 2 years behaind schedule, we had a system
that didn't really work, was almost unmaintainable and had at least twice
the code necessary to do the job.

If the team had been reduced to the three (or four) best programmers the
project would have been done, nearly on time, and certainly in a usable
form.  The additional 7-8 people just slowed it down (and reduced quality).
[This was an extreme case, and there were other problems - like changing
specs, but the man-power bloat just amplified the problems]
-- 
---------------
uunet!tdatirv!sarima				(Stanley Friesen)

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

>>I'd guess seven would be the top end,
>>providing you have the right seven.  Three seems to be a good number in
>>practice.

>This certainly fits with my experience.

>A few years ago I was working on a 'large' project (for another company).
>We had a team of about 10-12 programmers on the project for most of its
>run.  When we finally quit, 2 years behaind schedule, we had a system
>that didn't really work, was almost unmaintainable and had at least twice
>the code necessary to do the job.

Please define 'large'. This whole discussion hinges on what that term
means to various people.
-- 
*** 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++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

> > Tommyrot! How on earth is a single human being going to write "most",
> > or, for that matter, even a FRACTION, of the code on a project of
> > significant size? I'm talking here of things like the multi-MILLION
> > line FAA rewrite of the U.S. air traffic control system.

>If one can imagine the system then one can build the system, just a little
>slower than two, or three.

Look, this is just silly. Back of the envelope, I get 1MSLOC as something
like 4 million words to type (this is probably much too low, but let's
assume few comments and few identifiers per line), which, for a
60 wpm typist works out to 6 months of just TYPING. No thought, no design,
no documentation, no debugging, no test, no integration. Just six months
to TYPE that much code. How long do you think it would take for one human
being to actually write real code of that size? 20 years? How much code
have you written in your lifetime, in aggregate? What's the most working
documented code you've seen a single human being crank out in a year?

Modern software projects cannot be written by one person unless the
customer is willing to wait 20-40 years for delivery.

>Every new person
>adds to the communications burden and increases the chance of a
>mis-communication causing something to be misunderstood.  Misunderstandings
>lead to defects and system failures.  I'd guess seven would be the top end,
>providing you have the right seven.  Three seems to be a good number in
>practice.

This is the Mythical Man Month and all that, but it is not necessarily
true. The trick is to divide up the project into chunks (I call them
subsystems) that themselves CAN be implemented by small teams, and to
formally enforce the interfaces between the chunks. The trick then
becomes for an architect to know where to make the slices.
-- 
*** 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++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[John Nagle]

jls@netcom.COM (Jim Showalter) writes:

>>     Real chief programmer teams are very rare. I've never heard of one
>>other than in Brooks' book.

>Given your description below, I don't find this surprising, since I
>find it impossible. Read on.

>>It's organized like a surgical team.  The chief
>>programmer personally writes most of the delivered code, and everything else
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>is set up to facilitate this.

>Tommyrot! How on earth is a single human being going to write "most",
>or, for that matter, even a FRACTION, of the code on a project of
>significant size? I'm talking here of things like the multi-MILLION
>line FAA rewrite of the U.S. air traffic control system. No, what is
>needed is a single architect (or at least a very small number of
>architects on a tightly focused team) who set up the groundrules for
>the overall system. After that, a horde of implementors can hammer
>out the individual subsystems.

      There's a school of thought that if you're writing something that big,
your approach is wrong, and you need to develop some abstraction that makes
the job smaller and moves most of the specifics into some kind of database.

      But what Brooks was talking about was a job of the size of an
operating system kernel, a compiler, or a typical shrink-wrapped
application.  Many such jobs are something a single person could write
with adequate support; examples of each of the above written by individuals
exist.  There are also examples of each of the above written by large
teams, of course.  

      With respect to the FAA application, it's entirely possible that
the whole system will be obsoleted by something that has most of the
smarts in the airplanes, perhaps a successor to ACAS with GPS inputs.
Articles in Aviation Leak indicate that distributed systems are being
worked on, especially for Europe, where cross-border ATC isn't well
integrated.

				John Nagle

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

nagle@well.sf.ca.us (John Nagle) writes:

>jls@netcom.COM (Jim Showalter) writes:

>>I'm talking here of things like the multi-MILLION
>>line FAA rewrite of the U.S. air traffic control system.

>      There's a school of thought that if you're writing something that big,
>your approach is wrong, and you need to develop some abstraction that makes
>the job smaller and moves most of the specifics into some kind of database.

There's a school of thought that people who belong to the other school
of thought suffer from having never actually BUILT an air traffic control
system. ;-)

As far as developing abstractions that move the "specifics into some kind
of database", I find "some kind of database" to be rather vague. An air
traffic control system consists of a bewildering array of input sources
(e.g. various kinds of radar) with various signal processing requirements,
critical real time constraints, distributed heterogeneous networking,
and a host of other nasties. In short--they're COMPLICATED. And to top
it off, if they fail, people die. In large numbers. All at once.

It may seem surprising, but the folks that build these things actually
tend to be very bright, very motivated, and very concerned that they
do it correctly. They aren't boobs, and there's a REASON why the code
is big. They're not just writing code to write code. Whenever I hear
someone say that these systems are "too big", I'm reminded of the scene
in "Amadeus" where the emperor chides Mozart for using "too many notes",
to which Mozart replies "Which notes would you have me remove, Sire?".
Which lines of code would you have removed from an air traffic control
system? The display code that manages the screens? The error detection
and correction code? The code that interfaces with the various radars
and normalizes the incoming data? I'm sure there must be literally
hundreds of thousands of superfluous code in there somewhere...
-- 
*** 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++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[Christopher Warack]

In article <1991Jun25.183805.9549@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
>nagle@well.sf.ca.us (John Nagle) writes:
>>jls@netcom.COM (Jim Showalter) writes:
>>>I'm talking here of things like the multi-MILLION
>>>line FAA rewrite of the U.S. air traffic control system.
>
>>      There's a school of thought that if you're writing something that big,
>>your approach is wrong, and you need to develop some abstraction that makes
>>the job smaller and moves most of the specifics into some kind of database.
>
> ...
>
>is big. They're not just writing code to write code. Whenever I hear
>someone say that these systems are "too big", I'm reminded of the scene
>in "Amadeus" where the emperor chides Mozart for using "too many notes",
>to which Mozart replies "Which notes would you have me remove, Sire?".
>Which lines of code would you have removed from an air traffic control
>system? The display code that manages the screens? The error detection
>and correction code? The code that interfaces with the various radars
>and normalizes the incoming data? I'm sure there must be literally
>hundreds of thousands of superfluous code in there somewhere...

I agree with Jim here.  Yet there is even more to consider.  I found
that in building the satellite early warning system more support software
was needed than operational software.  The support software did things
like database maintenance (on top of a DBMS), analysis, system evaluation,
simulation, test support.  I'm sure that FAA has similar needs in these
areas.

Even the operational software can surprise you.  Our biggest chunk of 
code was spent in operator interfaces.  When you have a multi-person
interacting crew whose mistakes can be catastrophic, you're interfaces
need to be simple and powerful enough to do the job fast...  Another
area that adds lots of software throughout a system is dependability.
You can imagine the level of system dependability needed in an early
warning system -- it don't do much good if it isn't running.  I know
that the FAA requirements are orders of magnitude tougher.  To achieve
this level in a large distributed system requires lots of monitoring,
control and diagnostic software that itself must be reliable.

Multi-million lines of code systems don't surprise me at all.  But,
keep in mind that the software doing the primary function is only a 
fraction of the system.

-- Chris

Re: chief programmer team organizations

[John Baldwin]

John Nagle said in a previous post:

   JN> Real chief programmer teams are very rare. I've never heard of one
   JN> other than in Brooks' book.

   JN> It's organized like a surgical team.  The chief
   JN> programmer personally writes most of the delivered code,
   JN> and everything else is set up to facilitate this.


jls@netcom.COM (Jim Showalter) replied:

  JS> Tommyrot! How on earth is a single human being going to write "most",
  JS> or, for that matter, even a FRACTION, of the code on a project of
  JS> significant size? I'm talking here of things like the multi-MILLION
  JS> line FAA rewrite of the U.S. air traffic control system.


And finally,
In article <25649@well.sf.ca.us> nagle@well.sf.ca.us (John Nagle) writes:

>      But what Brooks was talking about was a job of the size of an
>operating system kernel, a compiler, or a typical shrink-wrapped
>application.


Actually, going back to Brooks' book, what he was talking about WERE
very large systems consisting of many software components.  I think
you are both right and are "looking at different parts of the same
elephant."

I believe the idea was to have a small committee consisting of a cross-
section of the Chief Programmers, who would be in charge of the
architecture of the ENTIRE system.  We all know (I hope) that big
committees never get any work done.  :-)

The entire system might be composed of 20 or more large modules.
For a mainframe's system software, a "large module" might be a
compiler, or the file system, or whatever.  (Case in point, I doubt
that the FAA system is one big executable or even as few as 20.)

The "architects" define the "grand vision" of the SYSTEM, not the
blocks.  They only ensure there is a consistent set of interfaces,
and that the work goes in the right direction.  The real work belongs
to the CPT's: One Team Per Module.  Thus, the chief writes most of the
code IN THAT MODULE.

The problems that can involve this dichotomy between the "architects"
and "the rest of the designers" might be more easily understood by
looking at the following example, also taken from Brooks as he talks
about "Big Oz," the OS/360 operating system, which took 5000 person-years
to develop....

The linker for this OS was the culmination of everything its designers
could possibly know about static overlay linking.  This is remarkably
funny, because the operating system could dynamically allocate system
memory and didn't need a linker with fancy overlay capabilities.  But the
linker team didn't know that, so they did all that work for nought,
and ended up with a linker that was slower than any of the compilers!





Followup's to comp.software-eng, where this really belongs.


-- 
John Baldwin              | johnb@searchtech.com
Search Technology, Inc.   | srchtec!johnb@gatech.edu
Atlanta, Georgia          | johnb%srchtec.uucp@mathcs.emory.edu

Re: chief programmer team organizations was (c++ vs ada results)

[George C. Harrison, Norfolk State University]

In article <25587@well.sf.ca.us>, nagle@well.sf.ca.us (John Nagle) writes:
>      Real chief programmer teams are very rare.  I've never heard of one
> other than in Brooks' book.  It's very different than having a lead programmer
> or a system architect.  It's organized like a surgical team.  The chief

> [etc.]

> 
>     It's too much of a culture shock for most organization.
> 
> 					John Nagle


Real life success stories are more than welcome to this Software Engineering
Teacher-type.  I've found that Brooks' book seems to place all teams in some
sort of Shangri-La, where managers are infinitely knowlegable and respect their
programmers, customers are always happy, etc.  

Do chief programmer teams really work anywhere outside of a university
classroom or in an experimental industrial setting?  

George C. Harrison, Professor of Computer Science
Norfolk State University, 2401 Corprew Avenue, Norfolk VA 23504
Internet:  g_harrison@vger.nsu.edu    Phone:  804-683-8654

Re: chief programmer team organizations was (c++ vs ada results)

[Harry Erwin]

g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University) writes:

>Do chief programmer teams really work anywhere outside of a university
>classroom or in an experimental industrial setting? 

We used a chief programmer team on some tasks on the Site Defense
Program in the mid-1970s at TRW. (This was the same program that
was the basis for many of Barry Boehm's results during the same
period. It seemed to work. 
-- 
Harry Erwin
Internet: erwin@trwacs.fp.trw.com

Re: chief programmer team organizations was (c++ vs ada results)

[Bob Martin]

In article <25587@well.sf.ca.us> nagle@well.sf.ca.us (John Nagle) writes:
>
>     Real chief programmer teams are very rare.  I've never heard of one
>other than in Brooks' book.  It's very different than having a lead programmer
>or a system architect.  It's organized like a surgical team.  The chief
>programmer personally writes most of the delivered code, and everything else
>is set up to facilitate this.  There is an administrator, who reports to the
>chief programmer, to take care of mundane problems.  A toolsmith creates
>tools not part of the deliverable code.  A language lawyer deals with
>compiler and library issues.  A tester tests everything.  A librarian 
>keeps track of everything.  All these people are subordinate to the chief
>programmer.
>
>    It's too much of a culture shock for most organization.
>
>					John Nagle
>    

Not to mention that it is impractical for one programmer to write the bulk
of the code required for today`s applications. 

One of the major problems in developing large projects is making sure that
everyone working on the project has the same 'vision' of what they are
building, and how they are going to build it.  This 'vision' spans concerns
which are as diverse as high-level architecture to coding standards to 
testing methodologies.  Providing this vision ought to be the job of 
the architect or a small group of architects.


-- 
+-Robert C. Martin-----+:RRR:::CCC:M:::::M:| Nobody is responsible for |
| rmartin@clear.com    |:R::R:C::::M:M:M:M:| my words but me.  I want  |
| uunet!clrcom!rmartin |:RRR::C::::M::M::M:| all the credit, and all   |
+----------------------+:R::R::CCC:M:::::M:| the blame.  So there.     |

Re: c++ vs ada results

[Jim Showalter]

>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++.    *

Re: c++ vs ada results

[Dan Weinreb]

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.

Re: c++ vs ada results

[Andrew Dunstan]

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  #                                 #
#######################################################################

Re: c++ vs ada results

[David Emery]

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

Re: c++ vs ada results

[Mats Henricson]

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

Re: c++ vs ada results

[Tom McClory]

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

Re: c++ vs ada results

[Jim Showalter]

>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++.    *

Re: c++ vs ada results

[Andrew Dunstan]

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  #                                 #
#######################################################################

Re: c++ vs ada results

[Jim Showalter]

>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++.    *

Re: c++ vs ada results

[Alex Blakemore]

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

Re: c++ vs ada results

[Jim Showalter]

>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++.    *

Re: c++ vs ada results

[Jim Showalter]

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++.    *

Re: c++ vs ada results

[CBW Consulting]

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

Re: c++ vs ada results

[Jim Showalter]

>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++.    *

Re: c++ vs ada results

[Dan L. Pierson]

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

Re: chief programmer team organizations was (c++ vs ada results)H

[Operator]

In article <1991Jun26.221811.5950@odi.com>, dlw@odi.com (Dan Weinreb) writes:
|> In article <1991Jun21.222536.18888@netcom.COM> jls@netcom.COM (Jim
Showalter) writes:
|> 
|>    If someone can provide me with an explanation for why junior
programmers
|>    should be making architectural decisions affecting the entire
project,
|>    I'm all ears.
|> 
1: Junior programmers are less experienced, not (necessarily) less
intelligent, less innovative,
less educated, or less resourceful.
1.1: Age has a fairly direct impact on beauty, but on brainpower no
strong correlation has been deomonstrated.

2: Junior programmers are (usually) closer to "fresh out of school" than
we, which means (in general)
2.1: their Profs taught them the solutions to the mistakes that our
Profs made teaching us
2.2: Their education is based on less obsolete hardware, software, and
engineering paradigms than ours
2.3: they are less resistant to learning a new method to solving the
problem at hand than the relativly more
crusted, wizened, and lofty senior.

3: Further embarrassments available upon request, but please keep in
mind that the "half life" of experience in
the computer engineering field is about 5 years. I.e. what you learned 5
years ago is loosing the last parts of its'
relavence now.

Brian (the Senior and student of the Juniors) Brunner