mcdonald@uxe.cso.uiuc.edu (07/22/89)
>There was an article on the front page of DIGITAL REVIEW this week that said >VAX FORTRAN will break under F88 if implemented. >Is this true? I have a lot of source codes that made extensive use of VAX >Extensions. Will these codes have to be modified to F77 so it will be >compatible with F88 when it comes out? Or, should I start looking at other >languages? By the time F88 compilers come out, you probably won't be running on Vaxes any more. It will have already been more cost-effective to recode in F77 or ANSI C and run on far, far, cheaper machines. That has already happened here. You can buy a PC that runs Fortran code as fast as the fastest mono-processor VAX (floating point). RISC boxes are even faster and as cost-effective. Doug McDonald
bill@ssd.harris.com (Bill Leonard) (08/08/89)
> By the time F88 compilers come out, you probably won't be running on > Vaxes any more. It will have already been more cost-effective to > recode in F77 or ANSI C and run on far, far, cheaper machines. > That has already happened here. You can buy a PC that runs Fortran > code as fast as the fastest mono-processor VAX (floating point). > RISC boxes are even faster and as cost-effective. It never ceases to amaze me how many people fall for this utterly misleading argument. Just because "you can buy" something doesn't mean that everyone will rush out and do so, especially if you already have something that is doing the job quite well and in which you have significant investment. It takes years for new technology to completely replace the old. Do you think DEC (or anyone else) is going to just sit around and wait for that to happen? This same argument has been used, for instance, in justifying the addition of feature after feature to 8x, despite the complexity they add to compilers. "But machines are becoming faster, so the users won't notice!" Bull! How many of you want to replace your old PC (say) with a brand new one that is supposed to run twice as fast, only to see your software run the same speed? On a different note, Bruce Martin posted an article saying: > All codes that use vendor-parochial extensions will break when a standard > is revised. Even if the standard is upward-compatible (i.e. extensions > only & no deletions, as is the case with Fortran-88). As a generalization, this is patently false. Yes, some codes will break, but obviously vendors will make every effort to merge new standard features with existing extensions. Bruce goes on to say: > Except for those which can be mechanically translated (like trailing > comments, for instance), vendor extensions are a snare and a delusion. > The value of a higher-level code is inversely proportional to the number > of systems and machine architectures on which it cannot run correctly. > The return on investment for software engineering efforts drops > precipitously if coders are permitted to freely use that tempting stuff > that appears with shaded background (or whatever) in the vendor reference > manual. (The fact that the coder did not learn it in school also adds to > the appeal!) Get real, Bruce. Most vendor extensions are aimed at specialized markets (e.g., real-time simulation, process control, etc.). The standards committee even encourages this! (The most frequent reason for not putting an otherwise nice feature in the standard is that it is too specialized, and is a good candidate for a vendor extension.) Vendors in a given market all tend to implement those extensions specialized to that market, regardless of their origin. Contrary to what Bruce says, vendor extensions are seldom a ploy to lock a user into his brand of machine -- more often it is a lure to a user of a competitor's hardware, to make it easier for him to switch brands. Almost all of the minicomputer vendors implement a large portion of the DEC FORTRAN extensions, for instance, because it is the only way to lure customers away from DEC! Finally, given the agonizing slowness of the standards process, vendor extensions are the only way users can get improved tools in a reasonable time. When a large number of varied vendors implements an extension, one would think it would be a good candidate for inclusion in the next standard. However, X3J3 has in many cases ignored such evidence and chosen to go their own route, thereby rendering the standard incompatible with many very popular extensions. (Only at the last minute did they relent and put in DO WHILE!) It's easy to sit in your ivory tower and say, "You shouldn't use vendor extensions." It's much harder to live in the real world where users want solutions now, not in 10 years. -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or hcx1!bill@uunet.uu.net