TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Proportional Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To:
"[log in to unmask](Comp.La (Comp.Lang.Ada)" <[log in to unmask]>
Date:
Tue, 8 Sep 1998 07:04:31 -0700
Reply-To:
"Robert C. Leif, Ph.D." <[log in to unmask]>
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
Content-Type:
text/plain; charset="iso-8859-1"
From:
"Robert C. Leif, Ph.D." <[log in to unmask]>
Parts/Attachments:
text/plain (57 lines)
From: Bob Leif
To: Fellow Readers of Comp.Lang.Ada and Members of Team-Ada

Of interest to the Ada community is that Jean Ichbiah et al. designed in Ada
a better tool to build a windowing system (tasks) than Microsoft's
call-backs.  Please see Claude Petitpierre, "Synchronous C++: A Language for
Interactive Applications," IEEE Computer Vol. 31, pages 65-72 1998
(September). The author borrows with essentially no attribution Ada's tasks
and reports on, "sC++ introduces the concept of an active object. He even
uses the term rendezvous.

However, on page 71, the author states:
"There are many advantages of the sC++ paradigm over the callback paradigm:

The order in which events are handled is clearly indicated by the statement
sequence.

sC++ allows splitting the main callback loop into several selects in several
objects.

The program both creates and reads the objects that generate events; the
objects do not need to call back the program functions.

To enhance reusability, the GUI, the network drivers, and all event-driven
functions can easily be defined as active objects in libraries, and thus do
not need to be inserted in the main loop.

Reading a text field or a socket is very similar to executing a scanf, read,
or c in (C++) statement.

Several programs can read the same device.

The program is much easier to model and analyze."

My (RCL) conclusion is since the language shows through, the Ada community
would be much better off developing new technology rather than making thin
bindings to existing de facto standards, such as windowing systems and SQL.
This does not preclude the real-world need for bindings. However these
should take advantage, as much as reasonably possible, of Ada technology.
The necessary switch from focusing on the Defense industry to commercial
development hopefully will inspire creativity and ingenuity in developing
products built with Ada.

Returning to "Synchronous C++: A Language for Interactive Applications," the
referees for this article appear to me to have an inadequate understanding
of the preexisting Ada technology and thus permitted the Author to claim
originality. Page 65, "Several other concepts have been proposed to extend
OO languages to concurrency: delayed evaluations (a concept that proposes to
launch each method on a separate thread, as in Actors (ref 5), processes
orthogonal to the objects (Ada), asynchronous channels and exceptions
(Eiffel (ref 6), and others." Please notice that the author did not include
any reference for Ada or describe Ada's extensive real-time capabilities. I
would hope that one or more of the Ada language experts will write the
Editor, Edward A. Parrish, WPI [log in to unmask] (508) 831-5200 and inform
him that his referees have been inadequate in their refereeing of this
article.

ATOM RSS1 RSS2