Re: Ada vs Fortran for scientific applications

[<adaworks@sbcglobal.net>]

"robin" <robin_v@bigpond.com> wrote in message 
news:TfPsg.3094$tE5.2436@news-server.bigpond.net.au...
> adaworks@sbcglobal.net wrote in message ...
>>
>>"Gordon Sande" <g.sande@worldnet.att.net> wrote in message
>>news:2006052509454116807-gsande@worldnetattnet...
>>>
>>> How many Ada systems can match the undefined variable checking of the
>>> old WatFor or the current Salford CheckMate or the Lahey/Fujitsu
>>> global checking? It seems to be a thing associated with places that
>>> run student cafteria computing on mainframes. Not much used anymore.
>>> There was a similar student checkout PL/I from Cornell if I recall
>>> correctly.
>>>
>>The default for Ada is to do thorough range checking on all numeric
>>types.
>
> Range checking is not a substitute for detection
> of uninitialized variables.
>
See my example on how Ada supports this in a different post
under this thread topic.   An Ada compiler can certainly check
for unitialized variables.  It can also check for misplaced artifacts
of all kinds, thereby assisting the developer with program
organization improvement.

As stated earlier, the fundamental design goal of Ada is provide the
maximum amount of error detection as early in the development
process as possible.   Errors, of course, are at different levels.
Sometimes the compiler provides advisory error messages, and
other times the error prevents compilation.    I have used a lot
of programming languages during my 40+ years in software and
I have not found a language that is as dependable in this respect
as Ada.

That being said, I sometimes prefer to use other languages when
Ada is too strict.   Currently, I enjoy Python.    In the past I have
liked Smalltalk.   Long, long ago, when PL/I was new (during
the 1960's and one project during the 1970's), I did some coding
in it, but I am certainly not current with modern PL/I.   It did
seem to be an improvement over Fortran and COBOL at that time.

Every language has its good and bad points, its weak points and
its strong points.  Ultimately, it is about choosing the right tool
for the right job.

I have tried to find information on PL/I that would encourage me to
recommend it.   I queried this forum for that kind of information and
received much verbal abuse (except from Tom, who was helpful)
for it.   I would like to see PL/I continue to evolve and receive
good support.    I would like to see it have a good model for
objec-oriented programming so it would be more attractive to
a larger audience.

Fortran has continued to evolve nicely.   The current standard has
much that is commendable.   Even COBOL has evolved with an
OOP capability.    In fact, COBOL, for all its faults, continues to
evolve rather well.   A language does not stay current with emerging
concepts in program design is not going to retain a following.  PL/I
has a good fundamental model.   There is no reason why it should
lose its place as a popular programming language.

So instead of being defensive about PL/I, or haranguing against those
who see potential for improvements, it is probably worthwhile to
work toward making those improvements.

Richard Riehle