[comp.lang.fortran] F8X: MODULE vs. INCLUDE -- Medium

hydrovax@nmtsun.nmt.edu (M. Warner Losh) (03/15/88)

Stuff in [[]] applies to Fortran and S8 committee, the rest is a lesson
learned from a software construction class.

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.)

I tend to agree completely about individual vs. committee design, in
general.  Committees can work, but it usually is quite painful.  I am
currently a member of a class that is writing a program to help users
manage a schedule.  The students of the class were given some vague
requirements from management [[ Gripes from Fortran User's ]].  We
formed a committee of the whole and turned about a page of vague and
nebulous features into over forty pages [[ The Fortran 8x's "proposed"
standard ]].

Everybody (only fourteen of us, but that was more than enough) had
their own favorite features to add to this program.  Many features
were nice to have.  In fact all the features had a good reason for
being present.  However, they were not mutually additive, that is each
added feature added a lot of work to the implementors (in this case
also us).  Also, the features didn't mix well, and strange and
elaborate rules had to be developed to handle all of the bizarre cases
we could think of.  Just when we though we had it all nailed down,
somebody would come up with some "small hole" that wasn't so small,
and forced a rethink.  After many of these rethinks, we decided that
what we had couldn't get any better.  [[ Fortran 8x released for
public comment. ]]  Then something weird happened.  We had done some
of the high level design (data flow diagrams, etc) and found more
holes. [[ public comment, here the analogy might end. ]].

Instead of another rethink we did something worthwhile (thank you
Brian and Pat), we took a HUGE AXE to the bloody thing.  We chopped
out the dead wood and unneeded, unasked for features.  What resulted was
a specification that provided what the user needs, and could reasonable
want, but no more.  Complex, overly general constructs were replaced with
more concise and germane constructs.  In short, the whole program was
made more usable and implementable.

I think that Fortran committee could learn from this example.  There
is a lot of good in the new Fortran, but there is also a lot of stuff
that just doesn't fit in well with traditional Fortran, like the
free-format source.  Not that I'm flaming the idea of free formatting
source code.  I love 'C' for this very reason, but it isn't Fortran.
Fortran has it's uses, although people are trying to make it all
things to all people.  Fortran is not Ada, nor has it ever pretend to
be, until now.  Fortran crunches numbers very well, at least compared
to other HLL available today.  I agree that many things are lacking in
Fortran, but the committee's document is like hunting doves with large
cannon.  It is just too much change to an old language that can't
really handle the change.

As somebody said earlier in this newsgroup, the Fortran 8X committee
should only add i) existing practice, where possible and ii) change
CLEAR short commings in Fortran.  All else should be scrapped with a
large axe (or other suitable sharp object).

Sorry for the length of this posting (emacs tells me it is seventy
lines long), but I think that it is a good example for the Fortran 8X
committee.

-- 
bitnet:	losh@nmt.csnet			M. Warner Losh
	warner@hydrovax.nmt.csnet    ! Don't know if this works, let me know.
csnet:	warner@hydrovax.nmt.edu
uucp:	...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!warner%hydrovax