Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!tank!ncar!ames!oliveb!sun!chiba!khb
From: khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering)
Newsgroups: comp.lang.fortran
Subject: Re: FORTRAN 88
Message-ID: <74284@sun.uucp>
Date: 24 Oct 88 18:50:35 GMT
Article-I.D.: sun.74284
References: <669@convex.UUCP> <5826@vdsvax.steinmetz.ge.com>
Sender: news@sun.uucp
Reply-To: khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering)
Distribution: comp.lang.fortran
Organization: Sun Microsystems, Mountain View
Lines: 85

In article <5826@vdsvax.steinmetz.ge.com> lamson@sierra.uucp (scott h lamson) writes:
>
>
>Help me here.  I work at General Electric Corporate Research and
>Development.  Probably not one of your smaller companies.  We have 300
>Sun's, 3 dozen or so VAX's, an IBM 3081K, and a Convex 210 (220
>soon...).   No vendor has come here to talk about Fortran  8x ever
>that I have been told about.  In order to have an informed opinion,
>I subscribe to the ACM Fortran Forum,

Until just over a year ago I too was a user. I even became an X3J3
observer to keep informed.

>ordered the draft of F8x, 6 copies of Fortran 8X Explained, and have
>asked about F8x at most vendor presentations.  But the vendors have
>not made an effort to publicize the proposed standard here one way or
>the other.  

Bully for you.

As for the user groups (DECUS, SHARE, CUG, or others), at
>least at our site, the people who might go to them are the systems
>managers, not people who (work for a living.. :) ) use fortran in
>their work.  

This is standard just about everywhere. Furthermore the presentations
I got reports about were very biased against the standard. The usual
presentation was summed up as "lots of new useless features and very
costly to implement, and it will be slow". This is what most users who
got ANY information at all got. Very few users went to the lengths you
did. 


>On the difficulty of implementing the proposed F8x, I feel that I must
>take the word of the experts that it will be difficult.  I just think
>that it will be worth the cost.  For each person-year that goes into
>writing a compiler, how many person-years go into people developing
>applications using that compiler?  

Exactly the point propronets have been making.

> As for the speed of the compiler, my own opinion is this
>is a non-issue.  
> 
I must disagree here. Compile speeds are killing VLIW vendors (Cydrome
and Multiflow). Many shops spend much of their time developing code,
or using code which has parameters coded in (especially memory sizes)
which must be recompiled (ABAQUS comes to mind as an example of a
production code which employs a program generator to create a program
which is compiled linked and then run).

Fortunately many of the features of f8x will REDUCE the number of
compiles. Dynamic memory, modules (implemented intellegently), etc.
The point being that, as a vendor, we are sensitive to compile speeds
(because our users are!)

>The last time I worried about that was on a RAYTHEON
>703, and even then the paper tape reader was slower.  I spend a lot
>more time reading code than compiling it.  That makes many of the
>features in modules and module procedures so very important;  to get
>understandable readable code for complex applications.  You can only
>worry about efficiency after you have the right answer.

True, but newer programmers like their systems to be highly
interactive. This is a great appeal of workstations :>). This is not
to say that I am against f88 (quite the contrary), just that compile
speed is important.

The "public review" is not done very well at all (procedurally).
Unless the public is well informed, their comments are meaningless
(e.g. How many complained about f88 not compiling f77 programs ? )
Furthermore the procedure is biased towards finding fault (no
scientific survey simply asks for responses from the public at
large... those who are UNhappy respond most often). Furthermore the
draft standard is designed as a formal document to be used for
compiler writers to work from. This is a very different sort of
document from a user guide (like Metcalf and Reid). User's who have
never worked with operator overloading and modules can't be expected
to decrypt the standing document and comment.




Keith H. Bierman
It's Not My Fault ---- I Voted for Bill & Opus