Re: C/C++ knocks the crap out of Ada

Re: C/C++ knocks the crap out of Ada

[Tuishimi]

>take into account that a programmer who says he knows C/C++ is generally
>lying, but one who says he knows Ada is generally honest.  this means
that
>you need to get *many* applicants for C/C++ jobs to find one you can
hire.

That is a terrible thing to say!!!  And how can you back this statement?

Besides, when someone is being interviewed, the interviewer should have
questions ready to determine the level of competence of the interviewee
for whatever the position and the requirements thereof.  I like to think
that people
don't lie (entirely) about what they know on their resumes.  Tho' if what
you mean
to say is that there are not many people who are intimately knowledgeable
of
C++, then I might agree.

Mike

Re: C/C++ knocks the crap out of Ada

[Tuishimi]

>notice how Microsoft's shitty products caused every user to seek help,
>write his own "smart utility", and thus generated enormous publicity for
>the products, including still-wet-behind-the-ears consultants,
third-party
>vendors who sold stop-gap solutions, and magazines that thrived on it
all.

Why are we microsoft bashing in an Ada language news group?  Anyway, while
I am not a big microsoft fan, I  shall say that I DID switch from OS2/Warp
to 
Windows 95 because Warp had many more stability problems than does W95.
At least in my case it did.  If this were an ideal world, we'd all be
using MACs or
NeXT computers.  :)

I agree, for the most part, with the rest of what you wrote.  But at the
same rate,
when PC DOS was first written, who would have known how the hardware would
change as it had?  (And continues to change).  Also, competition requires
companies to "rush" products out the door without thorough testing (or
with the knowledge that bugs exist, but htat they will fix them in a
future release) because of company A gets a new and widely desired product
out months or even a year before company B gets their robust version out,
it will be too late and company A will have cornered the market -- buggy
software and all.

I am not advocating this.  Actually, I quit my last job with a company I
had been with for 11 years because they started spitting out software with
known bugs, just because they wanted to get it out fast to compete.

Mike

Re: C/C++ knocks the crap out of Ada

[Tuishimi]

Jon, can you summarize on the Booch Method?

Re: C/C++ knocks the crap out of Ada

[Tuishimi]

>English is a good example of what happens when you let the user
>community design the language :-)
>
>-- Steve

That's pretty funny!  :)

Mike

Re: C/C++ knocks the crap out of Ada

[Tuishimi]

>Yes indeed: you get a language that is large, ungainly, full of
>irregularities and historical oddities.  You also get a language
>that in much of the world is the de facto standard for commercial
>communication.  I remember once standing in the lobby of a
>hotel in Copenhagen watching a French visitor trying to talk
>to the desk clerk; since one spoke no French and the other
>no Danish, they settled on English.
>-- 
>				--Andrew Koenig
>				  ark@research.att.com

I think someone out there should volunteer to write an English compiler. 
One that
supports all dialects on all platforms!  :)

Excerpt of code from a "valley person":

If, like -- omigod!, the big red cadillac costs more than the bitchin'
BMW, like, buy the BMW!!!

ENG-E-FATSYNERR, Fatal syntax error, "like -- omigod!"
ENG-F-VALNOTSUP, Valley dialect not supported in this version.

Re: C/C++ knocks the crap out of Ada

[Tuishimi]

>For natural language, the size of the vocabulary and grammatical and 
>stylistic permissivity are benefits.

That reminds me of an assembler-like language where you define all of your
variable types as well as language verbs, sort of like macros...  does
anyone know what I am talking about.. .what it is/was called??

Mike

Re: C/C++ knocks the crap out of Ada

[Tuishimi]

>Another thing not mentioned is that Ada is far more complicated to learn
>fully than is C/C++.  The complexity of the language can add to an
increase
>in the probabilty of bugs being introduced and also adds to an increase
in
>project maintanace costs.

At the same rate, Ada is so strongly typed and has such rigid syntax that
it can aid in the location of bugs far more quickly than with C or C++.

I also believe that anyone who learned Pascal in college can pick up Ada
very quickly.  I did.  But maybe it is easier for some people than others,
I don't know.

Mike

Re: C/C++ knocks the crap out of Ada

[Chris Littlejohns]

James O'Connor wrote:
> 
> In <312515DF.7D3B@cmlj.demon.co.uk>, Chris Littlejohns <chris@cmlj.demon.co.uk> writes:
> >Ramses Youhana wrote:
> >>
> >> Another thing not mentioned is that Ada is far more complicated to learn
> >> fully than is C/C++.  The complexity of the language can add to an increase
> >> in the probabilty of bugs being introduced and also adds to an increase in
> >> project maintanace costs.
> >
> >The only area of Ada that I've observed people having real difficulty
> >with is Tasking. However, concurrent threads is something that a lot of
> >people have difficulty with irrespective of the language.
> >
> >With regards to maintenance, there's many people out there who consider
> >C/C++ a Write only language. It takes real talent to write an unreadable
> >Ada program. I know what I'd prefer any day, and it begins with 'A'.
> 
> Not really, my first professional programming was maintaing a poorly designed
> Ada program.  The code was a disaster.  No private types, all types in the
> public part of the spec.  Obscure use of unchecked-conversion, misunderstanding
>  of how enumerated types were indexed.
>   This experience quickly got me over the Ada propaganada and I now fully
> believe that there is no substitue to disciplined, experienced designers and
>  programmers.

100% agree, I was just assuming a level of competence slightly above the inability
to structure anything at all!!  :-)

> 
> 
> James O'Connor
> oconnor@apci.net

Re: C/C++ knocks the crap out of Ada

[Ell]

Tuishimi (tuishimi@aol.com) wrote:
:...
: Where I work, there are/were no (followed)
: standards and we are in the (long) process of defining them.  It is not an
: easy road to take, since everyone there has there own idea of how it
: should be done.  (Does anyone know of any papers or books on the topic?) 

Try Grady Booch's Object Solutions book for pointers on development 
process at both the strategic and tactical levels.

Elliott

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

Ramses asks

"Didn't NASA loose a satelite due to a bug in a piece of Ada code?"

And thus are rumours borne out of innocent (?????) questions :-)

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

Ramses says:

"Another thing not mentioned is that Ada is far more complicated to learn
fully than is C/C++.  The complexity of the language can add to an increase
in the probabilty of bugs being introduced and also adds to an increase in
project maintanace costs.

Ramses."

Well from that comment, one thing we know for sure is that Ramses has not
yet "learn[ed] fully .. C/C++"

In fact anyone lumping C and C++ together in the same breath like that often
turns out not to know C++ very well at all, since if you really *do* know
C++ you would not consider it to be in the same complexity class as C.

I would *definitely* guess from your comments that you have not learned
Ada 95 fully, and it seems appropriate to suggest that only someone who
DID know both languages really well could offer even a semi-relevant
*subjective* opinion on the relative complexities of the languages.

By objective criteria (size of description e.g.) they are similar, but it
is hard to know whether such criteria are meaningful.

What is interesting is to ask how often bugs are caused by misunderstanding
of the language. Here in my experience, Ada 95 has a clear win, since many
misunderstandings result in compiler error messages instead of obscure
runtime bugs.

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

Robin said

"---It's other things besides -- like, how to find a square root, how to do
simple I/O.
__________________________________________________________________________

both these things are trivial in Ada 95, certainly not something students
have problems with, even right at the start, Robin what are you talking
about. 

Re: C/C++ knocks the crap out of Ada

[++ robin]

	Chris Littlejohns <chris@cmlj.demon.co.uk> writes:

	>The only area of Ada that I've observed people having real difficulty 
	>with is Tasking.

---It's other things besides -- like, how to find a square root, how to do
simple I/O.
__________________________________________________________________________

From comp.lang.ada Sun Feb 18 11:30:51 1996
From: kst1ju@herts.ac.uk (Ryan)
Subject: Please help a beginner! (second try)

Could somebody please help me with what I am sure is a simple
problem. I need to do some basic text and integer IO. Apparently
I need the TEXT_IO library for this - it is on my system, and
I believe I am using it in the following code. However, when I 
compile the program, the errors mentioned in the comments are
given out :
[snip]

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

Dave Weller said

"Compared to C++?  You are wrong.  There are fewer features in C++, yet
the (draft) reference manual is larger than Ada 95 (not that this is
necessarily a good measure, but rather that a language that is less
complex would hopefully require less "langauge" to specify it).  My
personal experience with Ada 95 and C++ indicates the exact opposite
of your conclusion.  I have a feeling you haven't used Ada 95 very
much to make such claims."

Actually the source of this incorrect viewpoint often stems from lack
of familiarity with C++ (you can sort of guess this from anyone who
writes C/C++ as though it were one language). It is remarkable how many
people think they know C++ becaus they program in it, and yet they are
unaware of exceptions,  namespaces and the standard template library.
And try seeing how many C++ programmers really understand the overloading
semantics in C++.

I have seen so-called "C++" programs that were litte more than C programs
with C++ style comments :-)

Re: C/C++ knocks the crap out of Ada

[Adam Morris]

Someone was heard to mumble:-
>> Truth is, Ada has its strengths 

And it's weaknesses... Like EVERY other language (in my opinion)

>> and is (for certain projects) far superior to any other structured 
>> language. 

and ML is far superior for certain projects, and C is better for other ones, 
and if what you really want is Fortran then that's the best... For a 
particular project then yes Ada or C++ or BCPL or whatever may be the best... 
but for EVERY project there is no one language that is the best every time.

I am quite happy to admit that I prefer programming in C/C++ to programming in 
Basic, but if I want a really small simple thing done I'm willing to use a 
batch file/shell script.  If I can do it in that in a couple of minutes why do 
I need to write a fully compiled program that will do it.  

Need I add that all of this is my own personal opinions?  

BTW in my opinion I won't find a language that is perfect for me until I write 
one that does everything I want in the way that I want it to, even then, you 
may not like it, or you may only like bits of it.  And i'm never going to 
write it because my requirements are always changing... :-)

Adam.

Re: C/C++ knocks the crap out of Ada

[Simon Johnston]

> >Yes indeed: you get a language that is large, ungainly, full of
> >irregularities and historical oddities.  You also get a language
> >that in much of the world is the de facto standard for commercial
> >communication.  I remember once standing in the lobby of a
> >hotel in Copenhagen watching a French visitor trying to talk
> >to the desk clerk; since one spoke no French and the other
> >no Danish, they settled on English.
> >--
> >                               --Andrew Koenig
> >                                 ark@research.att.com
>
> I think someone out there should volunteer to write an English compiler.
> One that
> supports all dialects on all platforms!  :)
>
> Excerpt of code from a "valley person":
>
> If, like -- omigod!, the big red cadillac costs more than the bitchin'
> BMW, like, buy the BMW!!!

or even:     buy the Beamer!!!

> ENG-E-FATSYNERR, Fatal syntax error, "like -- omigod!"
> ENG-F-VALNOTSUP, Valley dialect not supported in this version.
>
>

with StandardDisclaimer; use StandardDisclaimer;
package Sig is
--,-------------------------------------------------------------------------.
--|Simon K. Johnston - Development Engineer (C++/Ada95) |ICL Retail Systems |
--|-----------------------------------------------------|3/4 Willoughby Road|
--|Unix Mail: skj@acm.org                               |Bracknell          |
--|Telephone: +44 (0)1344 476320 Fax: +44 (0)1344 476302|Berkshire          |
--|Internal : 7261 6320   OP Mail: S.K.Johnston@BRA0801 |RG12 8TJ           |
--|WWW URL  : http://www.acm.org/~skj/                  |United Kingdom     |
--`-------------------------------------------------------------------------'
end Sig;

Re: C/C++ knocks the crap out of Ada

[Norman H. Cohen]

In article <4g56g9$1sk@newsbf02.news.aol.com>, tuishimi@aol.com (Tuishimi)
writes: 

|> I think someone out there should volunteer to write an English compiler.
|> One that
|> supports all dialects on all platforms!  :)
|>
|> Excerpt of code from a "valley person": 
|>
|> If, like -- omigod!, the big red cadillac costs more than the bitchin'
|> BMW, like, buy the BMW!!!
|>
|> ENG-E-FATSYNERR, Fatal syntax error, "like -- omigod!"
|> ENG-F-VALNOTSUP, Valley dialect not supported in this version.

I heard a proposal several years ago for a programming language based on
Valley English.  The programming language was named VALGOL.  The Boolean
constants were named Fer_Sure and As_If.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: C/C++ knocks the crap out of Ada

[Ted Dennison]

Ramses Youhana wrote:
> 
> Ted Dennison (dennison@escmail.orl.mmc.com) wrote:
> > Quite true. But having "cleaned up" both, I can tell you Ada is MUCH
> > easier to detangle.
> 
> That's interesting.  Is this due to the language itself, or the way
> the programs were written or both?  I have had to "detangle" other

I'd say due to the language.

> peoples C code on many occasions.  Those that were well written
> were very easy to fix, however, the majority were incredibly poorly
> written.  These were very hard to fix, and in many cases, the code had
> to be re-written.  All of these problems were due to the poor design and
> coding habits of the programmer and not the C language.  I am wonderring
> how much protection Ada provides against bad programmers and engineers.
> I know that C doesn't provide much protection.  This is one reason why
> it is important to design the system first (on paper) before one starts
> coding.

Well, for the quailty developers you've got a language with integral
facilities for information hiding, and strong typing to preserve the
integrity of their objects. 

For your average developers, you've got a language where pointers are
NOT used for arrays and parameter passing. And when pointers ARE used,
they are NOT assignment-compatable with integers and characters and
pointers to objects of another type. This cuts out a lot of the most
common C errors. 

You also have a language where array bounds are checked. For those of
you who follow Unix security, you know that the single most common 
cause of Unix security holes is due buffer overflow conditions on
arrays wihtout range checking. Hackers know about Unix's C 
shortcommings, and exploit this lack of range checking to insert 
their own code into a running  Unix job with root privs. If Unix 
were written in a language with range checking, a whole cottage 
industry of Unix security consultants would be put out of work.

Also, proper use of typing will prevent errors like garbage data
propagating through a system (sometimes a network!) and crashing
a seeminly unrelated routine (eg: when it tries to index by that
value).

The strong typing has one other effect. The extra pain involved in
hosing the type checking encourages developers to think through their
typing scheme ahead of time, and to choose wisely.

Thus for code written by average and above average coders, debugging
typically means finding the cause of some Ada exception that occured,
and adding code to handle that case.

For your poor developers, (who will often STILL write code that
has to be rewritten), you have a language where aliasing is difficult
and obvious when done. 

You have a language that forces separation of interfaces and 
implementation. This not only makes important interface information 
easier to locate (without having to wade through tons of irrelevant 
code), but it also discourages poor develpers from hosing of your 
"objects", by hiding the details of their implementation in another
place. 

You also have a language whose package-based scoping rules imply that
the rotten code is generally confined to one source file. This one 
source file can usually be completely rewritten, WITHOUT changing the
interface to the rest of the code at all. 

In practice, the only real way to write spaghetti code in Ada is the
infamous "generic-ghetti". This involves using multiple levels of
nested generics (usually with a lot of procedure parameters) in a
structure so complex that it is nearly impossible to tell what the
instantiated code does. (Here we often refer to it as "Frankel-ghetti",
in honor of an STGT developer who managed to write an example so bad
that the DEC Ada compiler simply spat out an "I give up" error message.)
Once C++ folks start to figure out templates, they'll have this problem
too.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: C/C++ knocks the crap out of Ada

[Pete Becker]

In article <312515DF.7D3B@cmlj.demon.co.uk>, chris@cmlj.demon.co.uk says...
>
>With regards to maintenance, there's many people out there who consider 
>C/C++ a Write only language.

How many of the people who say this have actually used C++ enough to 
understand it? I know it's popular today to dump on C++, but my experience has 
been that most of the people who produce one-liners like this simply don't 
know what they're talking about. If relying on that sort of ignorance is the 
best you can do to defend ADA, so be it. But I'll bet that if you try you can 
come up with arguments that are actually based on fact. Those would lead to a 
much more interesting and useful discussion.

Re: C/C++ knocks the crap out of Ada

[Mike Stark]

jsa@organon.com (Jon S Anthony) wrote:
>In article <4g1b7n$l5@mailhub.scitec.com.au> ramsesy@rd.scitec.com.au (Ramses Youhana) writes:
>
>> You'll be surprised how easily both junior (and senior) engineers can turn
>> both C/C++ and Ada programs into spaghetti code.  The language itself
>> doesn't make for a quality system.
>
>Yes, but there are degrees of ease with which this can be done.  I think
>that was more to the point.
>
>
>> Didn't NASA loose a satelite due to a bug in a piece of Ada code?
>
>I don't think so.  I believe that the only confirmed case of a probe
>loss due to software was a Venus probe which had Fortran code (the
>problem was a "lexical" error concerning spaces not acting as lexical
>separators).  The recent Mars probe that "vanished" was (last I saw)
>thought to have been lost due to a small rupture in one of the on board
>tanks.  This caused the ship to go into uncontrolled tumbling.  I don't
>know what it was programmed with.
>
>/Jon
>-- 
>Jon Anthony
>Organon Motives, Inc.
>1 Williston Road, Suite 4
>Belmont, MA 02178
>
>617.484.3383
>jsa@organon.com
>

Folks --

The mere fact that Ada (or any other language) is used for a satellite does not
guarantee that the software is reliable enough -- there is far more to engineering
flight qualified software.  That being said, I would prefer a language that can
use exception handling to recover from anomalies such as bit flips caused by
cosmic rays, and that doesn't allow unrestricted address arithmetic to 
(potentially) store data into the code currently in memory.  Ada isn't the only
language designed for high reliability (Java and Eiffel leap to mind), but if I
were a satellite project manager I would certainly prefer it to C or C++.

Mike

-----------------------------------------------------------------------
Michael Stark                                     NASA/GSFC                                           
Phone: (301) 286-5048                             Code 552
Fax:   (301) 286-0245                             Greenbelt, MD 20771
e-mail: michael.e.stark@gsfc.nasa.gov
"I don't give them hell.  I tell the truth and they THINK it's hell!"
    -- Harry S. Truman
-----------------------------------------------------------------------

Re: C/C++ knocks the crap out of Ada

[Ian S. Nelson]

Adam.Morris@octacon.co.uk (Adam Morris) writes:

>Someone was heard to mumble:-
>>> Truth is, Ada has its strengths 

>And it's weaknesses... Like EVERY other language (in my opinion)

I agree, use what you gets the job done and what you have around.

>>> and is (for certain projects) far superior to any other structured 
>>> language. 

>and ML is far superior for certain projects, and C is better for other ones, 

Take that back!  ML isn't superior for any projects...

Re: C/C++ knocks the crap out of Ada

[AdaWorks]

::::::

I have been reluctant to comment on this thread because of its origins. 
However, since many in the community that I respect have chosen to 
contribute, I feel more comfortable adding my humble observations.

If I understand the meaning of the word "crap," it seems to be argot for
something characterized by its fecal properties.  Therfore, I can only
assume that the designers of Ada 95, cognizant of those properties in
C++, studiously eliminated them from the design of Ada.  Consequently, my
interpretation of the caption for this thread is that Ada is now free of
the fecal matter that continues to reside in C++.  :-)

Richard Riehle
adaworks@netcom.com

richard@adaworks.com

-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: C/C++ knocks the crap out of Ada

[Ramses Youhana]

John Byerly (byerly_j@srm9.motsat.sat.mot.com) wrote:
> In article <4etcmm$lpd@nova.dimensional.com> cjames@melchizedek.cec-services.com (The Right Reverend Colin James III) writes:

You complain about someone elses logic being flawed when your logic is just as flawed.
Don't just read other peoples comments and take them at face value.  Try and understand
them first.

For example:

> > C/C++ is also superior for six, very practical reasons:  
> > 
> > 1.  C/C++ compilers which are industrial quality with professional
> > support are cheaper than the expensive, vendor-gouging Ada ones;  

> C/C++ is cheaper than Ada.  Does that mean that it is superior to Ada?  If so, let's
> follow the logic and grab a freeware compiler of some language, since it would be
> (by your logic) more superior to C/C++.

In the first posting, the writer does not say that the cheaper the product is the better
it is.  Instead he believes that C/C++ is better than Ada (for practical reasons) because
it is within more peoples reach, as C/C++ compilers and tools are cheaper than the equivalent
Ada compilers and tools.  As a result, it is more likely that there are more people out
there who use (and/or prefer to use) C/C++ than Ada.

How many Ada compilers and software tools are there out there for (say) writing Windows
applications, and how good are these applications compared with those of C/C++
compilers and tools (especially when you take value for money into account)?


> > 5. C/C++ jobs are more in demand and plentiful and easier to get and
> > in hundreds more US geographic areas than Ada jobs;

> Yes, and burger flipping jobs are even more plentiful than C/C++ jobs.  Once again,
> this has NO bearing on how effective a tool is.

C/C++ and Ada are software languages useful for writing programs.  Burgers are not.  If
you are a software programmer or a Software engineer, then C/C++ and Ada jobs are more
appropriate than are Burger flipping jobs.


Ramses.

Re: C/C++ knocks the crap out of Ada

[Ramses Youhana]

Ted Dennison (dennison@escmail.orl.mmc.com) wrote:
> Ramses Youhana wrote:
> > 
> > You'll be surprised how easily both junior (and senior) engineers can turn
> > both C/C++ and Ada programs into spaghetti code.  The language itself
> > doesn't make for a quality system.

> Quite true. But having "cleaned up" both, I can tell you Ada is MUCH 
> easier to detangle.

That's interesting.  Is this due to the language itself, or the way
the programs were written or both?  I have had to "detangle" other
peoples C code on many occasions.  Those that were well written
were very easy to fix, however, the majority were incredibly poorly
written.  These were very hard to fix, and in many cases, the code had
to be re-written.  All of these problems were due to the poor design and
coding habits of the programmer and not the C language.  I am wonderring
how much protection Ada provides against bad programmers and engineers.
I know that C doesn't provide much protection.  This is one reason why
it is important to design the system first (on paper) before one starts
coding.

Personally I don't wish to get involved in the "C/C++ is better than
Ada" debate.  I would however, like to hear both sides of the arguements.


Ramses.

Re: C/C++ knocks the crap out of Ada

[Ramses Youhana]

David Weller (dweller@dfw.net) wrote:
> In article <4g1bgf$l5@mailhub.scitec.com.au>,
> Ramses Youhana <ramsesy@rd.scitec.com.au> wrote:
> >Another thing not mentioned is that Ada is far more complicated to learn
> >fully than is C/C++.  The complexity of the language can add to an increase
> >in the probabilty of bugs being introduced and also adds to an increase in
> >project maintanace costs.
> >

> Compared to C++?  You are wrong.  There are fewer features in C++, yet
> the (draft) reference manual is larger than Ada 95 (not that this is
> necessarily a good measure, but rather that a language that is less
> complex would hopefully require less "langauge" to specify it).  My
> personal experience with Ada 95 and C++ indicates the exact opposite
> of your conclusion.  I have a feeling you haven't used Ada 95 very
> much to make such claims.

Sorry.  I had once heard that Ada was more complicated than C.  However, as
many people have posted and told me otherwise, I take the comment back.

However, I am interested in knowing what the advantages and disadvantages C/C++
and Ada (or Ada 95) languages have over each other, without having to buy a
book on Ada (as I am unlikely to use it in my profession), especially for
engineering applications.

Ramses.

Re: C/C++ knocks the crap out of Ada

[Ian S. Nelson]

ramsesy@rd.scitec.com.au (Ramses Youhana) writes:

>David Weller (dweller@dfw.net) wrote:
>> In article <4g1bgf$l5@mailhub.scitec.com.au>,
>> Ramses Youhana <ramsesy@rd.scitec.com.au> wrote:
>> >Another thing not mentioned is that Ada is far more complicated to learn
>> >fully than is C/C++.  The complexity of the language can add to an increase
>> >in the probabilty of bugs being introduced and also adds to an increase in
>> >project maintanace costs.
>> >

>> Compared to C++?  You are wrong.  There are fewer features in C++, yet
>> the (draft) reference manual is larger than Ada 95 (not that this is
>> necessarily a good measure, but rather that a language that is less
>> complex would hopefully require less "langauge" to specify it).  My
>> personal experience with Ada 95 and C++ indicates the exact opposite
>> of your conclusion.  I have a feeling you haven't used Ada 95 very
>> much to make such claims.

>Sorry.  I had once heard that Ada was more complicated than C.  However, as
>many people have posted and told me otherwise, I take the comment back.

>However, I am interested in knowing what the advantages and disadvantages C/C++
>and Ada (or Ada 95) languages have over each other, without having to buy a
>book on Ada (as I am unlikely to use it in my profession), especially for
>engineering applications.

I'm not an Ada ninja or anything, I've done a fair bit of coding in it though.
I've done a heap of coding in C++, I've been hacking around with it since
around 1990.  I'll try to start it off though...  (and if you are an engineer
then there is a decent chance that you might end up using Ada, it depends on
who you work for though.)

These are all religious issues to a lot of people.  It is possible, IMO, to 
write good C++ and to write crappy Ada.

For imparitive programming and in general:
	*  C++ is not strong typed.  You can point a string to an integer
	   to a float and the most you'll usually get is a compiler warning.
	   C coders can use that ability to do neat things but in terms of 
	   language design, I think it is more desirable to only allow those
	   kinds of conversions if you mean it. Bad things can happen.
	*  C++ functions can be anywhere.  On more than one occasion I have
	   had to result to using "grep" on a large directory of files because
	   a programmer decided to just throw it in to a file for no obvious
	   reason.  Ada coaxs programmers to put things together a little more.
	*  Ada makes it more clear on what parameters for functions (procedures
	   and functions) do and what happens to them.  It is not uncommon to
	   send a pointer to a function in C++ even though the function doesn't
	   change anything.   
	*  Here is a good religious issue: C and C++ pick lousy names for the
	   standard library functions and classes.
	*  Ada is case insensitive.  C and C++ both care about the case you
	   use.
	*  There are stylistic differences.  I can't think of a good way to
	   describe them.  When you design a big C++ program you do it 
	   differently than you do with Ada.  Surely someone else can explain
	   this more.  C++ code is structured into files, Ada is in packages,
	   they are just different in some holistic way.
	*  C++ templates and exceptions are a pretty new standard for the
	   language, until recently the compiler vendor decided how to handle 
	   them.  They aren't really in wide use yet.
	*  C++ won't let you range types: a la "type year is an integer from
	   -2000 to 2050" or like that.  
	*  C++ enums are still typically just integers, is this changing?
	*  C and C++ have macros, I don't think ada has a feature like that.
	*  I'm not sure if this is a compiler feature or an Ada feature, but
	   Ada pays more attention to header files when compiling.  With C++
	   you can change one header file and it won't recompile your source
	   files unless you tell it to in your makefile.  I think Ada will 
	   notice those changes.
	*  There is probably a larger amount of C and C++ code open to the 
	   public that you can draw from.
	*  There are more C and C++ compilers.
	*  There are more C and C++ books.
	*  There is a certification process for Ada compilers, you take the
	   vendor's word for it in the C++ world.

	add more if you think they are relevent.  Please correct me if I messed
	something up, today has been an overly productive code day and I'm 
	drained.  

For objects:
	Now this section is much more religious, that's just the nature of 
	OOP...

	*  Ada doesn't have multiple inheritance, at least I don't think it
	   does.  This is subjective, there are ways around it and
	   many people think it is "dangerous."  I kind of like to have it as
	   an option though, if my object model demands that an object has to 
	   superclasses then I want it.  More importantly, if my boss gives me
	   an object model with a class that has two parents then I want it.
	*  It's my opinion that Ada is more likely to bark at you if you 
	   forget to include a method.  I've written code that has outputed
	   pointer addresses to the screen because I didn't supply a method
	   and then I just threw in a cast because it gave me a warning.
	*  Here is another really religious issue.  When I get really tired and
	   I'm doing C++, I resort to doing stupid tricks to make things 
	   compile (I hate leaving code broken overnight)  when I get a
	   compiler error I, in advertantly, do something stupid to "fix" it.
	   When I get a clean ada compile, I feel better about the code.  When
	   I get a clean C++ compile I question my test methodology.  You can
	   always force C++ to compile even if it does something really stupid.
	*  Ada seems tobe easier to do large projects in.  In C++, it has been
	   my experience that work gets divided up between coders by class.
	   (eg: Bob, you do the string class.  Bill, you do the LZW class.
	   Sarah, you do the tree class... etc.) 
	*  I think I like the emacs mode for ada more than the C++ mode that I
	   have.  
	
	surely there is a lot more to be said about this.  I'm starting to
	have a lot of trouble typing so I'm going to stop now.

Ian

>Ramses.

Re: C/C++ knocks the crap out of Ada

[Richard A. O'Keefe]

ramsesy@rd.scitec.com.au (Ramses Youhana) writes:
>Another thing not mentioned is that Ada is far more complicated to learn
>fully than is C/C++.  The complexity of the language can add to an increase
>in the probabilty of bugs being introduced and also adds to an increase in
>project maintanace costs.

It is true  that Ada (95) is harder to learn fully than C.
It is FALSE that Ada (95) is harder to learn fully than C++.

To start with, C++ is still a moving target.  Anything I say about it today
may be false tomorrow (and in fact, since I don't have the current
committee draft, but only the April 95 version, so what I say today may be
false today).  More importantly, the C++ draft is written in much sloppier
language.  I don't believe _anyone_ fully understands C++.  (If they do,
why can't I find two compilers that agree about which programs are legal?)

(Actually, I am being generous about C.  Most C textbooks contain serious
factual errors, so if it is so easy to learn the language fully, why don't
the authors get their books right?)

Furthermore, it is not clear that anyone _needs_ to understand a programming
language fully.  I understand Ada fixed point arithmetic well enough to know
when it's appropriate and what it looks like, and what to study if I ever
find it to be appropriate.

The real flaw in the claim, though, is that while the complexity of a
language MIGHT lead to an increase in bugs being introduced, what really
counts is the probability of UNDETECTED bugs, and it should be obvious
that _in principle_ one language might be more complex than another and
yet permit far superior compile-time bug detection.  Whether the greater
complexity of C++ does in fact lead to such an advantage is of course an
empirical question.

-- 
Election time; but how to get Labour _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: C/C++ knocks the crap out of Ada

[Richard A. O'Keefe]

rav@goanna.cs.rmit.EDU.AU (++           robin) writes:
>---It's other things besides -- like, how to find a square root, how to do
>simple I/O.

How to do a square root:

Step 1 (applies to all programming languages)
    Look up square root in the manual.

Step 2 (applies to all programming languages)
    Do what the Fine Manual says.

In Ada, use the index, which points you to A.5.1, and do

	with Ada.Numeric_Elementary_Functions;
	use  Ada.Numeric_Elementary_Functions;

	...
	    sqrt(X)
	...

Section G.2.4 even gives you error bounds on the result, which no other
language standard I've checked does.  Just because of that, I'd rather
do a square root in Ada than anything else.

Simple I/O:

Step 1
    Look it up in the manual
Step 2
    Do what the Fine Manual says.

*SIMPLE* I/O involves withing and using a couple of standard packages,
and then using Put, New_Line, Get, and Skip_Line.  Pretty darned simple.
It has not been a problem for first-year students at this university.

Ada does not support Fortran-style formatted I/O, nor PL/I style
formatted or pictured I/O (but see Interfaces.COBOL).

-- 
Election time; but how to get Labour _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: C/C++ knocks the crap out of Ada

[Ken Garlington]

Jon S Anthony wrote:
> 
> So, does this mean that there are _no_ confirmed cases of probes lost due
> software?  If so, I'm impressed as software has just plain _got_ to be
> the weakest link in the chain.  1/2 :-)

Actually, I would say that system requirements are the weak link in the chain,
although the errors often tend to occur in software these days since more
requirements (and particularly the harder, more volatile requirements) tend to
be put in software.

Three cases near and dear to my heart:

For years, I have heard the story about how a "bug" in the F-16 flight control
computer caused it to roll to an inverted position when crossing the equator. I
have never found anything authoritative that exactly described the circumstances
(if anyone has this information, let me know); but there are two points to be
made about this:

  1. Until relatively recently, the F-16 flight control computer didn't have any
     software in it. It was an analog computer.

  2. Some people believe they heard this story in terms of the behavior of a
     handling qualities _simulation_ of the flight control system, in which
     the environment model only contained a part of the northern hemisphere. Someone
     decided to see what happened when you "flew off the edge of the earth."

The other two cases are more recent and involve pilot-induced oscillations leading
to an aircraft crash. In both cases, the press widely reported (in at least one
case, quoting a senior executive at one company) that "the software got confused."
However, the error in both cases was due to an interaction of the control law model, 
which can be implemented in either hardware or software, and the pilot. (The pilot 
will probably say the control laws were wrong; the control law people will probably 
say that the pilot operated the system outside its' limits. Both are probably right 
:). Nonetheless, because the behavior occured in software, that's what gets the 
blame.

Dr. Levison's "Safeware" defines far issue much better than I just did, BTW.

Re: C/C++ knocks the crap out of Ada

[Lee Graba]

In article <312992F6.588D@lfwc.lockheed.com>,
	Ken Garlington <GarlingtonKE@lfwc.lockheed.com> writes:
>Jon S Anthony wrote:
>> 
>> So, does this mean that there are _no_ confirmed cases of probes lost due
>> software?  If so, I'm impressed as software has just plain _got_ to be
>> the weakest link in the chain.  1/2 :-)
>
>Actually, I would say that system requirements are the weak link in the chain,
>although the errors often tend to occur in software these days since more
>requirements (and particularly the harder, more volatile requirements) tend to
>be put in software.
>
>Three cases near and dear to my heart:
>
>For years, I have heard the story about how a "bug" in the F-16 flight control
>computer caused it to roll to an inverted position when crossing the equator. I
>have never found anything authoritative that exactly described the circumstances
>(if anyone has this information, let me know); but there are two points to be
>made about this:
>
>  1. Until relatively recently, the F-16 flight control computer didn't have any
>     software in it. It was an analog computer.

Actually, the F-16A had a hybrid flight control computer.  The primary flight
control functions were performed by an analog computer, but some flight control
gains were scheduled with respect to flight condition by a digital computer and
fed to the analog computer.  However, setting gains should not cause the above-
described phenomenon.

If such a thing did occur, it would probably be due to the Navset, which is 
usually a separate digital computer whose responsibility is to take 
measurements and then compute positions and attitudes, and associated rates.
A software error here might cause a problem, if say, it was telling the flight
control computer that it was flying straight and level, and suddenly told it
that it was really upside down.  The flight control computer would then try
to right the plane, since it doesn't know good information from bad.

I have heard the above story, as well, but don't know if it is true.

>
>  2. Some people believe they heard this story in terms of the behavior of a
>     handling qualities _simulation_ of the flight control system, in which
>     the environment model only contained a part of the northern hemisphere. Someone
>     decided to see what happened when you "flew off the edge of the earth."
>
>The other two cases are more recent and involve pilot-induced oscillations leading
>to an aircraft crash. In both cases, the press widely reported (in at least one
>case, quoting a senior executive at one company) that "the software got confused."
>However, the error in both cases was due to an interaction of the control law model, 
>which can be implemented in either hardware or software, and the pilot. (The pilot 
>will probably say the control laws were wrong; the control law people will probably 
>say that the pilot operated the system outside its' limits. Both are probably right 
>:). Nonetheless, because the behavior occured in software, that's what gets the 
>blame.
>
>Dr. Levison's "Safeware" defines far issue much better than I just did, BTW.

Re: C/C++ knocks the crap out of Ada

[Matt Austern]

In article <4g8ook$bce@mailhub.scitec.com.au> ramsesy@rd.scitec.com.au (Ramses Youhana) writes:

> Sorry.  I had once heard that Ada was more complicated than C.  However, as
> many people have posted and told me otherwise, I take the comment back.
> 
> However, I am interested in knowing what the advantages and disadvantages C/C++
> and Ada (or Ada 95) languages have over each other, without having to buy a
> book on Ada (as I am unlikely to use it in my profession), especially for
> engineering applications.

You've asked two questions, not one: C and C++ are very different
languages.  C and C++ both have strong points and weak points, but you
definitely should not confuse them.
-- 
Matt Austern
SGI: MTI Compilers Group
austern@isolde.mti.sgi.com

Re: C/C++ knocks the crap out of Ada

[Ketil Z Malde]

>>>>> "Nasser" == Nasser Abbasi <nabbasi@qualcomm.com> writes:

    Nasser> Given 2 equally good programmers one in C++ and one in
    Nasser> Ada, most people will agree that Ada code is easier to
    Nasser> read than the C++ code.
	:	:	:
    Nasser> A code that is easier to read, is easier to maintain.

I'm certainly not qualified to parttake in this fla^H^H^Hheated debate
about Ada vs. C++ -- however, I believe Booch (in "Object oriented
analysis and design") cites an example program that shrunk 90% when
recoded into C++ from Ada.  Question is, is this typical?  And if so,
is it easier to read/maintain 100K lines of Ada than 10K lines C++?

-kzm

Re: C/C++ knocks the crap out of Ada

[Ed Franks]

In article <4gaa6l$8mk@post.gsfc.nasa.gov>,
   Mike Stark <michael.e.stark@gsfc.nasa.gov> wrote:
>jsa@organon.com (Jon S Anthony) wrote:
>>In article <4g1b7n$l5@mailhub.scitec.com.au> ramsesy@rd.scitec.com.au 
(Ramses Youhana) writes:
>>
>>> You'll be surprised how easily both junior (and senior) engineers can turn
>>> both C/C++ and Ada programs into spaghetti code.  The language itself
>>> doesn't make for a quality system.
>>
>>Yes, but there are degrees of ease with which this can be done.  I think
>>that was more to the point.
>>
>>
>>> Didn't NASA loose a satelite due to a bug in a piece of Ada code?
>>
>>I don't think so.  I believe that the only confirmed case of a probe
>>loss due to software was a Venus probe which had Fortran code (the
>>problem was a "lexical" error concerning spaces not acting as lexical
>>separators).  The recent Mars probe that "vanished" was (last I saw)
>>thought to have been lost due to a small rupture in one of the on board
>>tanks.  This caused the ship to go into uncontrolled tumbling.  I don't
>>know what it was programmed with.
>>
>>/Jon
>>-- 
>>Jon Anthony
>>Organon Motives, Inc.
>>1 Williston Road, Suite 4
>>Belmont, MA 02178
>>
>>617.484.3383
>>jsa@organon.com
>>
>
>Folks --
>
>The mere fact that Ada (or any other language) is used for a satellite does 
not
>guarantee that the software is reliable enough -- there is far more to 
engineering
>flight qualified software.  That being said, I would prefer a language that 
can
>use exception handling to recover from anomalies such as bit flips caused by
>cosmic rays, and that doesn't allow unrestricted address arithmetic to 
>(potentially) store data into the code currently in memory.  Ada isn't the 
only
>language designed for high reliability (Java and Eiffel leap to mind), but if 
I
>were a satellite project manager I would certainly prefer it to C or C++.
  
Yes, but you are not. Meanwhile, the software for the Mission Control Center 
(MOC) at NASA Johnson Space Center is being rewritten in C++, not ADA.

>
>Mike
>
>-----------------------------------------------------------------------
>Michael Stark                                     NASA/GSFC                  
                         
>Phone: (301) 286-5048                             Code 552
>Fax:   (301) 286-0245                             Greenbelt, MD 20771
>e-mail: michael.e.stark@gsfc.nasa.gov

Ed Franks

Re: C/C++ knocks the crap out of Ada

[Ketil Z Malde]

Since, as you say, these issues are religious, here's a little
gospelling -- hope I don't miss the mark entirely:

Ian said:

For imparitive programming and in general:
	*  C++ is not strong typed.  You can point a string to an integer
	   to a float and the most you'll usually get is a compiler warning.

Don't you need a cast to do this?!?

	*  C++ functions can be anywhere.  On more than one occasion I have
	   had to result to using "grep" on a large directory of files because
	   a programmer decided to just throw it in to a file for no obvious
	   reason.

This is, of course true.  Use [ce]tags, or some other scheme to
navigate your source code.

	*  Ada makes it more clear on what parameters for functions (procedures
	   and functions) do and what happens to them.  It is not uncommon to
	   send a pointer to a function in C++ even though the function doesn't
	   change anything.

..which is why you declare it as "const" (even though I know you can
probably still fool it)

	*  Here is a good religious issue: C and C++ pick lousy names for the
	   standard library functions and classes.

Whatever.

	*  Ada is case insensitive.  C and C++ both care about the case you
	   use.

I care, too, so that suits me fine.  Matter of taste?

	*  There are stylistic differences. [...]
	*  C++ templates and exceptions are a pretty new standard for the
	   language, until recently the compiler vendor decided how to handle 
	   them.  They aren't really in wide use yet.

Hmm...I think templates are coming along nicely, at least the STL
seems to gain some foothold, don't you think?  Any compilers *still*
not supporting templates?  I doubt it.

	*  C++ won't let you range types: a la "type year is an integer from
	   -2000 to 2050" or like that.

But you can easily write one yourself, and make your own choices when
there's a tradeoff between flexibility and performance.

	*  C++ enums are still typically just integers, is this
           changing?

I believe so -- though don't bet on it.

	*  C and C++ have macros, I don't think ada has a feature like
           that.

I thought macros were bad?  Anyway, I think cpp adds some nice
features every now and again.

[...]

	*  I think I like the emacs mode for ada more than the C++ mode that I
	   have.  
	
I do wish cc-mode would support highlighting template definitions as
well, yes.

-kzm

Re: C/C++ knocks the crap out of Ada

[Ted Dennison]

Ketil Z Malde wrote:
> 
> I'm certainly not qualified to parttake in this fla^H^H^Hheated debate
> about Ada vs. C++ -- however, I believe Booch (in "Object oriented
> analysis and design") cites an example program that shrunk 90% when
> recoded into C++ from Ada.  Question is, is this typical?  And if so,
> is it easier to read/maintain 100K lines of Ada than 10K lines C++?


I believe that was when it was recoded into Ada (95). If I remember
correctly, the size of the Ada 83 version was even longer. Ada (95)
has not been around long enough to have any real reliable numbers about
how typical this is.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

Richard said

Ada does not support Fortran-style formatted I/O, nor PL/I style
formatted or pictured I/O (but see Interfaces.COBOL).

Wrong advice, Ada 95 DOES spport COBOL-style pictures, see the information
systems annex. I am not sure what "pictured I/O" is (COBOL certainly does
not have it! But both COBOL and Ada 95 provide facilities for the use of
pictures to edit alphanumeric data (this data can certainly be output
after it is edited :-)

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

"So, does this mean that there are _no_ confirmed cases of probes lost due
software?  If so, I'm impressed as software has just plain _got_ to be
the weakest link in the chain.  1/2 :-)"

Not true. It is perfectly possible to write reliable software, although
it is an expensive process. Think about airline crashes and space disasters,
far more problems have been caused by mechanical failures (e.g. Apollo 13,
Challenger, the loss of the early Comet's etc) than by software failure.

Re: C/C++ knocks the crap out of Ada

[Andrew Koenig]

In article <4gb4r3$psg@qualcomm.com> x!news.be.innet.net!INbe.net!usenet writes:

> Given 2 equally good programmers one in C++ and one in Ada, most 
> people will agree that Ada code is easier to read than the C++ code.

Most?  I have yet to meet anyone who knows both Ada and C++
well enough to be able to make a reasoned comparison.
-- 
				--Andrew Koenig
				  ark@research.att.com

Re: C/C++ knocks the crap out of Ada

[Nasser Abbasi]

In article <4gad29$ddp@druid.borland.com>, pete@borland.com (Pete Becker) says:
>
>In article <312515DF.7D3B@cmlj.demon.co.uk>, chris@cmlj.demon.co.uk says...
>>
>>With regards to maintenance, there's many people out there who consider 
>>C/C++ a Write only language.
>
>How many of the people who say this have actually used C++ enough to 
>understand it? I know it's popular today to dump on C++, but my experience has 
>been that most of the people who produce one-liners like this simply don't 
>know what they're talking about. If relying on that sort of ignorance is the 
>best you can do to defend ADA, so be it. But I'll bet that if you try you can 
>come up with arguments that are actually based on fact. Those would lead to a 
>much more interesting and useful discussion.
>

Given 2 equally good programmers one in C++ and one in Ada, most 
people will agree that Ada code is easier to read than the C++ code.

(Ada is sometimes used to write algorithm in becuase of its clarity,
even though the actual algorithm will be coded in another language).

I have been programming officialy for about 13 years now, and 
programmed in about 7-8 languages an average of 1-3 years each, and 
I can say that I found Pascal and Ada code the easist to read, 
followed by FORTRAN and PLI followed by SNOBOL followed by C/C++ and 
LISP and BLISS and finally assembler.

A code that is easier to read, is easier to maintain.

Nasser

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

In article <dewar.824610024@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:

> Robin said
> 
> "---It's other things besides -- like, how to find a square root, how to do
> simple I/O.
> __________________________________________________________________________
> 
> both these things are trivial in Ada 95, certainly not something students
> have problems with, even right at the start, Robin what are you talking
> about. 

He's talking about how little he knows the language and how much he
likes to pontificate on it despite this (rather obvious) fact.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

In article <4g966j$cr8@goanna.cs.rmit.EDU.AU> ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes:

> Simple I/O:
> 
> Step 1
>     Look it up in the manual
> Step 2
>     Do what the Fine Manual says.
> 
> *SIMPLE* I/O involves withing and using a couple of standard packages,
> and then using Put, New_Line, Get, and Skip_Line.  Pretty darned simple.
> It has not been a problem for first-year students at this university.
> 
> Ada does not support Fortran-style formatted I/O, nor PL/I style
> formatted or pictured I/O (but see Interfaces.COBOL).

For most naive (first time users) needs it is even simpler than this.
Here, again, is a version in C and Ada of a simple first program:

First, the Ada (14 lines):

with Ada.Command_Line;  use Ada.Command_Line;
with Text_Io;  use Text_Io;
 
procedure X is
 
begin
    Put_Line(
        "My name is " & Command_Name & ", I have" &
        Integer'Image(Argument_Count) & " arguments.");
    Put_Line("They are: ");
    for I in 1..Argument_Count loop
        Put_Line("  " & Argument(I));
    end loop;
end;

$ gnatmake $tests_wrk/x.adb
$ x 1 2 3
My name is x, I have 3 arguments.
They are: 
  1
  2
  3


Now the C (14 lines):

#include <stdio.h>
 
main (argc, argv)
    int argc;
    char *argv[];
 
{
    int i;
 
    printf ("My name is %s, I have %d arguments \n", argv[0], argc-1);
    printf ("They are: \n");
    for (i = 1; i < argc; i++)
    printf("  %s\n", argv[i]);
}

$ gcc -o cx cx.c
$ cx 1 2 3
My name is cx, I have 3 arguments 
They are: 
  1
  2
  3


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

In article <DMwFqr.EGD@thomsoft.com> kst@thomsoft.com (Keith Thompson) writes:

> The story that a Venus probe was destroyed by a Fortran error has been
> widely propagated, but it's inaccurate.  The probe in question was
> Mariner 1, which was destroyed 4 minutes after launch on July 22, 1962.

So, does this mean that there are _no_ confirmed cases of probes lost due
software?  If so, I'm impressed as software has just plain _got_ to be
the weakest link in the chain.  1/2 :-)


[neat info snipped...]


/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C/C++ knocks the crap out of Ada

[Matthew M. Lih]

Ed Franks wrote:

> >(potentially) store data into the code currently in memory.  Ada isn't the
> only
> >language designed for high reliability (Java and Eiffel leap to mind), but if
> I
> >were a satellite project manager I would certainly prefer it to C or C++.
> 
> Yes, but you are not. Meanwhile, the software for the Mission Control Center
> (MOC) at NASA Johnson Space Center is being rewritten in C++, not ADA.

My initial reaction to this piece of news is: Great. Another technical decision
from the same people who brought you frozen O-rings.

However, trying to keep an open mind, does anyone know what the justification
for this was?


Matthew M. Lih
Software Lead, SAIN Project
TRW Enterprise Solutions

Re: C/C++ knocks the crap out of Ada

[Mark A Biggar]

In article <4gd3ui$6fi@moon.src.honeywell.com> graba@htc.honeywell.com (Lee Graba) writes:
>In article <312992F6.588D@lfwc.lockheed.com>,
>	Ken Garlington <GarlingtonKE@lfwc.lockheed.com> writes:
>>Jon S Anthony wrote:
>>  1. Until relatively recently, the F-16 flight control computer didn't have any
>>     software in it. It was an analog computer.
>
>Actually, the F-16A had a hybrid flight control computer.  The primary flight
>control functions were performed by an analog computer, but some flight control
>gains were scheduled with respect to flight condition by a digital computer and
>fed to the analog computer.  However, setting gains should not cause the above-
>described phenomenon.
>
>If such a thing did occur, it would probably be due to the Navset, which is 
>usually a separate digital computer whose responsibility is to take 
>measurements and then compute positions and attitudes, and associated rates.
>A software error here might cause a problem, if say, it was telling the flight
>control computer that it was flying straight and level, and suddenly told it
>that it was really upside down.  The flight control computer would then try
>to right the plane, since it doesn't know good information from bad.
>
>I have heard the above story, as well, but don't know if it is true.

I believe that this is listed in the Risks list that appears the ACM SIGSEM.

The way I heard it, was that this never happen in an actual plane but was a
bug in a early version of the autopilot simulation system.

--
Mark Biggar
mab@wdl.loral.com

Re: C/C++ knocks the crap out of Ada

[David Weller]

In article <4geaac$bh6@qualcomm.com>,
Nasser Abbasi <x!news.be.innet.net!INbe.net!usenet> wrote:
>In article <4gd94r$isu@mack.rt66.com>, egf@Rt66.com (Ed Franks) says:
>
>>Meanwhile, the software for the Mission Control Center 
>>(MOC) at NASA Johnson Space Center is being rewritten in C++, not ADA.
>
>Can any one else confirm this? How large is this software project?
>

I can confirm it.  In fact, I can also confirm that NASA/JSC is
flocking as rapidly as possible to C++.  WIth the exception of some
flight software on the space station, and the space station simulator,
you'd be hard-pressed to find Ada.  In fact, rumor has it that
NASA/JSC is pressuring the last "non-flight-software" Ada developers
to "consider" switching to C/C++.

Ada is indeed dead and unwell at JSC.  YOu really need look no further
than the "satellite" university, University of Houston at Clear
Lake...a considerable amount of NASA-, and NASA-contractor-funded
research work is in C++, despite UHCL once being one of, if not _the_,
strongest supporter of Ada in the late 80's.

And, just to keep the facts straight, Ada is NOT a "mandated" language
within NASA.  At one point in time, there was a policy that it was
"preferred", but that policy is clearly moot.

-- 
		    GNAT = GNAT is Not an Ada Translator
==Ada 95 Booch Components: www.ocsystems.com/booch or www.dfw.net/~dweller==
Reality: Work, Work, Work, Guitar.         | Plugged: Fender Telecaster Deluxe
Fantasy: Guitar, Guitar, Guitar, Work(ha!) | Unplugged: Yamaha CG-150SA

Re: C/C++ knocks the crap out of Ada

[David Weller]

In article <dirk.824894312@demokrit>,
Dirk Dickmanns <dirk@demokrit.informatik.unibw-muenchen.de> wrote:
>>I'm certainly not qualified to parttake in this fla^H^H^Hheated debate
>>about Ada vs. C++ -- however, I believe Booch (in "Object oriented
>>analysis and design") cites an example program that shrunk 90% when
>>recoded into C++ from Ada.  Question is, is this typical?  And if so,
>>is it easier to read/maintain 100K lines of Ada than 10K lines C++?
>

That comparison was with Ada 83.  My experience is that you can write
fewer lines of Ada 95 to do the same thing in C++ (see my Booch
Components homepage).  SO, the question should be:
It it easier to maintain 9K of Ada 95 than 10K of C++?

(In reality, it's a silly argument, but I just get tired of seeing
those _extremely old_ statistics of C++ vs Ada being quoted, because 
all those comparisons are of C++ vs Ada 83)
-- 
		    GNAT = GNAT is Not an Ada Translator
==Ada 95 Booch Components: www.ocsystems.com/booch or www.dfw.net/~dweller==
Reality: Work, Work, Work, Guitar.         | Plugged: Fender Telecaster Deluxe
Fantasy: Guitar, Guitar, Guitar, Work(ha!) | Unplugged: Yamaha CG-150SA

Re: C/C++ knocks the crap out of Ada

[Nasser Abbasi]

In article <4gd94r$isu@mack.rt66.com>, egf@Rt66.com (Ed Franks) says:

>Meanwhile, the software for the Mission Control Center 
>(MOC) at NASA Johnson Space Center is being rewritten in C++, not ADA.

Can any one else confirm this? How large is this software project?

thanks,
Nasser

Re: C/C++ knocks the crap out of Ada

[Robert S. White]

In article <312992F6.588D@lfwc.lockheed.com>, GarlingtonKE@lfwc.lockheed.com 
says...
>For years, I have heard the story about how a "bug" in the F-16 flight 
control
>computer caused it to roll to an inverted position when crossing the 
equator. I
>have never found anything authoritative that exactly described the 
circumstances
>(if anyone has this information, let me know)

I've heard this story many, many times.  And it has always be attributed to a 
sign error ( wrong handleing of - ) rather than any language error.  Sign 
errors have been the worst bug-a-boo in the building that I have worked in 
for the last ten years.  And no computer language has yet solved this 
problem!
-- 
___________________________________________________________________________
Robert S. White                    -- an embedded systems software engineer
WhiteR@CRPL.Cedar-Rapids.lib.IA.US -- It's long, but I pay for it!
---------------------------------------------------------------------------

Re: C/C++ knocks the crap out of Ada

[Ramses Youhana]

Richard A. O'Keefe (ok@goanna.cs.rmit.EDU.AU) wrote:
> ramsesy@rd.scitec.com.au (Ramses Youhana) writes:
> >Another thing not mentioned is that Ada is far more complicated to learn
> >fully than is C/C++.  The complexity of the language can add to an increase
> >in the probabilty of bugs being introduced and also adds to an increase in
> >project maintanace costs.

> It is true  that Ada (95) is harder to learn fully than C.
> It is FALSE that Ada (95) is harder to learn fully than C++.
> <snip>

Since I posted the above, I've been flamed by every man and his dog.  The comment
was based on something I was told at UNI by one of the lecturers, and not out of
my own experience.  I realise it was a stupid comment, however, I wasn't attempting
to put Ada down.  I've also received mail messages from people out there, and in
particular, one who stated that I could probably learn Ada in about one week.
I really don't know how difficult the language is to learn, however, from what
you all have said about it, I'm interested in learning it.  Can anyone suggest
any good books on it (one that reasonably priced) and possibly a good compiler
for a PC.

Also, according to many of the postings, I'm being given the impression that there
are plenty of engineering jobs for Ada.  I've been looking in the job ads (in Sydney,
Australia) and I can't seem to find many Ada jobs (as compared with C and C/C++ jobs)
for engineers.  I'm interested to know where these jobs are.

Ramses.

Re: C/C++ knocks the crap out of Ada

[Jay Martin]

ark@research.att.com (Andrew Koenig) writes:

>In article <4gb4r3$psg@qualcomm.com> x!news.be.innet.net!INbe.net!usenet writes:

>> Given 2 equally good programmers one in C++ and one in Ada, most 
>> people will agree that Ada code is easier to read than the C++ code.

>Most?  I have yet to meet anyone who knows both Ada and C++
>well enough to be able to make a reasoned comparison.
>-- 
>				--Andrew Koenig
>				  ark@research.att.com

Baah!  What you really saying is that you have not met any Ada people.

I know both (well Ada83 and some of the new features of Ada95).  I
have been using only C++ for the last few years.  And anyone with a
basic understanding of imperative software engineering language design
will acknowledge that Ada has better readability characteristics over
C/C++. (Unfortunately, what CS program actually teaches,researches or
cares about imperative computer language design?) Ada was designed for
readability, C (and C++) was designed for hacking in an evolutionary
manner.  Just read "Evolution...C++" when BS starts talking about
brain damaged or broken features or "too cute for its own good" or
"the anti-keyword militia" or "backwards (philosophic) compatibility",
its a good indication of a place where readability/understandability
suffered in C++.

Jay

Re: C/C++ knocks the crap out of Ada

[Nasser Abbasi]

In article <Dn3Krz.6yw@research.att.com>, ark@research.att.com (Andrew Koenig) says:
>
>In article <4gb4r3$psg@qualcomm.com> x!news.be.innet.net!INbe.net!usenet writes:
>
>> Given 2 equally good programmers one in C++ and one in Ada, most 
>> people will agree that Ada code is easier to read than the C++ code.
>
>Most?  I have yet to meet anyone who knows both Ada and C++
>well enough to be able to make a reasoned comparison.
>-- 

Does one really need to be a guru in both languages to observe that
one is more readable than the other?

I was not talking about a comprehensive comparison. I was only talking
about the readability (sp?) aspect of the languages. 

Nasser

Re: C/C++ knocks the crap out of Ada

[Nasser Abbasi]

From "Improving software economics in the aerospace and defense industry:

A technical paper by Mike Devlin, Chairman and Walker Royce, director 
of software-engineering process. Rational corp.  1995.


"The definition of the Ada language is unique in that it was designed
to enable better management, design, and architectural control -- the
higher-leverage aspects of software engineering -- while sacrificing
some ease of programming.

This is the essence of the Ada culture: top-down control where
programmers are subordinates of the lead architects and managers.

Other languages -- specifically C++ -- focus on simplifying the
programming activities while sacrificing some of the ease of control.

This, of course, is the essence of the C/C++ culture where programmers
lead the way.

For small programs and noncritical projects, the C++ culture can work 
well, and the Ada culture is perhaps overkill. For large, complex, 
mission-critical systems, though, the Ada culture is a field-proven
necessity for success.

Culture is a set of trends imposed by humans. Clearly, an Ada culture
can be practiced by C++ and vice versa, but the paradigm shift for an
organization with cultural inertia is an emotional and extremely 
difficult undertaking"


Nasser.

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

Ketil asks

"I'm certainly not qualified to parttake in this fla^H^H^Hheated debate
about Ada vs. C++ -- however, I believe Booch (in "Object oriented
analysis and design") cites an example program that shrunk 90% when
recoded into C++ from Ada.  Question is, is this typical?  And if so,
is it easier to read/maintain 100K lines of Ada than 10K lines C++?"

It's easy to get confused in this debate (even for the qualified :-)
but you are suffering from overloading confusion. The language we discuss
these days is Ada 95. When you see Ada with no further qualification in
this newsgroup, you have to scratch your head and figure out if the author
means Ada 83 or Ada 95, and if this is not clear ask!

In this case, Booch is comparing Ada 83 to C++, and the reduction in size
comes from two sources. First, the rewriting itself cleaned things up, the
original Ada 83 could definitely be reduced in size. Secondly, and more
importantly, the C++ version uses type extension and inheritance. These
features were not available in Ada 83, but are now available in Ada 95.

At NYU, as part of the IAT work, we looked at the Booch components in both
Ada 83 and C++, and concluded that a full implementation of these components
in Ada 95 would be about the same size as the implementation in C++, while
retaining the usual advantages of Ada 95 (greater safety and improved
readability).

It will help in this newsgroup if everyone makes sure to say Ada 83 when they
mean Ada 83!

Re: C/C++ knocks the crap out of Ada

[Peter Seebach]

In article <4g95c4$bhp@goanna.cs.rmit.EDU.AU>,
Richard A. O'Keefe <ok@goanna.cs.rmit.EDU.AU> wrote:
>(Actually, I am being generous about C.  Most C textbooks contain serious
>factual errors, so if it is so easy to learn the language fully, why don't
>the authors get their books right?)

Mostly because they're incompetent.  C is not a fast-moving target, but it has
moved some.  Many of the foolish things that have been said probably were true
once, and the remainder are people who naively assume that testing something
tells you whether or not it works.  :)

I have seen several decent books.  Between _The C Programming Language_
and _C Traps and Pitfalls_, I see no serious issues.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1995 Peter Seebach.
C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
FUCK the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.txt

Re: C/C++ knocks the crap out of Ada

[Dirk Dickmanns]

ketil@ii.uib.no (Ketil Z Malde) writes:

...

>I'm certainly not qualified to parttake in this fla^H^H^Hheated debate
>about Ada vs. C++ -- however, I believe Booch (in "Object oriented
>analysis and design") cites an example program that shrunk 90% when
>recoded into C++ from Ada.  Question is, is this typical?  And if so,
>is it easier to read/maintain 100K lines of Ada than 10K lines C++?

My 2 Pfennig: It would have shrunk to 10 KLOC in all of Ada, C++,
Eiffel, Sather, whatever during recoding.  Maybe we have some kind of
code compressors, but up to now any recode I saw shrunk a lot and was
-- even if done by me -- not neccessarily less readable.

Dirk

--
Dirk Dickmanns -- real-time dynamic computer vision
Sun OS 4.1.3; PC Linux; Transputers -- embedded
Ada 95, Ada 83, OCCAM2/3, ANSI C, Eiffel 3, PROLOG

Re: C/C++ knocks the crap out of Ada

[Peter Seebach]

In article <4g95c4$bhp@goanna.cs.rmit.EDU.AU>,
Richard A. O'Keefe <ok@goanna.cs.rmit.EDU.AU> wrote:
>(Actually, I am being generous about C.  Most C textbooks contain serious
>factual errors, so if it is so easy to learn the language fully, why don't
>the authors get their books right?)

Mostly because they're incompetent.  C is not a fast-moving target, but it has
moved some.  Many of the foolish things that have been said probably were true
once, and the remainder are people who naively assume that testing something
tells you whether or not it works.  :)

I have seen several decent books.  Between _The C Programming Language_
and _C Traps and Pitfalls_, I see no serious issues.

(K&R2 does have a couple of sample programs that use a non-standard qsort()
which they defined, but they do point out that the standard library provides
one.  I have seen this lead foolish programmers to make mistakes, but only
rarely.)

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1995 Peter Seebach.
C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
FUCK the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.txt

Re: C/C++ knocks the crap out of Ada

[Peter Seebach]

In article <4g8ook$bce@mailhub.scitec.com.au>,
Ramses Youhana <ramsesy@rd.scitec.com.au> wrote:
>David Weller (dweller@dfw.net) wrote:
>> Compared to C++?  You are wrong.  There are fewer features in C++, yet
>> the (draft) reference manual is larger than Ada 95 (not that this is
>> necessarily a good measure, but rather that a language that is less
>> complex would hopefully require less "langauge" to specify it).  My
>> personal experience with Ada 95 and C++ indicates the exact opposite
>> of your conclusion.  I have a feeling you haven't used Ada 95 very
>> much to make such claims.

>Sorry.  I had once heard that Ada was more complicated than C.  However, as
>many people have posted and told me otherwise, I take the comment back.

Don't.  It's entirely correct.  Let's distinguish:
1.  Ada is more complicated than C.
2.  It is debatable wheter or not Ada is more complicated than C++.

A concise reference for C, tolerably complete, could be done easily in 272
pages, including copious examples, exercises, and a reasonably complete
tutorial for the language.  A standard, complete in every detail, would
probably be about 220 pages, including the updates produced by the committe
since then, and could probably be trimmed if they assumed the reader is
familiar with programming languages and computers.  :)  Once again, including
examples.

These are not made up numbers; K&R, including all of the exercises and
examples, is a mere 272 pages.  It's very close to a suitable and complete
reference.  The version of the standard I have is 217 pages, and could
probably be trimmed quite a bit without real loss.

*C and C++ are different languages.*

At this point, I do not know Ada and C++ well enough to judge which is more
complex; they are both, however, orders of magnitude more complicated than
plain old C.

This is not necessarily a bad thing; what I write in is considerably more
complex than pidgin English.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1995 Peter Seebach.
C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
FUCK the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.txt

Re: C/C++ knocks the crap out of Ada

[@ 1996-02-21 0:00 UTC (permalink / raw)]

> >I'm certainly not qualified to parttake in this fla^H^H^Hheated debate
> >about Ada vs. C++ -- however, I believe Booch (in "Object oriented
> >analysis and design") cites an example program that shrunk 90% when
> >recoded into C++ from Ada.  Question is, is this typical?  And if so,
> >is it easier to read/maintain 100K lines of Ada than 10K lines C++?

PLEASE Ketil,

do yourself a big favor and check thoroughly on this quote !!! (:-)
Booch commented on the design in Ada83, not Ada95 ! 
If you want the "real deal" comparison check out :
 " http://ocsystems.com/booch/booboo.html " ( Thanks to David Weller ).
Afterwards I am sure that this discussion will be settled.


CU,

Ralph Paul

	ralph@ifr.luftfahrt.uni-stuttgart.de

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

In article <312992F6.588D@lfwc.lockheed.com> Ken Garlington <GarlingtonKE@lfwc.lockheed.com> writes:

***Definitely off topic, but:

> The other two cases are more recent and involve pilot-induced
> oscillations leading to an aircraft crash. In both cases, the press
> widely reported (in at least one case, quoting a senior executive at
> one company) that "the software got confused."  However, the error
> in both cases was due to an interaction of the control law model,
> which can be implemented in either hardware or software, and the
> pilot. (The pilot will probably say the control laws were wrong; the
> control law people will probably say that the pilot operated the
> system outside its' limits. Both are probably right :).

From experience I can say that PIO can definitely "suck you in" under
certain circumstances.  In particular, when flying formation as wing
in, say parade position, you can think relative motion to lead is due
to lead not being "smooth" when in fact it is you who are flailing
around and causing the problem to get worse with each "correction".
Of course this only happens in early training. :-)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C/C++ knocks the crap out of Ada

[AdaWorks]

anh@kuhub.cc.ukans.edu wrote:
: Hello,

: Please list a few strong points of ADA as compared to C/C++. What is
: the signature of an ADA program? I am seriously interested in ADA. Thank-you.

: Anh

  I do not know if there is any such thing as a "best" programming
  language, but here is the fundamental, underlying rationale for
  the design of Ada.

      1. The compiler should identify and reject the maximum number of
         errors before they ever get to the "debugging" stage.  

      2. The run-time environment should identify any error that occurs
         during execution and provide a way for the program to handle it.

  The language is designed to maximize those two goals.  Some people don't
  like this.  So be it.  Others do like it. Fine.  

  If you are looking for a language that catches the largest number of errors
  during compilation, choose Ada.  If your goals are different. Choose 
  something else.  

  As for the question about whether Ada can be used to actually build 
  reliable software, that question has been asked and answered many times
  over with the large number of deployed Ada software systems in a variety
  of real-time, real-time embedded, and other applications. 

  Why is there so much fuss about this?  Ada works.  C++ works. C works. 
  Eiffel works.  Smalltalk works.  They simply emphasize different things.
  Pick the tool that puts emphasis on what you want.  Isn't that simple?

  Richard Riehle
  adaworks@netcom.com

-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: C/C++ knocks the crap out of Ada

[Ken Garlington]

Lee Graba wrote:
> 
> >  1. Until relatively recently, the F-16 flight control computer didn't have any
> >     software in it. It was an analog computer.
> 
> Actually, the F-16A had a hybrid flight control computer.  The primary flight
> control functions were performed by an analog computer, but some flight control
> gains were scheduled with respect to flight condition by a digital computer and
> fed to the analog computer.  However, setting gains should not cause the above-
> described phenomenon.

You're right - by analog, I meant that the gains were computed as analog values. The
key statement, of course, is that there was no software in it anywhere. The gain
scheduling was done via digital non-programmable electronic circuitry. AFTI/F-16 was
the first F-16 flight control computer to contain software; it was called the digital
flight control computer (and we called the older computer the _analog_ system
to distringuish it, even though it did it include digital circuits). The Block 40
system was called the _production_ digital flight control system, BTW. Since
all of our newer systems contain software, we now drop the "digital" part
and just talk about "the flight control system".

> If such a thing did occur, it would probably be due to the Navset, which is
> usually a separate digital computer whose responsibility is to take
> measurements and then compute positions and attitudes, and associated rates.
> A software error here might cause a problem, if say, it was telling the flight
> control computer that it was flying straight and level, and suddenly told it
> that it was really upside down.  The flight control computer would then try
> to right the plane, since it doesn't know good information from bad.

Well, a single-point Navset failure would be detected, but a generic software
fault in an IRS system might not. However, no one has ever been able to say what
happened, or even if this ever really did happen (and as such is another software
"urban legend" to add to the pile).

Re: C/C++ knocks the crap out of Ada

[Nasser Abbasi]

In article <4gh5r8$i2@mailhub.scitec.com.au>, ramsesy@rd.scitec.com.au (Ramses Youhana) says:
>
>Richard A. O'Keefe (ok@goanna.cs.rmit.EDU.AU) wrote:
>>       <snip>
>> (3) Precisely because they are popular, C and C++ are used by a lot of
>>     programmers who shouldn't be allowed near a keyboard without a helmet
>>     and padded knees.  There is a lot of extremely bad C and C++ code.
>>     It is easy for a language to get a bad reputation when nearly every
>>     book you see has dreadful code in it.
>>       <snip>
>
>I agree.  I would also include many engineers (and not just programmers).
>Far too many programmers and software engineers skip over the DESIGN process
>and jump straight into coding.
>

Well, do not blame them too quickly. What else would you do if you 
have to have the thing up and running 2 days from now? (that is 
what the schedule says). If you don't get it out of the door by
thursday, someone else will and you'll lose some sale.

No time to do much design is the most common answer to the question 
of why there is no or little design done befor jumping to coding.

It is a sad state of affair, but I bet you a whole dollar that it 
is what happen in many places.

Nasser

Re: C/C++ knocks the crap out of Ada

[Ketil Z Malde]

>>>>> "Ralph" == Ralph Paul <ralph@ifr.luftfahrt.uni-stuttgart.de> writes:

    Ralph> do yourself a big favor and check thoroughly on this quote
    Ralph> !!! (:-) Booch commented on the design in Ada83, not Ada95

Err...I see.  As I think I said, I don't know much about Ada, so I
wouldn't really know the difference anyway.  Until now.  Sorry :-)

-kzm

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

T.E.D. says

"I believe that was when it was recoded into Ada (95). If I remember
correctly, the size of the Ada 83 version was even longer. Ada (95)
has not been around long enough to have any real reliable numbers about
how typical this is."

nope, that's wrong, for the kind of approach the Booch components take, you
would expect the size in C++ to be about the same size as Ada 95, there is
no basis for expecting any significant difference.

Re: C/C++ knocks the crap out of Ada

[Gary McKee]

In article <eg4tslzr18.fsf@trost.ii.uib.no>,
ketil@ii.uib.no (Ketil Z Malde) wrote:

 > I'm certainly not qualified to parttake in this fla^H^H^Hheated debate
 > about Ada vs. C++ -- however, I believe Booch (in "Object oriented
 > analysis and design") cites an example program that shrunk 90% when
 > recoded into C++ from Ada.  Question is, is this typical?  And if so,
 > is it easier to read/maintain 100K lines of Ada than 10K lines C++?

--------------------------------------------------------
On the other hand, I have never seen a large program (10k+ loc) that could
not be rewritten with significant improvements. The second time is always
easier, smaller, cleaner, and more elegant.

Then you add in Grady's obvious expertise with OO stuff and the
statististics aren't surprising. I bet that he could find a fortran or C
program with similar improvements when written in Ada95 if he decided to
make the effort.


--------------------------------------------------------------------
Gary McKee                           McKee Consulting
gmckee@cloudnine.com                 P. O. Box 3009
voice: (303) 795-7287                Littleton, CO 80161-3009
WWW home page =>                     <http://www.csn.net/~gmckee/>
--------------------------------------------------------------------

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

In article <4gejp7$o23@mailhub.scitec.com.au> ramsesy@rd.scitec.com.au (Ramses Youhana) writes:

Ramses,

> Since I posted the above, I've been flamed by every man and his dog.

:-)

> The comment was based on something I was told at UNI by one of the
> lecturers, and not out of my own experience.

Yes, it is highly unfortunate that people in "positions of authority
or power" should pontificate on things they know absolutely nothing
about.  I suppose this is just one more piece of evidence suggesting
that so called "authorities" are to be questioned at every point.
It is unfortunate that it has come to this, but it appears to be
true...

> particular, one who stated that I could probably learn Ada in about
> one week.

Same comment applies.  This is just pure baloney.  You can learn the
core of the language (C/Pascal equivalent) in somewhat less time than
learning Pascal (due to the more regular syntax and semantics).  I
really don't believe that you can learn all of Pascal (and actually
know it) in "about one week".

> in learning it.  Can anyone suggest any good books on it (one that
> reasonably priced) and possibly a good compiler for a PC.  Also,

Well, two excellent books would be John Barnes's Programming in Ada95,
Addison Wesley; and Norman Cohen's Ada as a Second Language (the new
edition covering Ada95).  Both are probably going to run around
US$45.00.  As for a compiler, you are in good luck.  A couple options
are Gnat (download your favorite machine binary version for free from
cs.nyu.edu pub/gnat [includeing Win/95, Win/Nt, OS/2, DOS] and make
sure you pick up the emacs mode or M. Felman's GWU Turbo-like
environment) or Thompson's ActivAda or ObjectAda (beta test) for under
US$100.00.  There are many others.  Also, for all sorts of information
like this check out the Ada WWW home page: http://lglwww.epfl.ch/Ada/


> according to many of the postings, I'm being given the impression
> that there are plenty of engineering jobs for Ada.  I've been
> looking in the job ads (in Sydney, Australia) and I can't seem to
> find many Ada jobs (as compared with C and C/C++ jobs) for
> engineers.  I'm interested to know where these jobs are.

Unfortunately, this topic generally generates only flames and other
irrational comments.  IMO, the exact situation is very unclear, but
it seems there are (in general) more Ada positions than qualified
people to fill them.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C/C++ knocks the crap out of Ada

[Matt Kennel]

Jon S Anthony (jsa@organon.com) wrote:
> In article <DMwFqr.EGD@thomsoft.com> kst@thomsoft.com (Keith Thompson) writes:

> > The story that a Venus probe was destroyed by a Fortran error has been
> > widely propagated, but it's inaccurate.  The probe in question was
> > Mariner 1, which was destroyed 4 minutes after launch on July 22, 1962.

> So, does this mean that there are _no_ confirmed cases of probes lost due
> software?  If so, I'm impressed as software has just plain _got_ to be
> the weakest link in the chain.  1/2 :-)

I believe there were software problems with the Phobos Mars probes; improper
instructions were sent which caused a terminal destabilization and loss of
contact.  And unlike NASA probes there was not a "failsafe" tracking mode
that tried to find the sun again and beam back to earth if it got totally
confused. 

Apparently there was a division between the "engineering" organization
running the spacecraft bus and the Space Research Institute (IKI in
russian) who were actually running the instruments and doing the
science.

Bottom line was that IKI thought the other people were totally
incompetent and they should have run the whole thing themselves. 


> [neat info snipped...]


> /Jon

> -- 
> Jon Anthony
> Organon Motives, Inc.
> 1 Williston Road, Suite 4
> Belmont, MA 02178

> 617.484.3383
> jsa@organon.com

Re: C/C++ knocks the crap out of Ada

[Ted Dennison]

Matthew M. Lih wrote:
> 
> My initial reaction to this piece of news is: Great. Another technical decision
> from the same people who brought you frozen O-rings.

Morton-Thyocol?

(My how this thread has strayed.)


-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

Nasser said

"Well, do not blame them too quickly. What else would you do if you
have to have the thing up and running 2 days from now? (that is
what the schedule says). If you don't get it out of the door by
thursday, someone else will and you'll lose some sale.

No time to do much design is the most common answer to the question
of why there is no or little design done befor jumping to coding."

If you have so little time, it is even more important than usual not
to jump into the coding, since you will have no time to correct errors.
It takes discipline, but it is ALWAYS a good idea to design carefully
before coding, ESPECIALLY when time is very tight.

Re: C/C++ knocks the crap out of Ada

[Ted Dennison]

Ken Garlington wrote:
> 
> Richard A. O'Keefe wrote:
> >
> > PL/I-style "record" I/O is also not supported by Ada 95.
> > It might actually be worth discussing this at some time; what did DEC Ada
> > do about RMS?
> 
> It added extra packages. See Chapter 14 of the DEC Ada language reference
> manual for the descriptions of

It also allowed access to significant portions of RMS through the
standard
I/O packages using the "FORM" parameter.



-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: C/C++ knocks the crap out of Ada

[Bill Lee]

In article <eg4tslzr18.fsf@trost.ii.uib.no> ketil@ii.uib.no writes:
>>>>>> "Nasser" == Nasser Abbasi <nabbasi@qualcomm.com> writes:
>
>    Nasser> Given 2 equally good programmers one in C++ and one in
>    Nasser> Ada, most people will agree that Ada code is easier to
>    Nasser> read than the C++ code.
>	:	:	:
>    Nasser> A code that is easier to read, is easier to maintain.
>
>I'm certainly not qualified to parttake in this fla^H^H^Hheated debate
>about Ada vs. C++ -- however, I believe Booch (in "Object oriented
>analysis and design") cites an example program that shrunk 90% when
>recoded into C++ from Ada.  Question is, is this typical?  And if so,
>is it easier to read/maintain 100K lines of Ada than 10K lines C++?
>
>-kzm
>
>


In your own words, you are "certainly not qualified".  Go ask those
who are what the same components resulted in when recoded in Ada95.
I've heard the author say something like "Somewhat less than the
C++ code."  (David? Care to comment? Perhaps you already have.)

I'm sorry for the flame, but this kind of out-of-context comment
from the self-proclaimed "certainly not qualified" gets to me on occasion.

Regards,

Bill Lee

Re: C/C++ knocks the crap out of Ada

[Bill Lee]

In article <4gd94r$isu@mack.rt66.com> egf@Rt66.com (Ed Franks) writes:
	.
	.
>  
>Yes, but you are not. Meanwhile, the software for the Mission Control Center 
>(MOC) at NASA Johnson Space Center is being rewritten in C++, not ADA.
>

Wrong. C, not C++. And serious, grievous error whichever. Software
which has life-threatening consequences should not be written in
an intrinsically unsafe language.

It is not a good day to be an astronaut.

Regards,


Bill Lee

Re: C/C++ knocks the crap out of Ada

[Richard A. O'Keefe]

In article <312515DF.7D3B@cmlj.demon.co.uk>, chris@cmlj.demon.co.uk says...
>With regards to maintenance, there's many people out there who consider 
>C/C++ a Write only language.

pete@borland.com (Pete Becker) writes:
>How many of the people who say this have actually used C++ enough to 
>understand it?

(1) Almost any programming language is going to be called "write-only" by
    people who have not worked with it for a bit.

(2) "Notation as a tool of thought": there are some really brilliant notations
    which can actually help you think more clearly about some things.  APL is
    a case in point:  I have found it a very powerful notation for a small
    class of problems; within that class trying to keep it simple often led
    me to a specification with fewer "rough edges".  The notation could be
    abused; it often was abused; and it was limited.  Mathematical notation
    in general can be concise, verbose, revealing, hopelessly obscure.  You
    have to combine even the best notation with a sense of elegance and some
    consideration for your readers.

(3) Precisely because they are popular, C and C++ are used by a lot of
    programmers who shouldn't be allowed near a keyboard without a helmet
    and padded knees.  There is a lot of extremely bad C and C++ code.
    It is easy for a language to get a bad reputation when nearly every
    book you see has dreadful code in it.

(4) C++ in particular has been changing very rapidly.  It seems as if every
    time I turn around there is a new keyword.  I was looking at some code
    fragments today in a book; they were full of things like
	void HelpIndex () (RTMessage) = [CM_FIRST+CM_HelpIndex];
    I've used three C++ compilers, read every book with "Stroustrup" on it,
    and keep on browsing through the draft standard, and haven't the foggiest
    notion what this is supposed to do.  If a few keywords had been used
    instead of punctuation marks, I might have been able to figure it out...
    Conversely, there's a program I was given in 1988, written in C++, that
    I haven't been able to compile for years, so today's _compilers_ think
    it isn't "readable" (sad smiley).

(5) Let's be clear about the goals and accomplishments of C++.
    It was designed to make it easy for skilled programmers to WRITE large
    object-oriented programs.  It is obvious to any fair observer that it
    has accomplished these goals.  It was _not_ designed with readability,
    formal verification, or protecting idiots from themselves in mind.

(6) In the world of software engineering, easy to read is better than easy
    to write, even Homer nods to protecting idiots like me from ourselves
    is thought to be important, and some level of verifiability is thought
    to be a Good Thing.  (Come to think of it, the way Alphard 'form's
    were annotated should carry over nicely to C++ classes, so how come
    such annotations are so rare in the code I've seen?)
    
(7) Intentionally left blank.
-- 
Election time; but how to get Labor _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: C/C++ knocks the crap out of Ada

[Richard A. O'Keefe]

I wrote:
>Ada does not support Fortran-style formatted I/O, nor PL/I style
>formatted or pictured I/O (but see Interfaces.COBOL).

dewar@cs.nyu.edu (Robert Dewar) writes:
>Wrong advice, Ada 95 DOES spport COBOL-style pictures, see the information
>systems annex. I am not sure what "pictured I/O" is (COBOL certainly does
>not have it! But both COBOL and Ada 95 provide facilities for the use of
>pictures to edit alphanumeric data (this data can certainly be output
>after it is edited :-)

"Wrong advice"?   But I never said Ada 95 doesn't support COBOL-style
pictures!  I avoided mention of the Information Systems annex because
it is one of the "Specialised Needs" annexes, which are optional, but
annex B isn't (though if I understand correctly the child packages are).

What I wrote was
	Ada does not support ... PL/I style formatted or pictured I/O
                                 ^^^^

It remains true that Ada 95 does not support PL/I style pictures, neither
in the core nor in any specialised needs annex, nor does it support PL/I
*style* I/O.  I am actually _happy_ that this is so.

PL/I-style "record" I/O is also not supported by Ada 95.
It might actually be worth discussing this at some time; what did DEC Ada
do about RMS?
-- 
Election time; but how to get Labor _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: C/C++ knocks the crap out of Ada

[Ken Garlington]

Richard A. O'Keefe wrote:
> 
> PL/I-style "record" I/O is also not supported by Ada 95.
> It might actually be worth discussing this at some time; what did DEC Ada
> do about RMS?

It added extra packages. See Chapter 14 of the DEC Ada language reference
manual for the descriptions of

   Relative_IO
   Indexed_IO
   Sequential_Mixed_IO
   Direct_Mixed_IO
   Relative_Mixed_IO
   Indexed_Mixed_IO
   Aux_IO_Exceptions

> --
> Election time; but how to get Labor _out_ without letting Liberal _in_?
> Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: C/C++ knocks the crap out of Ada

[Ramses Youhana]

Richard A. O'Keefe (ok@goanna.cs.rmit.EDU.AU) wrote:
>	<snip>
> (3) Precisely because they are popular, C and C++ are used by a lot of
>     programmers who shouldn't be allowed near a keyboard without a helmet
>     and padded knees.  There is a lot of extremely bad C and C++ code.
>     It is easy for a language to get a bad reputation when nearly every
>     book you see has dreadful code in it.
>	<snip>

I agree.  I would also include many engineers (and not just programmers).
Far too many programmers and software engineers skip over the DESIGN process
and jump straight into coding.

Ramses.

Re: C/C++ knocks the crap out of Ada

[Gene Ouye]

Dirk Dickmanns <dirk@demokrit.informatik.unibw-muenchen.de> wrote:
 
> >[another citation of Ada 83 Booch Components shrunk 80%, 90%, 100%, 
    or more when written in C++ deleted...]
> 
> My 2 Pfennig: It would have shrunk to 10 KLOC in all of Ada, C++,
> Eiffel, Sather, whatever during recoding.  Maybe we have some kind of
> code compressors, but up to now any recode I saw shrunk a lot and was
> -- even if done by me -- not neccessarily less readable.

Dirk is right on the mark here (no pun intended:-).  Grady has said
MANY TIMES and in MANY LOCATIONS that the reason the components shrank 
so much was in no way due to the inherent expressiveness, goodness, or
any other attribute of either Ada or C++, but was rather due to the 
"aha" factor after examining the completed work and then taking a 
second (or more) pass through and redoing it.  He admitted that due 
to Ada's (at the time) lack of support for dynamic dispatching, there
was some additional overhead that would be written into the code, but
that regardless, there would have been an order of magnitude reduction
in the size of the code similar to the reduction found in the C++ 
components had they been redone in Ada 83.

Given Ada 95's support for tagged types, plus other goodies, it is 
expected that the size of the final Ada 95 version will likely be 
somewhat smaller than the C++ version.  Do not construe from this 
that Ada 95 is now slightly more expressive than C++, probably if 
someone takes another pass through the C++ version, it could be made
even smaller as well.

Besides, statistics about a component library such as the Booch 
components, or Tools.h++, or anything like that are pretty much 
irrelevant to the normal programmer, who is NOT writing a reusable 
component library, but rather an application that, among other things,
utilizes component libraries.  These kinds of statistics make great 
flame war fodder, but one would hope that reasonable people making 
reasonable decisions about programming languages would be able to 
see them for what they are and USE THEM IN THE PROPER CONTEXT.


> 
> Dirk
> 
> --
> Dirk Dickmanns -- real-time dynamic computer vision
> Sun OS 4.1.3; PC Linux; Transputers -- embedded
> Ada 95, Ada 83, OCCAM2/3, ANSI C, Eiffel 3, PROLOG

Gene Ouye <geneo@rational.com>

Re: C/C++ knocks the crap out of Ada

[Ghost In The Machine]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: Actually the source of this incorrect viewpoint often stems from lack
: of familiarity with C++ (you can sort of guess this from anyone who
: writes C/C++ as though it were one language). It is remarkable how many
: people think they know C++ becaus they program in it, and yet they are
: unaware of exceptions,  namespaces and the standard template library.
: And try seeing how many C++ programmers really understand the overloading
: semantics in C++.

Hmmm ... a professor at mine is one of the fine fellows who developed
the standard template library.  That right there would lead me to
believe that he "understands" C++ by your estimation.  He also seems
to recognize the features of exceptions, namespaces, etc.  Yet, he
has been talking in class the past several classes about Ada95's 
advantages over C++.  So, it would seem that not everyone who says
that Ada95 is better then C++ simply "doesn't understand C++" ....

--
Jeff Gentry            jester@rpi.edu
PGP Public Key Available Upon Request
http://www.rpi.edu/~gentrj

Re: C/C++ knocks the crap out of Ada

[Richard A. O'Keefe]

nabbasi@qualcomm.com (Nasser Abbasi) writes:
>Well, do not blame them too quickly. What else would you do if you 
>have to have the thing up and running 2 days from now? (that is 
>what the schedule says).

I suspect that if we took the various codes of ethics that have been proposed
seriously, the answer would NOT be "hack it and hope" but "blow the whistle
and resign".

>No time to do much design is the most common answer to the question 
>of why there is no or little design done befor jumping to coding.

If I were charged with assault, I wouldn't like to defend myself by
proving that I was off murdering someone else at the time.  Insufficient
time given to design is a serious management problem.

>It is a sad state of affair, but I bet you a whole dollar that it 
>is what happen in many places.

"There's never time to do it right but there's always time to do it over."
-- 
Election time; but how to get Labor _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: C/C++ knocks the crap out of Ada

[Tom Payne]

Pete Becker (pete@borland.com) wrote:
: In article <312515DF.7D3B@cmlj.demon.co.uk>, chris@cmlj.demon.co.uk says...
: >
: >With regards to maintenance, there's many people out there who consider 
: >C/C++ a Write only language.
: 
: How many of the people who say this have actually used C++ enough to 
: understand it? I know it's popular today to dump on C++, but my experience has 
: been that most of the people who produce one-liners like this simply don't 
: know what they're talking about. If relying on that sort of ignorance is the 
[...]


Let's not blame the victim!  It is hardly "ignorance" or lack of
familiarity that leads programmers to conclude that C/C++ is difficult
to read and to express that judgement in the hyperbole, "write-only
language."

C++ has been amazingly successful in achieving its design goals, thus
assuring continued C/C++ dominance in the market.  As with the 80386
extention to the 80286 instruction set, however, the resulting
language is far from elegant.  We are talking about a language whose
syntax is so convoluted that, Dan Saks devoted over a hundred column
inches of the January issue of C/C++ Users Journal to telling
professional C/C++ programmers how to parse declarations.  In the same
issue, Pete Becker devoted space to explaining the meaning of
sizeof(Sample&), which reads, "the number of bytes in the object
representation for the type reference-to-Sample."  That value turns
out to be (get this!) the number of bytes used to encode objects of
type Sample, regardless of the number of bytes used to encode
references --- a design decision so obscure and irregular that even
the authors of the April Draft of the C++ standard missed it.

Tom Payne (thp@cs.ucr.edu)

P.S. My students say that C is an in-joke that everyone now knows,
while C++ is a shaggy dog whose punch line is STL.

Re: C/C++ knocks the crap out of Ada

[Matthias Blume]

In article <4gj8f3$mr4@usenet.rpi.edu> gentrj@sage3101-21.its.rpi.edu (Ghost In The Machine) writes:

   Robert Dewar (dewar@cs.nyu.edu) wrote:
   : Actually the source of this incorrect viewpoint often stems from lack
   : of familiarity with C++ (you can sort of guess this from anyone who
   : writes C/C++ as though it were one language). It is remarkable how many
   : people think they know C++ becaus they program in it, and yet they are
   : unaware of exceptions,  namespaces and the standard template library.
   : And try seeing how many C++ programmers really understand the overloading
   : semantics in C++.

   Hmmm ... a professor at mine is one of the fine fellows who developed
   the standard template library.  That right there would lead me to
   believe that he "understands" C++ by your estimation.  He also seems
   to recognize the features of exceptions, namespaces, etc.  Yet, he
   has been talking in class the past several classes about Ada95's 
   advantages over C++.  So, it would seem that not everyone who says
   that Ada95 is better then C++ simply "doesn't understand C++" ....

Correct me if I'm wrong, but isn't is the case that Robert is arguing
against those who say "C/C++ is better than Ada" and not the other way
around?

--
-Matthias

Re: C/C++ knocks the crap out of Ada

[Ray Toal]

ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) wrote:

>(4) C++ in particular has been changing very rapidly.  It seems as if every
>    time I turn around there is a new keyword.  I was looking at some code
>    fragments today in a book; they were full of things like
>	void HelpIndex () (RTMessage) = [CM_FIRST+CM_HelpIndex];
>    I've used three C++ compilers, read every book with "Stroustrup" on it,
>    and keep on browsing through the draft standard, and haven't the foggiest
>    notion what this is supposed to do.

That line of code was not standard C++ (not that there even is a standard
yet :-). It was a "syntax extension" that came with the Borland C++
Compiler Version 3.x as part of the ObjectWindows Framework.  
Interestingly when Borland released 4.0 they removed that "syntax
extension."

I would be interested to know if any Ada vendors have released
Ada compilers with vendor-specific syntax modifications.

Ray Toal

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

Jeff said

"Hmmm ... a professor at mine is one of the fine fellows who developed
the standard template library.  That right there would lead me to
believe that he "understands" C++ by your estimation.  He also seems
to recognize the features of exceptions, namespaces, etc.  Yet, he
has been talking in class the past several classes about Ada95's
advantages over C++.  So, it would seem that not everyone who says
that Ada95 is better then C++ simply "doesn't understand C++" ...."

No one ever said that this applied to "everyone", my original remark
was that it was remarkable how many people made pronouncements about
C++ without knowing much about it, and that particularly people who
lumpied C and C++ together as though they were one language were likely
in that category.

I am sure your professor does not think that C and C++ are the same
language :-)

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

Ray Toal asks

"I would be interested to know if any Ada vendors have released
Ada compilers with vendor-specific syntax modifications."

Certainly not if they are validated, since part of the validation process
involves a "declaration of conformance" that verifies that you have not
added non-permissible extensions, and syntax modifications are certainly
in this category.

It would be valid to have extensions under control of a compiler switch,
but even this is unusual in the Ada arena, since portability is highly
valued.

Re: C/C++ knocks the crap out of Ada

[JR Crosmer]

Ray Toal wrote:
> 
> ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) wrote:
> 
> >(4) C++ in particular has been changing very rapidly.  It seems as if every
> >    time I turn around there is a new keyword.  

What is the status of the plain/ordinary/but very noticably forgotten boolean?

It seems that the biggest difficutly that run into is that everybody needs/wants to
declare a new version (and they are not all compatible!).  Because C/C++ were never
polite enough to provide it to begin with (0 or non-zero is hardly a good substitute)
we end up either creating the (ITEM, NON_ITEM) form, create yet another version
(my latest is BooleaN, { FalsE, TruE } ).  I think I remember something about
BOOL in one of the C or C++ stds.  Which compilers use it?  (Borland does not, 
at least thru 4.0).

As you can tell from the tone of this post, I would be much happier to have a language
that provides a few comforts and niceties, i.e., Ada, but I haven't yet been able to
convince my cohorts and managers to come along.

JR Crosmer

[Loving Ada, but not using IT!]

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

Matthias says

"Correct me if I'm wrong, but isn't is the case that Robert is arguing
against those who say "C/C++ is better than Ada" and not the other way
around?"

Robert replies:

That was the original context, however, the problem of people arging
language comparisons without knowing one of the languages well works
in all directions. Quite often on CLA you see negative statements about
C, C++ and other languages (in comparison to Ada), and it is clear that
the writer does not know the other language well enough. Even if the
writer is supporting Ada (and thus has the right conclusion :-) :-)
uninformed argument does not help anything -- in fact uninformed
argument hurts.

So the rule that you should not argue in the language comparison area
without knowing both languages well applies to Ada supporters too!

P.S. it's true that the sited professor definitely seems not to be in
this category, and of course I never suggested he/she was!

Re: C/C++ knocks the crap out of Ada

[J Greene]

Nasser Abbasi wrote:
> 
> In article <Dn3Krz.6yw@research.att.com>, ark@research.att.com (Andrew Koenig) says:
> >
> >In article <4gb4r3$psg@qualcomm.com> x!news.be.innet.net!INbe.net!usenet writes:
> >
> >> Given 2 equally good programmers one in C++ and one in Ada, most
> >> people will agree that Ada code is easier to read than the C++ code.
> >
> >Most?  I have yet to meet anyone who knows both Ada and C++
> >well enough to be able to make a reasoned comparison.
> >--
> 
> Does one really need to be a guru in both languages to observe that
> one is more readable than the other?
> 
> I was not talking about a comprehensive comparison. I was only talking
> about the readability (sp?) aspect of the languages.
> 
> Nasser


I have industry expierence in both languages.  It has been my expierence
that the readiblity of a language actually depends on the programming
style of the author.   I have come across pieces of Ada code which
very painful to debug, and I can say the same for C++.  I have also
worked (thankfully a good deal of the time) with well written C++
code that was easy to pick up,  and the same for Ada. 

Implementation and good software engineering make or break any software.
As for readiblity,  a poor software engineer can make either a nightmare.

I have had to learn both, work in both, and maintain both.  To be honest,
each is just another language.  As far as the argument of readibility 
goes,  I have found that the programmer makes the difference,  
(between C++ and Ada) not the language.

                                  J.Greene

Re: C/C++ knocks the crap out of Ada

[vancleef]

In article <tgmDnC3AM.MEv@netcom.com>, tgm@netcom.com (Thomas G. McWilliams) writes:
> Ted Dennison (dennison@escmail.orl.mmc.com) wrote:
> :  Matthew M. Lih wrote:
> :   > My initial reaction to this piece of news is: Great. Another technical decision
> :   > from the same people who brought you frozen O-rings.
> : 
> : Morton-Thyocol?
> 
> For the record, it was NASA administrators who pushed for the
> Challenger launch. The engineers and contractors were overruled in
> their efforts to scrub the launch.
> 

The NASA admins, of course, were pushed by the Whitehouse, who insisted
on having the Challenger in orbit during Reagan's State of the Union
Address, where the plan was to do a live interview with the Teacher-In-Space
and the President during the address, all in the name of propoganda.

-Garrett



> 

Re: C/C++ knocks the crap out of Ada

[Andrew Koenig]

In article <dewar.824906485@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:

> "I'm certainly not qualified to parttake in this fla^H^H^Hheated debate
> about Ada vs. C++ -- however, I believe Booch (in "Object oriented
> analysis and design") cites an example program that shrunk 90% when
> recoded into C++ from Ada.  Question is, is this typical?  And if so,
> is it easier to read/maintain 100K lines of Ada than 10K lines C++?"

It depends on the author, as Prof. Dewar should know --
I would rather maintain his assembly language code
than most other people's code in any language at all.
-- 
				--Andrew Koenig
				  ark@research.att.com

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

"For the record, it was NASA administrators who pushed for the
Challenger launch. The engineers and contractors were overruled in
their efforts to scrub the launch."

Are you sure of this, it certainly does not correspond to published news
accounts and public statements at the time. I am questioning the part of
your statement that says "contractors", rather than "engineers". 

Are you really saying that everyone at all levels in the contractor's
organization recommended against the launch and NASA overruled? This
would be a rather remarkable situation, and, as I say was not what
was in the news at the time -- which instead indicated a much more
muddled picture, in which some engineers were concerned, but there
was controversy at all levels as to how significant this concern was.

Re: C/C++ knocks the crap out of Ada

[Ed Franks]

In article <1996Feb22.005518.13396@leeweyr.sccsi.com>,
   bill@leeweyr.sccsi.com (Bill Lee) wrote:
>In article <4gd94r$isu@mack.rt66.com> egf@Rt66.com (Ed Franks) writes:
>	.
>	.
>>  
>>Yes, but you are not. Meanwhile, the software for the Mission Control Center 
>>(MOC) at NASA Johnson Space Center is being rewritten in C++, not ADA.
>>
>
>Wrong. C, not C++. And serious, grievous error whichever. Software
>which has life-threatening consequences should not be written in
>an intrinsically unsafe language.

The language being used to rewrite the MOC software at JSC is C++, not C.
The language selection was made back in 1993. The selection came down to
either C++ or ADA with a dialect/preproccesor called Dragoon.  The rationale 
for selecting C++ is all documented in a report to NASA by the 
ROSE (Reusable Objects Software Environment) project.  
Last time I checked, there were 80+ developers and
support staff from Rockwell, UNISYS, Loral, Barrios,and NASA
working on getting a legacy body of software 
( >2.5 million SLOC) rehosted to C++ on a network of CDC/DEC/Sun workstations.
I was a member of ROSE until May 1995.
 
>
>It is not a good day to be an astronaut.
>
>Regards,
>
>
>Bill Lee
>


Ed Franks
--

Re: C/C++ knocks the crap out of Ada

[Ghost In The Machine]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: No one ever said that this applied to "everyone", my original remark
: was that it was remarkable how many people made pronouncements about
: C++ without knowing much about it, and that particularly people who
: lumpied C and C++ together as though they were one language were likely
: in that category.

Yes, I must apologize ... it seems that I either did not read 
your post carefully enough, or simply misunderstood it for a 
second.  All these people waving their language's flag like it
was their national banner tends to get me a bit jumpy :) ...

: I am sure your professor does not think that C and C++ are the same
: language :-)

  From lectures, it would seem that answer is a no, but I don't think
most people when they say C/C++ are insinuating that they're the
same language (I don't, at least) ... I mean, for instance,
I say that on occasion, and I love c coding, but really would rather
not code in C++ ... its just something that i've never really
gotten into. (of course, I've not done any 'Real World large programming')
either - If I thought they were the same language, It would stand
to reason that i'd enjoy or dislike both, eh? :)

<Humour mode>
Anyhow, perhaps the reason C/C++ started is due to all these DOS
C++ compilers out there which have every Tom, Dick, and Harry
"wannabe windows" programmer writing c code, using // for comments,
and think they have C++ programs ;)  </Humour mode>

--
Jeff Gentry            jester@rpi.edu
PGP Public Key Available Upon Request
http://www.rpi.edu/~gentrj

Re: C/C++ knocks the crap out of Ada

[Thomas G. McWilliams]

Ted Dennison (dennison@escmail.orl.mmc.com) wrote:
:  Matthew M. Lih wrote:
:   > My initial reaction to this piece of news is: Great. Another technical decision
:   > from the same people who brought you frozen O-rings.
: 
: Morton-Thyocol?

For the record, it was NASA administrators who pushed for the
Challenger launch. The engineers and contractors were overruled in
their efforts to scrub the launch.

Re: C/C++ knocks the crap out of Ada

[Matt Austern]

In article <AUSTERN.96Feb26094555@isolde.mti.sgi.com> austern@isolde.mti.sgi.com (Matt Austern) writes:

> C does not have a boolean type, but C++ does.  It was added precisely
> because every language was defining its own boolean type: it was clear
> that a standard boolean type was needed for the sake of avoiding name
> clashes.

This is a typo, of course.  It should read "every library was defining
its own boolean type."
-- 
Matt Austern
SGI: MTI Compilers Group
austern@isolde.mti.sgi.com

Re: C/C++ knocks the crap out of Ada

[James O'Connor]

Ray Toal wrote:
> 
> ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) wrote:
> 
> >(4) C++ in particular has been changing very rapidly.  It seems as if every
> >    time I turn around there is a new keyword.  I was looking at some code
> >    fragments today in a book; they were full of things like
> >       void HelpIndex () (RTMessage) = [CM_FIRST+CM_HelpIndex];
> >    I've used three C++ compilers, read every book with "Stroustrup" on it,
> >    and keep on browsing through the draft standard, and haven't the foggiest
> >    notion what this is supposed to do.
> 
> That line of code was not standard C++ (not that there even is a standard
> yet :-). It was a "syntax extension" that came with the Borland C++
> Compiler Version 3.x as part of the ObjectWindows Framework.
> Interestingly when Borland released 4.0 they removed that "syntax
> extension."
> 
> I would be interested to know if any Ada vendors have released
> Ada compilers with vendor-specific syntax modifications.
> 
> Ray Toal


This was only used for a Windows application (a TWindow classs, to be 
specific) to tie certain message responses (In this case a Menu choice 
with an ID of CM_HelpIndex) to certain functions.  (When the (MS) window 
receives the Command Message of CM_HelpIndex, it calls the C++ function 
HelpIndex defiend in the TWindow subclass behind the 'Real' Window.  
You're right, for OWL 2.0, they changed to a standard function 
declaration and added a couple of MACROS to handle the mapping...

James O'Connor
oconnor@apci.net

Re: C/C++ knocks the crap out of Ada

[Matthew M. Lih]

vancleef@ohstpy.mps.ohio-state.edu wrote:

> In article <tgmDnC3AM.MEv@netcom.com>, tgm@netcom.com (Thomas G. McWilliams) writes:
> > Ted Dennison (dennison@escmail.orl.mmc.com) wrote:
> > :  Matthew M. Lih wrote:
> > :   > My initial reaction to this piece of news is: Great. Another technical decision
> > :   > from the same people who brought you frozen O-rings.

> > : Morton-Thyocol?

That's Morton Thiokol.

> > For the record, it was NASA administrators who pushed for the
> > Challenger launch. The engineers and contractors were overruled in
> > their efforts to scrub the launch.

The administrators are who I meant. Sorry for the imprecision.

> The NASA admins, of course, were pushed by the Whitehouse, who insisted
> on having the Challenger in orbit during Reagan's State of the Union
> Address, where the plan was to do a live interview with the Teacher-In-Space
> and the President during the address, all in the name of propoganda.

Unless the White House was explicitly briefed on the risks involved, I would
say the responsibility still rests with the administrators to "just say no".

Just to provide some context, someone recently posted that much of the
software at Johnson Spaceflight Center (the ground-based stuff?) was being
rewritten in C++.


Matthew M. Lih
Software Lead, SAIN Project
TRW Enterprise Solutions

Re: C/C++ knocks the crap out of Ada

[Peter Finney]

J Greene <jkgreene@nando.net> wrote:

[snip]

>I have had to learn both, work in both, and maintain both.  To be honest,
>each is just another language.  As far as the argument of readibility 
>goes,  I have found that the programmer makes the difference,  
>(between C++ and Ada) not the language.

All languages are equal - but some languages are more equal than
others.
(apologies to George Orwell)

Peter Finney
Principal Consultant
BAeSEMA Ltd
Portchester UK

Re: C/C++ knocks the crap out of Ada

[Matthew B. Kennel]

Nasser Abbasi (nabbasi@qualcomm.com) wrote:


: From "Improving software economics in the aerospace and defense industry:

: A technical paper by Mike Devlin, Chairman and Walker Royce, director 
: of software-engineering process. Rational corp.  1995.


: "The definition of the Ada language is unique in that it was designed
: to enable better management, design, and architectural control -- the
: higher-leverage aspects of software engineering -- while sacrificing
: some ease of programming.

: This is the essence of the Ada culture: top-down control where
: programmers are subordinates of the lead architects and managers.

: Other languages -- specifically C++ -- focus on simplifying the
: programming activities while sacrificing some of the ease of control.

Would somebody from Rational care to explain what aspects of C++ they believe
simplify the programming activity compared to Ada?

: Nasser.

Re: C/C++ knocks the crap out of Ada

[Matt Austern]

In article <312FDB27.4B83@inav.net> JR Crosmer <rainbow@inav.net> writes:

> > >(4) C++ in particular has been changing very rapidly.  It seems as if every
> > >    time I turn around there is a new keyword.  
> 
> What is the status of the plain/ordinary/but very noticably forgotten boolean?
> 
> It seems that the biggest difficutly that run into is that everybody needs/wants to
> declare a new version (and they are not all compatible!).  Because C/C++ were never
> polite enough to provide it to begin with (0 or non-zero is hardly a good substitute)
> we end up either creating the (ITEM, NON_ITEM) form, create yet another version
> (my latest is BooleaN, { FalsE, TruE } ).  I think I remember something about
> BOOL in one of the C or C++ stds.  Which compilers use it?  (Borland does not, 
> at least thru 4.0).

C does not have a boolean type, but C++ does.  It was added precisely
because every language was defining its own boolean type: it was clear
that a standard boolean type was needed for the sake of avoiding name
clashes.

The C++ boolean type is called bool, and its two permissible values
are the manifest constants true and false.  For the sake of
compatibility with old code, there are standard conversions from bool
to int and from int to bool.
-- 
Matt Austern
SGI: MTI Compilers Group
austern@isolde.mti.sgi.com

Re: C/C++ knocks the crap out of Ada

[Richard A. O'Keefe]

JR Crosmer <rainbow@inav.net> asks about c++
>What is the status of the plain/ordinary/but very noticably forgotten boolean?

Not forgotten.  The 28 April 1995 draft lists
	bool	false	true
as keywords.  There are some oddities, notably that
	boolvar++;
is defined to have the same effect as
	boolvar = true;
which will not impress readers of comp.lang.ada.

If you haven't already got them, then
	#define bool int
	#define false 0
	#define true 1
will be a workable substitute (LC-lint already assumes this).

A new header <bool.h> making these keywords available in C has been proposed
for the revised C standard.

The fundamental problem is that the mistakes a language _doesn't_ allow are
almost as important as the good things it _does_ allow, and C and C++ have
a lot of old code to be compatible with.  This doesn't mean that strict
checking is not possible, only that compilers are unlikely to do it by
default.  If only there were an LC-lint++ ...

-- 
Election time; but how to get Labor _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

Nasser asks

": This is the essence of the Ada culture: top-down control where
: programmers are subordinates of the lead architects and managers.

: Other languages -- specifically C++ -- focus on simplifying the
: programming activities while sacrificing some of the ease of control.

Would somebody from Rational care to explain what aspects of C++ they believe
simplify the programming activity compared to Ada?"

I am not from Rational :-)

but here is my answer anyway, just one example.

If a programmer wants to do a weird unchecked conversion, in C++ you just
go ahead and write a cast and that's the end of it.

In Ada, you have to make a big production of things, with unchecked_Conversoin,
instantiated it, and then use it.

Not only is this more work, but you might find some pesky rule saying that
only certain units in the program are permitted to with Unchecked_Conversion
(an example of top down control).

------------------------------------
The interesting thing about the above reply is that a C fan could read it
as supportive of C/C++ :-) :-)

I am not saying all C programmers would read it this way, just some!

Re: C/C++ knocks the crap out of Ada

[ron thompson]

dewar@cs.nyu.edu (Robert Dewar) wrote:
>Nasser asks
>
>": This is the essence of the Ada culture: top-down control where
>: programmers are subordinates of the lead architects and managers.
>
>: Other languages -- specifically C++ -- focus on simplifying the
>: programming activities while sacrificing some of the ease of control.
>
>Would somebody from Rational care to explain what aspects of C++ they believe
>simplify the programming activity compared to Ada?"
>
>I am not from Rational :-)
>
>but here is my answer anyway, just one example.
>
>If a programmer wants to do a weird unchecked conversion, in C++ you just
>go ahead and write a cast and that's the end of it.
>
>In Ada, you have to make a big production of things, with unchecked_Conversoin,
>instantiated it, and then use it.
>
>Not only is this more work, but you might find some pesky rule saying that
>only certain units in the program are permitted to with Unchecked_Conversion
>(an example of top down control).

Exactly. In our world, we consider that "big production of
things" to be the tip off to the savvy reader/maintainer
that SOMEthing is going to happen here that may or may
not explicitly meet the eye. It is our experience that readers
tend to glide the parenthesis, saving them for later study
should they feel a need to. Cast via parenthetical indication
is often overlooked until about the nth time through it.

We like that glaring
"... is new unchecked conversion(Something, Something_Else);"

The conversion is then an actual call to a hopefully 
descriptive name that is just a tad harder to overlook then a 
call with a series of parenthetical notes as to what is being
done.

We also find that a good spot for commenting is just prior
to a function/procedure call, so the habit of commenting is
applied to the upcoming cast. It is easy to comment the next
call yet forget that we are casting on the fly.

The trade obviously is that it makes a few steps more in
the process. The one I always enjoy is that it is far less
typing in C/C++...

As for top-down control, well we just always remember that
no matter what the architecture, OS, or language, NObody
knows the job like the engineers/programmers. Sure we are 
suboordinates to the top end, but hey, someone has to be. 
Besides, they provide us with such a rich variety of laughs...

rct

The opinion(s) expressed above are mine and mine alone.

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

In article <4iah20$p7k@saba.info.ucla.edu>,
Jay Martin <jmartin@cs.ucla.edu> wrote:
 >rlk@rational.com (Bob Kitzberger) writes:
 >
 >>:   make is a _general_purpose_ utility.  It _can_ be used to manage C 
 >>: projects, or it can be used for a whole host of other things.  How is 
 >>: this hard to understand?  Does ADA provide its own OS, its own editor and 
 >>: its own hardware so that you never need to use anything else?
 >
 >>I don't think that anyone is having difficulty understanding your point.
 >>Make is indeed general purpose, but its roots are in the C/Unix
 >>culture, and those roots show.
 >
 >Right, make is mostly used to support development in C and other
 >primitive languages.  I have seen this piece of crap utility used for
 >all sort of braindead misuses.  Unix-ites seem to love to dp goofy
 >things with their utilities.  Heh, I have seen people using Lex and
 >Yacc to build parsers to read in simple tables.  Like swatting a bug

I use Lex and Yacc for scanning simple configuration files and what not? What
is your problem? According to what you are saying, the features of Ada are also
overkill---why not just use hand-coded assembly language? C++ classes? Why
bother, just use static tables for everything!

Lex and Yacc are proven utilities that work. 

The input file to Lex is far easier to debug and maintain than a hand-written
lexical analyzer.

Yacc makes you an efficient LALR(1) parser---all you do is specify a grammar
and a few C snippet ``actions''! If it was any easier, I'd fall asleep at the
keyboard.

It's a lot easier to change the grammar and have yacc regenerate new code than
to fiddle with a hand coded recursive-descent or shift-reduce parser.


 >with a sledge hammer (they ever heard of "scanf"?), but they probably

A lex generated scanner is far more robust and _faster_ than scanf(), you twit,
especially if you use GNU flex -f to generate the scanner.

I have written a test program in which I compared a flex scanner against
scanf(). The task was to read an eight megabyte file containing eight or nine
digit integers. One program did a loop in which scanf("%d") was invoked.
Another used a lexical analyzer to match the tokens and atoi() to do the
integer conversion. The flex-generated code was almost twice as fast.

I have created about half a dozen lexers/parsers in the last year alone, each
of which took the lesser part of an afternoon of fiddling. Some were for
retrieving data out of HTML, others for parsing logs, configuration files and
the like.

I replaced one use of scanf() for parsing the entries of a log with a lex
scanner, and improved the CPU efficiency of the program twenty fold!

Programs that use yacc are a godsend too! Easy to understand and modify. I can
read the yacc grammar and understand the input language. It's self-documenting.

Believe me, these tools have been a wallet-enhancing productivity items. Some of
us have a life.

 >felt so Computer Scientific doing it! (The journey is the reward) By the

That is completely false. What journey are you talking about? Five minutes of
punching in a simple grammar specification instead of hours of debugging some
silly code only to have it run no faster than an automatically generated
program?

The self-indulgent programmer will insist on hand-coding everything. I would
find it a lot more gratifying to write out a grammar on hand, compute the LR(1)
state machine construction and code my own parsing table, and then whip it up
into raw code. That would be my idea of ``journey is the reward''.

 >way after 10+ years of using Unix I am having trouble thinking of a
 >standard Unix utility that is not a total misdesigned piece of crap!
 >Maybe someone can help me.

A professional counsellor, perhaps.
-- 

Re: C/C++ knocks the crap out of Ada

[Ian Johnston (by ubsswop)]

In article <4iah20$p7k@saba.info.ucla.edu>, jmartin@cs.ucla.edu (Jay Martin) writes:

[...]

|> Right, make is mostly used to support development in C and other
|> primitive languages.  I have seen this piece of crap utility used for
|> all sort of braindead misuses.

Yes, make is primitive and often leaves a lot to be desired. But...

Oh, I want the debug build.
Hmm, now I need a profiled build.
Let's see, I want the Solaris verion. No, the AIX version.
Er, I need the NT version.
Oh, and I might as well do the VMS version now too.
Umm, I need to rebuild these IDL files; before that I need to run my
Ada-to-IDL converter.
By the way, we need the ACMS task list too. Better run that scanner.
I just changed a header file. I'll run the C++ dependency finder now.
Now, where was that package? I'll run the Ada dependency finder now.
Oh, the library changed? I'll run the C to Ada package converter then.
Er, I want to preprocess this C file, with all those cpp flags.


|>  Unix-ites seem to love to dp goofy
|> things with their utilities.  Heh, I have seen people using Lex and
|> Yacc to build parsers to read in simple tables.  Like swatting a bug
|> with a sledge hammer (they ever heard of "scanf"?), but they probably
|> felt so Computer Scientific doing it! (The journey is the reward)

Too true.

|> By the
|> way after 10+ years of using Unix I am having trouble thinking of a
|> standard Unix utility that is not a total misdesigned piece of crap!
|> Maybe someone can help me.

grep ?

Ian

Re: C/C++ knocks the crap out of Ada

[Robert A Duff]

In article <4ic8dk$amh@ra.nrl.navy.mil>,
Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
>Do you have personal experience of this rough equivalence or is this something  
>whose practical reality should be self evident?

Yes, I have practical experience working on large C programs, and
successfully keeping things consistent using an automatic build tool.
(I hope I correctly understood what you're asking.)  I've also written
such a tool for C, Pascal, Modula-2, and Ada.  The Ada support was
harder then the other three put together.

I admit I have also worked on projects where people weren't so careful
to use the tool, or used a NON-automatic build tool, like Unix 'make'
and hand-written make files.  And that does indeed cause trouble: once
in a while, there's a missing dependency in the make file, and it
causes a run-time bug.  And there are *always* extra dependencies,
which don't cause bugs, but needlessly increase compile time.  (I've
also seen cases where a company ships custom-modified software to a
customer, and fails to remember or save the version that was sent!)

Look, I'm not being anti-Ada.  I wouldn't have spent 3.5 years of my
life helping to design Ada 9X, if I thought C was just as good a tool.
I have *not* experienced C programs that effectively used type
checking, or run-time range checking, or information hiding, etc etc,
to prevent bugs -- lint notwithstanding.  ;-) I just think that this
particular advantage of Ada over C that we're arguing about has been
somewhat exaggerated.  (I didn't deny that it's an advantage, either.)

Somebody (I've lost track of whether it was you or someone else) made
the claim that C programming inherently involves using hand-written
make files.  That's simply not true, and saying it won't convince
anyone that they should use Ada.  At best, you can convince them to
quit using hand-written make files, and use a more automated tool
instead.

- Bob

Re: C/C++ knocks the crap out of Ada

[Robert A Duff]

In article <4hml8s$a1q@solutions.solon.com>,
Peter Seebach <seebs@solutions.solon.com> wrote:
>Certainly.  A C implementation is free to be an interpreter that emulates
>every bit of every value and checks for arbitrary programming errors.
>
>There is no restriction that an implementation may not offer range checking,
>and many already do have stricter type checking than the standard requires.

But C doesn't have any syntax for defining the range of an int, except:

    int x; /* x is always between 1 and 10 */

So how can a C implementation check this range, without extending the
syntax of the language?  There are many other examples.

It is true that a C implementation can check array bounds without
extending the language.  But it's quite expensive at run time, because
of the confusion between pointers and arrays.

- Bob

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

In article <DoBIoL.1JC@world.std.com>,
Robert A Duff <bobduff@world.std.com> wrote:
 >In article <4hml8s$a1q@solutions.solon.com>,
 >Peter Seebach <seebs@solutions.solon.com> wrote:
 >>Certainly.  A C implementation is free to be an interpreter that emulates
 >>every bit of every value and checks for arbitrary programming errors.
 >>
 >>There is no restriction that an implementation may not offer range checking,
 >>and many already do have stricter type checking than the standard requires.
 >
 >But C doesn't have any syntax for defining the range of an int, except:
 >
 >    int x; /* x is always between 1 and 10 */
 >
 >So how can a C implementation check this range, without extending the
 >syntax of the language?  There are many other examples.

Quite frankly, you can't do it. If the integer is not used as any sort of array
index, you don't know what the range is. Here are some alternatives:

1.	Use an enumerated type. Drawback: it's not an arithmetic type.
	Incrementing an enumerated variable, for instance, is a no no.
	An expression involving an enumerated type promotes it to an
	int, and can't be assigned back to the enumerated type.

2.	assert() macros. This is ugly, and places the burden on the programmer.
	It does work, however, and _is_ standardized.

Specifying ranges for integers is something that I dearly miss about Modula 2.
(But that's about it...) It really is a significant feature.
-- 

Re: C/C++ knocks the crap out of Ada

[Richard Pitre]

In article <DoBFpD.Htx@world.std.com> bobduff@world.std.com (Robert A Duff)  
writes:
> In article <4ia666$jtm@ra.nrl.navy.mil>,
> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> >> You could argue that Ada is better because it complains when there's an
> >> inconsistency.  Fine, but for a large program, it's a nightmare to
> >> figure out what to *do* about that inconsistency, unless you have an
> >> automatic tool (not 'make').  
> >
> >You are talking about a tool that does what, exactly?
> 
> I am talking about a tool that determines what needs to be recompiled,
> and does it.  Some people have mentioned that one way to do that is for
> the tool to generate a make file.  That works OK, but it's not the only
> way to do it (and I don't really think it's the best way to do it).
> 
> Most Ada compilers, and many C compilers, come with such a tool.
> 
> >> So, in practice, you need a separate tool
> >> anyway, and if you use it religiously, you won't get burned by
> >> inconsistencies in *either* language.
> 
> >Are you saying that, in your experience, the extra checking that Ada does is  
> >not that significant relative to what a C/C++ compiler will do for you?
> >Please elaborate.
> 
> No, I wasn't saying that *in general*.  Ada compilers do *lots* of
> useful checking that C compilers don't do (and even lint doesn't do).
> 
> I was only talking about this specific case: Ada compilers check the
> consistency of compilation units, so if I compile A and B, and they both
> make use of X, then you can be sure that A and B are both using the same
> version of X.  I'll admit this is useful, but if you use the tool I
> mentioned above (and you should), then it's not *that* useful, because
> the tool ensures exactly that sort of consistency, anyway. 

Do you have personal experience of this rough equivalence or is this something  
whose practical reality should be self evident?

> I don't want
> my Ada compiler to complain about this kind of inconsistency -- I want
> it (or a separate tool) to FIX it for me, by recompiling what needs to
> be recompiled.  (And I want it to be fast!)
> 
> - Bob

richard

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

In article <adaworksDoBrqA.7or@netcom.com>,
AdaWorks <adaworks@netcom.com> wrote:
 >   No language can help you "do the right job."  Languages such as Ada
 >   and Eiffel are designed to maximize the help one can get from the
 >   compiler to "do the job right."  C++ also defines a language that
 >   makes it possible to get more help from the compiler.  Surely, no one
 >   would ever suggest that C is such a language.  If it were, there would
 >   not be such a huge aftermarket for product such as Purify.

The C standard needs to be updated to demand more ``compiler help'' and other
environment features, and a validation suite needs to be made part of the
standard.

 >   There are certainly times when one does not want to get a lot of help
 >   from the compiler.  There are some exceptionally bright people who
 >   do not require such help.  However, when it is appropriate to seek the
 >   a lot of help from a compiler, one clear choice is Ada.

The trouble is that it's not help to all the organizations that depend on C.

The choice of language is sometimes dictated by other factors than just
technical merit. Especially the _continued_ use of a particular language.

Most of the C problems lie, arguably, with the inadequate coverage by the
standard of certain issues, not with the syntax and semantics of the language
per se.

The standard doesn't require compilers to implement range checking. Hence we
have compilers without range checking. And so forth.
-- 

Re: C/C++ knocks the crap out of Ada

[Jay Martin]

c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:

>In article <4iah20$p7k@saba.info.ucla.edu>,
>Jay Martin <jmartin@cs.ucla.edu> wrote:
> >rlk@rational.com (Bob Kitzberger) writes:
> >
> >>:   make is a _general_purpose_ utility.  It _can_ be used to manage C 
> >>: projects, or it can be used for a whole host of other things.  How is 
> >>: this hard to understand?  Does ADA provide its own OS, its own editor and 
> >>: its own hardware so that you never need to use anything else?
> >
> >>I don't think that anyone is having difficulty understanding your point.
> >>Make is indeed general purpose, but its roots are in the C/Unix
> >>culture, and those roots show.
> >
> >Right, make is mostly used to support development in C and other
> >primitive languages.  I have seen this piece of crap utility used for
> >all sort of braindead misuses.  Unix-ites seem to love to dp goofy
> >things with their utilities.  Heh, I have seen people using Lex and
> >Yacc to build parsers to read in simple tables.  Like swatting a bug

>Lex and Yacc are proven utilities that work. 

Lex and Yacc are braindead crap along with C and Unix.  Do they have an
option to output Ada??

>The input file to Lex is far easier to debug and maintain than a hand-written
>lexical analyzer.
>Yacc makes you an efficient LALR(1) parser---all you do is specify a grammar
>and a few C snippet ``actions''! If it was any easier, I'd fall asleep at the
>keyboard.

You have become and "idiot savant" at it, congratulations,
unfortunately the next guy might not reading your code. I wasn't
talking about needing a grammer, I was talking with about reading in a
simple table.  Its stupid to bring in two tools with two more
"languages" to do something trivial that takes a page of normal code.

>A lex generated scanner is far more robust and _faster_ than scanf(),
you twit, >especially if you use GNU flex -f to generate the scanner.
>I have written a test program in which I compared a flex scanner against
>scanf().... 

> System specific performance nonsense deleted.
> Glowing accounts of the wonderfulness of Lex and Yacc deleted.

Jay

Re: C/C++ knocks the crap out of Ada

[AdaWorks]

Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote:


: You mean, that if I intend to write a procedure which computes the GCD of a
: pair of integers, and I somehow end up computing the LCM instead, your Ada
: programming environment will kindly inform me with a diagnostic: `


   Barry Boehm has often distinguished between,

                   "Doing the right job"

                           and

                   "Doing the job right"

   No language can help you "do the right job."  Languages such as Ada
   and Eiffel are designed to maximize the help one can get from the
   compiler to "do the job right."  C++ also defines a language that
   makes it possible to get more help from the compiler.  Surely, no one
   would ever suggest that C is such a language.  If it were, there would
   not be such a huge aftermarket for product such as Purify.

   There are certainly times when one does not want to get a lot of help
   from the compiler.  There are some exceptionally bright people who
   do not require such help.  However, when it is appropriate to seek the
   a lot of help from a compiler, one clear choice is Ada.

   Richard Riehle
   adaworks@netcom.com

-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: C/C++ knocks the crap out of Ada

[AdaWorks]

Kevin Cline (kcline@sun152.spd.dsccc.com) wrote:


: In fact there were several serious flaws in the Ada-83 language
: that made development of hosted applications in Ada-83 more difficult
: than developing them in C or C++.  

  I would almost agree, except my view is that Ada 83 shortcomings were 
  more in the category of incoveniences than "flaws."  But we are dealing
  with the new Ada standard.

  It might be useful for some readers to know that, in our experience
  teaching Ada 95, the most receptive students tend to be those who already
  know C++ (as C++).  Long-standing attributes of Ada 83 are better 
  understood by the  experienced C++ programmer.  And the updated features
  in Ada 95 are easily understood by a C++ programmer.  

  It may very well be the case that the advent of C++ has been one of the
  more important developments for assuring Ada's long-term survival.

  Richard Riehle
  adaworks@netcom.com

  
-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

In article <4icja9$1r92@saba.info.ucla.edu>,
Jay Martin <jmartin@cs.ucla.edu> wrote:
>>Lex and Yacc are proven utilities that work. 
>
>Lex and Yacc are braindead crap along with C and Unix.  Do they have an
>option to output Ada??

Sorry, I don't know. I have heard of adaptations to other languages. I would
love to try an alternate parser generator to Yacc (other than GNU Bison), but
it is the only one which I can depend to ``always be there''.

What does Ada have to do with this? If a parser generator outputs Ada code,
does that make it valid in your eyes or what?

>>The input file to Lex is far easier to debug and maintain than a hand-written
>>lexical analyzer.
>>Yacc makes you an efficient LALR(1) parser---all you do is specify a grammar
>>and a few C snippet ``actions''! If it was any easier, I'd fall asleep at the
>>keyboard.
>
>You have become and "idiot savant" at it, congratulations,
>unfortunately the next guy might not reading your code. I wasn't
>talking about needing a grammer, I was talking with about reading in a
>simple table.  Its stupid to bring in two tools with two more
>"languages" to do something trivial that takes a page of normal code.

The tools are not required once the code is distilled. They _are_ needed for
its maintenance, though not absolutely essential.

Your last sentence is an example of obsolete thinking. I could easily form all
kinds of silly arguments based on the same form: ``It's stupid to do structured
analysis, design and implementation when you can just sit down at the
workstation and hack it out!''; ``It's stupid to re-use code when you can write
from scratch!''; ``It's stupid to use a high-level language when you can code
in assembly language'', and so forth.

Let me guess, real programmers enter hexadecimal opcodes directly into memory!

Did I detect Ada advocacy coming from you? I must surely have been mistaken...

>>A lex generated scanner is far more robust and _faster_ than scanf(),
>you twit, >especially if you use GNU flex -f to generate the scanner.
>>I have written a test program in which I compared a flex scanner against
>>scanf().... 
>
>> System specific performance nonsense deleted.

This was not very system specific.  I doubt that the operating system and
hardware could be reorganized in such a way that such a landslide performance
difference could be reversed.  Perhaps with compiler optimization of the
scanf() routine, or a better scanf() implementation.

>> Glowing accounts of the wonderfulness of Lex and Yacc deleted.

Conveniently so for you. Deletion is not a form of refutation, however. It just
means that you can't find a suitable way to  falsify my claims about how these
tools have helped me  write reliable scanner and parser combinations in minimum
time. Quite unlike your ridiculous claim that using Yacc is done for the sake
of using Yacc and some sort of glory of computer science. Pure bullshit.

Yacc gets the job done. Find me a parser generator that's better, and I will
use it. I wouldn't mind one that can do canonical LR(1) rather than LALR(1),
for instance. Also a parser generator that handles some form of attribute
grammar would might also be useful to me in the future.

You are obviously a crazed fanatic with a tenuous grip on reality.  I bet the
serious Ada programmers in comp.lang.ada are red with embarrassement due to
their loose association with you.

Hatred of Yacc, indeed! Boy, I ought to report you to some animal rights
activists!

By the way, there is no such word as ``wonderfulness''. Try ``wonders of ...''.
-- 

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

In article <4idh80$6tj@solutions.solon.com>,
Peter Seebach <seebs@solutions.solon.com> wrote:
 >In article <4icja9$1r92@saba.info.ucla.edu>,
 >Jay Martin <jmartin@cs.ucla.edu> wrote:
 >>>Lex and Yacc are proven utilities that work. 
 >
 >>Lex and Yacc are braindead crap along with C and Unix.  Do they have an
 >>option to output Ada??
 >
 >Huh?  I'm sorry, but you have *no* argument here.  Lex and Yacc are brilliant;
 >they do *exactly* what they're supposed to do.  What problems do you see
 >with them?  (Reply by email, please, this is even less topical than usual.)
 >
 >Sure they have an option to output Ada.  It's the one you're about to write,
 >if it's so useful.  I have no need for it, so I'm not about to.  It could
 >be done, of course - it's just not currently needed.  :)
 >
 >>You have become and "idiot savant" at it, congratulations,
 >>unfortunately the next guy might not reading your code. I wasn't
 >>talking about needing a grammer, I was talking with about reading in a
 >>simple table.  Its stupid to bring in two tools with two more
 >>"languages" to do something trivial that takes a page of normal code.
 >
 >Very few people would bring in yacc for just reading a table.  I personally
 >would.  My table parser would also support simple expression grammars.  Could
 >you do that in a page of normal code, too?  (Of course you could; you'd
 >use perl, and call eval.)

I do too. I recently wrote a configuration file parser for a daemon I
was hired to develop. Right now, it has a brain-dead syntax. However, it is
robust with respect to comments and whitespace and deals with ".." strings,
integer constants and identifiers properly. 

I used error productions in the yacc grammar to generate useful, friendly error
messages that pinpoint a problem.

I anticipate that the grammar will get more complicated when I add certain
features; the parser/scanner will be a snap to update, compared to having to
understand my own code. :)

I didn't want to waste time writing this thing. I wanted a configuration file
facility, NOW! Lex and yacc gave it to me, in minutes. And hey, regular
expressiona and grammars _are_ more fun than switch() statements with numeric
case labels... so punish me for enjoying the ``journey'' for its own sake!
I'm glad I like my work!

 >Like all tools, lex and yacc are excellent for some tasks, and useless
 >for others.  I can only assume you've been trying to use them for
 >inappropriate tasks, or more likely, that you haven't ever used them,
 >and that you're not familiar with C, either.  You've posted many
 >claims, with *no* documentation, *no* examples, and *no* rationale.

That trick allows an author to retreat infinitely without admitting he is
wrong, because there is no wall to back into.  ``But I never said this or
that...''. Of course not. Didn't say a damn thing, in fact.  Without the
documentation, examples and whatnot, it is just *.advocacy fluff.

 >Most Ada advocates at least have points to make; you, sir, are a discredit
 >to Ada users.  Hmph.  "rabid language fanatics" indeed.

On the contrary, I don't think he discredits anyone but himself.  I'd hate to
think that someone would consider some random C/UNIX fanatic to be a discredit
to _me_.  (Unless I _am_ that fanatic, of course :).
-- 

Re: C/C++ knocks the crap out of Ada

[Peter Seebach]

In article <4icja9$1r92@saba.info.ucla.edu>,
Jay Martin <jmartin@cs.ucla.edu> wrote:
>>Lex and Yacc are proven utilities that work. 

>Lex and Yacc are braindead crap along with C and Unix.  Do they have an
>option to output Ada??

Huh?  I'm sorry, but you have *no* argument here.  Lex and Yacc are brilliant;
they do *exactly* what they're supposed to do.  What problems do you see
with them?  (Reply by email, please, this is even less topical than usual.)

Sure they have an option to output Ada.  It's the one you're about to write,
if it's so useful.  I have no need for it, so I'm not about to.  It could
be done, of course - it's just not currently needed.  :)

>You have become and "idiot savant" at it, congratulations,
>unfortunately the next guy might not reading your code. I wasn't
>talking about needing a grammer, I was talking with about reading in a
>simple table.  Its stupid to bring in two tools with two more
>"languages" to do something trivial that takes a page of normal code.

Very few people would bring in yacc for just reading a table.  I personally
would.  My table parser would also support simple expression grammars.  Could
you do that in a page of normal code, too?  (Of course you could; you'd
use perl, and call eval.)

>> System specific performance nonsense deleted.
>> Glowing accounts of the wonderfulness of Lex and Yacc deleted.

In other words, you deleted the content, and failed to respond to any
of the points.  So, you're saying you're quite sure that a hand-written
piece of code in some language would be dramatically better than a
similar thing done in lex and/or yacc?  Unconditionally?  Nonsense.

Like all tools, lex and yacc are excellent for some tasks, and useless
for others.  I can only assume you've been trying to use them for
inappropriate tasks, or more likely, that you haven't ever used them,
and that you're not familiar with C, either.  You've posted many
claims, with *no* documentation, *no* examples, and *no* rationale.

It's clear that you hate C, and anything you think is tainted by it; it's
unclear why you care so much, or where you got your ideas.

Most Ada advocates at least have points to make; you, sir, are a discredit
to Ada users.  Hmph.  "rabid language fanatics" indeed.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
FUCK the communications decency act.  Goddamned government.  [literally.]

Re: C/C++ knocks the crap out of Ada

[Richard Pitre]

In article <DoDq5n.40@world.std.com> bobduff@world.std.com (Robert A Duff)  
writes:
> In article <4icqe6$9v@ra.nrl.navy.mil>,
> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> 
> Your posting completely confuses me.  I'm mystified as to how you can
> conclude some of these things from what I wrote.  Sorry, I'll try once
> more to be clearer.
> 
> >In article <DoBr15.D23@world.std.com> bobduff@world.std.com (Robert A Duff)  
> >writes:
> >> In article <4ic8dk$amh@ra.nrl.navy.mil>,
> >> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> >> >Do you have personal experience of this rough equivalence or is this  
> >something  
> >> >whose practical reality should be self evident?
> >> 
> >> Yes, I have practical experience working on large C programs, and
> >> successfully keeping things consistent using an automatic build tool.
> >> (I hope I correctly understood what you're asking.)  I've also written
> >> such a tool for C, Pascal, Modula-2, and Ada.  The Ada support was
> >> harder then the other three put together.
> >
> >What did the tool that you wrote for Ada do, and what did the tool that you  
> >wrote for C do? From the perspective that the standard compilers do  
different  
> >things automatically,  what is it that you wrote?
> 
> I'm not sure what you're getting at, but here goes: It was one tool,
> with support for multiple languages.  It gathered information about
> inter-file dependencies from the source code, and recompiled what needed
> to be recompiled.  For efficiency, information-gathering was
> incremental.  It is true that there were differences between Ada
> compilers that needed to be handled specially -- e.g. different handling
> of pragma Inline and generic instantiations.  That problem was worse for
> Pascal, since each Pascal compiler had it's own notion of separate
> compilation -- essentially, each Pascal compiler had to be considered a
> different language, with it's own language-specific module.  For C, this
> wasn't a problem at all, as I recall.  This was 5 or 10 years ago, so
> for Ada, I'm talking about Ada 83.
> 
> >> I admit I have also worked on projects where people weren't so careful
> >> to use the tool, or used a NON-automatic build tool, like Unix 'make'
> >> and hand-written make files.  And that does indeed cause trouble: once
> >> in a while, there's a missing dependency in the make file, and it
> >> causes a run-time bug.  And there are *always* extra dependencies,
> >> which don't cause bugs, but needlessly increase compile time.  (I've
> >> also seen cases where a company ships custom-modified software to a
> >> customer, and fails to remember or save the version that was sent!)
> >> 
> >> Look, I'm not being anti-Ada.  I wouldn't have spent 3.5 years of my
> >> life helping to design Ada 9X, if I thought C was just as good a tool.
> >> I have *not* experienced C programs that effectively used type
> >> checking, or run-time range checking, or information hiding, etc etc,
> >> to prevent bugs -- lint notwithstanding.  ;-) I just think that this
> >> particular advantage of Ada over C that we're arguing about has been
> >> somewhat exaggerated.  (I didn't deny that it's an advantage, either.)
> >
> >So, can I assume that you feel that your level of productivity and
> >confidence in your results was about equal when you using C as it was
> >when you used Ada?
> 
> Umm, no, you should not assume that.  I said ONE PARTICULAR advantage of
> Ada had been exaggerated.  From that, how do you conclude that I think
> *ALL* advantages of Ada have been exaggerated?  On the contrary, I think
> there are MANY advantages of Ada over C, for many types of applications,
> and I think they are important.
> 
> >Regarding exageration of the significance of all the the extra cross  
checking  
> >etc,
> 
> ARGHH.  I did *NOT* say anything about "all the extra cross checking
> etc".  I said something about one *particular* instance of cross
> checking.
> 
> >... I don't think that the simple facts with clear implications needs any  
> >exageration at all. It should be self evident.  So again its not clear to me  
> >what you are saying here.
> 
> The feeling is mutual.  :-)
> 
> >... It sounds to me like you are saying that its no big  
> >deal when you say "somewhat exagerated".
> 
> Yes, but please understand that I was only talking about one particular
> issue, NOT about the Ada language as a whole vs. the C language as a
> whole.  Somebody claimed that Ada is superior to C because (1) you have
> to use hand-written make files in C, and (2) hand-written make files are
> awful.  I was simply trying to refute part (1) of that claim.  That's
> all.  (I happen to agree with part (2) of the claim.)
> 
> >...The only thing that I see exagerated  
>         ^^^^
> >in this thread is people's confidence in their ability to check their code  
as  
> >consistently and  perfectly as compiler would and/or promises to use  
> >prosthetics religiously. It gives me the same type of comforting feeling  
that I  
> >get from watching ads urging people to wear prophylactics. 
> 
> I understand and agree with that.  There are lots of folks going around
> denying that they themselves put bugs in their code, so where does all
> this buggy software I use every day come from !?  But that's not the
> *only* thing I see in this thread.  I also see some bogus claims about
> how Ada will walk on water and raise the dead.
> 
> >> Somebody (I've lost track of whether it was you or someone else) made
> >> the claim that C programming inherently involves using hand-written
> >> make files.  That's simply not true, and saying it won't convince
> >> anyone that they should use Ada.  At best, you can convince them to
> >> quit using hand-written make files, and use a more automated tool
> >> instead.
> >> 
> >> - Bob
> >
> >I like C and C++. They are good tools. If what you say is true then there is  
> >some hope that with the right reliable portable prosthetics I don't need to  
> >seriously consider something like Ada.
> 
> No, I disagree.  You *should* consider something like Ada.  You cannot
> add a whole bunch of tools to C (like lint), and produce an environment
> that has equal protections to something like Ada.  This is because C has
> no syntax for expressing certain kinds of constraints, which means that
> lint or any other tool is unable to know anything about those
> constraints -- they're written down as comments, if at all.
> 
> IMHO, in general Ada doesn't go FAR ENOUGH in that direction.  On the
> other hand, there are some cases in which Ada goes too far -- requiring
> the programmer to obey rules that merely get in the way, but don't
> actually help prevent bugs.  Ada isn't perfect (surprise, surprise).
> 
> >... I am obviously skeptical. This is a big deal to me and many other
> >programmers. Whether I stick with C/C++ or not, I don't care to see
> >professional programmers posturing and denying their limitations in
> >order to defend archaic tools at the cost of real solutions. How are we
> >ever going to get past square one if we let this kind of bullshitting
> >substitute for actual performance when it comes time to commit
> >resources. Here we sit with massive software projects falling in on
> >themselves and we want to defend things that suffer greviously and
> >explicitly from backward compatibility with tools that were a workable
> >compromise in 64k of memory and a 1MHz cpu.
> 
> I'm not sure what you're getting at here, either.  I don't think the
> problems of 'make' can be attributed to 64k of memory.  Besides, isn't
> it OK to defend one aspect of some archaic tool, without being accused
> of posturing and all those other evil things you mention?  I'm not even
> sure if you're accusing me or somebody else.
> 
> - Bob

Have you personally made extensive use of Ada? 

richard

Re: C/C++ knocks the crap out of Ada

[Jay Martin]

kcline@sun132.spd.dsccc.com (Kevin Cline) writes:

>Maybe, but I personally find it much easier to maintain lex & yacc
>grammers which make the file syntax explicit, instead of trying to
>divine the syntax from scanf statements scattered throughout a dozen
>subroutines.

If you have to parse something, fine use lex and yacc.  If it is
simple I prefer to use simple IO statements of the language.  Parsing
is really only needed when there are nested structures in the text.
As a user, I do not want to read a grammer for a text file format.
As a programmer annotated grammers do not do much for me either.

>The scanf programmers tend to define their input file syntax to make
>it easy to parse, rather than easy to read, and then resist all
>suggestions to extend the syntax for user convenience.

I personally do not find complex text file formats as an exceptable
user friendly method of input in this day and age.  Users should look
at GUI's not goofy text files.  Thus, slight differences in the
flexiblity of file formats is really of little concern these days as
no one should be really looking at them. Besides grammer style legacy
text file formats I see little use for parsing besides writing your
own C++ or Ada95 or other language compiler ( or pretty printer, etc).
Something I am not planning to do anytime soon.  So has GUI's and huge
languages really ruined the usefulness of parsing, or am I forgetting
some important uses of parsers.

Jay

Re: C/C++ knocks the crap out of Ada

[Zsoter Andras]

Jay Martin (jmartin@cs.ucla.edu) wrote:

>felt so Computer Scientific doing it! (The journey is the reward) By the
>way after 10+ years of using Unix I am having trouble thinking of a
>standard Unix utility that is not a total misdesigned piece of crap!
>Maybe someone can help me.

Does awk count as a "standard Unix utility" ?

Andras

Re: C/C++ knocks the crap out of Ada

[Richard Pitre]

In article <DoDq5n.40@world.std.com> bobduff@world.std.com (Robert A Duff)  
writes:
> In article <4icqe6$9v@ra.nrl.navy.mil>,
> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> 
> Your posting completely confuses me.  I'm mystified as to how you can
> conclude some of these things from what I wrote.  Sorry, I'll try once
> more to be clearer.
> 
> >In article <DoBr15.D23@world.std.com> bobduff@world.std.com (Robert A Duff)  
> >writes:
> >> In article <4ic8dk$amh@ra.nrl.navy.mil>,
> >> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> >> >Do you have personal experience of this rough equivalence or is this  
> >something  
> >> >whose practical reality should be self evident?
> >> 
> >> Yes, I have practical experience working on large C programs, and
> >> successfully keeping things consistent using an automatic build tool.
> >> (I hope I correctly understood what you're asking.)  I've also written
> >> such a tool for C, Pascal, Modula-2, and Ada.  The Ada support was
> >> harder then the other three put together.
> >
> >What did the tool that you wrote for Ada do, and what did the tool that you  
> >wrote for C do? From the perspective that the standard compilers do  
different  
> >things automatically,  what is it that you wrote?
> 
> I'm not sure what you're getting at, but here goes: It was one tool,
> with support for multiple languages.  It gathered information about
> inter-file dependencies from the source code, and recompiled what needed
> to be recompiled.  For efficiency, information-gathering was
> incremental.  It is true that there were differences between Ada
> compilers that needed to be handled specially -- e.g. different handling
> of pragma Inline and generic instantiations.

What is it that you were trying to do that the Ada compiler did not or does not  
already do?







  
> That problem was worse for
> Pascal, since each Pascal compiler had it's own notion of separate
> compilation -- essentially, each Pascal compiler had to be considered a
> different language, with it's own language-specific module.  For C, this
> wasn't a problem at all, as I recall.  This was 5 or 10 years ago, so
> for Ada, I'm talking about Ada 83.
> 
> >> I admit I have also worked on projects where people weren't so careful
> >> to use the tool, or used a NON-automatic build tool, like Unix 'make'
> >> and hand-written make files.  And that does indeed cause trouble: once
> >> in a while, there's a missing dependency in the make file, and it
> >> causes a run-time bug.  And there are *always* extra dependencies,
> >> which don't cause bugs, but needlessly increase compile time.  (I've
> >> also seen cases where a company ships custom-modified software to a
> >> customer, and fails to remember or save the version that was sent!)
> >> 
> >> Look, I'm not being anti-Ada.  I wouldn't have spent 3.5 years of my
> >> life helping to design Ada 9X, if I thought C was just as good a tool.
> >> I have *not* experienced C programs that effectively used type
> >> checking, or run-time range checking, or information hiding, etc etc,
> >> to prevent bugs -- lint notwithstanding.  ;-) I just think that this
> >> particular advantage of Ada over C that we're arguing about has been
> >> somewhat exaggerated.  (I didn't deny that it's an advantage, either.)
> >
> >So, can I assume that you feel that your level of productivity and
> >confidence in your results was about equal when you using C as it was
> >when you used Ada?
> 
> Umm, no, you should not assume that.  I said ONE PARTICULAR advantage of
> Ada had been exaggerated.  From that, how do you conclude that I think
> *ALL* advantages of Ada have been exaggerated?  On the contrary, I think
> there are MANY advantages of Ada over C, for many types of applications,
> and I think they are important.
> 
> >Regarding exageration of the significance of all the the extra cross  
checking  
> >etc,
> 
> ARGHH.  I did *NOT* say anything about "all the extra cross checking
> etc".  I said something about one *particular* instance of cross
> checking.
> 
> >... I don't think that the simple facts with clear implications needs any  
> >exageration at all. It should be self evident.  So again its not clear to me  
> >what you are saying here.
> 
> The feeling is mutual.  :-)
> 
> >... It sounds to me like you are saying that its no big  
> >deal when you say "somewhat exagerated".
> 
> Yes, but please understand that I was only talking about one particular
> issue, NOT about the Ada language as a whole vs. the C language as a
> whole.  Somebody claimed that Ada is superior to C because (1) you have
> to use hand-written make files in C, and (2) hand-written make files are
> awful.  I was simply trying to refute part (1) of that claim.  That's
> all.  (I happen to agree with part (2) of the claim.)
> 
> >...The only thing that I see exagerated  
>         ^^^^
> >in this thread is people's confidence in their ability to check their code  
as  
> >consistently and  perfectly as compiler would and/or promises to use  
> >prosthetics religiously. It gives me the same type of comforting feeling  
that I  
> >get from watching ads urging people to wear prophylactics. 
> 
> I understand and agree with that.  There are lots of folks going around
> denying that they themselves put bugs in their code, so where does all
> this buggy software I use every day come from !?  But that's not the
> *only* thing I see in this thread.  I also see some bogus claims about
> how Ada will walk on water and raise the dead.
> 
> >> Somebody (I've lost track of whether it was you or someone else) made
> >> the claim that C programming inherently involves using hand-written
> >> make files.  That's simply not true, and saying it won't convince
> >> anyone that they should use Ada.  At best, you can convince them to
> >> quit using hand-written make files, and use a more automated tool
> >> instead.
> >> 
> >> - Bob
> >
> >I like C and C++. They are good tools. If what you say is true then there is  
> >some hope that with the right reliable portable prosthetics I don't need to  
> >seriously consider something like Ada.
> 
> No, I disagree.  You *should* consider something like Ada.  You cannot
> add a whole bunch of tools to C (like lint), and produce an environment
> that has equal protections to something like Ada.  This is because C has
> no syntax for expressing certain kinds of constraints, which means that
> lint or any other tool is unable to know anything about those
> constraints -- they're written down as comments, if at all.
> 
> IMHO, in general Ada doesn't go FAR ENOUGH in that direction.  On the
> other hand, there are some cases in which Ada goes too far -- requiring
> the programmer to obey rules that merely get in the way, but don't
> actually help prevent bugs.  Ada isn't perfect (surprise, surprise).
> 
> >... I am obviously skeptical. This is a big deal to me and many other
> >programmers. Whether I stick with C/C++ or not, I don't care to see
> >professional programmers posturing and denying their limitations in
> >order to defend archaic tools at the cost of real solutions. How are we
> >ever going to get past square one if we let this kind of bullshitting
> >substitute for actual performance when it comes time to commit
> >resources. Here we sit with massive software projects falling in on
> >themselves and we want to defend things that suffer greviously and
> >explicitly from backward compatibility with tools that were a workable
> >compromise in 64k of memory and a 1MHz cpu.
> 
> I'm not sure what you're getting at here, either.  I don't think the
> problems of 'make' can be attributed to 64k of memory.  Besides, isn't
> it OK to defend one aspect of some archaic tool, without being accused
> of posturing and all those other evil things you mention?  I'm not even
> sure if you're accusing me or somebody else.
> 
> - Bob

Re: C/C++ knocks the crap out of Ada

[Jay Martin]

c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:

> >Like all tools, lex and yacc are excellent for some tasks, and useless
> >for others.  I can only assume you've been trying to use them for
> >inappropriate tasks, or more likely, that you haven't ever used them,
> >and that you're not familiar with C, either.  You've posted many
> >claims, with *no* documentation, *no* examples, and *no* rationale.

>That trick allows an author to retreat infinitely without admitting he is
>wrong, because there is no wall to back into.  ``But I never said this or
>that...''. Of course not. Didn't say a damn thing, in fact.  Without the
>documentation, examples and whatnot, it is just *.advocacy fluff.

Alright dumbshits lesson time:

  -- Tools and operating systems that only support one language are junk.
     Basic computer science, anyone who thinks otherwise is incompetent.
  
  -- Stupidly go on and on about how an certain IO routine is not as fast
     as Lex, not too swift.  (1) Won't matter if your reading in 1K.
     (2) Just shows the IO routine is broken.  Its trivia.
   
  -- Go on and on how its great to over-engineer something simple.
     How great it is to be a "savant" at a criptic tool with little
     eye to the effects of using that tool to the maintainability
     of the software.  This is called "eat shit next guy" hacking.

Of course when you tell of maintainance headaches caused by abuse of
these tools do to they are ready availability and it is supposed to be
so cool to use them.  Then its the usual C/Unix hacker macho attitude
of "they are just lame programmers" the tools are great!  

The Unix philosophy is great for the quick hack, but for larger
software development the philosophy becomes counter productive.



   

Re: C/C++ knocks the crap out of Ada

[Alan Brain]

bobduff@world.std.com (Robert A Duff) wrote:

>I understand and agree with that.  There are lots of folks going around
>denying that they themselves put bugs in their code, so where does all
>this buggy software I use every day come from !?  But that's not the
>*only* thing I see in this thread.  I also see some bogus claims about
>how Ada will walk on water and raise the dead.

Guess I've been guilty of this latter in the past - at least, according to 
many people who should know.

I find myself in a quandary though: unlike a lot of the contributors, I've 
actually worked with multiple Ada projects, and multiple C projects, and 
even more projects that were mixed. And the results I reported were the 
ones actually experienced. e.g. one case where a fault in the design of a 
CPU caused problems that the Ada run-time checks were able to detect, even 
though the fault caused essentially branches to random parts of the 
memory. In theory, of course, no language could cope with such a 
situation 'absolutely and at all times': in practice though, it could and 
did cope with it for months. 'Cope' is the word. Abnormal functionality, 
slow functionality, hiccups, but nothing fatal. In Practice, with 
sufficient error-checking, it doesn't matter that something really, really 
nasty happens for a short time: the error will soon grow so huge in 
ramifications that an inconsistency will be detected ( ie in C a Coredump) 
and you can rewind. Yes, it requires programmers who know what they're 
doing, the facilities in Ada 83 are NECCESSARY but not SUFFICIENT in the 
mathematical sense of the terms.

Our metrics showed a good rule-of-thumb was that 5% of CPU time was 
'wasted' doing error-checks, assuming pragmas in place for letting the 
compiler optimise out impossible cases. I forget what the ratio was when 
no optimisation was performed - 15% sounds about right, but don't quote 
me. I always preferred the latter though, as forex the 'branch randomly' 
error adduced above would not have been caught and worked around so easily 
(easily he says, HA! it was farnarckling painful) without it.

I always have a cold shiver when I hear that 'of course we pragma'd out 
the run-time checking in the production system'. 5% better performance is 
generally not that critical - if it is, start reaching for a new CPU, as 
the additional functionality you're gonna need in the maintenance phase 
will eat that up in a week or two.

FYI the chip was the d-stepping of the i860 , rev 4, the error occurred 
when paging was enabled, caching was enabled, and an integer was loaded 
into the floating-point processor within 16 instructions of an operation 
on it, and where an interrupt occurred. It clobbered the interrupt return 
address register, so you'd return pretty much anywhere...

I get the feeling whenever I make such a 'walk-on-water' outrageous claim, 
'Ada 83 (helps to) Solves Chip Design Fault!' I'd better give 
Chapter-and-Verse, as above. Yet it did happen, what am I to do, claim it 
didn't, just to add credibility?
   

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

In article <4if97t$1cqm@saba.info.ucla.edu>,
Jay Martin <jmartin@cs.ucla.edu> wrote:
 >c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:
 >
 >> >Like all tools, lex and yacc are excellent for some tasks, and useless
 >> >for others.  I can only assume you've been trying to use them for
 >> >inappropriate tasks, or more likely, that you haven't ever used them,
 >> >and that you're not familiar with C, either.  You've posted many
 >> >claims, with *no* documentation, *no* examples, and *no* rationale.
 >
 >>That trick allows an author to retreat infinitely without admitting he is
 >>wrong, because there is no wall to back into.  ``But I never said this or
 >>that...''. Of course not. Didn't say a damn thing, in fact.  Without the
 >>documentation, examples and whatnot, it is just *.advocacy fluff.
 >
 >Alright dumbshits lesson time:
 >
 >  -- Tools and operating systems that only support one language are junk.
 >     Basic computer science, anyone who thinks otherwise is incompetent.

What operating systems are those? Clearly you can't be talking about UNIX which
supports too many languages for me to even try to enumerate (including Ada).

 >  -- Stupidly go on and on about how an certain IO routine is not as fast
 >     as Lex, not too swift.  (1) Won't matter if your reading in 1K.
 >     (2) Just shows the IO routine is broken.  Its trivia.

Why does it show the IO routine is broken? Maybe it shows that flex generated
programs (it was GNU flex that made the faster code---lex's was _slightly_
slower) programs are in fact faster. Why do you assume that the IO routine
must necessarily be broken if it can't outperform a flex program? Have you
actually _looked_ at the the body of a flex program before spouting off?

As soon as you do anything less trivial than just scanning a bunch of numbers,
lex-generated programs  quickly become faster than the standard scanf()
routine.  The scanf() routine has to interpret its format string each time it
is invoked. On the other hand, lex generates a static table.
Suppose I have just a few keywords to match:

"foo" 	{ }
"bar"	{ }
"lex"	{ }

If I used scanf(), I would have to extract a token, and then do a search to
find which of the keywords it matches using hashing or what have you.
A lex program doesn't have to do that since when its automaton arrives at an
acceptance state, it knows which keyword has been matched. It matches them all
simultaneously.

My performance test (which I ran on three machines/operating systems, not just
one) showed that even for scanning a simple file of numbers, the lex program
was no less efficient than the IO routine scanf(), while the one generated by
flex from the same specification was twice as fast.

 >  -- Go on and on how its great to over-engineer something simple.
 >     How great it is to be a "savant" at a criptic tool with little

Cryptic tool in your eyes. A compiler is also a cryptic tool to someone who
doesn't ``speak'' the language. So is a text editor, etc. You train to learn
these things. You think that lex and yacc mastery is congenital? I learned by
taking a course, reading books and documentation, and, of course, practice. The
same way I learned everything else in computing. Programming languages,
operating systems, tools, etc. Just because you are not willing to put in the
extra effort doesn't mean that you have to denigrate the skills learned by
others who are willing to put in the effort. You surely must have put out
_some_ effort to get where you are, wherever that may be.

 >     eye to the effects of using that tool to the maintainability
 >     of the software.  This is called "eat shit next guy" hacking.

In the past I have had to modify some programs that embodied yacc parsers. I
found it quite easy. One time I was looking for a bug the ``tcpdump'' utility.
Bacause its expression compiler was done with yacc, the task was made all the
simpler. The program was far more understandable to me. I rejoiced at the
program's nice layout---far from feeling like the programmers had the above
sentiment toward me, the next guy.

 >Of course when you tell of maintainance headaches caused by abuse of
 >these tools do to they are ready availability and it is supposed to be
 >so cool to use them.  Then its the usual C/Unix hacker macho attitude
 >of "they are just lame programmers" the tools are great!  

What does ``cool'' and ``macho'' have to do anything? Get out of puberty!
Are you suffering from some kind of inferiority complex?

 >The Unix philosophy is great for the quick hack, but for larger
 >software development the philosophy becomes counter productive.

I think you are stretching your little lex and yacc slam a little too far.

You are also contradicting yourself.  A ``quick hack'' is an activity
diametrically opposed to ``over-engineering something simple''. At first you
were advocating the use of quick hacks rather than tools which abstract away
from the low-level. Now you are saying that since these tools make your work go
faster, you are guilty of quick hacking if you use them.  Getting something
done quickly is a worthwhile goal. It's called ``productivity'', and is not
necessarily incompatible with other goals.
-- 

Re: C/C++ knocks the crap out of Ada

[Norman H. Cohen]

In article <4ia41k$e04@solutions.solon.com>, seebs@solutions.solon.com
(Peter Seebach) writes: 

|> My general strategy is to just rebuild everything after any significant
|> change.  CPU time is cheap during the build process.  I have more processor
|> time than hair.

Ada would reject this comparison as a type mismatch.  C apparently
silently promotes both processor time and hair to unsigned long.

;-)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: C/C++ knocks the crap out of Ada

[Matt Kennel]

Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote:
> Most of the C problems lie, arguably, with the inadequate coverage by the
> standard of certain issues, not with the syntax and semantics of the language
> per se.

To plagiarize somebody elses aphorism,

This is like saying that the guillotine has nothing to do with the French
Revolution.  

What? Were they giant Jacobin-bacchanalia-sized brie slicers?   ;-) 

> The standard doesn't require compilers to implement range checking. 
Hence we > have compilers without range checking. And so forth.

We don't have compilers with range checking and all those other checking
things because the core concepts of the C langauge makes such an
implementation harder, slower and less idiomatic and useful and thus MORE
EXPENSIVE than a checking Eiffel or Ada implementation. 

> -- 

Re: C/C++ knocks the crap out of Ada

[Kevin Cline]

In article <adaworksDoBsy8.Brz@netcom.com>,
AdaWorks <adaworks@netcom.com> wrote:
 >Kevin Cline (kcline@sun152.spd.dsccc.com) wrote:
 >
 >
 >: In fact there were several serious flaws in the Ada-83 language
 >: that made development of hosted applications in Ada-83 more difficult
 >: than developing them in C or C++.  
 >
 >  I would almost agree, except my view is that Ada 83 shortcomings were 
 >  more in the category of incoveniences than "flaws."  But we are dealing
 >  with the new Ada standard.
 >

I suppose every language design error could be classified as an
inconvenience, since there is almost always some workaround available.
But the following missing features in Ada-83 were serious problems
when developing hosted applications and directly led to the rejection
of Ada by the marketplace:
 1. Inability to pass a function or procedure as an argument.
    This went far beyond an "inconvenience" for those of us attempting
    to use event-driven GUI libraries.  There was no portable 
    work-around for this problem.

 2. No standard interface to any OS facility more advanced
    than line-at-a-time input/output.  Also very difficult to
    work around, particularly if trying to produce a portable program. 

-- 
Kevin Cline

Re: C/C++ knocks the crap out of Ada

[Richard Pitre]

In article <DoInIF.HtK@world.std.com> bobduff@world.std.com (Robert A Duff)  
writes:
> In article <4ifccc$e2c@ra.nrl.navy.mil>,
> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> >Have you personally made extensive use of Ada? 
> 
> Why do you ask?
> 
> - Bob

If should be clear from the context that you removed.
Thanks for answering anyway.

Re: C/C++ knocks the crap out of Ada

[Peter Seebach]

In article <1996Mar19.175606.5918@nosc.mil>,
Charles H. Sampson <sampson@nosc.mil> wrote:
>In article <4ia41k$e04@solutions.solon.com>,
>Peter Seebach <seebs@solutions.solon.com> wrote:

>>To be specific, C compilers are required to tell you about *some*
>>inconsistencies.  There's a clever trick with externs that lets you get
>>this checking, and have the diagnostic be required.

>     I know I'm showing my ignorance of vanilla flavored C, but I find
>this a surprising statement.  C compilers are _required_ to tell the
>user something and there's a clever trick to get the C compiler to do
>what it's required to do.  Is this a meaning of _required_ that I'm not
>aware of?


No.  It's like this; C compilers are required to detect conflicting
definitions.  If you maintain version information in files of the sort that a
C compiler will detect if it is in conflict, you can cause the C compiler's
required diagnostics to apply to your files, as long as the versioning info is
maintained.

Not as good as "real" versioning, but cheap.  :)

>     I can understand a command line switch that affects this required
>reporting, although my preferred implementation would be to get the mes-
>sages by default and use the switch to suppress them.  However, to have
>to use a trick to obtain required behaviour seems bizarre, even for the
>C world.  Can you elaborate?

Sure.  Basically, you provide version based definitions, so any conflict will
cause a diagnostic.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
FUCK the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

In article <DoD6CB.3Kq@hkuxb.hku.hk>,
Zsoter Andras <h9290246@hkuxa.hku.hk> wrote:
 >Jay Martin (jmartin@cs.ucla.edu) wrote:
 >
 >>felt so Computer Scientific doing it! (The journey is the reward) By the
 >>way after 10+ years of using Unix I am having trouble thinking of a
 >>standard Unix utility that is not a total misdesigned piece of crap!
 >>Maybe someone can help me.
 >
 >Does awk count as a "standard Unix utility" ?

Yes. It is one of those commands standardized by POSIX.2.
-- 

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

In article <4ikbar$g0k@tpd.dsccc.com>,
Kevin Cline <kcline@sun132.spd.dsccc.com> wrote:
 >In article <adaworksDoBsy8.Brz@netcom.com>,
 >AdaWorks <adaworks@netcom.com> wrote:
 > >Kevin Cline (kcline@sun152.spd.dsccc.com) wrote:
 > >
 > >
 > >: In fact there were several serious flaws in the Ada-83 language
 > >: that made development of hosted applications in Ada-83 more difficult
 > >: than developing them in C or C++.  
 > >
 > >  I would almost agree, except my view is that Ada 83 shortcomings were 
 > >  more in the category of incoveniences than "flaws."  But we are dealing
 > >  with the new Ada standard.
 > >
 >
 >I suppose every language design error could be classified as an
 >inconvenience, since there is almost always some workaround available.
 >But the following missing features in Ada-83 were serious problems
 >when developing hosted applications and directly led to the rejection
 >of Ada by the marketplace:
 > 1. Inability to pass a function or procedure as an argument.
 >    This went far beyond an "inconvenience" for those of us attempting
 >    to use event-driven GUI libraries.  There was no portable 
 >    work-around for this problem.
 >
 > 2. No standard interface to any OS facility more advanced
 >    than line-at-a-time input/output.  Also very difficult to
 >    work around, particularly if trying to produce a portable program. 

In 1983, C had no such interface either. The C language still has no interface
to a terminal that is ``more advanced'' than line-at-a-time I/O. This is smart,
IMHO. The comp.lang.c FAQ explains the rationale behind not including ways to
do character input in the ANSI standard.

That's what POSIX.1 is for: there is a POSIX interface standard for C as well
as Ada.
-- 

Re: C/C++ knocks the crap out of Ada

[Charles H. Sampson]

In article <4ia41k$e04@solutions.solon.com>,
Peter Seebach <seebs@solutions.solon.com> wrote:
>
>To be specific, C compilers are required to tell you about *some*
>inconsistencies.  There's a clever trick with externs that lets you get
>this checking, and have the diagnostic be required.

     I know I'm showing my ignorance of vanilla flavored C, but I find
this a surprising statement.  C compilers are _required_ to tell the
user something and there's a clever trick to get the C compiler to do
what it's required to do.  Is this a meaning of _required_ that I'm not
aware of?

     I can understand a command line switch that affects this required
reporting, although my preferred implementation would be to get the mes-
sages by default and use the switch to suppress them.  However, to have
to use a trick to obtain required behaviour seems bizarre, even for the
C world.  Can you elaborate?

				    Charlie

Re: C/C++ knocks the crap out of Ada

[Sheldon White]

In article <4if97t$1cqm@saba.info.ucla.edu> jmartin@cs.ucla.edu (Jay Martin) writes:
>c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:
>

(deletia)

>
>Alright dumbshits lesson time:
>
>  -- Tools and operating systems that only support one language are junk.
>     Basic computer science, anyone who thinks otherwise is incompetent.
>  

That's probably true. Fortunately, UNIX is not such a system.

>  -- Stupidly go on and on about how an certain IO routine is not as fast
>     as Lex, not too swift.  (1) Won't matter if your reading in 1K.
>     (2) Just shows the IO routine is broken.  Its trivia.
>   

I've worked on a lot of parsers, both using Yacc/Lex and using straight C
code. Unless the syntax was completely trivial, using a tool like Yacc is
vital for maintaining the code. Also, if your scanf version is too slow, what
are you going to do? Rewrite scanf()?

>  -- Go on and on how its great to over-engineer something simple.
>     How great it is to be a "savant" at a criptic tool with little
>     eye to the effects of using that tool to the maintainability
>     of the software.  This is called "eat shit next guy" hacking.
>

Have you ever had to maintain a large parser, day in and day out, written in
"just-crank-some-code" C? Talk about "eat shit next guy"...

Have you ever used a tool like Yacc?

>Of course when you tell of maintainance headaches caused by abuse of
>these tools do to they are ready availability and it is supposed to be
>so cool to use them.  Then its the usual C/Unix hacker macho attitude
>of "they are just lame programmers" the tools are great!  
>

There's nothing cool about Yacc. There's nothing cool about a sledgehammer.
They are tools that can make life much, much easier.

>The Unix philosophy is great for the quick hack, but for larger
>software development the philosophy becomes counter productive.

I'm sorry, but you sound like someone who hasn't had to maintain a large
-- 

-sheldon white-  :^/

sheldon@amc.com

Re: C/C++ knocks the crap out of Ada

[David Taylor]

In article <4id4cc$1rau@saba.info.ucla.edu>,
Jay Martin <jmartin@cs.ucla.edu> wrote:
>
>I personally do not find complex text file formats as an exceptable
>user friendly method of input in this day and age.  Users should look
>at GUI's not goofy text files.  Thus, slight differences in the
>flexiblity of file formats is really of little concern these days as
>no one should be really looking at them. Besides grammer style legacy
>text file formats I see little use for parsing besides writing your
>own C++ or Ada95 or other language compiler ( or pretty printer, etc).
>Something I am not planning to do anytime soon.  So has GUI's and huge
>languages really ruined the usefulness of parsing, or am I forgetting
>some important uses of parsers.

How about tools for extracting information from source code?  If you
use a structured commenting convention in your code, then you can
extract extremely useful documentation with a simple parser.  (Doesn't
Java have something like this?)

Or how about small custom tools?  For example, one project I worked
(using C) on had a tool to generate prototype files.

Besides, with text based formats, you can do remote configuration a
lot more easily (I'm guessing you're not using X).

-- 
Andrew Taylor     |email: davidt@cpsc.ucalgary.ca
                  |www:   http://www.cpsc.ucalgary.ca/~davidt

Re: C/C++ knocks the crap out of Ada

[Jay Martin]

sheldon@amc.com (Sheldon White) writes:

>In article <4if97t$1cqm@saba.info.ucla.edu> jmartin@cs.ucla.edu (Jay Martin) writes:
>>c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:
>>

>(deletia)

>>
>>Alright dumbshits lesson time:
>>
>>  -- Tools and operating systems that only support one language are junk.
>>     Basic computer science, anyone who thinks otherwise is incompetent.
>>  

>That's probably true. Fortunately, UNIX is not such a system.

Then where have been the standard system interfaces for all the
other languages?  They don't exist.  UNIX only really supports
one language, C.  Which is why C didn't die like all the other
low level languages of its period.

>>  -- Stupidly go on and on about how an certain IO routine is not as fast
>>     as Lex, not too swift.  (1) Won't matter if your reading in 1K.
>>     (2) Just shows the IO routine is broken.  Its trivia.
>>   

>I've worked on a lot of parsers, both using Yacc/Lex and using straight C
>code. Unless the syntax was completely trivial, using a tool like Yacc is
>vital for maintaining the code. Also, if your scanf version is too slow, what
>are you going to do? Rewrite scanf()?

We were talking about a trivial table, something easily accomplished
by standard IO routines in any language. That I mentioned "scanf" in a
retort was not inportant (scanf == simple IO routines).  (Scanf is
obsolete anyway use "iostream.h") If you are reading a 2K file at the
start of a 2 day computation should you care?  If scanf is so slow its
broken, like most of C.  Using Lex/Yacc to read in tables just for the
sake of performance is really silly.  Its just another example of the
rabid performance paranoia exhibited by C programmers.

>>  -- Go on and on how its great to over-engineer something simple.
>>     How great it is to be a "savant" at a criptic tool with little
>>     eye to the effects of using that tool to the maintainability
>>     of the software.  This is called "eat shit next guy" hacking.
>>

>Have you ever had to maintain a large parser, day in and day out, written in
>"just-crank-some-code" C? Talk about "eat shit next guy"...

Yes I would and have used a parser tool like Yacc for a real parser
(Though for a really good language compiler I hear its worth the pain
of a recursive decent parser), but I wasn't talking about a parser
or a real grammer we were talking about over engineering simple
IO code.

>Have you ever used a tool like Yacc?

Yes

>>Of course when you tell of maintainance headaches caused by abuse of
>>these tools do to they are ready availability and it is supposed to be
>>so cool to use them.  Then its the usual C/Unix hacker macho attitude
>>of "they are just lame programmers" the tools are great!  
>>

>There's nothing cool about Yacc. There's nothing cool about a sledgehammer.
>They are tools that can make life much, much easier.

If you are using them to do what they are supposed to do, then they
are cool.  This whole thread is using complex tools when they are not
necessary. One guy bragged about how cool it is to instead of just
inputting a number, you allow arbitrarily complex expressions to be
inputed. Extra complex tools causes maintance headaches because it
requires expertise when it is not necessary. 

Suppose I have programmer that works for me "FORTRAN-Bob".  Bob
doesn't have a CS degree and is learning C.

CS-Jay:  Well Bob your input file to your program should probably
         be done as a parser.  Its really cool and allows you to
         have "free format" input and stuff. 

FORTRAN-BOB:  You mean so it will be so easy to use as if it had a GUI or
              DB front end?

CS-Jay: Well no not really, it will still suck, but I think parsers
        are cool.  Well anyway you got to read some books, first
        you will need to read this automata/language theory book
        here, then half of this compilers text, after that you
        should read thes lex and yacc books.  And so you don't
        make any style mistakes read "Good style with Lex and
        Yacc".

FORTRAN-BOB: (Thoughts) I wish I could use FORTRAN READ.

Moral: Just because you are an expert at something doesn't mean
everyone else is.

>>The Unix philosophy is great for the quick hack, but for larger
>>software development the philosophy becomes counter productive.

>I'm sorry, but you sound like someone who hasn't had to maintain a large

Yes I have maintained large programs.  The Unix philosophy is
anti-software engineering (quick and dirty) if you ask me.

Jay

Re: C/C++ knocks the crap out of Ada

[Kevin Cline]

In article <4imqofINNn82@keats.ugrad.cs.ubc.ca>,
Kazimir Kylheku <c2a192@ugrad.cs.ubc.ca> wrote:
>In article <4ikbar$g0k@tpd.dsccc.com>,
>Kevin Cline <kcline@sun132.spd.dsccc.com> wrote:
> > 2. No standard interface to any OS facility more advanced
> >    than line-at-a-time input/output.  Also very difficult to
> >    work around, particularly if trying to produce a portable program. 
>
>In 1983, C had no such interface either. The C language still has no interface
>to a terminal that is ``more advanced'' than line-at-a-time I/O. This is smart,
>IMHO. The comp.lang.c FAQ explains the rationale behind not including ways to
>do character input in the ANSI standard.
>
>That's what POSIX.1 is for: there is a POSIX interface standard for C as well
>as Ada.

You are confusing de jure standards with de facto standards.  Both are
useful.  In fact, it is often the case that de facto standards are
more useful than de jure standards: consider TCP/IP vs. OSI, and
PHIGS vs. OPEN-GL. 

The Ada community has been particularly slow at agreeing on de facto
standards, while the C community has moved much more quickly.  Every
UNIX workstation is now X-windows based and the Ada community still
hasn't agreed on an API to X-windows.

Practically this meant that the same C program could be ported between
compilers on the same OS, and could be ported between UNIX systems
with a bit more effort.  This was not the case for Ada programs; every
compiler vendor provided a different API to the POSIX.1 facilities,
and until GNAT, no single compiler was available for all popular UNIX
systems.

There is much to like about the Ada language, but it just isn't practical
for development of medium-scale (50-100K SLOC) UNIX or PC applications
with a significant system interface.  The high startup cost and portablility 
problems overwhelm the advantages of more stringent compile-time 
and run-time checking.  For 1M SLOC projects the advantages of Ada 
may outweigh the disadvantages.
-- 
Kevin Cline

Re: C/C++ knocks the crap out of Ada

[Richard Pitre]

In article <4ipbdb$6j7@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline)  
writes:
> There is much to like about the Ada language, but it just isn't practical
> for development of medium-scale (50-100K SLOC) UNIX or PC applications
> with a significant system interface.  The high startup cost and portablility 
> problems overwhelm the advantages of more stringent compile-time 
> and run-time checking. 

Please say more about why this is so. Is it primarily the X Window interface  
that caused you problems? Do you have any opinion about  Ada-Tcl. 
Any more detailed experiences with relative costs of implementation, 
interfacing, maintenance etc. in C++ vs. Ada would be very useful. All of these
things are things that I'm trying to weigh in moving away 
from pure C coding. Email is fine.

I'm encouraged to see that GNAT
is available on so many systems. C++ is available everywhere but I have a 
concern that the features that I like in C++ are not uniformly 
available. What are your observations on this issue? 
I've had a little luck with Borland C++ but I don't believe that 
the feature set of Borland  C++ is portable. The Gnu g++ compiler is 
a potential solution but it did asked for a bug report on the very first file, 
that I gave it. Dismay. Perhaps g++ it could use some DoD 
support like GNAT had. 

> For 1M SLOC projects the advantages of Ada 
> may outweigh the disadvantages.
> -- 
> Kevin Cline

How, in your view, does GNAT affect this final assessment?
My application area is sonar simulation for research purposes. 
The codes are usually not large but they have many interacting components 
i.e.  they get fairly complex and they can get to be of moderate size. 
Its necessary to interface with old and new Fortran libraries. 

I'm definitely leaning toward GNAT and am experimenting with it now.
Based on a limited experience with the overhead of making GUI's, 
I confine myself to file IO  and use commercial packages 
like Mathematica, Matlab etc. on the front and back ends. A coworker is
looking into the practicality of Tcl/Tk but its not likely. The closest
thing that I have seen to a GUI builder that is implementationally cost viable
in my setting is NeXTStep Interface Builder. Nevertheless, it is 
useless because of the non portability. I guess there are X-Window tools
that surpass it now. If so I would like to hear about them.

richard

Re: C/C++ knocks the crap out of Ada

[AdaWorks]

Kevin Cline (kcline@sun132.spd.dsccc.com) wrote:
: In article <adaworksDoBsy8.Brz@netcom.com>,
: AdaWorks <adaworks@netcom.com> wrote:
:  >Kevin Cline (kcline@sun152.spd.dsccc.com) wrote:
:  >
:  >

: I suppose every language design error could be classified as an
: inconvenience, since there is almost always some workaround available.
: But the following missing features in Ada-83 were serious problems
: when developing hosted applications and directly led to the rejection
: of Ada by the marketplace:
:  1. Inability to pass a function or procedure as an argument.
:     This went far beyond an "inconvenience" for those of us attempting
:     to use event-driven GUI libraries.  There was no portable 
:     work-around for this problem.

   OK, Kevin,

   I'll give you this one. There were some non-portable workarounds, but
   this was a shortcoming of Ada 83.  The new ISO Ada standard supports 
   the ability to pass a function of procedure as an argument.

   However, for the next one:

:  2. No standard interface to any OS facility more advanced
:     than line-at-a-time input/output.  Also very difficult to
:     work around, particularly if trying to produce a portable program. 

   The only thing wrong with this was including it in the "core" of the
   Ada 83 definition.  Text_IO was never intended to be more than it 
   was, a universal scrolling, left-to-right and downward I/O package.
   The issue with all the I/O packages was portability.  It still is.

   Nothing in the Ada 83 design precludes the creation of I/O packages
   for other terminals, operating systems, and I/O devices.  In fact, such
   packages abound.  How do you think people use Ada for the huge range
   of operating systems on which applications have been deployed?

   The Ada predefined I/O packages were not intended to be platform-specific.
   The language designers expected compiler vendors to provide packages for
   I/O on their targeted platforms.  Many compiler publishers fell short in
   this area. This was especially true of "checkbox" compilers supplied
   by some of the hardware vendors. 

   Once again, the ISO 1995 Ada standard updates the facilities of the I/O
   packages, but portability is still a concern.  Therefore, interfaces to
   specific operating systems is outside the scope of the core language,
   as it should be.

   Richard Riehle
   adaworks@netcom.com
  
       BTW, a "checkbox" compiler is one which satisfies the minimum
       standard for validation so the vendor can check the box on the
       procurement request for validated Ada.  This practice created
       additional problems for Ada since the hardware vendor was only
       interested in getting a collection of computers in the door, not
       in seriously supporting Ada.  To avoid lawsuits, I'll not post
       the names of such vendors, but they know who they are.

       RR
-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

In article <4ipbdb$6j7@tpd.dsccc.com>,
Kevin Cline <kcline@sun132.spd.dsccc.com> wrote:
 >The Ada community has been particularly slow at agreeing on de facto
 >standards, while the C community has moved much more quickly.  Every

Not sure about that one. Ada became standardized very quickly, compared to C.
It is a younger language, yet C took until 1989 to become standardized, six
years after Ada 83.

 >UNIX workstation is now X-windows based and the Ada community still
 >hasn't agreed on an API to X-windows.

Well, that's a little unfair, considering that X was developed using C. The
Xlib client library naturally arose at the same time as X! Let's give the Ada
folk a break!
-- 

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

In article <4ipbdb$6j7@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes:

> The Ada community has been particularly slow at agreeing on de facto
> standards, while the C community has moved much more quickly.  Every
> UNIX workstation is now X-windows based and the Ada community still
> hasn't agreed on an API to X-windows.

What's the matter with the C one?  Sure, it's lowlevel, but the C
folk get by with it.  Just take the thin binding (via interfaces.c)
and place the use of it in the implementation of the "GUI" interface
specification for your program.


> Practically this meant that the same C program could be ported between
> compilers on the same OS, and could be ported between UNIX systems
> with a bit more effort.  This was not the case for Ada programs; every
> compiler vendor provided a different API to the POSIX.1 facilities,
> and until GNAT, no single compiler was available for all popular UNIX
> systems.

Well, the POSIX bindings have been done for a while now.  And they
work fine with Gnat.  So, I suppose this paragraph is just irrelevant
rubbish.


> There is much to like about the Ada language, but it just isn't practical
> for development of medium-scale (50-100K SLOC) UNIX or PC applications
> with a significant system interface.  The high startup cost and portablility 

Really?  It's worked just fine for me on several occasions for this
sort of thing.  Quite practical.


> problems overwhelm the advantages of more stringent compile-time 
> and run-time checking.  For 1M SLOC projects the advantages of Ada 
> may outweigh the disadvantages.

Checking is the least advantage Ada offers.  I see you are still
smoking some pretty potent stuff.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

In article <adaworksDoL573.7vs@netcom.com> adaworks@netcom.com (AdaWorks) writes:

>    OK, Kevin,
> 
>    I'll give you this one. There were some non-portable workarounds, but
>    this was a shortcoming of Ada 83.  The new ISO Ada standard supports 
>    the ability to pass a function of procedure as an argument.

Kevin does not appear to realize that it is 1996 and that ISO 8652:1995
has been out for over a year and that compilers (including Gnat and
ObjectAda) for it are available.  This seems to be why his comments
are largely out-of-date irrelevant rubbish.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C/C++ knocks the crap out of Ada

[Ron Collins]

Ken Garlington (GarlingtonKE@lfwc.lockheed.com) wrote:
: Kazimir Kylheku wrote:
: > 
: > Make is not really a C tool. I use Make to process TeX documents for instance.

: AFAIK, Make-type tools are commonly used to manage large C applications. Is this
: not the case?

"make" is also used to manage large Ada applications.  (Our developement
system runs a script that uses "make" with an auto-generated makefile).

I wouldn't consider "make" to belong to any particular language or
application.

			-- collins --

Re: C/C++ knocks the crap out of Ada

[Glenn H. Porter]

I missed the original post on this thread, but I have a couple of
observations about ADA vs C.

First, ADA was invented so that DoD could have a single, maintainable
sourcecode language for all _embedded_ computing systems (check the
legislation on this--embedded systems are specifically stated in the
statute).  At the time the requirement was stated, C was a private
language, and the whole community was awash with different,
incompatable versions of a number of languages that we'd call "stupid"
or worse today.

Second, a large number of customers in DoD have missed the meaning of
"embedded systems", and therein lies the crux of the I/O problem.  An
embedded system is a computer that, say, runs a targeting computer on
a fighter, or the navigation system on a missile.  The I/O is hardware
dependent, but the software must not be, because the system may be
upgraded at any time for new functionality or differing missions or
threats.  There are _no_ embedded desktop applications.  I've seen an
application that was embedded but ran on an Intel-based laptop.  This
program was not much more than a text processor that told
microprocessor-controlled radios what to do and told the operator what
they said in return.  The silly thing was almost 200k of executable!
But it was maintainable, and that's the key.

That said, I think ADA is a great language for applications that use
hardware I/O, because the hard part is taken care of by the hardware.
The meaning of the input, and the outputs needed are the business of
the programmer.

Finally, the replies on this thread seem to have degenerated to the
level of C programmers snapping at each other.  How does that fit in
on the thread?

Glenn

Re: C/C++ knocks the crap out of Ada

[Kevin Cline]

In article <adaworksDoL573.7vs@netcom.com>,
AdaWorks <adaworks@netcom.com> wrote:
 >   Nothing in the Ada 83 design precludes the creation of I/O packages
 >   for other terminals, operating systems, and I/O devices.  In fact, such
 >   packages abound.  How do you think people use Ada for the huge range
 >   of operating systems on which applications have been deployed?

The problem I had with Ada-83 was that I became responsible for
the creation of these packages.  In C or C++, I would have had
a ready-made API.  Yet another Ada project start-up cost that a C
developer would not have to pay.
-- 
Kevin Cline

Re: C/C++ knocks the crap out of Ada

[AdaWorks]

Kevin Cline (kcline@sun132.spd.dsccc.com) wrote:

: The problem I had with Ada-83 was that I became responsible for
: the creation of these packages.  In C or C++, I would have had
: a ready-made API.  Yet another Ada project start-up cost that a C
: developer would not have to pay.
: -- 
: Kevin Cline
 
  Kevin,

  I agree that it was frustrating to purchase a compiler and discover
  that the compiler publisher forgot to include platform-specific I/O
  packages.  This was in part due to the idea that all one had to do
  to provide an Ada compiler was pass the validation suite.  Hardware
  vendors were particularly culpable on this one.  

  With a little luck, we will see the compiler publishers paying attention
  to need for their compiler to actually work on the devices attached to
  the operating system for which their compiler is intended.

  Before I get flamed too badly, not all compiler publishers were at 
  fault on this. And many got better as they got more mature in their
  understanding of the needs of their customers.

  Richard Riehle
  adaworks@netcom.com
-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: C/C++ knocks the crap out of Ada

[Kevin Cline]

In article <JSA.96Mar21154344@organon.com>,
Jon S Anthony <jsa@organon.com> wrote:
>Well, the POSIX bindings have been done for a while now.  And they
>work fine with Gnat.  So, I suppose this paragraph is just irrelevant
>rubbish.
>

You took my remarks out of context.  I was pointing out why Ada is not
more popular now, and why people had good and sufficient for
continuing to use C and C++ through the early 1990's.  Ada advocates
seem to attribute to continued use of C and C++ to willful ignorance,
and that just isn't so.  There were serious portability problems with
the use of Ada for UNIX application development in the days before
GNAT.  

>...
>It's worked just fine for me on several occasions for this
>sort of thing.  Quite practical.

Perhaps you could tell us more precisely what sort of things you have 
developed. How large was your application?  Did you provide a GUI?  
What compiler did you use?  When did you write it?   Did you port it
or attempt to port it to multiple varieties of UNIX, 
say SunOS and HP-UX and SGI Irix?
-- 
Kevin Cline

Re: C/C++ knocks the crap out of Ada

[Kevin Cline]

In article <JSA.96Mar21160427@organon.com>,
Jon S Anthony <jsa@organon.com> wrote:
>In article <adaworksDoL573.7vs@netcom.com> adaworks@netcom.com (AdaWorks) writes:
>
>>    OK, Kevin,
>> 
>>    I'll give you this one. There were some non-portable workarounds, but
>>    this was a shortcoming of Ada 83.  The new ISO Ada standard supports 
>>    the ability to pass a function of procedure as an argument.
>
>Kevin does not appear to realize that it is 1996 and that ISO 8652:1995
>has been out for over a year and that compilers (including Gnat and
>ObjectAda) for it are available.  This seems to be why his comments
>are largely out-of-date irrelevant rubbish.
>

You don't seem to realize that I wasn't talking about 1996.  I was 
relating my problems developing an Ada application from 1991 to 1994,
and explaining why the issues prevented the use Ada for normal
desktop applications, at least until the release of GNAT.
These early problems were a major factor causing Ada's
continuing unpopularity.  People tried it.  They didn't like it.
Now everything is fixed, but that early taste lingers.

BTW, what architectures does ObjectAda support, and will ObjectAda
code compile largely unmodified with Gnat, and vice versa?


-- 
Kevin Cline

Re: C/C++ knocks the crap out of Ada

[David Weller]

In article <4isvac$kek@tpd.dsccc.com>,
Kevin Cline <kcline@sun132.spd.dsccc.com> wrote:
>In article <adaworksDoL573.7vs@netcom.com>,
>AdaWorks <adaworks@netcom.com> wrote:
> >   Nothing in the Ada 83 design precludes the creation of I/O packages
> >   for other terminals, operating systems, and I/O devices.  In fact, such
> >   packages abound.  How do you think people use Ada for the huge range
> >   of operating systems on which applications have been deployed?
>
>The problem I had with Ada-83 was that I became responsible for
>the creation of these packages.  In C or C++, I would have had
>a ready-made API.  Yet another Ada project start-up cost that a C
>developer would not have to pay.

This is certainly more of a point about economics than any technical
flaw in the language (although Ada 83 did have some akward issues).

Most vendors (rightly) regard C as the "Least Common Denominator" for
their markets.  This doesn't make it any easier for somebody working
in Delphi, Java, COBOL, or Fortran (or Ada).  The problem, of course,
is that many companies can't invest the $$ to create bindings for all
their customer's pet languages.  CORBA IDL does a great job of making
that step a little easier, but I don't think we're going to see
widespread distributions in IDL for some time.  

In any case, it's quite true that you would avoid paying for the
creation of an API layer by using C or C++, but not every problem is
suited for C/C++, and most of the time, you're better off investing
the small amount of money to create an API (compared to switching to
something "archaic" like C :-)

-- 
		    GNAT = GNAT is Not an Ada Translator
==Ada 95 Booch Components: www.ocsystems.com/booch or www.dfw.net/~dweller==
Reality: Work, Work, Work, Guitar.         | Plugged: Fender Telecaster Deluxe
Fantasy: Guitar, Guitar, Guitar, Work(ha!) | Unplugged: Yamaha CG-150SA

Re: C/C++ knocks the crap out of Ada

[Carl J R Johansson]

Richard Pitre (pitre@n5160d.nrl.navy.mil) wrote:

: In software and language design there is a conflict between the need for  
: machine efficiency and our limited ability to manage complexity. The  
: differences between Ada and C++ can be fruitfully discussed  in terms of the  
: different compromises which were made in their designs in order to deal with  
: this conflict.  It is my understanding that the implementers of both languages  
: struggled mightily with this issue. To my knowledge, there is no universal  
: ideal compromise.

So, is C really so much more efficient than other languages (I do not
question the efficiency of assembly, just C/C++) and is it not just a
myth? Does anyone have figures on this? I don't think a difference of a
few microseconds has any practical implications if that is what is
referred to. 

Of course measuring can be a bit difficult, both applications should
probably be done by one person equally fluent in both languages (and
unbiased) and on the same platform (without any inline assembly). 
If possible s/he should probably be as experienced as possible. 

With efficiency I mean raw speed and not memory usage etc.

carl.johansson@helsinki.fi
http://www.helsinki.fi/cjjohans/

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

Carl says

"So, is C really so much more efficient than other languages (I do not
question the efficiency of assembly, just C/C++) and is it not just a
myth? Does anyone have figures on this? I don't think a difference of a
few microseconds has any practical implications if that is what is
referred to."

There is no such language as C/C++

There are two completely different languages C and C++, the fact that
there is a significant intersection (it's only an intersection, C is not
a subset of C++) should not lead to confusing them into one language.

If you are looking at C, then the answer is no, C is not much more
efficient than other languages. This depends on implementations, not
languages. For example, Phillippe Kahn of Borland once suprised a
big meeting by noting that the fastest compiler for ANY langueg on
the prime number sieve benchmark was Realia COBOL (I am talking not
about compiler speed here, though Realia COBOL was and is the fastest
compiler on the PC, but about performance of executable code). What
are we to conclude from this? That COBOL is a more efficient language
than C? Of course not! Just that the Realia COBOL compiler had a better
code generator.

In the case of Ada, and C, the performance varies. If you use the same
code generator with similar code, then you get the same performance. Last
year at the UK Ada meeting, someone came to me and reported (with an amazed
tone) that Whetstone running on GNAT was comparable with Whetstone running
with GCC C (and was incidentally better than any other Ada compiler he had
tried). Fine, I was not surprised! What would have suprised me is if they
had been different -- that could only be caused by a bug. There are still some
bugs of this type around, where the GNAT/Ada performance is not what one would
expect, but they are getting steadily fixed.

Comparing C++ and Ada 95 wrt high level features like exceptions, dispatching,
and finalization is MUCH harder here. In fact for such features, the restuts
are even MORE likely to depend on implementatoin strategy and quality.

You *can* make some theoretical observations on efficiency. For example,
other things being equal, the obviously far superior aliasing information
available in Ada, due to its strong typing, and lack of pointer punning,
will give an advantage over C. However, things are almost never equal 
enough to actually measure these theoretical advantages.

Another point that may make Ada seem slow is that it is a higher level
language than C, and if you take advantage of high level features, you
pay a price. For example, if you use Unbounded_Strings and compare it
with do it yourself strings in C, with manual storage allocation, then
you will find that the Ada is slower. THat's because there is an overhead
to be paid for using high level features like the automatic finalization
that is part of the Unbounded_Strings implementation. On th other hand,
you have gained convenience and safety, which may well be worthwhile
trade offs.

I often find that Ada programmers are blissfully unaware of the consequences
of the code they write. It is instructive to use the -gnatdg switch in GNAT
which displays the low level generated code in a syntax close to normal
Ada to understand the consequneces of the use of high level features.

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

In article <4iupk7$5t4@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes:

> >Kevin does not appear to realize that it is 1996 and that ISO 8652:1995
> >has been out for over a year and that compilers (including Gnat and
> >ObjectAda) for it are available.  This seems to be why his comments
> >are largely out-of-date irrelevant rubbish.
> >
> 
> You don't seem to realize that I wasn't talking about 1996.  I was 
> relating my problems developing an Ada application from 1991 to 1994,

The reason I wouldn't realize this (along with most others) is that
you keep saying it with _present_ tense.

> These early problems were a major factor causing Ada's
> continuing unpopularity.  People tried it.  They didn't like it.
> Now everything is fixed, but that early taste lingers.

Now here issomething that does have a fair degree of truth in it.


> BTW, what architectures does ObjectAda support, and will ObjectAda
> code compile largely unmodified with Gnat, and vice versa?

A Thompson guy could better answer this.  I would be surprised
if Gnat and ObjectAda didn't compile things with little or no
modification.  Heck, I've taken large chuncks of VAX Ada and moved
them to Gnat with no changes.  Of course, these did not have any
OS specific stuff in them.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

"A Thompson guy could better answer this.  I would be surprised
if Gnat and ObjectAda didn't compile things with little or no
modification.  Heck, I've taken large chuncks of VAX Ada and moved
them to Gnat with no changes.  Of course, these did not have any
OS specific stuff in them."

That should be true providing you stick to the subset of the language in
terms of annexes that ObjectAda implements. GNAT is the only Ada 95
compiler so far that implements all the annexes, so if you take advantage
of this, your code will not be easily portable to other compilers not
supprting these annexes. 

Moving large chunks of VAX Ada is not a test, since that is Ada 83 code.

The question was whether GNAT code can be moved to ObjectAda. Note also
that GNAT implements a number of implementatoin dependent pragmas
and attributes. If you are using any of these, you will have to check
whether the other compiler does too. FOr example, if you are using the
pragmas to provide interoperability between C++ classes and Ada tagged
types, you may have a hard time moving your code. Not only may the pragmas
not exist, but there simply may be no such interoperability, since it is
not rquired by the standard.

As always, if you want to write highly portable code, stay away from
implementation dependent features, and make sure the compilers support
the same feature sets.

Of course porting code from one GNAT implementation to another is much
less of a problem, and since GNAT is available on many platforms, with
more being added all the time, this form of portability will be enough
for many users of Ada 95 :-)

Robert Dewar
Ada Core Technologies

Re: C/C++ knocks the crap out of Ada

[Ed Falis]

Jon S Anthony wrote:
> 
> In article <4iupk7$5t4@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes:
> 
> > BTW, what architectures does ObjectAda support, and will ObjectAda
> > code compile largely unmodified with Gnat, and vice versa?
> 
> A Thompson guy could better answer this.  I would be surprised
> if Gnat and ObjectAda didn't compile things with little or no
> modification.  Heck, I've taken large chuncks of VAX Ada and moved
> them to Gnat with no changes.  Of course, these did not have any
> OS specific stuff in them.
> 

Well, I'll give it a shot.  This year, it'll be Wintel, PowerPC/Win NT, 
Sun/Solaris, HP-UX and (I believe) PowerPC/AIX.  We also expect Wintel 
cross to 32 bit X86 this year.  Various PowerPC and 68K cross early next 
year.

My experience so far is that the ability to cross compile code developed 
on GNAT or ObjectAda is pretty good - the main issues are in a couple of 
areas: one or other of the front-ends is a bit stronger in "corners" of 
the language, availability of identical bindings, and application use of 
implementation defined pragmas (Unchecked_Union definitely comes to 
mind, per discussion on another thread).  On the other hand, there are 
an awful lot of issues that we used to see with Ada 83 compilers that 
just aren't there any more, especially such things as vendor defined 
unsigned types, low-level operations on addresses, shift operations etc. 
 And these latter issues have always been the real ugly ones I've seen - 
where client code is calling 
"vendor_x_system.ought_to_have_been_defined_in_the_standard;"

and it has to be reorganized or changed in hundreds of places.  
Obviously this was poor design, but Ada 95 will still help with its more 
uniform treatment of these kinds of issues.

- Ed
Ed Falis	
Thomson Software   falis@thomsoft.com	(617) 221-7341
========================================================
Ideological disarmament: a koan for the 21st century
========================================================

Re: C/C++ knocks the crap out of Ada

[Kevin Cline]

In article <31582A63.4BE9@east.thomsoft.com>,
Ed Falis  <falis@east.thomsoft.com> wrote:
>Jon S Anthony wrote:
>> 
>> In article <4iupk7$5t4@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes:
>> 
>> > BTW, what architectures does ObjectAda support, and will ObjectAda
>> > code compile largely unmodified with Gnat, and vice versa?
>> 
>> A Thompson guy could better answer this.  I would be surprised
>> if Gnat and ObjectAda didn't compile things with little or no
>> modification.  Heck, I've taken large chuncks of VAX Ada and moved
>> them to Gnat with no changes.  Of course, these did not have any
>> OS specific stuff in them.
>> 
>
>Well, I'll give it a shot.  This year, it'll be Wintel, PowerPC/Win NT, 
>Sun/Solaris, HP-UX and (I believe) PowerPC/AIX.  We also expect Wintel 
>cross to 32 bit X86 this year.  Various PowerPC and 68K cross early next 
>year.
>

Well, that means that today's ObjectAda would not solve
my 1993 problem: writing a Motif application for SunOS 4.1.3,
Solaris, and SGI IRIX.

Some of you may be asking "Why did you use Ada given all these problems?"
I used it because my DoD customer wanted me to. 

>My experience so far is that the ability to cross compile code developed 
>on GNAT or ObjectAda is pretty good - the main issues are in a couple of 
>areas: ... availability of identical bindings

This problem alone is enough to disqualify Ada for development
of medium-sized UNIX applications.  Admittedly, until POSIX all
UNIX systems appeared to be slightly different, even to C/C++ 
applications, but the differences were relatively minor, well known,
and easily worked around.  Different Ada bindings tend to (say) UNIX
tend to be radically different and much more work is required to
translate from one binding to another.
-- 
Kevin Cline

Re: C/C++ knocks the crap out of Ada

[Richard Pitre]

In article <4j173h$lvo@oravannahka.Helsinki.FI> cjjohans@cc.Helsinki.FI (Carl J  
R Johansson) writes:
> Richard Pitre (pitre@n5160d.nrl.navy.mil) wrote:
> 
> : In software and language design there is a conflict between the need for  
> : machine efficiency and our limited ability to manage complexity. The  
> : differences between Ada and C++ can be fruitfully discussed  in terms of  
the  
> : different compromises which were made in their designs in order to deal  
with  
> : this conflict.  It is my understanding that the implementers of both  
languages  
> : struggled mightily with this issue. To my knowledge, there is no universal  
> : ideal compromise.
> 
> So, is C really so much more efficient than other languages (I do not
> question the efficiency of assembly, just C/C++) and is it not just a
> myth? Does anyone have figures on this? I don't think a difference of a
> few microseconds has any practical implications if that is what is
> referred to. 
> 
> Of course measuring can be a bit difficult, both applications should
> probably be done by one person equally fluent in both languages (and
> unbiased) and on the same platform (without any inline assembly). 
> If possible s/he should probably be as experienced as possible. 
> 
> With efficiency I mean raw speed and not memory usage etc.
> 

I don't know, but I would guess that it depends on the compiler implentation
more than the language unless a language doesn't support critical
features. While any programmer can 
implement anything the compiler won't necessarily be able to 
optimize it as well as  a built in feature. 
Those kinds of features aside its my guess is that C++ and Ada compilers are 
roughly equivalent in the efficiency of the code that they generate. 

richard

Re: C/C++ knocks the crap out of Ada

[mich]

In <4ic92p$2fa@ubszh.fh.zh.ubs.com>, gzhjis@ubszh.net.ch (Ian Johnston (by ubsswop)) writes:
> By the
> way after 10+ years of using Unix I am having trouble thinking of a
> standard Unix utility that is not a total misdesigned piece of crap!
> Maybe someone can help me.

>grep ?

Pipe?

-----------------------------
Reality Meter: [\.....], thought so
-----------------------------

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

In article <4jf3dg$8jm@ra.nrl.navy.mil> pitre@n5160d.nrl.navy.mil (Richard Pitre) writes:

> In article <4jeel1$erh@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline)  
> > applications, but the differences were relatively minor, well known,
> > and easily worked around.  Different Ada bindings tend to (say) UNIX
> > tend to be radically different and much more work is required to
> > translate from one binding to another.
> > -- 
> 
> This is 1996.
> Ada95 is a standard.
> C++ is no standard and it does not have anything remotely
> like uniform implementation. Are you saying that we should
> be using C ? 

No, he is saying how much he enjoys saying out of date, irrelevant,
uninformed, ignorant or otherwise wrong things in public forums.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

In article <4jeel1$erh@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes:

> >Well, I'll give it a shot.  This year, it'll be Wintel, PowerPC/Win NT, 
> >Sun/Solaris, HP-UX and (I believe) PowerPC/AIX.  We also expect Wintel 
> >cross to 32 bit X86 this year.  Various PowerPC and 68K cross early next 
> >year.
> >
> 
> Well, that means that today's ObjectAda would not solve
> my 1993 problem: writing a Motif application for SunOS 4.1.3,
> Solaris, and SGI IRIX.

Other than the GCC C compiler, what C compiler could do this now or in
1993?  None.  Of course, Gnat can do it now too.  I am assuming here
that you are talking about the fact that ObjectAda does not appear
to support IRIX or SunOS (an obsolete OS...)


> Some of you may be asking "Why did you use Ada given all these problems?"
> I used it because my DoD customer wanted me to. 

What I'm wondering is, what the f**k your point is wrt to the situation
today?


> >My experience so far is that the ability to cross compile code developed 
> >on GNAT or ObjectAda is pretty good - the main issues are in a couple of 
> >areas: ... availability of identical bindings
> 
> This problem alone is enough to disqualify Ada for development
> of medium-sized UNIX applications.  Admittedly, until POSIX all
> UNIX systems appeared to be slightly different, even to C/C++ 
> applications, but the differences were relatively minor, well known,
> and easily worked around.  Different Ada bindings tend to (say) UNIX
> tend to be radically different and much more work is required to
> translate from one binding to another.

I see you are _still_ the clueless wonder.  Since Ada95 _portably_
interfaces with C, thin bindings give you everything you get with C
(or C++).  Now, this may not be all that high level or clean, but they
are _exactly_ what the C hack uses.  Ada bindings that are "radically
different" (or even different...) are those which are _thick_ bindings
- ones trying to hide the ugliness of the lowlevel C binding.  Since
you are a C guy, you apparently get along just fine with these
lowlevel bindings and so should not be complaining about using the Ada
_thin_ bindings to them - they are effectively identical!!  They even
_look_ pretty much the same.  I'm building a Motif interface and
building a couple custom widgets to go with it and the calls to the X,
Xt and Motif toolkits look (for good or ill) virtually the same as a C
version.  So, just what _are_ you talking about?  Hmmmm????

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C/C++ knocks the crap out of Ada

[Kevin Cline]

In article <JSA.96Mar29195546@organon.com>,
Jon S Anthony <jsa@organon.com> wrote:
>In article <4jeel1$erh@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes:
>
>> >Well, I'll give it a shot.  This year, it'll be Wintel, PowerPC/Win NT, 
>> >Sun/Solaris, HP-UX and (I believe) PowerPC/AIX.  We also expect Wintel 
>> >cross to 32 bit X86 this year.  Various PowerPC and 68K cross early next 
>> >year.
>> >
>> 
>> Well, that means that today's ObjectAda would not solve
>> my 1993 problem: writing a Motif application for SunOS 4.1.3,
>> Solaris, and SGI IRIX.
>
>Other than the GCC C compiler, what C compiler could do this now or in
>1993?  None.  

As usual, you missed the point, Jon.  Different Ada-83 compiler vendors
provided different bindings to key functionality like UNIX OS calls
and X/Motif.  Of course these bindings were proprietary.  

This was never a problem for C code.  ANSI-C compilers have been available
for every platform you can name for many years, so porting C code from
one vendor's compiler to another was never a big problem.

>What your point is wrt to the situation today?

1. I wanted to know if there was something I should have done differently
back then.  Apparently there wasn't.  Ada-83 just sucked for non-embedded
application development.

2. I wanted to know if the situation had improved.

3. I wanted to explain to Ada advocates why developing
portable UNIX applications was impossible with Ada-83. 

>Since Ada95 _portably_ interfaces with C, 
>thin bindings give you everything you get with C (or C++).  

There is some information I can use.

>Jon Anthony
>Organon Motives, Inc.
>1 Williston Road, Suite 4
>Belmont, MA 02178

With an attitude like Jon's, I would imagine this is a single-employee
organization.
-- 
Kevin Cline

Re: C/C++ knocks the crap out of Ada

[Lawrence Kirby]

In article <4jp388$d56@tpd.dsccc.com>
           kcline@sun132.spd.dsccc.com "Kevin Cline" writes:

>As usual, you missed the point, Jon.  Different Ada-83 compiler vendors
>provided different bindings to key functionality like UNIX OS calls
>and X/Motif.  Of course these bindings were proprietary.  
>
>This was never a problem for C code.  ANSI-C compilers have been available
>for every platform you can name for many years, so porting C code from
>one vendor's compiler to another was never a big problem.

ANSI C doesn't define UNIX OS calls so isn't really relevant to your point.
Unix calls are reasonably standardised for C through the likes of POSIX and
X/Open which is natural because C is the core development language for
the platform.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: C/C++ knocks the crap out of Ada

[Tom Payne]

Lawrence Kirby (fred@genesis.demon.co.uk) wrote:
: In article <4jp388$d56@tpd.dsccc.com>
:            kcline@sun132.spd.dsccc.com "Kevin Cline" writes:
: 
: >As usual, you missed the point, Jon.  Different Ada-83 compiler vendors
: >provided different bindings to key functionality like UNIX OS calls
: >and X/Motif.  Of course these bindings were proprietary.  
: >
: >This was never a problem for C code.  ANSI-C compilers have been available
: >for every platform you can name for many years, so porting C code from
: >one vendor's compiler to another was never a big problem.
: 
: ANSI C doesn't define UNIX OS calls so isn't really relevant to your point.
: Unix calls are reasonably standardised for C through the likes of POSIX and
: X/Open which is natural because C is the core development language for
: the platform.

There is, as I understand, a POSIX standard for Ada bindings, which
I've not seen mentioned in this discussion.  I'd like to know more
about it.  What is its state of development?  Does GNAT support it?

Tom Payne (thp@cs.ucr.edu)

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

In article <4jp388$d56@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes:

> >> Well, that means that today's ObjectAda would not solve
> >> my 1993 problem: writing a Motif application for SunOS 4.1.3,
> >> Solaris, and SGI IRIX.
> >
> >Other than the GCC C compiler, what C compiler could do this now or in
> >1993?  None.  
> 
> As usual, you missed the point, Jon.  Different Ada-83 compiler vendors
> provided different bindings to key functionality like UNIX OS calls
> and X/Motif.  Of course these bindings were proprietary.  

OK, Kevin, please reread your own comment above.  You claim that _ObjectAda_
(a 1996 Ada95 product) would not be usable.  You are now claiming that
your "point" was about Ada83 and (even less relevant) various Ada83
vendor proprietary bindings.  Since you are unclear what your point
is, it is not surprising that I "missed it".


> >What your point is wrt to the situation today?
> 
> 1. I wanted to know if there was something I should have done differently

OK, so what about all the many posts prevented you from acknowledging
any of the information presented on all 3 of your points????


> >Since Ada95 _portably_ interfaces with C, 
> >thin bindings give you everything you get with C (or C++).  
> 
> There is some information I can use.

Information that was stated many times.  By several people.
Information that you (conveniently?) just plain ignored over and over
again.


> >Jon Anthony
> >Organon Motives, Inc.
> >1 Williston Road, Suite 4
> >Belmont, MA 02178
> 
> With an attitude like Jon's, I would imagine this is a single-employee
> organization.

Wrong again.  First, this is a rather rare case where your continual
misleading pontifications became very frustrating and annoying.  I confess
to succumbing to this baiting.  Second, while small, we are 7 in size.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com