Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!mcnc!xanth!kent
From: kent@xanth.UUCP (Kent Paul Dolan)
Newsgroups: comp.lang.fortran
Subject: Re: F8X comments
Message-ID: <3389@xanth.UUCP>
Date: Mon, 16-Nov-87 02:45:43 EST
Article-I.D.: xanth.3389
Posted: Mon Nov 16 02:45:43 1987
Date-Received: Wed, 18-Nov-87 07:18:49 EST
References: <50500015@uxe.cso.uiuc.edu> <5774@j.cc.purdue.edu> <422@uni2.bcm.tmc.edu> <402@auvax.UUCP>
Reply-To: kent@xanth.UUCP (Kent Paul Dolan)
Organization: Old Dominion University, Norfolk Va.
Lines: 57
Keywords: But you have DECADES to get ready!
Summary: You lose when you upgrade and no F66 compiler is there.

In article <402@auvax.UUCP> rwa@auvax.UUCP (Ross Alexander) writes:
>In article <422@uni2.bcm.tmc.edu>, rick@svedberg.bcm.tmc.edu (Richard H. Miller) writes:
>> Augh! Fortran has been around for many many years. Why is there such an
>> insistance upon "improving" a language to the point it is totally different
>> from existing implementations of the language. You will force a rewrite of
>> many millions of lines of working code. This will force the redeployment of
>> many programmers to do this upgrade which will not allow them to work on 
>> *new* applications. 
>
>No it won't.  Dusty decks can be complied with the *old* compiler; new
>decks can be compiled with either, depending on which side of the bed the
>programmer who wrote them got up on that day.  Just because someone invents
>a new language, x, and chooses to call it y.2 where y is a previously existing
>language, doesn't make any difference to however many gazillions of lines
>of y code already out there.  I mean really, are the compiler police going
>to come and take your fortran {II, IV, -66, -77} compiler & libraries away?
>Get serious.
>
>Ross Alexander @ you too can read the path


No the cops won't get the old decks, but the mainframe vendors will
upgrade, and when the next 32 bits are added to everyone's busses to
allow for more masive memory addressing needs, the compilers will need
to be revised to emit code for the new hardware, and suddenly F66 or
F77 may not seem like its worth the trouble.  Moral:  yes, the
capability to compile F66 could be expensive to keep.

But, the FORTRAN committee has always been highly aware of this
problem, using the responsible technique of "deprecating" features
while keeping them in operation for another standard review cycle.

This warns folks to get rid of them, or at least don't use them any
more in _new_ code.

We've learned a lot about what is good and bad in maintaining code.
Uncontrolled globals, like FORTRAN's COMMON blocks, turn out to be
maintenance nightmares.  Since FORTRAN shows few signs of folding up
its tent and slipping quietly into the night, it is probably a "good
thing" to remove these features as we discover their consequences, and
to replace them with features that lead to code that is easier to
maintain.

The problem with the dusty deck is that it doesn't just sit around for
free; it costs money to maintain and upgrade, and it costs more money
when hard to maintain features are part of the language.

So, I guess, if you love FORTRAN, don't suffocate it, let it grow.  If
it doesn't grow, then it will die, replaced by Modula 2, Ada(tm) or
whatever lies just over the horizon in the way of cheaper to maintain
langauges.

This is spoken from a 26 year love affair with FORTRAN, but with no
chance to review the proposed standard (on $700 per month, where do I
get $50 for a dpANS?)

Kent, the man from xanth.