Re: c++ vs ada results

Re: c++ vs ada results

[Fred Stluka]

In article <1991Aug13.142900.28910@slcs.slb.com> cornish@slcs.slb.com (Darryl C
ornish) writes:
> Grady Booch converted the Booch Ada Component Library from ADA to C++.
> The result was thaty 150,000 lines of ADA became 20,000 lines of C++. 
> 
> While smaller is not necessarily better, this does give one cause to
> wonder at the logic of people (e.g., the DOD) who make decisions on 
> the fact that ADA programmers produced 30% more lines of code / month 
> than C++ programmers.

This comparison requires some context.

The Booch parts are a small collection of FAMILIES of related parts.
That is, there are dozens of variations on the implementation of a 
stack, dozens of queues, etc.  This is exactly the kind of code which
can benefit MOST by inheritance (one of C++'s admitted strengths over 
Ada).  It would be hard to contrive a 150,000 line example which was 
less suited to Ada and more suited to C++.  

Based on the huge amount of duplication in the Booch parts, I am 
surprised that the reduction was only a factor of 7.5.

It is unreasonable to extrapolate from this single figure when 
discussing complete software systems.

--Fred
-- 
Fred Stluka                               Internet: stluka@software.org
Software Productivity Consortium          UUNet:    ...!uunet!software!stluka
2214 Rock Hill Rd, Herndon VA 22070 USA   Voice:    (703)742-7236

Re: c++ vs ada results

[Ma ts Henricson]

emery@Dr_No.mitre.org (David Emery) writes:

>Where I work, 100k SLOC is a small program, 1-2m SLOC is average, and
>a really big program might have 5-10m SLOC.  Ada is making a
>difference in programs of this size (e.g. AFATDS, CCPDS-R,
>STANFINS-R).  I've not heard of similar-sized C++ programs.

Of what I know, Mentor Graphics holds the record in the C++ industry.
But, then again, I may be wrong... ;-) Unfortunately, I don't know
exactly how large their system is.

Mats Henricson

Re: c++ vs ada results

[David Emery]

The Booch Components ARE NOT a complete system.  There has been some
debate over whether the C++ components achieve the same level of
functionality as the Ada components, i.e.  is there a C++ component
for every Ada component.  

I would be very surprised if the Booch Components did not shrink in
SLOC when coded in C++.  They were designed using that kind of
object-oriented paradigm.  But, real systems consist of a lot more
than little data structure components.  

Where I work, 100k SLOC is a small program, 1-2m SLOC is average, and
a really big program might have 5-10m SLOC.  Ada is making a
difference in programs of this size (e.g. AFATDS, CCPDS-R,
STANFINS-R).  I've not heard of similar-sized C++ programs.  What I
have heard is that large C++ programs, particularly those developed by
different groups of people, and integrated, tend to fall apart when
something goes wrong in the inheritance heirarchy.  In particular,
trying to find out "whose method is this?" in a very large, complex
C++ program is damned hard.

By the way, if Darryl Cornish thinks that software is "finally
discovering the architect/engineer/trades-person paradigm" just now,
then he has missed much of the discussions in software engineering
over the last 50 years, both theoretical work (e.g. Chief Programmer
Teams) and practical experience.  Read "The Mythical Man-Month", and
then come back and say that architect/engineer/trades-person is a new
idea for software...

				dave

Re: c++ vs ada results

[Doug Smith]

In article <1991Aug15.154021.24043@cats.com> andy@cats.com (Andy Davidson) writ
es:
> In article <1991Aug14.182554.16576@software.org> smithd@software.org (Doug Sm
ith) writes:
> >
> >It is possible to take an algorithmic approach to building these
> >utilities.  This creates a smaller library of generics that provide the

> What exactly do you mean by an "algorithmic approach"? Do you mean a
> structured design approch?? Can you elaborate on your statement
> 
(I don't think this is structured design, you be the judge...)

Since several people have asked for more information...

There is a published work that you can reference:

    The Ada Generic Library
        Linear List Processing Packages
    Musser & Stepanov
    Springer-Verlag 1989

An example that comes to mind is the usual sort generic:

    generic
        type Element is private;
        type Index is (<>);
        type Arrays is array (Index range <>) of Element;
        with function "<" (Left, Right : Element)
                           return        Boolean;
    procedure Sort (Arr : in out Arrays);

I consider this the usual data structure oriented approach.  Which is
a conventient form, but should be built on top of a more general
sorting algorithm:

    generic
        type Element is limited private;
        type Index is (<>);
        type Arrays is array (Index range <>) of Element;
        with function "<" (Left, Right : Element)
                           return        Boolean;
        with procedure Swap (Left, Right : in out Element);
    procedure Sort (Arr : in out Arrays);

Which could be built on another, even more general sorting algorithm:

    generic
        type Index   is (<>);
        with function Element_Is_Less_Than
                          (Left, Right : Index)
                           return        Boolean;
        with procedure Swap (Left, Right : in     Index);
    procedure Sort (From, To : in     Index);

And then I would even try to make Index limited private, but that
gets messy, and you get the idea.  When you get down to the actual
algorithm, you will have declared the assumptions that the algorithm
makes as part of the declaration.

So if you can describe the Quick_Sort algorithm using only limited
private types, and for a binary tree you have a way of partitioning
the tree, moving elements, comparing elements, etc.--then you have
an efficient sort that works both on arrays and binary trees.

Re: c++ vs ada results

[Andy Davidson]

In article <1991Aug14.182554.16576@software.org> smithd@software.org (Doug Smit
h) writes:
>
>There are several ways that the Booch Components use generics that
>create an excessive amount of code.  As an early attempt to use generics
>for a library of reusable code, they have stood up very well.  But
>as an example of what can be accomplished with generics, they are
>slightly dated.
>
>As relates to this thread, there is excessive duplication of code to
>handle the same algorithms.  For example, several of the generics that
>use linked list implement traversing, constructing, etc. similarly.
>
>It is possible to take an algorithmic approach to building these
>utilities.  This creates a smaller library of generics that provide the
>same capabilities.  If my memory serves, a conservative estimate was a
>reduction from 1000+ to about 150 generic packages.  I would also
>predict an increase in the number of utilities that could be constructed
>from the 150 generics.
>
>Although I did not attempt to convert the Booch library to an
>algorithmic approach, I did build a memory management library which
>consisted of 8 packages (2 + 3 + 3) that could construct 18 (2 * 3 * 3)
>utilities.  They were used on a project and worked fine.

What exactly do you mean by an "algorithmic approach"? Do you mean a
structured design approch?? Can you elaborate on your statement

	"It is possible to take an algorithmic approach to building these
	utilities.  This creates a smaller library of generics that provide the
	same capabilities."

Thanks in Advance Andy
-- 

-----------------------------------------------------------------
                 "bede-bede-bede Thats all Folks"
                            Porky Pig

Re: c++ vs ada results

[Paul Baker - CTA]

Since Booch hasn't joined this thread, let me pass along some
rumors/disinformation about the two sets of Booch components.

The dramatic reduction in code size between the Ada and C++ versions
requires using both inheritance and a home-brew template mechanism.
The C++ results, while they appear dramatic, do not represent portable
C++ code.  They uses Booch's intrepretations of the next revision of
C++.  The Ada components are portable.  A fair comparison would be
to contrast the next version of C++ with Ada9X.  The current version
of C++ wouldn't handle this problem at all well.

I do believe, however, that the reduction in size is a true measure of
the value of inheritance as a code reuse mechanism.  The question is,
is inheritance the best mechanism?  Generative reuse may be more
effective and its code easier to maintain.

plb

Re: c++ vs ada results

[Jim Showalter]

smithd@software.org (Doug Smith) writes:

>As an early attempt to use generics
>for a library of reusable code, they have stood up very well.  But
>as an example of what can be accomplished with generics, they are
>slightly dated.

The C++ version benefitted from several years of 20-20 hindsight.
What would be interesting to me would be for the Ada version to
be rewritten using everything that has been learned about Ada
and C++ in those years, and _then_ comparing them.

I concede, however, that the result is still unlikely to be as
dense as the C++ version, precisely because of the lack of inheritance.
Consider, for example, what happens when you try to implement a
singly-linked list generic and a doubly-linked list generic: since
the data structures are fundamentally different, you wind up having
to write two different packages even though they are quite similar in
a variety of ways.

On the other hand, this still isn't a truly fair comparison. The
C++ version exploits both inheritance and genericity ("templates")
to achieve its density. The Ada version has only genericity at its
disposal, and so naturally comes up short (well, long--but you know
what I mean). But consider this: many of the people who extoll the
virtues of inheritance do so without taking genericity into account.
My guess is that the C++ version written with inheritance but not
templates would be about as cumbersome as the Ada version written
with genericity but not inheritance. And I also think that both
versions would be about the same size (within a small constant
attributable to syntactical differences and naming conventions) if
they were both written using inheritance and genericity. In sum,
I think both of these features are important to a language.
-- 
* Jim Showalter, software engineering consultant *
*         e-mail: jls@netcom.com                 *
*         voice : (408) 243-0630                 *
*         data  : (408) 984-5019                 *

Re: c++ vs ada results

[Doug Smith]

In article <1991Aug14.182554.16576@software.org> smithd@software.org (Doug Smit
h) writes:
> In article <1991Aug14.050358.19787@beaver.cs.washington.edu> mfeldman@june.cs
.washington.edu (Mike Feldman) writes:
> > In article <1991Aug13.142900.28910@slcs.slb.com> cornish@slcs.slb.com (Darr
yl Cornish) writes:
> > >
> 
> It is possible to take an algorithmic approach to building these
> utilities.  This creates a smaller library of generics that provide the
> same capabilities.  If my memory serves, a conservative estimate was a
> reduction from 1000+ to about 150 generic packages.  I would also
> predict an increase in the number of utilities that could be constructed
> from the 150 generics.

Well, I finally found an old copy of the paper, and my age has warped
my memory.  The number of Booch components is 501 (not 1000+), and the
prediction was that only a "few dozen" generics would be needed if the
algorithmic approach was used.

Additionally, the memory management utilites consisted of 7 (3 + 2 + 2)
generic packages that implemented 12 (3 * 2 *2) utilities.  It should
still be obvious how powerful the approach is as the number of generics
increases.

Please send your flames directly to me.  I deserve them for not checking
the facts first.

Re: c++ vs ada results

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!utgpu!]

In article <1991Aug14.144129.6334@software.org>, stluka@software.org (Fred Stlu
ka) writes:
|> In article <1991Aug13.142900.28910@slcs.slb.com> cornish@slcs.slb.com (Darry
l Cornish) writes:
|> > Grady Booch converted the Booch Ada Component Library from ADA to C++.
|> > The result was thaty 150,000 lines of ADA became 20,000 lines of C++. 
|> > 
|> > While smaller is not necessarily better, this does give one cause to
|> > wonder at the logic of people (e.g., the DOD) who make decisions on 
|> > the fact that ADA programmers produced 30% more lines of code / month 
|> > than C++ programmers.
|> 
|> This comparison requires some context.
|> 
|> The Booch parts are a small collection of FAMILIES of related parts.
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yes, but that's what you get in a typical application
(in my own experience 4 years of C++) coded using OO principles.

|> ...

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

[Doug Smith]

In article <1991Aug14.050358.19787@beaver.cs.washington.edu> mfeldman@june.cs.w
ashington.edu (Mike Feldman) writes:
> In article <1991Aug13.142900.28910@slcs.slb.com> cornish@slcs.slb.com (Darryl
 Cornish) writes:
> >
> >Grady Booch converted the Booch Ada Component Library from ADA to C++.
> >The result was thaty 150,000 lines of ADA became 20,000 lines of C++. 
> >
> 
> Also I wonder if coding style made any difference. Perhaps Booch adopted a
> more concise style in the C++ version. I have not seen the C++ version.
> Booch's Ada components are, IMHO, rather excessively verbose, especially
> as to extra-long names, which of course make the total LOC higher.
> 
> I don't want to get into language wars here, just to be certain we are
> comparing the versions on a level playing field. Assuming that there were 
> inherent aspects of C++ that allowed more concise coding - and not just a
> different lexical convention, for example - then it would be interesting
> to know what these aspects were. Maybe Grady will respond himself?
> 
> Mike

There are several ways that the Booch Components use generics that
create an excessive amount of code.  As an early attempt to use generics
for a library of reusable code, they have stood up very well.  But
as an example of what can be accomplished with generics, they are
slightly dated.

As relates to this thread, there is excessive duplication of code to
handle the same algorithms.  For example, several of the generics that
use linked list implement traversing, constructing, etc. similarly.

It is possible to take an algorithmic approach to building these
utilities.  This creates a smaller library of generics that provide the
same capabilities.  If my memory serves, a conservative estimate was a
reduction from 1000+ to about 150 generic packages.  I would also
predict an increase in the number of utilities that could be constructed
from the 150 generics.

Although I did not attempt to convert the Booch library to an
algorithmic approach, I did build a memory management library which
consisted of 8 packages (2 + 3 + 3) that could construct 18 (2 * 3 * 3)
utilities.  They were used on a project and worked fine.

Re: c++ vs ada results

[Mike Feldman]

In article <1991Aug13.142900.28910@slcs.slb.com> cornish@slcs.slb.com (Darryl C
ornish) writes:
>
>Grady Booch converted the Booch Ada Component Library from ADA to C++.
>The result was thaty 150,000 lines of ADA became 20,000 lines of C++. 
>
First a bit of pedantry: please spell it Ada, not ADA.

Second, the Ada version of the Booch components has both sequential and
concurrent versions of each component; the concurrent version serializes
all method calls. This probably accounts for a fair number of the "extra"
lines. Does the C++ version take account - somehow - of a concurrent
environment?

Also I wonder if coding style made any difference. Perhaps Booch adopted a
more concise style in the C++ version. I have not seen the C++ version.
Booch's Ada components are, IMHO, rather excessively verbose, especially
as to extra-long names, which of course make the total LOC higher.

I don't want to get into language wars here, just to be certain we are
comparing the versions on a level playing field. Assuming that there were 
inherent aspects of C++ that allowed more concise coding - and not just a
different lexical convention, for example - then it would be interesting
to know what these aspects were. Maybe Grady will respond himself?

Mike


Mike

Re: c++ vs ada results

[David Emery]

>Grady Booch converted the Booch Ada Component Library from ADA to C++.
>The result was thaty 150,000 lines of ADA became 20,000 lines of C++. 
Since C++ has no expression of concurrency, I strongly suspect that a
lot of the "code reduction" comes from not having to duplicate all of
the tasking variants of the Booch Components.  

Also, the Booch Components are NOT a complete system.  They're the
type of things (common data structures, etc) where C++ _should_ be
powerful.  That's the easy stuff in an application.  Unfortunately,
real systems tend to have a lot of algorithmic and concurrency stuff
that gets in the way of these kinds of designs, not to mention
large-scale structural and architectural issues.

I think it would be very interesting to compare "systems" and not just
"components".  There's some of that (although you may find the data
suspect because of the source) in the Ada vs C++ study that has
recently come out.

				dave emery
				emery@dr_no.mitre.org

Re: c++ vs ada results

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!qt.cs.utexas.edu!cs.utexas.e]

In article <EACHUS.91Jun20145614@largo.mitre.org>, eachus@largo.mitre.org (Robe
rt I. Eachus) writes:
|> 
|> In article <1991Jun20.140836.24430@scrumpy@.bnr.ca> stevej@bnrmtl.bnr.ca (St
eve 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 cowhenatmmitted 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...


Have you tried to architect a large propram with C++. 

Grady Booch converted the Booch Ada Component Library from ADA to C++.
The result was thaty 150,000 lines of ADA became 20,000 lines of C++. 

While smaller is not necessarily better, this does give one cause to
wonder at the logic of people (e.g., the DOD) who make decisions on the fact th
at ADA programmers produced 30% more lines of code / month than C++ programmers
.

There are things in C++ that I don't like but overall it is a useful
tool. It can definitely be used as a vehicle for the implementation of
large projects with a few architects, a few more engineers, and a large
number of programmers.

It is interesting that we are finally discovering the architect/engineer/
trades-person paradigm for large project management. This paradigm has
been used successfully for around 4000 years in the construction industry,
although 4000 years ago the trades people were called slaves....I guess
things really don't change.

djc
//---------------------------------------------------------------------
E-Mail address:
internet	cornish@slcs.slb.com
Sinet		slcs::cornish

Mail address:
Schlumberger Laboratory for Computer Science
8311 North RR 620
PO Box 200015
Austin, TX, 78720-0015
Att'n: Darryl Cornish

Phone: (512) 331-3787

//---------------------------------------------------------------------

Re: c++ vs ada results

[Andrew Dunstan]

In article <1991Jun26.224737.16660@netcom.COM>, jls@netcom.COM (Jim
Showalter) writes:
|> >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.
|> 

I did have a smiley, Jim! Long package names I grant you, but I do find
names like of_the_set a bit annoying. Just a matter of taste, I guess.

While we are on this subject, Booch says that he rarely uses USE clauses,
because they "pollute the name space". I routinely use USE, and find that 
it makes the code more readable. Using qualified names all the time is a
pain in the neck.

Neither of these considerations would make me refrain from using Booch's
components.

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

Ok, what follows is subject to the following caveat:
   I think Booch's book and components are valuable resources. There is a
   lot we can learn from them about good ways of doing things.

It was a while since I looked at the book, and then I did not do any analysis
of it, but gathered impressions. So when I saw your posting I went and got
a copy of the book and looked at it over the weekend. Here are some thoughts.

The stuff on conceptually linear structures (lists, stacks, queues, rings, 
strings) I generally have no quarrel with. Maps, Sets and Trees, however, are 
more problematical. I generally think of sets in functional terms. 
Hence, my sets package has union, intersection, set-difference etc. as
functions returning sets. Similarly for maps, (which are really binary
relations). When I was working last year on binary relations, I looked
at Booch's maps packages and decisded that they did not do what I
needed. Here is a piece of code from a program that used the package that I
eventually wrote (It works out the Director Symbol sets for the productions
in a grammar):
  DirSet :=
  --    the follow set of the left hand side if there is no right hand side,
         Rules*Null_Rule*pred*G*FOLLOW
  -- or the first set of the leftmost symbol,
      or Rules*succ*LeftMost*G*FIRST
  -- or the follow set of the lhs if the right hand side is only one nullable
  -- symbol
      or Rules*succ*LeftMost*Nullable*RightMost*pred**2*G*FOLLOW
  -- or the first set of the symbol following the leftmost symbol if the 
  -- leftmost is nullable, etc
      or Rules*succ*LeftMost*(+(Nullable*Next))*G*FIRST
  -- or the follow set of the lhs if the right hand side is completely nullable
      or Rules*succ*LeftMost*(+(Nullable*Next))*Nullable*RightMost*(+Prev)*
         Leftmost*pred**2*G*FOLLOW;

All the objects here are binary relations. "*" means relation composition and
unary "+" means relation closure.

Booch's maps tools do not provide these operations. Worse (from my point of 
view), if he did provide them it would be via procedure calls rather than 
function calls. This involves a serious limit on the expressiveness given by
his components.

I know (at least I think I know) why he has done it this way. It is safer
to do it like this, and so the managed forms will have the same interface
as the unamanaged forms. (I was dealing with the equivalent of his
sequential_unbounded_unamanaged forms). But the safety and uniformity
come at a high price. The loss of expressive power is not small.

What happens here? You can quickly accumulate MASSIVE amounts of garbage.
Ok, then, let's get better (existant?) garbage collectors instead of
doing things in a less than intuitive way.

There is also a problem in the level of abstraction applied. I use trees
quite a bit, but usually as a representation of something else (a set
for example). In fact Booch's first example of a tree in his chapter on trees
is of something that is not conceptually a tree at all: it is a bag (strictly
an ordered bag). Now there is nothing wrong in using an ADT at one level as
the representation of an ADT at another level, but it is a pity that Booch did
not give an example of a tree as an ADT instead of using it to represent
something else.

Lastly, the SWAP operation in some of these components (e.g. trees) is a bit
odd. Yes, I have read your defence of them in later mail, but this seems to me
to miss the point a bit. An ADT interface should be independent of safety and
management considerations, as far as possible. 

I hope this is enough elaboration for you! 

p.s. like you, I am an Ada fan.

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

[Ray Diederich, 301-294-8400]

In INFO-ADA Vol.91, #181, pyrdc!grebyn!cbw@uunet.uu.net (Chuck Williams)
writes:

>It shows that c++ is cheaper than Ada.  There are a few other factors
>that need to be examined.  First the results of the study are derrived
>from a small number of c++ project and most of them are in the
>telecommunications domain.  Second, the learning curve to go from c to
>c++ is much shorter and easier than that for COBOL, Fortran, etc. to
>Ada.

and in INFO-ADA, Vol. 91, #183, netcomsv!jls@decwrl.dec.com (Jim Showalter)
replies:

>A much more valid comparison, I think, would be the learning curve to
>go from C to C++ vs the learning curve to go from Pascal to Ada.

I disagree. Sure it's easy to go from Pascal to Ada, but is anyone really
doing any Pascal programming? If the future Ada programmers are the current
Pascal programmers, there won't be many Ada programmers in the future. On
the other hand, the future C++ programmers are _likely_ to be the current C
programmers, and there seems to be an awful lot of C programmers.

So the valid consideration is still between C->C++ and COBOL/FORTRAN->Ada,
and I think that Chuck's original point is that this comparison unfairly
favors C++. The results of the original report are skewed, because it only
shows short-term gains.

Ray Diederich
GTE Government Systems Corporation
Electronic Defense Sector
National Center Systems Organization
========================================
My employer would prefer that I had no opinions to express, especially any
that may have been expressed here.
========================================

Re: c++ vs ada results

[Chuck Shotton]

In article <1991Jun26.221313.5872@odi.com>, dlw@odi.com (Dan Weinreb) writes:
> However, anecdotal data such as "We did some projects, and we did them
> in Ada, and they went very well" does not provide experimental
> evidence that those same projects would have gone significantly less
> well had they been done in some other language, with everything else
> being equal.
> 
> 
Likewise, yours is not an argument for doing the projects in a language other
than Ada.

> It's very difficult, in general, to produce real evidence that would
> help to significantly support or deny claims about how choice of
> language affects the course of a software project, mainly because it's
> so hard to assure that all else is equal, and because it would be so
> expensive.

I can give you plenty of "evidence" relating the difference between a C project
and Ada project, both of which addressed the same problem space, resulted
in similar solutions, and were staffed by similar numbers of experienced people. I can
tell you from first hand experience that in every measure, the Ada task outperformed
the C task. If you'd like more details, please reply in e-mail, as this topic
has veered far astray from comp.lang.ada.

-----------------------------------------------------------------------
Chuck Shotton                 Internet:  cshotton@girch1.med.uth.tmc.edu
BIAP Systems                  UUCP:      ...!buster!brain!chuck
"Your silly quote here."      AppleLink: D1683       MacNet: shotton

Re: c++ vs ada results

[ryer]

At the WAdaS conference this week, Lloyd Moseman, the Air Force Ada Executive
Official, announced that a comprehensive Ada vs C++ study had been done,
and would be available soon.

Mike "If I had more details, I would already have posted them" Ryer
Intermetrics

Re: c++ vs ada results

[ryer]

Further Information on DOD Ada vs. C++ report:

   The Air Force says they will hold a press conference and announce the 
   availability of the Ada/C++ report within the next 30 days; the Ogden 
   Air Logistics Center STSC's CROSSTALK will describe how to get a copy.  

Mike Ryer 
Intermetrics

Re: c++ vs ada results

[Chuck Shotton]

In article <1991Jun20.140836.24430@scrumpy@.bnr.ca>, stevej@bnrmtl.bnr.ca (Steve Juneau) writes:
> Was all this achievable because you used Ada, or can have be done with
> any language?  IMHO it can be done with any language.
> 

Please spare us. Automata Theory 101 teaches us that a Finite State Automaton
can solve any deterministic computing problem. Let's just toss programming
languages altogether.

The point is that Ada provides facilities in the language that support modular
design, consistent implementation, and most of all support integration and
test activities. Freed from the logistics of engineering and implementing
a system, Ada developers can actually concentrate more on the task at hand
instead of the mechanics of integrating a system. And, you CAN'T do that with
just any language.

As an aside, the religous wars (discussions) here over "my language is bigger
than your language" really don't appear to come to any constructive end. Do
they ever die down, or is the news group actually just a place for Ada weenies
to beat their chests? 

-----------------------------------------------------------------------
Chuck Shotton                 Internet:  cshotton@girch1.med.uth.tmc.edu
                              UUCP:      ...!buster!brain!chuck
"Your silly quote here."      AppleLink: D1683       MacNet: shotton

Re: c++ vs ada results

[Thomas M. Breuel]

In article <0D010010.63iouh@brain.UUCP> chuck@brain.UUCP (Chuck Shotton) writes:
   The point is that Ada provides facilities in the language that support modular
   design, consistent implementation, and most of all support integration and
   test activities. Freed from the logistics of engineering and implementing
   a system, Ada developers can actually concentrate more on the task at hand
   instead of the mechanics of integrating a system. And, you CAN'T do that with
   just any language.

Both C++ and Ada provide the facilities necessary for "modular design,
consistent implementation, ...". The difference is that Ada enforces
them more strongly, while C++ does not.

Depending on your applications, this can be an advantage or a
disadvantage. In many settings, it is probably the case that the
increase in time required to write some program because of the
inconvenient restrictions that Ada imposes (compared with C++) is
more than made up for by the fact that it enforces consistency
and has better error detection. However, to claim that Ada
"frees you" of anything is probably wrong. Scheme "frees" you,
anything else restricts you in various ways that may or may
not be good for you.

					Thomas.

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

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