TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text 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]>
Subject:
From:
Jerry van Dijk <[log in to unmask]>
Date:
Sat, 9 Nov 1996 01:22:56 +0100
In-Reply-To:
X-To:
Tucker Taft <[log in to unmask]>
Reply-To:
Jerry van Dijk <[log in to unmask]>
Parts/Attachments:
text/plain (55 lines)
On Fri, 8 Nov 1996, Tucker Taft wrote:

> software written by the same company.  For this kind of environment,
> Ada is an excellent choice, especially compared with writing in some
> other less reliability-oriented 3GL.  However, this does not make a compelling
> argument for (or against) Ada in other kinds of environments, such
> as building an accounts payable system.  Whether Ada is the right
> technology base for building an accounts payable system depends a great
> deal on who is doing the building, what parts they are starting with,
> what tools they have available in the domain, etc.

Perhaps not anyone realizes that most financial software is required to
run 24 hrs/day, 7 days/week performing complex real-time and batch
processing working together with numerous other systems. And that downtime
can be very, very costly. And remember: this
type of software usually has proven life-cycles of 5-20 years!

Would you trust this kind of software to a Visual Basic ? (if it ran on
mainframes and midrange systems). Even C doesn't have fixed point.
(Libraries ? Sure, if you can garantee its stil around 10 years from
now)

Ever tried to do hourly accumulating interest calculations,
converting billions of dollars into yens in the process ?

Currently Ada is the logical alternative for COBOL and PL/I for these kind
of applications. Why it hasn't taken over the market ? Apart from the
usual bad reputation, mostly because a) no large company (eg IBM) is
pushing it and b) no development enviroments/system/tools/compilers are
available for the 3090 architecture.

> Quality is a great thing.  However, if by using some other technology
> (e.g. YACC) one can build, e.g., a more reliable parser, then writing a
> parser by hand in Ada may end up losing out, because more code needs to
> be written by hand.  Even though each line is less likely to be wrong, the
> number of lines written is sufficiently greater as to defeat the per-line
> advantage.

This is nonsense because it assumes the parser generator (tool) used is
fault-less and conforms to a strict definition exactly.
You would first need to spend a lot of time and money to assure the
above.
Then its code should also satisfy other demands like performance and
maintainability. And of course it should remain available.

- Speaking from experience here -

Jerry.

+-----------------------------+-----------------------+
|       Jerry van Dijk        | email [log in to unmask] |
| Product Development Manager |       Team Ada        |
|     Ordina Finance BV       |   Haarlem, Holland    |
+-----------------------------+-----------------------+

ATOM RSS1 RSS2