Re: Ada vs standard languages / reliability

Re: Ada vs standard languages / reliability

[Michael Hunter]

gateley@m2.csc.ti.com (John Gateley) writes:
>I probably shouldn't do this, but here are some nitpicks:
>Ada is NOT a much more powerful language than C. Ada has some features
>that C doesn't, and C has some features that Ada doesn't and so on.
>They are both turing complete (or whatever the phrase is). If you
>are going to make such a broad statement, you need to carefully
>define what powerful is.
Yea...I could write a turing machine in either....in fact you can write a
turing machine with gotos, moves, and compares.  I don't think I would even be
happy with this machine.

Mike Hunter - Box's and CPU's from HELL: iapx80[012]86, PR1ME 50 Series, 1750a
UUCP: {ames!elroy, <routing site>}!gryphon!pnet02!bagpiper
INET: bagpiper@pnet02.gryphon.com

Official lang. interpretations for ACVC 1.11 Ch13 tests?

[Andrew Nguyen]

A question for the Ada language lawyers out there:

ACVC 1.11 contains a large number of new Chapter 13 tests, that make
mandatory certain levels of support and behaviour for the various
Chapter 13 features (length clauses, record rep specs, unchecked
conversion, et al).

The question is, where are the official language interpretations that
back up these new tests?  Are they in AI-00550 through -00564 and -00590
(which still read as though they're in draft stage), or are they elsewhere?

Thanks for any information anyone can provide.  I have Ada IC / DDN access,
so no need to send me actual rulings, just point me in the right direction.

-- 
Andy Nguyen		Team Paranoid		...!uunet!actnyc!aqn

Re: Ada vs standard languages / reliability

[Bjarne Stroustrup]

Since C++ has been mentioned several times in the discussions here
(comp.lang.ada) lately it might be appropriate for me to comment.

In my opinion, the most significant difference between C++ and Ada is
that you don't have to use C++. If you don't like it, no government
will try to bribe or coerce you into using it. I do understand that
governments sometimes have to operate in this manner.  However, if you
don't like C++, don't use it - but please first try to make sure you
know what you are rejecting (and why) and realize that other people
will have different requirements and tastes than you and may therefore
decide differently.

Whatever support C++ has it has earned. Note that you have never
seen an AT&T ad for C++. Even if you don't like C++, if you are prevented
from using it, or if C++ simply isn't the right choice for you now you
might still learn something from it.

Ada afficionados often dismiss C++ for not being standardized. That is
a major issue to some because in some areas ANSI and/or ISO standardization
is a legal or semi-legal requirement for use of a language. Just don't
use C++ in those areas. Critizising C++ for not being standardized
is a bit like critisizing a person for being young. Sometimes youth is
a disqualifying factor, sometimes it isn't.

Anyway, most C++ standardization problems arise because C++ has several
independent implementations. This is a problem of succcess; most languages
never get a second implementation: their application areas and user
base simply never grows to make a second (or a tenths) implementation
viable.

For many people, the implementations are not sufficiently different for the
largely accidental incompatibilities to be a really major problem and the
implementations are getting less different as the compiler writers are
cooperating to create a genuine standard. Formal ANSI standardization has
started. People for whom the current state of affairs is unacceptable can
wait and look again in a couple of years to see if they like C++ better then.

Some critisisms have been leveled at C++ on comp.lang.ada that ought not to
have been. Some were based on the assumption that C++ is simply a minor
variation of C and refered to point about C that simply didn't hold for C++.
Similarly, some people have managed to confuse C++ and Smalltalk.

Please read some technical information about C++ yourself instead of relying
on heresay or hype merchants. There is a large and vigorous C++ litterature.
The last half-way comprehensive bibliography is 11 typeset pages.

I can recommend a paper (by myself,sorry):

	``What is Object-Oriented Programming?'' May'88 IEEE Software magazine.

some books:

	0-07-881522-3	Using C++			Eckel
	0-13-723156-3	Programming in C++		Dewhurst & Stark
	0-201-11497-6	C++ Answer Book			Tony Hansen
	0-201-12078-X	C++ Programming Language	Bjarne Stroustrup
	0-201-16487-6	C++ Primer			Lippman

some proceedings (usenix: 213-592-1381):

	Proc USENIX C++ workshop, Santa Fe, NM, Nov'87
	Proc USENIX C++ Conference, Denver, CO, Oct'88

and the AT&T 2.0 documentation (AT&T: 1-800-432-6600 or 317-352-8557):

	reference manual: 307-146
	library manual: 307-145
 	selected readings: 307-144
	release notes: 307-090

Relative to Ada, I think that C++'s major deficiencies are the lack of an
exception handling mechanism and of a mechanism providing generics (see the
``whatis paper'' or my book). Proposals for remedying this can be found in:

	B. Stroustrup: Parameterized Types for C++. Journal of Object-oriented
		Programming. Jan/Feb 1989 and the 2nd USENIX proceedings.

	A. Koenig and B. Stroustrup: Exception Handling for C++.
		Proc. C++ at Work Conference. Nov'89.

The absense of generics is usually (incompletely) compensated for through
the use of combinations of inheritance and macros. The absense of exceptions
is usually (incompletely) compensated for through various uses of pointers
to functions.

I do not consider C++'s lack of direct support for concurrency a weakness.
On the contrary, concurrency supported through libraries can serve a wider
range of needs better. Unfortunately, I see no way of proving this conjecture
in general.