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=1.3 required=5.0 tests=BAYES_00,INVALID_MSGID,
	MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,30df5a909ff1af4
X-Google-Attributes: gid103376,public
From: Robert Dewar <robert_dewar@my-deja.com>
Subject: Re: Answering an Ada/COBOL Question
Date: 1999/11/19
Message-ID: <812obu$1pp$1@nnrp1.deja.com>#1/1
X-Deja-AN: 550399490
References: <80hr16$5q2$1@nntp5.atl.mindspring.net>
 <Pine.BSF.4.10.9911131710530.16406-100000@shell5.ba.best.com>
 <80leu1$k3l$1@nnrp1.deja.com>
 <Pine.BSF.4.10.9911132308290.27448-100000@shell5.ba.best.com>
 <80mc1j$6fo$1@nnrp1.deja.com>
 <Pine.BSF.4.10.9911141057210.7241-100000@shell5.ba.best.com>
 <80piek$rd3$1@nntp1.atl.mindspring.net> <80qk9s$6h5$1@nnrp1.deja.com>
 <80sfrb$1o0$1@nntp3.atl.mindspring.net> <80vfv9$m0s$1@nnrp1.deja.com>
 <38341CB6.AF2A5895@pwfl.com>
X-Http-Proxy: 1.0 x38.deja.com:80 (Squid/1.1.22) for client 205.232.38.14
Organization: Deja.com - Before you buy.
X-Article-Creation-Date: Fri Nov 19 05:48:47 1999 GMT
X-MyDeja-Info: XMYDJUIDrobert_dewar
Newsgroups: comp.lang.ada
X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I)
Date: 1999-11-19T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <38341CB6.AF2A5895@pwfl.com>,
  condicma@pwflcom wrote:
> Robert Dewar wrote:
>
> > That's true, but I am afraid this potential is so far
> > unrealized. The COBOL sector in general regards C and C++
> > as hacker languages unsuitable for fiscal programming, But
> > they simply don't know about Ada as an alternative.
>
> I've wondered why it is that the perception exists that C/C++
would be
> unsuitable for financial software? They are, after all,
"general
> purpose" languages. They may lack some of the convenient I/O
that COBOL
> has and the support for decimal arithmetic, but one could
probably build
> up some libraries to support that.

These libraries will tend to be very inefficient, and the lack
of literals and convenient notations is a serious one. Just
try writing typical bond yield programs in C++, and see if
you find it a pleasing experience :-)

The data declaration style in COBOL is also very convenient
for file related data.

Typically this kind of comment comes from people who don't
have experience writing fiscal programs in COBOL or any other
language :-)


Sent via Deja.com http://www.deja.com/
Before you buy.