C++ vs. Ada -- Is Ada loosing?

C++ vs. Ada -- Is Ada loosing?

[happy.colorado.edu!srheintze]

There are a lot of people out there who think C++ is the greatest thing since
sliced bread.  C++ is a truly wonderful toy because you can redefine the
language for your application.  

For example you can provide the function that is invoked in response to
assignment so you can optimize your matrix class to (1) only pass a pointer to
the matrix data instead of actually making a physical copy and (2) defer the
actual copy operation to the point in time when (and if) the target of the
assignment is modified.  This is impressive.

HOWEVER, please read "A dynamic Vector is harder than it looks" from the June
1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5 no 4. 
*THIS ARTICLE IS SCARY*  Basically Tom Cargill pointed out a bug that nearly
all C++ textbooks have made when they implement a dynamically sized array. 
This includes the textbook written by the implementor of the AT&T Cfront
compiler (will I get in trouble if I mention his name?).  If the language is so
convoluted that even the experts (including the compiler writers) cannot get
their simple textbook examples correct, then I conclude there is something
drastically wrong with the language.

I don't want anybody writing code in C++ for satellites funded with my tax
dollars!

I heard a rumer about a multi-million (or multi-billion) dollar satellite going
astray because some one left a comma out of a FORTRAN DO loop and it was still
syntactically legal.  Can anybody give me a reference on this?  

So we have C++ with very similar problems to this problem in FORTRAN that (I
believe, correct me if I am wrong) Ada was supposed to solve. You can insert a
";" between the ")" and the "{" in any while or if statement and the C++
program is still syntactically correct but semantically disasterous.

So, Ada was on the seen.  I spent some significant time as a project lead with
Ada in '89-90.  I was excited about the language.  Now I am independent and
make my living with C++.  

Where is Ada going?  Is it dying? That thread on "Is GNU-Ada self-insulting"
suggests that Ada is floundering. How badly is Ada floundering? Does that mean
I'll never see inheritance in Ada?

			Thanks,
				Sieg

Re: C++ vs. Ada -- Is Ada loosing?

[Kurt Olender]

srheintze@happy.colorado.edu writes:

   ... stuff deleted ...

   HOWEVER, please read "A dynamic Vector is harder than it looks" from the
   June 1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5
   no 4.  *THIS ARTICLE IS SCARY* Basically Tom Cargill pointed out a bug that
   nearly all C++ textbooks have made when they implement a dynamically sized
   array.  This includes the textbook written by the implementor of the AT&T
   Cfront compiler (will I get in trouble if I mention his name?).  If the
   language is so convoluted that even the experts (including the compiler
   writers) cannot get their simple textbook examples correct, then I conclude
   there is something drastically wrong with the language.


Well, without making any statements about the relative merits of Ada and C++,
I don't think you can make much real hay out of this fact.  After all, legend
has it that that it was 10 years from the first publication of a binary search
algorithm to the first publication of a correct binary search algorithm.
Perhaps it only says that we're not really good at these things, until we've
done them a few (dozens, hundreds, thousands?) of times.

Re: C++ vs. Ada -- Is Ada loosing?

[Mark A Biggar]

In article <1992Dec4.141816.1@happy.colorado.edu> srheintze@happy.colorado.edu 
writes:
>Where is Ada going?  Is it dying? That thread on "Is GNU-Ada self-insulting"
>suggests that Ada is floundering. How badly is Ada floundering? Does that mean
>I'll never see inheritance in Ada?
>				Sieg

But, Ada already has inheritance.  That's what derived types provide.  What
Ada doesn't currently have are type extension and dynamic dispatching, Both
of which are being added to Ada9x.

--
Mark Biggar
mab@wdl1.wdl.loral.com

Re: C++ vs. Ada -- Is Ada loosing?

[news]

In article <1992Dec4.141816.1@happy.colorado.edu>, srheintze@happy.colorado.edu
 writes:

[...is Ada losing?...]

No.  It LOST.  You've simply got your tense wrong.


-- 
Ted Holden
HTE

Re: C++ vs. Ada -- Is Ada loosing?

[Gregory Aharonian]

   The question shouldn't be so much that "Is Ada loosing?", but rather

"Can a language nurtured in a socialist environment (Ada) compete with
a language nurtured in a free market environment (C/C++)?"  

Note this shifts the argument (as I have been long arguing, apparently to
myself) away from language syntax and semantics, and towards language
socioeconomics.

Posed this way, one answer would be that "Ada started in at most fourth
place (after Cobol, Fortran, and C/C++) and will never catch up".

C/C++ is an imperfect language that thrives because its flaws creates
markets for software tools that create more use of the language and more
tools, etc., resulting in a thriving market. (One of the early claims of
some Ada vendors was that you didn't need many software tools to use Ada.)
C/C++ is an open language, constantly being debated, as well as its
environments and methodologies, subject to the evolutionary forces of the
free markets.  Ada is hostage to a bureacracy that suppresses criticism
and ignores free markets.

Thus, if you had money to invest in a software company, would you do it
for Ada or C/C++?

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

Re: C++ vs. Ada -- Is Ada loosing?

[Dag Bruck]

In <comp.lang.ada> srheintze@happy.colorado.edu writes:
>
>HOWEVER, please read "A dynamic Vector is harder than it looks" from the June
>1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5 no 4. 
>*THIS ARTICLE IS SCARY*  Basically Tom Cargill pointed out a bug that nearly
>all C++ textbooks have made when they implement a dynamically sized array. 
>This includes the textbook written by the implementor of the AT&T Cfront
>compiler (will I get in trouble if I mention his name?).  If the language is s
o
>convoluted that even the experts (including the compiler writers) cannot get
>their simple textbook examples correct, then I conclude there is something
>drastically wrong with the language.

I agree that Tom Cargill wrote an interesting article, but I think the
conclusion is exactly what Cargill writes: a dynamic vector class is
harder than it looks.

People sometimes fall into the trap of thinking that hard problems are
easier to solve with a "stricter" programming language.  This is often
not the case.  It is particularly difficult to realize a library that
is natural to use, and at the same time efficient with regard to space
and time.  A matrix library is a good example:

	- a trivial matrix library is not hard to write

	- it becomes much harder if you want to implement a full
	  set of natural operations, e.g., slices

	- it becomes harder if you want to provide automatic
	  memory management

	- it becomes *much* harder if you want to provide "optimal"
	  memory management that immediately reuses space for used
	  temporaries.

[Optimal space utilization is for example to use only one temporary
variable to calculate the matrix expression "X := A+B+C".]

Dag Bruck

Re: C++ vs. Ada -- Is Ada loosing?

[Jorge Luis Diaz-Herrera]

In article <1992Dec4.141816.1@happy.colorado.edu>, srheintze@happy.colorado.edu
 writes:
|> 
|> HOWEVER, please read "A dynamic Vector is harder than it looks" from the Jun
e
|> 1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5 no 4.
 
|> *THIS ARTICLE IS SCARY*  Basically Tom Cargill pointed out a bug that nearly
|> all C++ textbooks have made when they implement a dynamically sized array. 
|> This includes the textbook written by the implementor of the AT&T Cfront
|> compiler (will I get in trouble if I mention his name?).  If the language is
 so
|> convoluted that even the experts (including the compiler writers) cannot get
|> their simple textbook examples correct, then I conclude there is something
|> drastically wrong with the language.
|> ...
|> 			Thanks,
|> 				Sieg

I could not find this article! The June issue is volume 3 (not there) and
vlume 4 is July/August (not there!!)

jld-h
--..--

Re: C++ vs. Ada -- Is Ada loosing?

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

In article <1992Dec4.141816.1@happy.colorado.edu>, srheintze@happy.colorado.edu
 writes:
[stuff deleted]
> 
> Where is Ada going?  Is it dying? That thread on "Is GNU-Ada self-insulting"
> suggests that Ada is floundering. How badly is Ada floundering? Does that mea
n
> I'll never see inheritance in Ada?
> 
> 			Thanks,
> 				Sieg

I can tell you that Ada is alive and well at most Honeywell Divisions.  Almost
all of the programs here are now being developed or translated into Ada.  This
was a big step from Jovial and C which use a lot of pointers to manipulate data
in our real-time systems.  Ada 9X should bring Ada up to date, although you can
still write very good (maintainable) code with Ada 83.
-- 
-------------------------------------------------------------------------------
Todd A Sorensen               Honeywell Defense Avionics Systems Division
(505) 828-5611                internet: tas@dasd.honeywell.com
                              fax: (505) 828-5500
-------------------------------------------------------------------------------
 
Are You Free if you have a Job?
-------------------------------------------------------------------------------

Re: C++ vs. Ada -- Is Ada loosing?

[pitt.edu!dsinc!netnews.upenn.edu!prijat!guinness.cs.uofs.edu!beidler]

I've enjoyed reading all the postings on why Ada is loosing to C++.
Practically all of the posting are missing the "real" reason.  It has
to do with economic considerations (read my company wants to make
more money).  Think of it this way:  I'm a governement software
contractor.  If I build a perfect, or at least a close to perfect 
system, I make all my money (read profit) by the time I deliver 
the system.  However, if I build a buggy system with unreadable 
source code, I make money (again read profit) over the entire life 
of the software.  Since I can build buggier unreadable software in 
C and C++, naturally I want to use C and C++ so I can make more 
money over a longer period of time.
-- 
+------------------------------------------------------------------+
|  John (Jack) Beidler				                   |
|  Prof. of Computer Science Internet: BEIDLER@JAGUAR.UOFS.EDU     |
|  University of Scranton              beidler@guinness.cs.uofs.edu|
|  Scranton, PA 18510	      Bitnet : BEIDLER@SCRANTON            |
|                                                                  |
|          Phone: (717) 941-7446	 FAX:   (717) 941-4250     |
+------------------------------------------------------------------+

Re: C++ vs. Ada -- Is Ada loosing?

[agate!spool.mu.edu!caen!zaphod.mps.ohio-state.edu!darwin.sura.net!convex!]

In <11330@prijat.cs.uofs.edu> beidler@guinness.cs.uofs.edu (Jack Beidler) write
s:

>of the software.  Since I can build buggier unreadable software in 
>C and C++, naturally I want to use C and C++ so I can make more 
>money over a longer period of time.

Yes, but many organizations can support C and C++.
A better scheme is to use a language that few people use, 
like HAL/S, DG/L, PL/S or Bliss.  That way there's less chance of a 
competitor undercutting your rates when the support contract
is recompeted. Even if you've had to deliver a Software Development
Facility as part of the initial contract, it sure helps your BAFO if your
competition has to retrain their personnel to use your language.
Of course, your proposal would have a pretty chart detailing just
how many dedicated professionals you had on tap who were already fluent
in your obscure language.

I recall that this tactic was mentioned in some of the HOLWG papers.

--Rob   
--spray@convex.com

Re: C++ vs. Ada -- Is Ada loosing?

[Alex Blakemore]

In article <11330@prijat.cs.uofs.edu> beidler@guinness.cs.uofs.edu (Jack Beidle
r) writes:
> If I build a perfect ... system, I make all my money ...
> by the time I deliver the system.  However, if I build a buggy system with un
readable 
> source code, I make money ... over the entire life of the software.
> Since I can build buggier unreadable software in 
> C and C++, naturally I want to use C and C++ so I can make more 
> money over a longer period of time.

It may not be that cynically planned, but I agree economics are a primary drive
r.
A simpler economic explanation is just that:

  the (promised) savings of Ada are experienced by the customer over the long r
un.

  the (real) cost of switching to Ada is experienced by the contractor up front
.

  the contractor has little or no incentive to save the customer money over the
 long run,
  and may in fact view serious attempts in that direction as contrary to his in
terest.

  so its not suprising that contractors often fight using Ada and that may actu
ally
  be a sign that its the right thing to do.
-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted

Re: C++ vs. Ada -- Is Ada loosing?

[agate!spool.mu.edu!uwm.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mkso]

In <11330@prijat.cs.uofs.edu> beidler@guinness.cs.uofs.edu (Jack Beidler) write
s:

>I've enjoyed reading all the postings on why Ada is loosing to C++.
>Practically all of the posting are missing the "real" reason.  It has
>to do with economic considerations (read my company wants to make
>more money).  Think of it this way:  I'm a governement software
>contractor.  If I build a perfect, or at least a close to perfect 
>system, I make all my money (read profit) by the time I deliver 
>the system.  However, if I build a buggy system with unreadable 
>source code, I make money (again read profit) over the entire life 
>of the software.  Since I can build buggier unreadable software in 
>C and C++, naturally I want to use C and C++ so I can make more 
>money over a longer period of time.

More fuel for the flames.  <sigh>

Why is it your assumption that anyone who prefers a different language
than you do must be involved in some plot to deliberately write buggy
software? 

-- 
"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: C++ vs. Ada -- Is Ada loosing?

[news]

In article <11330@prijat.cs.uofs.edu>, beidler@guinness.cs.uofs.edu (Jack Beidl
er) writes:

^I've enjoyed reading all the postings on why Ada is loosing to C++.
^Practically all of the posting are missing the "real" reason.  It has
^to do with economic considerations (read my company wants to make
^more money).  Think of it this way:  I'm a governement software
^contractor.  If I build a perfect, or at least a close to perfect 
^system, I make all my money (read profit) by the time I deliver 
^the system.  However, if I build a buggy system with unreadable 
^source code, I make money (again read profit) over the entire life 
^of the software.  Since I can build buggier unreadable software in 
^C and C++, naturally I want to use C and C++ so I can make more 
^money over a longer period of time.

The more I think about it, Ada (safe, sane....) reminds me of the Volvo.
You see all those advertisements for Volvos tauting safety features, and
they never mention the best safety feature, i.e. the fact that they usually
don't run and you can only hurt yourself so badly sitting under a tree
in a car.  

Likewise with Ada.  If you figure all the things which it simply can't do,
as was so heavily documented in the 700 or so tales of grief from the AdaWoe
BBS, that really doesn't leave much.  Basically, all most people do when forced
to use Ada in projects is to write some stupid menu system in Ada to call C
or C++ routines and hope the Ada part doesn't screw the whole thing up
too badly.  That SHOULD be safe...



-- 
Ted Holden
HTE

Re: C++ vs. Ada -- Is Ada loosing?

[Pascal Obry]

He is up again.
Please, can somebody unplug him !

he/it seem to have some processes control problems.

--

-------------------------------------------------------------------------------
--  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: C++ vs. Ada -- Is Ada loosing?

[Richard A. O'Keefe]

In article <172@fedfil.UUCP>, news@fedfil.UUCP (news) writes:
> The more I think about it, Ada (safe, sane....) reminds me of the Volvo.
> You see all those advertisements for Volvos tauting safety features, and
> they never mention the best safety feature, i.e. the fact that they usually
> don't run and you can only hurt yourself so badly sitting under a tree
> in a car.  

I have deleted the rest of Holden's flame.  Let me offer a data point.
Just recentrly, I posted an article to comp.lang.c in which I listed a
number of errors in a textbook.  The textbook is about data structures
in C.  The authors understand data structures very well.
    Author X "is chair of the CS dept and Professor of CS&EE at
    <famous university>.  [He] has published 30 proceedings, managed
    research grants totalling over US$3.5 million, ... "
    Author Y "is Professor of CS in <not so famous university but I've
    heard of it even here>.  [He] has published over 140 articles and 
    has written several texts.  He is an editor of four professional
    journals and has managed over US$8 million in research grants."
    Author Z "is chair of <a third good university>'s CS dept and a
    veteran of 14 years of teaching."
The authors thank Profesor P, Dr Q, and Messrs R & S for "debugging"
the book.  They also thank Mr T of AT&T Bell Labs (who has written
several books on C himself) for reviewing the manuscript.

Sounds good, no?  The authors also say that the code in the book is not
specially typeset because every example has been tested, and they didn't
want to introduce any errors.
  
On p6 they write "all programs in this book follow the rules of ANSI C".
The first example is on p7, facing this claim, and it contains an OBVIOUS
violation of the ANSI standard, and a known portability problem (which
X3J11 invented a new macro for the express purpose of fixing), and calls
an operation which may fail without checking whether it succeeded.  The
last example in the book has a type error, and the authors' only comment
is to say that the compiler's error message can be ignored.

In my posting in comp.lang.c I described (with page numbers) several other
mistakes.  My personal favourite is one which appears to reveal a fairly
basic misunderstanding about C scope rules. There are others which should
never have been accepted by any C compiler, although they are legal C++.

Many of the problems are potentially serious.  As it happens, with the
exception of the scope problem, GCC or an ANSI lint _would_ catch all of
them.  But Professors X, Y, and Z "tested" their programs under an awesome
total of two compilers, which evidently did _not_ catch these errors.

I can never quite remember the line in "Life, the Universe, and Everything."
"Don't worry, Arthur Dent ............... be very very frightened."

You see, I had been talking with a publisher's representative, and had
complained about another publisher's recent book which had about one
factual error every two pages.  The publisher's representative said, "well,
OURS are checked.  I'll send you one I think you'll be able to use."
Well, no, I can't.  I think my students are better off being shown how to
write CORRECT C code for a smaller variety of data structures than
INCORRECT C code for an impressive range of data structures.  I also think
that a textbook that TALKS so much about abstract data types should teach
students to DO it, but although it is easy to define a stack type in C
so that a program using it has no clue about the implementation, the code
in this book just isn't like that.  The authors never even mention how to
use header files to get modular code.

Am I worried about C, when experienced people who are managing huge
amounts of money (once upon I time I paid US taxes, some of that was
my money) manifestly don't understand C, even though they imagine they
think they understand it well enough to instruct others?
Worried?  No.

I'm very very frightened.

I believe that Ada is a bigger language than C.  Both languages have "dark
corners".  But there seems to be a tradition of Ada compilers being picky
and C compilers letting it all hang out.  With all due respect to "The
Emperor's New Clothes", which I loved when it came out, I am now _more_
frightened about critical software being written in C or C++ than in Ada.

This is actually an important point.  A programming language is more than
a standard.  There is also a tradition, a way of approaching the language.
(It's something I have observed about Prolog:  if you plug into the
Edinburgh _tradition_, Prolog is a simple, comprehensible, and powerful
tool, but if you just look at a manual, most people never learn how to
use it effectively, and that most especially applies to the authors of
textbooks about it.)  It would be perfectly possible to have an "Ada"
compiler which was as sloppy as a C compiler, and it is possible to have
C systems which are very strict.

My current impression is that Ada textbooks tend to be more accurate in
the claims they make about what is or is not valid Ada, and tend to have
a higher level view of the software process, than C books.  Is this an
illusion, due to my knowing C relatively better than I know Ada?

Re: C++ vs. Ada -- Is Ada loosing?

[zaphod.mps.ohio-state.edu!cs.utexas.edu!milano!teenwolf.mcc.com!srogers]

In article <16269@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'K
eefe) writes:

>Just recentrly, I posted an article to comp.lang.c in which I listed a
>number of errors in a textbook.  The textbook is about data structures
>in C.  The authors understand data structures very well. . . . .

    <deleted>

>I believe that Ada is a bigger language than C.  Both languages have "dark
>corners".  But there seems to be a tradition of Ada compilers being picky
>and C compilers letting it all hang out.  With all due respect to "The
>Emperor's New Clothes", which I loved when it came out, I am now _more_
>frightened about critical software being written in C or C++ than in Ada.
>
>My current impression is that Ada textbooks tend to be more accurate in
>the claims they make about what is or is not valid Ada, and tend to have
>a higher level view of the software process, than C books.  Is this an
>illusion, due to my knowing C relatively better than I know Ada?
>

I'm not sure this is true; the Barnes Ada book has LOTS of examples that
violate the LRM.  I think perhaps it's more of a way of teaching than
a symptom of the particular language.  In my CS education, many instructors
(and books) adopted a method of presenting a narrow version of the language
as though it were the whole truth, then expanding it in steps with each
new lesson; perhaps under the theory that this would make it easier to
grasp the wider concepts.  I found it tiring after a while.  It would
go something like (exaggerated)

1. Variables are letters A-Z.  Use like A = 1.
2. Yesterday we learned variables are letters, today we will see that
   variables can have numbers appended for extra clarity.  Like A1 = 1.
3. Today we see that variables can also have multiple letters and
   underscores for even more clarity: ADD_VALUE = 1
. . . . 

The frustrating thing is that they would never get around to specifying
the fundamental principle behind the concept.  Eventually you find
yourself saying: OK, OK, but what is a variable, *really*?  It
seems more natural, IMHO, to start with the broad statement, then explain
what it means with examples in various contexts; rather than assume an
inital narrow context, then try to expand to more general cases.

I would say that C instruction does this more than Ada instruction, but
by no means is it a C phenomena.  I don't know what the mistakes were
that you found, but the ones I have noticed in the Barnes book are
all due to simplification.  I attribute it to the idea (IMHO mistaken)
that a student can benefit from an example that illustrates an idea
in a very clear and simple way, but which is invalid in the full context
of the language.

-- 
| Steven Rogers  MCC/ESL  3500 West Balcones Drive
| Austin, Texas 78759-6509  (512) 338-3691 srogers@mcc.com

Re: C++ vs. Ada -- Is Ada loosing?

[agate!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!csc.ti.com!til]

In <1992Dec18.141448.13862@mcc.com> srogers@teenwolf.mcc.com (Steve Rogers) wri
tes:

>In article <16269@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'
Keefe) writes:

>>Just recentrly, I posted an article to comp.lang.c in which I listed a
>>number of errors in a textbook.  The textbook is about data structures
>>in C.  The authors understand data structures very well. . . . .

>    <deleted>

>>I believe that Ada is a bigger language than C.  Both languages have "dark
>>corners".  But there seems to be a tradition of Ada compilers being picky
>>and C compilers letting it all hang out.  With all due respect to "The
>>Emperor's New Clothes", which I loved when it came out, I am now _more_
>>frightened about critical software being written in C or C++ than in Ada.
>>
>>My current impression is that Ada textbooks tend to be more accurate in
>>the claims they make about what is or is not valid Ada, and tend to have
>>a higher level view of the software process, than C books.  Is this an
>>illusion, due to my knowing C relatively better than I know Ada?
>>

>I'm not sure this is true; the Barnes Ada book has LOTS of examples that
>violate the LRM.  I think perhaps it's more of a way of teaching than
>a symptom of the particular language.  In my CS education, many instructors
>(and books) adopted a method of presenting a narrow version of the language
>as though it were the whole truth, then expanding it in steps with each
>new lesson; perhaps under the theory that this would make it easier to
>grasp the wider concepts.  

This is why I don't approve of Ada as a first language.  The language
is simply too large and powerful, and when you try to teach
restrictive subsets you wind up teaching things that are 'wrong' in
the broader scope.  C++ has this same problem, along with a problem
that it 'inherits' from C.  The biggest problem with C isn't the size
of the language (it's actually fairly small), but that so much of the
power and expressiveness of the language relies on things that
beginning students typically have a great deal of trouble with;
pointers and recursion.  When you add the somewhat arcane syntax
required for declaring complex types and all the safety of an
unshielded buzz saw, C is an even worse choice for a first language
than Ada is.

I think students would be best served by using something INTENDED for
teaching, which is relatively safe and small.  That pretty much means
Pascal.  Some schools have had good luck with LISP/SCHEME style
languages, but I'm not sure how easy they are to deal with as first
languages, either.

-- 
"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: C++ vs. Ada -- Is Ada loosing?

[Michael Feldman]

In article <16269@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'K
eefe) writes:
>
>My current impression is that Ada textbooks tend to be more accurate in
>the claims they make about what is or is not valid Ada, and tend to have
>a higher level view of the software process, than C books.  Is this an
>illusion, due to my knowing C relatively better than I know Ada?
>
This is not an illusion. Ada books were - in the bad old days - full of
errors because nobody had good compilers around to test their code with.
Now that everyone has correct compilers (as least as far as validation
can show them correct), we can test our stuff.

My data structures book (1985) had lots of errors in the code, but these
were either _algorithm_ errors or "version control" problems where the
pieces did not fit together correctly because of author and publisher
carelessness. None were "Ada errors" or nonportabilities.

My freshman book (1991) had a lot of typos when it first came out, but
these were in the _text_ - misspellings and inconsistencies in the
English, tables, blah blah. Lots of UW students got to point out these
errors during my year in Seattle; I paid $1.00 for the first report of
each error.

There were a few algorithm errors and other quibbles that had nothing to do
with Ada. And ONE nonportability: there are two programs in which I made
a bad assumption about float-to-integer conversion, so the programs will
give different results depending on whether the float is truncated or rounded
where the fractional part is in the middle of the interval. This is 2 
programs of 180, and the error was my own stupidity.

I tested (nearly) everything under at least 4 compilers, and other
adopters of the book are using any number of other compilers that I
don't have access to. I have yet to get a report of a portability bug
in any one of them; indeed, I am not getting bug reports at all.
The book includes a diskette of all the programs, so nobody ever has to
endure a keying error to use them.

The purpose of this is not to hype the book, but just to point out
how easy it is to develop Ada code that'll really be compiler-independent,
given today's compilers and programs that don't use a lot of Chapter 13
stuff (you wouldn't find that in a freshman book!).

You might quibble with an author's coding style, or choice of algorithm,
but these days you'll have to work very hard to find a language error
in today's Ada books.

Mike Feldman

PS - My $1.00 per error still stands.

Re: C++ vs. Ada -- Is Ada loosing?

[Robert I. Eachus]

In article <1992Dec18.141448.13862@mcc.com> srogers@teenwolf.mcc.com (Steve Rog
ers) writes:

   I'm not sure this is true; the Barnes Ada book has LOTS of examples that
   violate the LRM...

   Which edition?  The first edition was published before the ANSI (83)
standard was finalized.  However, it wasn't really Ada 80, more like
81 1/2.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: C++ vs. Ada -- Is Ada loosing?

[Morris J. Zwick]

In article <1992Dec18.181158.28683@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com
(fred j mccall 575-3539) writes:
>
>I think students would be best served by using something INTENDED for
>teaching, which is relatively safe and small.  That pretty much means
>Pascal.  Some schools have had good luck with LISP/SCHEME style
>languages, but I'm not sure how easy they are to deal with as first
>languages, either.
>

AMEN!!

         ___________________________________________________________________
        /  Morris J. Zwick	                 Internet: mzwick@vitro.com
__     /   Vitro Corporation	             Voice:    (301) 231-2784
  \   /    14000 Georgia Ave.                ___________________________
   \ /     Silver Spring, MD 20906-2972      |"I don't want the world; |
    *                                        | I just want your half!" |
                                             |  - They Might Be Giants |

Re: C++ vs. Ada -- Is Ada loosing?

[Steve Rogers]

In article <EACHUS.92Dec18164915@oddjob.mitre.org> eachus@oddjob.mitre.org (Rob
ert I. Eachus) writes:
>In article <1992Dec18.141448.13862@mcc.com> srogers@teenwolf.mcc.com (Steve Ro
gers) writes:
>
>   I'm not sure this is true; the Barnes Ada book has LOTS of examples that
>   violate the LRM...
>
>   Which edition?  The first edition was published before the ANSI (83)
>standard was finalized.  However, it wasn't really Ada 80, more like
>81 1/2.
>

The edition I am looking at is the 3rd edition.  Two examples:  The
FRAME program on page 325 violates LRM 9.1.4 - the type of the task
cannot be used as a typemark within the task itself.  It's easy to
see what the program means, but it doesn't comple.  There is a task
example on page 311 that has nested accepts for the same entry which
violates LRM 9.5(8).  Again, its clear what the program intends, but
it has been simplified in a way that keeps it from compiling.  These
are the latest ones I have noticed.  It seems to me that it would be
better to include such details in examples (certainly after several
hundered pages) so that the student/reader learns to see Ada and
the LRM as a consistent whole, rather than a lot of nit-picky
rules that get in the way.

I'm assuming that these things have been left in on purpose and
reflect a particular approach to teaching rather than simple
oversight. This simplification is consistent with the practice
I have seen in my CS education (addressed in my previous post)
and it is the 3rd edition, after all.  It is not my intent
to critisize this book - I bought the first edition and I'll
probably buy the 4th edition.  I'm addressing a particular
method of teaching CS.  The piecemeal approach is not as good
as a wholistic approach. I think students need to learn to
see the language as a consistent wholistic system, rather than
a hodge-podge box of semantic tools.  I think it is easier to
see this aspect of programming languages in Ada than most
others.  This is why I think it makes a good first language,
despite its complexity (just leave off tasks at first).

-- 
| Steven Rogers  MCC/ESL  3500 West Balcones Drive
| Austin, Texas 78759-6509  (512) 338-3691 srogers@mcc.com

Re: C++ vs. Ada -- Is Ada loosing?

[Michael Feldman]

In article <15@mlb.win.net> mbayern@mlb.win.net (Mark Bayern) writes:
>
>I'm afraid you're absolutely correct! But you don't have to look
>into the update cycle to see Ada's commercial problems.  Look at the
>original cost of getting the language.  Want to use C in your
>embedded 80x86? Both MSC and TurboC list for (much) less than
>$1000.  That and a little work and you're up and running.  Ada? How
>about $25,000 for a license, and $5,000 for the _required_ first
>year 'support'! 
>
Huh? I'm curious. Whose 80x86 target compiler is $25,000? RR, AETech, 
Meridian and Alsys' DOS extended-mode compilers are all in the $1-2k range,
commercial prices (maybe less). Who else is there?

Are you thinking of the commercial prices for Unix-server-host compilers?
I'll admit that those are too high, but not the DOS-host ones. Is your
information up to date? Meridian? Alsys? You awake out there?

If this post's information is correct, we are all in BIG trouble. If not,
this is a great example of the lousy job we are doing in the Ada
community in getting the facts out into the street, guys.

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: C++ vs. Ada -- Is Ada loosing?

[Jim Withrow]

In article <1992Dec23.221817.28758@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael
 Feldman) writes:
>From: mfeldman@seas.gwu.edu (Michael Feldman)
>Subject: Re: C++ vs. Ada -- Is Ada loosing?
>Date: Wed, 23 Dec 1992 22:18:17 GMT
>In article <15@mlb.win.net> mbayern@mlb.win.net (Mark Bayern) writes:
>>
>>I'm afraid you're absolutely correct! But you don't have to look
>>into the update cycle to see Ada's commercial problems.  Look at the
>>original cost of getting the language.  Want to use C in your
>>embedded 80x86? Both MSC and TurboC list for (much) less than
>>$1000.  That and a little work and you're up and running.  Ada? How
>>about $25,000 for a license, and $5,000 for the _required_ first
>>year 'support'! 
>>
>Huh? I'm curious. Whose 80x86 target compiler is $25,000? RR, AETech, 
>Meridian and Alsys' DOS extended-mode compilers are all in the $1-2k range,
>commercial prices (maybe less). Who else is there?
>
>Are you thinking of the commercial prices for Unix-server-host compilers?
>I'll admit that those are too high, but not the DOS-host ones. Is your
>information up to date? Meridian? Alsys? You awake out there?
>
>If this post's information is correct, we are all in BIG trouble. If not,
>this is a great example of the lousy job we are doing in the Ada
>community in getting the facts out into the street, guys.
>
>Mike Feldman


When I first read his post I though the same as you did.  But then I read it 
again and realized that he was talking about the cross compilers which run 
on a dos machine and target to a bare board 80x86.  I have the Alsys 386 DOS 
compiler and it will not target to a bare board (embedded) 80x86.  I also 
have an Alsys 386 DOS to 80386 cross compiler.  That compiler is really the 
same as the all DOS compiler, but has support for various bare board 
computers, including a PC with no disks (hard or floppy).  You can ROM the 
Ada executable or transfer it through the serial port.  The prices he is 
talking about do apply to that very same cross compiler from Alsys.  They 
gorge you for 25K + 5K for the first compiler.  Each additional compiler 
costs 5K + 1K.  

He does admit that he did have to do some work to get the equivalent to the 
RTE moved over.

If I did not work on a project which REQUIRED the use of embedded Ada, I 
don't think I would have purchased that 30K cross compiler from Alsys.  I 
see no justification for the high cost of that compiler.  (That cost 6x more 
than the cost of the 486/DX2-66 computer you use to work on the project!)  
Imagine if you had 4 people working on the project, you would need 48K for
the four compilers, for just the first year!

Although I am talking about Alsys pricing, I have had experience with other 
Ada compiler vendors who have prices which are even higher than Alsys.

Mike is correct regarding the need to get the facts about pricing out.  
There might be a way to shame the Ada vendors into lowering their prices.  
Although I hate to see the childish "C can do this in 2 statements and it 
takes 10 statements to do that in Ada", I would like to see comparisons of 
cost to do a project in Ada vs. C.  (When refering to cost, I mean cost of 
tools, compilers, editors..., not hours, which is too subjective.)

Jim Withrow

Re: C++ vs. Ada -- Is Ada loosing?

[Charles H. Sampson]

In article <withrow.13.0@lims01.lerc.nasa.gov> withrow@lims01.lerc.nasa.gov (Ji
m Withrow) writes:

>If I did not work on a project which REQUIRED the use of embedded Ada, I 
>don't think I would have purchased that 30K cross compiler from Alsys.  I 
>see no justification for the high cost of that compiler.  (That cost 6x more 
>than the cost of the 486/DX2-66 computer you use to work on the project!)  
>Imagine if you had 4 people working on the project, you would need 48K for
>the four compilers, for just the first year!

     While I can't defend Alsys's specific prices without more information,
one justification for the high cost of a compiler for a naked machine is
that the vendor has had to develop an entire executive (rather than tying
into an existing DOS or UNIX) and must amortize that cost over a small
customer base.  Basically, the high cost is for the RTE and the cross-
compiling utilities, not for the compiler itself.

				Charlie

Re: C++ vs. Ada -- Is Ada loosing?

[Michael Feldman]

In article <1992Dec29.161150.23301@nosc.mil> sampson@nosc.mil (Charles H. Samps
on) writes:
>
>     While I can't defend Alsys's specific prices without more information,
>one justification for the high cost of a compiler for a naked machine is
>that the vendor has had to develop an entire executive (rather than tying
>into an existing DOS or UNIX) and must amortize that cost over a small
>customer base.  Basically, the high cost is for the RTE and the cross-
>compiling utilities, not for the compiler itself.
>
This seems a weak justification. I'll agree that Ada may need a more
sophisticated RTE than C, but is it 25 times more so?

And the argument about a small customer base is self-fulfilling, as we
have discussed many times in this group. Perhaps a cross to a really
weird DoD-specific board might have a small base, but a standard OTS
80x86 package?

The back cover of IEEE Computer, Dec 92, has an ad from Computer Systems
Architects (CSA). They have a Transputer board you can add into a clone.
The education price for this board is $395, and it includes a parallel
C compiler and an occam2 compiler, _for the Transputer board_. I don't
know what the commercial price is, but it's probably <$1k. CSA
mentions that Ada is available. I assume this means Alsys, the only
compay supporting this configuration. Is the Transputer RTE _that_
much hairier than the occam one? Or parallel C? 

BTW - I bought one of these CSA babies at the Computer Science Conference
last year. It's a nice piece of work.

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: C++ vs. Ada -- Is Ada loosing?

[Mark Meyer]

	I'm new to this group, basically because I'm new to Ada.
Even so, I just have to comment on this:

In article <1992Dec21.161105.9344@mcc.com> srogers@teenwolf.mcc.com (Steve Roge
rs) writes:
> The edition I am looking at is the 3rd edition.

	Are you sure?  I'm looking at the 3rd Edition myself.  When
was your copy printed?  This book seems to go through a reprint twice
every year, and mine's from 1990.  I only ask because both your
examples of errors seem to be in error themselves, at least as far as
my copy is concerned.

> Two examples: The FRAME program on page 325 violates LRM 9.1.4 - the
> type of the task cannot be used as a typemark within the task itself.
> It's easy to see what the program means, but it doesn't comple. 

	No, it doesn't violate 9.1.4.  I could tell that by
inspection.  I was even able to compile it (after removing references
to the FRAME package - I don't know how to get our compiler to build a
library and someone else has the manual).  Nowhere in the task body of
FILTER does anyone try to use FILTER as a type.  In fact, on p. 327
Barnes specifically states, "(The use of the function MAKE_FILTER is
necessary to overcome a rule that in the body of a task type its name
refers to the current task and not the type.)"

> There is a task example on page 311 that has nested accepts for the
> same entry which violates LRM 9.5(8).  Again, its clear what the
> program intends, but it has been simplified in a way that keeps it
> from compiling.

	I was able to compile this program too.  In my copy of the
book, the accepts are not nested.  Do you have the 3rd Edition,
printed in 1990?  Maybe your book was printed earlier?

-- 
Mark Meyer                                               | mmeyer@dseg.ti.com |
Texas Instruments, Inc.,  Plano TX                       +--------------------+
Every day, Jerry Junkins is grateful that I don't speak for TI.
"There's lots of bread in the freezer!"  "No, I threw it out.  Hard as a rock."

Re: C++ vs. Ada -- Is Ada loosing?

[agate!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!milano!teenwol]

In article <MMEYER.92Dec31114831@m2.dseg.ti.com> mmeyer@m2.dseg.ti.com (Mark Me
yer) writes:
>
>	I'm new to this group, basically because I'm new to Ada.
>Even so, I just have to comment on this:
>
>In article <1992Dec21.161105.9344@mcc.com> srogers@teenwolf.mcc.com (Steve Rog
ers) writes:
>> The edition I am looking at is the 3rd edition.
>
>	Are you sure?  I'm looking at the 3rd Edition myself.  When
>was your copy printed?  This book seems to go through a reprint twice
>every year, and mine's from 1990.  I only ask because both your
>examples of errors seem to be in error themselves, at least as far as
>my copy is concerned.
>
>> Two examples: The FRAME program on page 325 violates LRM 9.1.4 - the
>> type of the task cannot be used as a typemark within the task itself.
>> It's easy to see what the program means, but it doesn't comple. 
>
>	No, it doesn't violate 9.1.4.  I could tell that by
>inspection.  I was even able to compile it (after removing references
>to the FRAME package - I don't know how to get our compiler to build a
>library and someone else has the manual).  Nowhere in the task body of
>FILTER does anyone try to use FILTER as a type.  In fact, on p. 327
>Barnes specifically states, "(The use of the function MAKE_FILTER is
>necessary to overcome a rule that in the body of a task type its name
>refers to the current task and not the type.)"

The date on my copy is 1989.  The FILTER task references itself on page 326.
I suppose the error was found and corrected in later editions.

>> There is a task example on page 311 that has nested accepts for the
>> same entry which violates LRM 9.5(8).  Again, its clear what the
>> program intends, but it has been simplified in a way that keeps it
>> from compiling.
>
>	I was able to compile this program too.  In my copy of the
>book, the accepts are not nested.  Do you have the 3rd Edition,
>printed in 1990?  Maybe your book was printed earlier?

Whoops!  I misread this one.  

The correction of the FRAME error answers the larger question of whether
or not the errors were intentionally included to make the examples
"easier" to understand.  It appears that this is NOT the case.

-- 
| Steven Rogers  MCC/ESL  3500 West Balcones Drive
| Austin, Texas 78759-6509  (512) 338-3691 srogers@mcc.com

C++ vs. Ada -- Is Ada loosing?

[branr62]

Hi all,

A terrific thread to read with some sound discussion.

What are everybody’s opinions now in 2019?

Re: C++ vs. Ada -- Is Ada loosing?

[robin.vowels]

On Saturday, December 5, 1992 at 7:18:16 AM UTC+11, srhe...@happy.colorado.edu wrote:
> There are a lot of people out there who think C++ is the greatest thing since
> sliced bread.  C++ is a truly wonderful toy because you can redefine the
> language for your application.  
> 
> For example you can provide the function that is invoked in response to
> assignment so you can optimize your matrix class to (1) only pass a pointer to
> the matrix data instead of actually making a physical copy and (2) defer the
> actual copy operation to the point in time when (and if) the target of the
> assignment is modified.  This is impressive.
> 
> HOWEVER, please read "A dynamic Vector is harder than it looks" from the June
> 1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5 no 4. 
> *THIS ARTICLE IS SCARY*  Basically Tom Cargill pointed out a bug that nearly
> all C++ textbooks have made when they implement a dynamically sized array. 
> This includes the textbook written by the implementor of the AT&T Cfront
> compiler (will I get in trouble if I mention his name?).  If the language is so
> convoluted that even the experts (including the compiler writers) cannot get
> their simple textbook examples correct, then I conclude there is something
> drastically wrong with the language.
> 
> I don't want anybody writing code in C++ for satellites funded with my tax
> dollars!
> 
> I heard a rumer about a multi-million (or multi-billion) dollar satellite going
> astray because some one left a comma out of a FORTRAN DO loop and it was still
> syntactically legal.  Can anybody give me a reference on this?

I think that you are referring to a DO statement like:

DO 50 I = 1.20

instead of

DO 50 I = 1,20

In FORTRAN 77, both statements are correct.
They are correct because spaces are ignored, but the first statement
is an assignment statement, viz,

DO50I = 1.20

not a loop control statement, and without any structure on a DO loop
(there's no END of loop statement) the error could not be diagnosed
by a compiler.

If this was reported as a real event, this info may help you to
find it.

> So we have C++ with very similar problems to this problem in FORTRAN that (I
> believe, correct me if I am wrong) Ada was supposed to solve. You can insert a
> ";" between the ")" and the "{" in any while or if statement and the C++
> program is still syntactically correct but semantically disasterous.
> 
> So, Ada was on the seen.  I spent some significant time as a project lead with
> Ada in '89-90.  I was excited about the language.  Now I am independent and
> make my living with C++.  
> 
> Where is Ada going?  Is it dying? That thread on "Is GNU-Ada self-insulting"
> suggests that Ada is floundering. How badly is Ada floundering? Does that mean
> I'll never see inheritance in Ada?
> 
> 			Thanks,
> 				Sieg

Re: C++ vs. Ada -- Is Ada loosing?

[Shark8]

On Thursday, August 8, 2019 at 9:23:47 AM UTC-6, robin...@gmail.com wrote:
> On Saturday, December 5, 1992 at 7:18:16 AM UTC+11, srhe...@happy.colorado.edu wrote:
> > 
> > HOWEVER, please read "A dynamic Vector is harder than it looks" from the June
> > 1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5 no 4. 
> > *THIS ARTICLE IS SCARY*  Basically Tom Cargill pointed out a bug that nearly
> > all C++ textbooks have made when they implement a dynamically sized array. 
> > This includes the textbook written by the implementor of the AT&T Cfront
> > compiler (will I get in trouble if I mention his name?).  If the language is so
> > convoluted that even the experts (including the compiler writers) cannot get
> > their simple textbook examples correct, then I conclude there is something
> > drastically wrong with the language.

For those interested, the sited paper can be read here:
https://drive.google.com/open?id=1PHUleua3FpIYRrumkboxBCLhMjc_mkxj

RE: C++ vs. Ada -- Is Ada loosing?

[Mark Bayern]

Jack Beidler writes:

>> ... Practically all of the posting are missing the "real"
>> reason. It has to do with economic considerations (read
>> my company wants to make more money).

I'm afraid you're absolutely correct! But you don't have to look
into the update cycle to see Ada's commercial problems.  Look at the
original cost of getting the language.  Want to use C in your
embedded 80x86? Both MSC and TurboC list for (much) less than
$1000.  That and a little work and you're up and running.  Ada? How
about $25,000 for a license, and $5,000 for the _required_ first
year 'support'! 

If I choose to use C I've invested less than $1000 in software,
instead of $30,000.  I've also invested a little work in porting
the C runtime startup code to the embedded system, but during that
time the team has been learning the details of the hardware.  Plus
the money is spent locally on labor, instead of spent to some large
Ada firm.

(Hmmm... now I'm having problems remembering why I choose Ada for my
commercial products.  Oh yeah! It had something to do with
validated compilers and run-times that wouldn't have any bugs or
support problems, silly me!).

Mark