Re: Answering an Ada/COBOL Question

[Robert Dewar <robert_dewar@my-deja.com>]

In article <3835B58B.9A24C3EB@pwfl.com>,
  condicma@pwflcom wrote:
> Not entirely fair. In another life, I developed lots of
> financial applications in COBOL for the City of Chicago.

I would be willing to bet that this was COBOL-75, which is
really not a sensible point of comparison at this stage.


> I'll
> grant that COBOL has
>
> facilities that make this sort of thing easier - especially
> with file
> handling, decimal numbers, output formatting, etc. My only
point was
> that otherwise intelligent people conclude that because COBOL
> has some
> superior features for a specific application domain that means
> the
> application domain can't be addressed by other languages which
> may not
> have all those spiffy domain specific features. I've also done
> financial
>
> applications in C. It's more work in some areas, but it is not
> at all
> impossible - or even necessarily difficult.

It is definitely dificult to write efficient 18-digit decimal
computational stuff in C with proper rounding and truncation
options. And furthermore it is junky to use because of not
having proper literals.

Sure you can do anything in any language, I personally would
be much happier addressing a lot of traditional C domains in
COBOL than the other way round (e.g. the Realia COBOL compiler
was written 100% in COBOL, and this proved to be a quite
reasonable environment, I would chose COBOL over C for writing
a compiler any day).

> I think that with
> Ada's data
> processing annex, it provides most of the tools needed to do
> the job -
> if not exactly as easily, at least well enough that it would
> be a viable
> choice for financial software alongside COBOL.

Well it was designed by people who know COBOL very well (Robert
Dewar, Ben Brosgol, Ken Fussichen), and we think we succeeded
far better than that and that for many of the traditional
COBOL tasks, Ada is better than COBOL. Note we did not put
file/io features in, because no one would use COBOL FILE
stuff any more, it is considered the assembly language of
IO, everyone uses data bases these days (Marin's reference
to file processing in COBOL is another reminder of ancient
bygone days in the COBOL world).

> (And let's be fair about
> COBOL: What it may make easier in some areas it often makes
> more difficult in others, so it may just be a wash.)

If you want to be fair, let's have some examples, and make sure
they are up to date with the current version of COBOL!

> Now how I went from business data processing to embedded
> realtime engine controls is a long story, but I've never been
> tempted to try writing a realtime executive in COBOL! ;-)

There is nothing inherently unreasonable about such a notion.
COBOL does suffer from insufficiently strong typing, I would
say it is on a par with C here, but on the other hand, the
object oriented support in COBOL is very sophisticated (if
anything it is too complex, it is certainly much more powerful
than corresponding features in C++ and Ada).



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