Path: utzoo!mnetor!uunet!nuchat!sugar!ssd
From: ssd@sugar.UUCP (Scott Denham)
Newsgroups: comp.lang.fortran
Subject: Re: F8X: MODULE vs. INCLUDE
Message-ID: <1759@sugar.UUCP>
Date: 25 Mar 88 17:17:22 GMT
References: <1112@ut-emx.UUCP> <6690013@hpclcdb.HP.COM> <1167@ut-emx.UUCP>
Organization: Sugar Land UNIX - Houston, TX
Lines: 47
Summary: but who ARE the committees???

In article <1167@ut-emx.UUCP>, reeder@ut-emx.UUCP (William P. Reeder) writes:
> 
> I just hate the idea of committees doing design work.  I would like to
> think that the vendors have a small number of folks doing design work,
> most of the team being programmers who implement the design.  There
> are also researchers at universities doing design work.  (Also
> hopefully not by committee.)
> 
> -- 
> William {Wills,Card,Weekly,Virtual} Reeder	reeder@emx.utexas.edu

Ah, but who ARE these coimmittees?? X3J3 is not a closed body; anyone can
get on (or could have early on, anyway) that has the time and inclination
to get involved. As we have vocally heard here and elsewhere, these vendors
DO have reps on the committee, who presumably represent the ideas and 
opinions of the design folks you mention. Ditto for the universities,
government research labs, etc. I'd like to see the standards process be
a little more foresighted that merely "standardizing existing practice",
because to me, that translates "change your existing code" to get to a
"standard" language form. Clearly this can be overdone, though, and I 
think that's what's happened to 8x. Had 8x been less ambitious in it's
goals, we might have had an 8x IN 198x, and got a 9x that might be very
close to what's in 8x now (but will probably end up a 199x standard at 
the rate we are closing). In short, it's just too big a jump - but it's
done, and other than the more awkward transition period, the end results
will not be too much different than if it had been done more is steps.
 
My big problem with the idea of taking 8x back to the table and making a
'new' language out of it is the problem of interlanguage linkage. Some
vendors do better at this than others, but by making this a new language,
all the issues of making the "new" structures (array sections, derived 
data types, etc) co-exist wit h the "old" language are dodged, and most 
vendors (mine at least) are not going to bend over backwards to see that
you can mix the two. Thus to begin writing mains in the "new" language,
I am forced to go back and convert many of my 2500+ library routines to 
the "new" language. Then I have dual maintenence to worry about, as I'm
not likely to soon convert ALL of my mains to the 'new' language, surely
not just to get a 2 line fix or upgrade in. 
 
I realize nothing in making 8x a "new" language forces the above scenario
to occur, but its a lot more likely than in a single language/single
product environment.
  
        Scott Denham 
         Western Atlas International 
 
 Who ME??? I didn't say that!!