TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Date: Mon, 9 Dec 2002 13:53:53 -0500
MIME-version: 1.0
Reply-To: Roger Racine <[log in to unmask]>
Content-type: text/plain; format=flowed; charset=us-ascii
From: Roger Racine <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
Content-transfer-encoding: 7BIT
Parts/Attachments: text/plain (53 lines)
> > >
> > >Even if they are "useless", they are not "negative".
> >
> > Not always. Sometimes useless things become negative - simply
> > because of someone's temptation for making use of them.
>
>Fire them!
>
>I'm getting the impression that you are saying "we are trying to let
>incompetent software engineers write real programs". If that's true,
>you need far more intelligent tools than either C++ or Ada.

1) There is a difference between "incompetent" and "poorly trained" or
"inexperienced".  A number of extremely intelligent software engineers came
to me during their first (or even second) Ada project with either questions
(how do I do this in Ada) or comments (Ada is terrible; see what happens
when I use this construct!).  Many times I would ask back "How would you do
it in C?", and they would immediately answer their own question or counter
their own complaint (Ada allows pointer manipulation, for example, if it is
really needed).

When I asked why they did not think of that answer themselves, they would
invariably say that they did not think it was the right way to do it in Ada.

A valid point in their favor (and in favor of the "temptation" argument in
general) is that the language definition says nothing about the performance
or suitability of any given construct.  And, performance changes with
compiler vendor.

2) My company used to use a computer language called MAC for rapid
prototypes.  Everything was double precision floating point.  You did not
need to declare variables (they were implicitly created when first used).

For small analyses, this language was very good.  Of course, it was not a
reasonable language for anything large (although it was used for a fairly
major-sized simulation by some very careful people before there really was
anything better), but for a large number of "what if" questions, it was an
excellent language.

I am sure there are many others who would extol the virtues of other
languages (like all the interpreted languages) for similar reasons.

Conclusion:

I suggest that it is fine to agree that short-term analyses can be more
efficiently done in C++ (I have no experience with that language, but I am
aware of people arguing the same using Smalltalk as the language).  At some
point, however, when the code gets complicated enough, Ada can be shown to
be a more productive language.

Roger Racine
Draper Lab

ATOM RSS1 RSS2