Comments on Ada vs. C++ panel

Comments on Ada vs. C++ panel

[Dag Bruck]

Last week there was a panel on Ada vs. C++ in Monterey.  Would anyone
who attended post a personal report on comp.lang.ada?

Thanks in advance.

Dag Bruck
--
Department of Automatic Control		E-mail: dag@control.lth.se
Lund Institute of Technology
P. O. Box 118				Phone:	+46 46-104287
S-221 00 Lund, SWEDEN			Fax:    +46 46-138118

Re: Comments on Ada vs. C++ panel

[Bob Kitzberger]

dag@bellman.control.lth.se (Dag Bruck) writes:

>Last week there was a panel on Ada vs. C++ in Monterey.  Would anyone
>who attended post a personal report on comp.lang.ada?

No, please don't!!!

	;-)
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
                        +1 619 457 2111    FAX +1 619 457 0888

Re: Comments on Ada vs. C++ panel

[Gregory Aharonian]

>>Last week there was a panel on Ada vs. C++ in Monterey.  Would anyone
>>who attended post a personal report on comp.lang.ada?

>No, please don't!!!

Yes, please do, especially if the panel discussed the economics aspects of
Ada and C++ market advocacy and policies vis-a-vis what is the best ways
to inevst(waste) tax dollars to push languages and mandates.

Greg Aharonian
Source Translation & Optimization
-- 
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178

Re: Comments on Ada vs. C++ panel

[agate!spool.mu.edu!uwm.edu!ogicse!psgrain!m2xenix!agora!robart]

>Yes, please do, especially if the panel discussed the economics aspects of
>Ada and C++ market advocacy and policies vis-a-vis what is the best ways
>to inevst(waste) tax dollars to push languages and mandates.
>
>Greg Aharonian
>Greg Aharonian


  This guy is quite biased.

Re: Comments on Ada vs. C++ panel

[John Bollenbacher]

Dag Bruck (dag@bellman.control.lth.se) wrote:
: Last week there was a panel on Ada vs. C++ in Monterey.  Would anyone
: who attended post a personal report on comp.lang.ada?
: 

Does anyone know whether there will be anything published from this event?

: Thanks in advance.

Ditto.

: 
: Dag Bruck
: --
: Department of Automatic Control		E-mail: dag@control.lth.se
: Lund Institute of Technology
: P. O. Box 118				Phone:	+46 46-104287
: S-221 00 Lund, SWEDEN			Fax:    +46 46-138118

--
-----------------------------------------------------------------------------
- John Bollenbacher                                        jhb@dale.cts.com -
- Titan Linkabit Corp.                                       (619) 552-9963 -
- 3033 Science Park Rd.                                                     -
- San Diego, Ca. 92121                                                      -
-----------------------------------------------------------------------------

Re: Comments on Ada vs. C++ panel

[Jack Beidler]

The Ada vs. C++ Panel at ASEET-7  was a good wrap up to a good 
conference.   Jerry Schwarz did a good job presenting the case
for C++.  Jerry was very honest about C++ and its C foundation.

On the other side, seeing RObert Dewar in action was a real treat.
I got the impression that Dewar knew more about C and C++ than
C and C++ programmers know about Ada.  No, let me rephrase that:
Dewar knows more about C and C++ than C and C++ programmers know
(or will admit they know) about C and C++. :-)
-- 
+------------------------------------------------------------------+
|  John (Jack) Beidler				                   |
|  Prof. of Computer Science Internet: BEIDLER@JAGUAR.UOFS.ED      |
|  University of Scranton              beidler@guinness.cs.uofs.edu|
|  Scranton, PA 18510	      Bitnet : BEIDLER@SCRANTON            |
|                                                                  |
|          Phone: (717) 941-7446	 FAX:   (717) 941-4250     |
+------------------------------------------------------------------+

Re: Comments on Ada vs. C++ panel

[Michael Hagerty]

DB> Last week there was a panel on Ada vs. C++ in Monterey.  Would anyone
  > who attended post a personal report on comp.lang.ada?

At the risk of offending those who foam up merely thinking of a comparison,
this is my view of what happened at the ASEET panel.

It was very tame, tame indeed.  One of the panelists was on the C++ standards
committee and admittedly was mostly ignorant of Ada-9X.  Hard to fault him
for that; when you are on a standards committee, the whole world begins to
narrow on down.  Nonetheless, he did a creditable job of presenting C++ and
a weak job of highlighting the warts on Ada/Ada-9X.

The criticisms of C++ were mostly of the variety, "C++ would be a really nice
language, IFF you could disable the user's ability to use C."  As most users
already know, this is the big downside to C++.  Unfortunately, the desired
ability to limit the use of C in C++ is not possible and thus the rivalry 
continues unabated.  

The interesting pitch for Ada was centered around the argument that Ada is
a superior language for software engineering as it supports most cleanly
these concepts.  It was interesting, as I said, but the pitch was delivered
only to the choir.

Regards, Mikey (michael.hagerty@nitelog.com)
---
 . MR/2 1.39x #63 . A processor is a terrible thing to share...
                                                           

Re: Comments on Ada vs. C++ panel

[fred j mccall 575-3539]

In <1009.237.uupcb@nitelog.com> michael.hagerty@nitelog.com (Michael Hagerty)  
writes:

>The criticisms of C++ were mostly of the variety, "C++ would be a really nice
>language, IFF you could disable the user's ability to use C."  As most users
>already know, this is the big downside to C++.  Unfortunately, the desired
>ability to limit the use of C in C++ is not possible and thus the rivalry 
>continues unabated.  

I'm curious about this.  Perhaps someone who agrees with this can
explain to me why a language restriction is better than, say, an
organizational policy restriction.  Personally, I would consider a
language that allows me to do things in special cases to be better
than one which does not, even if the 'things' are not necessarily a
good idea in the usual case.

[Let's try this one in Email -- I'm *NOT* interested in starting some
kind of language flamewar.  I'm simply honestly curious about the idea
that it is somehow 'better' for a language to restrict the developer
rather than for the developer to restrict himself or herself to good
practice while having the ability to step outside that for unusual
cases.]  

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: Comments on Ada vs. C++ panel

[david.c.willett]

>From article <1993Feb2.180552.5536@mksol.dseg.ti.com>, by mccall@mksol.dseg.ti
.com (fred j mccall 575-3539):
Original C++ discussion deleted.....

> explain to me why a language restriction is better than, say, an
> organizational policy restriction.  Personally, I would consider a
> language that allows me to do things in special cases to be better
> than one which does not, even if the 'things' are not necessarily a
> good idea in the usual case.
> 
> [Let's try this one in Email -- I'm *NOT* interested in starting some
> kind of language flamewar.  I'm simply honestly curious about the idea
> that it is somehow 'better' for a language to restrict the developer
> rather than for the developer to restrict himself or herself to good
> practice while having the ability to step outside that for unusual
> cases.]  
> 
> -- 
> "Insisting on perfect safety is for people who don't have the balls to live
>  in the real world."   -- Mary Shafer, NASA Ames Dryden
> -----------------------------------------------------------------------------
-

Fred,
	I'll take on your question, don't worry no language flamewar from here.
To me the question hinges on whether a language should "assist" the developer
or not.  It is much the same question as GUI vs. command interpreter interfaces
or automatic vs. manual transmissions.

	Generally, I'd prefer not to have the assistance, so I eschew GUI
interfaces, spreadsheets, and automatic transmissions.  However, there are
situations where I find such things useful.  If I'm doing a lot of 
"application hopping" being able to run 3..5 things in different windows
without having to type complicated command scripts is nice.  Spreadsheets
have their purpose in accounting work, but I generally prefer an "old 
fashioned" ledger form.  Automatics are better for city driving, which is
the kind I'm doing most of the time now.

	How does all this relate to languages?  What is "better" depends
on the kind of work you do.  If I have a one-to-four person-month project
which is isolated or well insulated from the rest of the world, I don't 
care which language is used.  Maintenance might become an issue but 
probably not for a while.

	At the other extreme is the 24-48 person-month effort which 
is central to a sophisticated system of software.  Here is where I'd 
want to make very sure that the techniques used were consistent and 
rigorous.  You suggest that ogranizational standards (may I infer
software management? ) could enforce such techniques so the language
doesn't have to.  I submit that compilers are better "enforcers" than
people.  They are consistent.  They are equitable.  They do not crack
under cost or schedule pressures.  The bottom line is that they are
generally better at the job.


-- 
Dave Willett          AT&T Federal Systems Advanced Technologies
attmail!dwillett      (AT&T FSAT)
If you think it's so !#$%^& easy, You try it!

Re: Comments on Ada vs. C++ panel

[att!cbnewsk!cbnewsj!att-out!walter!obry]

Fred,

> I'm curious about this.  Perhaps someone who agrees with this can
> explain to me why a language restriction is better than, say, an
> organizational policy restriction.  Personally, I would consider a
> language that allows me to do things in special cases to be better
> than one which does not, even if the 'things' are not necessarily a
> good idea in the usual case.

No flamewar here.

The answer could be : We need language restrictions because we are *only*
		      humans. And even with a strong policy restrictions
		      we can't be sure to stay in the straight line. And worst
		      we can't be sure that others would stay ...

So after while, how will you look at the software ?

Pascal.


Le plus important dans un language ce n'est pas ce qu'il permet c'est ce qu'il
interdit. J.P. Rosen (I'am not sure of the author)


--

-------------------------------------------------------------------------------
--  Pascal OBRY								     --
--  Room 2D-337				e_mail : obry@bellcore.com  	     --
--  Bellcore								     --
--  445 South Street			voice : 1 - 201 829 4039	     --
--  Post Office Box 1910		FAX   : 1 - 201 829 5981	     --
--  Morristown, New Jersey 07962-1910					     --
-------------------------------------------------------------------------------

  `` inheritance is surely a good answer, but who knows the question ? ''

Re: Comments on Ada vs. C++ panel

[usenet.ins.cwru.edu!howland.reston.ans.net!bogus.sura.net!darwin.sura.net]

In article <1009.237.uupcb@nitelog.com> michael.hagerty@nitelog.com (Michael Ha
gerty)  writes:

[stuff deleted]
>
>At the risk of offending those who foam up merely thinking of a comparison,
>this is my view of what happened at the ASEET panel.

I think everyone who was there would share your assessment.
>
>It was very tame, tame indeed.  One of the panelists was on the C++ standards
>committee and admittedly was mostly ignorant of Ada-9X.  Hard to fault him
>for that; when you are on a standards committee, the whole world begins to
>narrow on down.  Nonetheless, he did a creditable job of presenting C++ and
>a weak job of highlighting the warts on Ada/Ada-9X.

Right. I think he was in fact kinder to Ada than I would have expected,
especially given the flame wars on the net. Schwarz's comparison, in fact,
showed that Ada (especially Ada9X) and C++ really have more similarity
than they have difference. We tend to argue a lot about issues that are
really at the margin. He pointed out e.g. that even in the C++ world,
multiple inheritance is controversial and perhaps unnecessary for
most applications. Don't forget that Schwarz really comes from the
LISP/Scheme world, and so for him, comparing Ada and C++ is not really
that much of a comparison.
>
>The criticisms of C++ were mostly of the variety, "C++ would be a really nice
>language, IFF you could disable the user's ability to use C."  As most users
>already know, this is the big downside to C++.  Unfortunately, the desired
>ability to limit the use of C in C++ is not possible and thus the rivalry 
>continues unabated.  

Right. IMHO the rivalry is mostly unwarranted. The two languages are
similar enough that almost anything we want to do is possible (and,
probably, cost-effective) in either language. Many in the DoD world
are expending tremendous effort to circumvent the Ada mandate and use
C++. They will no doubt discover that the language was not the issue,
so they might better have devoted that energy to learning and using Ada.
>
>The interesting pitch for Ada was centered around the argument that Ada is
>a superior language for software engineering as it supports most cleanly
>these concepts.  It was interesting, as I said, but the pitch was delivered
>only to the choir.

ASEET had perhaps 100 attendees. Indeed the sermon was delivered to the
converted. Will there be such a panel at OOPSLA? The next OOPSLA actually
wants to emphasize Ada more, so here is the chance we've been waiting for
to make the congregation bigger.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans want the fruits of patience -- and they want them now."
------------------------------------------------------------------------

Re: Comments on Ada vs. C++ panel

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!csc.ti.com]

In <OBRY.93Feb3162044@cheesesteak.flash.bellcore.com> obry@flash.bellcore.com (
Pascal Obry) writes:


>Fred,

>> I'm curious about this.  Perhaps someone who agrees with this can
>> explain to me why a language restriction is better than, say, an
>> organizational policy restriction.  Personally, I would consider a
>> language that allows me to do things in special cases to be better
>> than one which does not, even if the 'things' are not necessarily a
>> good idea in the usual case.

>No flamewar here.

>The answer could be : We need language restrictions because we are *only*
>		      humans. And even with a strong policy restrictions
>		      we can't be sure to stay in the straight line. And worst
>		      we can't be sure that others would stay ...

>So after while, how will you look at the software ?

The same way I look at it now.  Well written and maintainable software
is well written and maintainable software.  Poorly written and
unmaintainable software is poorly written and unmaintainable software.
Either can (and probably has been and will again) be produced in
pretty much any language.  I simply don't see this as a convincing
argument. 

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: Comments on Ada vs. C++ panel

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall]

In <1993Feb3.055305.16347@cbnewsl.cb.att.com> willett@cbnewsl.cb.att.com (david
.c.willett) writes:

[Good analysis of potential reasons motivating language selection
deleted.] 

>	At the other extreme is the 24-48 person-month effort which 
>is central to a sophisticated system of software.  Here is where I'd 
>want to make very sure that the techniques used were consistent and 
>rigorous.  You suggest that ogranizational standards (may I infer
>software management? ) could enforce such techniques so the language
>doesn't have to.  I submit that compilers are better "enforcers" than
>people.  They are consistent.  They are equitable.  They do not crack
>under cost or schedule pressures.  The bottom line is that they are
>generally better at the job.

I see the better solution as simply not electing to 'crack' and
deciding that quality and well-engineered software are more important
than 'schedule crunch'.  Difficult in the real world, to be sure, but
more and more organizations seem to be coming around to this point of
view.  Other than that, it seems to me that a good up-front design
would meet most of the requirements you've listed.  After all, that's
why we do modular software, abstraction, and all those other good
things, right?  To get the pieces of the problem down small enough so
that they are back in that category of "small and well-insulated from
the rest of the world".  

Once you have that kind of design and have specified the interfaces
between the pieces, you're back out of the realm described above.  Of
course, Ada makes it much more difficult to 'hack' out a solution, and
so encourages all that up-front work that a good engineer should be
doing anyway, but I'm not convinced that that is sufficient
justification for mandating its use or for feeling that other
languages are so unsuitable (which is where this sort of started
from).  

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.