From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!think!ames!ucbcad!ucbvax!JPL-VLSI.ARPA!larry
From: larry@JPL-VLSI.ARPA
Newsgroups: comp.lang.ada
Subject: C++ & Real-time
Message-ID: <870319210239.06g@Jpl-VLSI.ARPA>
Date: Fri, 20-Mar-87 00:02:38 EST
Article-I.D.: Jpl-VLSI.870319210239.06g
Posted: Fri Mar 20 00:02:38 1987
Date-Received: Sat, 21-Mar-87 09:53:23 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
List-Id: <comp.lang.ada>

--The following was sent to me personally so I've left off the senders' name.

>   I basically agree with your comments abour complexity.  I would put it
>   between PL1 ... and some of the larger Pascal dialects. C++ has
>   nothing to do with Ada.  It was an experiment by Bjorn to put object-
>   oriented features into the language.  It went a lot further than planned.
>
>   Real time: No the designers are not ignorant.  They are not optional
>   and if they are not available, its not Ada.  Portions of Ada are
>   good in a general purpose sense.  Writing an Ada program like COBOL
>   would be interesting since COBOL is basically a formatting language.
>   (I can see it now, some package of COBOL defs.....).  There are
>   better ways to do this kind of job (over COBOL OR Ada).  No I think 
>   it is mostly a real-time language, and your argument here is weak.

C++:      I realize Stroustrup began it as an experiment, but I get the
impression AT&T is encouraging it for reasons of their own.  I find it
interesting that things ordinary C hackers scream about in Ada (strong
typing, various black-boxing features) have been added by the el primo C
hackers at AT&T. 

And some of its features do seem similar to Ada.  In classes (packages) all
data is private unless declared public, for instance.  Except that it's done
"backwards" from Ada's PRIVATE this declaration seems identical.  Operators
and functions can be overloaded (assignment cannot).  Classes can be
generic.  Other features, as Richard Welty points out, are closer to Simula.

Real-time:        I obviously need to clarify my comments.  Representation
specs are explicitly defined in the standard as optional.  It is through
them that bit-twiddling and interrupts can be done in Ada; without them one
cannot do real-time programming.  The pragma INLINE is only a recommendation
to the compiler.  It is also important for real-time programming (though
less so than rep specs) because you can eliminate subprogram-call overhead
for actions that have to been done very fast. 

Perhaps Ada's biggest deficiency (for r-t programming) is its handling of
time, which is at the very core of real-time programming.  There is no Ada
facility to schedule an action at a specific time or within a min or max
time, for instance.  (The DELAY statement only guarantees a minimum delay.)

These are the reasons why I say Ada is not designed (for whatever reasons)
to be a real-time language.  To continue to limit it only to that fairly
small problem domain by falsely labeling it does the Ada community a
disservice.

CoBOL-like Ada:      I agree that we don't want to slavishly duplicate the
one feature of CoBOL where it really shines, data formatting.  As good as
that is, there're probably several ways to improve on it.  Ada can be
especially useful here because it can be extended into any number of
special-purpose languages.  Yet, since this is done WITHIN THE STANDARD,
their users only have to learn the extensions--which are abstractions with
which they are already familiar.  (Thus my example of orders triggering the
creation of shippers, back-orders, and invoices.)