Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!texsun!texsun.central-relay.sun.com!convex!mic!authorplaceholder From: d25001@mic.UUCP Newsgroups: comp.lang.fortran Subject: Re: FORTRAN 8X discussion Message-ID: <137400001@mic> Date: 6 Feb 88 20:06:00 GMT References: <3885@xanth.cs.odu.edu> Lines: 93 Nf-ID: #R:xanth.cs.odu.edu:-388500:mic:137400001:000:4619 Nf-From: mic.UUCP!d25001 Feb 6 14:06:00 1988 >>People being people they don't want to go back and change the old dusty >>decks ... they work ... why fix them. > > This one I am sure is a red herring over the lifetime of the > planned changes; at least 10 years, more likely 20, will pass > before the changes that make the "dusty decks" uncompilable > will finally take effect. I worked recently in a major > programming shop (200 active coders) with a 6.5 million line > inventory of production code, about 80:20 COBOL to FORTRAN. > Essentially NONE of it sat for as long as 5 years without > change, and with each change, we had to pay for the lack of > maintainability constructs in two of the oldest languages in > common use. > > In fact, as part of a mainframe change that changed the > word-size of our computers, we had to rewrite ALL of the code > in 18 months (we hired expensive help). I think this > experience is common; ... My own experience argues just the opposite. Where I work we have a large body of FORTRAN code, some of which is now over 15 years old. During the last fifteen years we have ported the code to three or four mainframes (depending on how you want to count the IBM 3090 with Vector Facility versus the vanilla scalar IBM's) and three different array processor boxes. Yes, all this has involved the rewriting of a number of subroutines. But there are just as many subroutines that are largely untouched in move to move. Some have not changed at all (unless you count the purely mechanical translation from EBCDIC to ASCII) in ten years. Change does not always mean rewrite. And rewrite does not always mean redesign. All of the changes to existing programs over the past 10-15 years have centered around HOW we crunch numbers. The 'control' code, that determined WHICH numbers to crunch, has remained basically unchanged from machine to machine. This is the code that the 8x standard would call into question. I shall not dispute that they may have a 'better way' but to remove the COMMON blocks from a large complex program is not merely a rewrite -- it is a REDESIGN. >>One of our arguments has always been that when people are faced with >>a major rewrite, they will go with a different language which solves >>their problem instead of using one that is full of quirks... > > My experience in the above major change was that we had Pascal, > Ada, and many fourth generation language "COBOL generators" > available for use, but we had a shop full of FORTRAN and COBOL > programmers. Inertia and good sense meant that we upgraded > our code to the latest standard (COBOL 74, FORTRAN 77) in the > process of making the move, but did not change languages for > most of the code. I think the argument ignores the inertia of > the mass of programmers and the reluctance of their managers > to provide expensive training or take unquantified risks. Carried to the extreme inertia could mean large blocks of users ignoring the 8x changes and staying with 'good ole' FORTRAN-77. While we were disussing the proposed standard recently, one otherwise intelligent senior programmer advanced the opinion that ALL the changes since FORTRAN IV have been bad. This was not a gray haired old fogey either; I think he must be in his mid-thirties. >>My thought is that the committee should reconfirm FORTRAN for >>another 5 years, clean up this new proposed standard removing >>the things they want to deprecate, etc., fix the problems in >>areas of new functionality ... and call it language X. Let >>FORTRAN stay FORTRAN and move the world to language X. > > This won't work at all; names have a strong magic: it was not > technical superiority or competitive pricing or excellent > support that made their microcomputers outsell all others, it > was the three letters "IBM". Similarly, if it isn't "FORTRAN", > but it still contains FORTRAN's weaknesses, no one will go to > your language X. It is the programming language going by the > name of FORTRAN that needs improving. ... In other words, "Engineers will program in anything as long as they can call it 'FORTRAN.'" Are you suggesting that if in the early 1960's IBM had continued in its alledged intent to market as "FORTRAN VI" the language that we know as "PL/I", we would all be happily programming in PL/I? There are many who would consider the 8x language to be very nearly as radical a departure from FORTRAN-77 as PL/I is/was from FORTRAN IV. Are you saying that with canny marketing ("Call it FORTRAN") 8x will succeed where PL/I 'failed'? >Kent, the man from xanth. Carrington Dixon UUCP: {convex, killer} mic!d25001