Aesthetics, FORTRASH, and C.

[Steve Lamont]

Dave Sill <dsill at NSWC-OAS.ARPA> quotes me as saying:

> In article <88012145556.2040246a at Sds.Sdsc.Edu> Steve Lamont
> <lamonts at Sds.Sdsc.EDU> writes:
> >I don't see the lack of indirection as a major disadvantage in the type of 
> >programs FORTRAN is suited to.  Perhaps I am missing the point here.  Can
> >someone please illuminate the subject?

> Perhaps you're missing the *pointer*. :-)

Good point (:-)... but the key phrase is "the type of programs FORTRAN is
suited to..."  There are whole bunches of things that FORTRAN is suited to
that C is not, and vice versa.  I agree that it would be nice to have
dynamically allocated arrays in FORTRAN but I think that, bearing in mind the
gawdawful hassle handling multiply dimensioned arrays in C, (KEY PHRASE COMING
UP...) that, for the purposes that it was designed to address, FORTRAN, by
and large, has it right.  (FLAME RETARDANT:  THIS DOES NOT MEAN THAT C HAS IT
WRONG.... IT JUST MEANS THAT THEY WERE DESIGNED TO DO TWO DIFFERENT THINGS)

> >...  In fact, in
> >light of some other comments that I've seen on this group, the construction
> >
> >      call bar
> >
> >is slightly more aestheticly pleasing than
> >
> >      bar();

> To coin a phrase: beauty is in the eye of the beholder.  I think
> "bar();" is more in keeping with the philosophy of C, hence more
> aesthetic.

No argument (pun intended...), as long as we're talking about C.  This was 
only a side comment, directed at the null statement discussion that has been
going on for the past week.

> >[my comments about named common and logical grouping of external data
> >references]

> That's funny, if you had asked me to list of what I think are
> Fortran's 10 biggest mistakes, COMMON blocks would probably be at the
> top.  They are probably the single largest cause of suicide among
> Fortran maintenance programmers, although implicit variable
> declarations might be close.

Howcome?  I've been programming in FORTRAN for about 10 years, both writing
my own code and maintaining others' and find it useful to know which program
unit (subroutine or function) has the capability of diddling with what 
external variable and which program doesn't.  Are you saying that lumping
all externals into one pool is *more* maintainable?  How so?  How else do
you suggest?  I'm genuinely interested.  But, then, again, I happen to like
implicit declarations, too... ;-) <---- flamers... note smiley guy...
 
                                                   spl
----------------------------------------
Internet: LAMONTS at SDS.SDSC.EDU
Bitnet:   LAMONTS at SDSC
Span:	  SDSC::LAMONTS (27.1)
USPS:	  Steve Lamont
	  San Diego Supercomputer Center
	  P.O. Box 85608
	  San Diego, CA 92138
AT&T:	  619.534.5126