Xref: utzoo comp.arch:4284 comp.misc:2245
Path: utzoo!mnetor!spectrix!clewis
From: clewis@spectrix.UUCP (Chris Lewis)
Newsgroups: comp.arch,comp.misc
Subject: Re: FORTRAN Horror
Message-ID: <538@spectrix.UUCP>
Date: 8 Apr 88 03:11:18 GMT
References: <1135@pembina.UUCP> <46500011@uxe.cso.uiuc.edu> <6630@ames.arpa>
Reply-To: clewis@spectrix.UUCP (Chris Lewis)
Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada
Lines: 131

In article <6630@ames.arpa> lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster) writes:

Much as I hate FORTRAN, I will admit it has its uses.  Particularly in
number crunching.  Mind you I believe that the main reason that FORTRAN
is used so much for number crunching and is better than most others for
number crunching is simply because it's used so much for number crunching.
A circular argument ;-).  But consider, since there is relatively little 
demand for SERIOUS number crunching in any other language, no other 
language-developer (eg: C or whatever) bothers to tune their language 
for it, nor is much in the way of mathematical libraries for anything 
else.  Similar statement:

	IBM PC's or clones are better for running LOTUS than a Sun
	["FORTRAN" is better for "NUMBER CRUNCHING" than "C"]

Of course!  Lotus doesn't run on a Sun....
[The only customers of ours doing number crunching use APL!]

I wouldn't normally have said anything here, but I'm a little curious
about some of your statements, and I would like you to clarify them.

>2) Fortran is modular.  Fortran subroutines are modules, and this puts
>Fortran ahead of any language (e.g. Pascal) which only has "procedures".
>Yes, both would be better.  Unfortunately, I haven't seen any vectorizing
>Modula-2 compilers for the Cray or CDC machines.  Convex does sport a
>vectorizing C compiler, however.

What exactly do you mean by "modular"?  Separate compilation and linking?
Most "serious" languages have that - C, PL/1, Assembler, COBOL and (gasp) ADA
to name a few (no flames about Ada being "serious" please :-).

Most useable Pascal compilers (for big "systemy" things) do too (eg:
IBM Pascal/VS), though this is of course not part of Wirth Pascal.
It's been a while since I did any work with FORTRAN, but I think I can
do just about everything FORTRAN can do with COMMONs and EQUIVALENTs in C.

Simply because a language definition doesn't refer to "modules" doesn't
mean that it doesn't have them.

>3) Fortran is not a bad programming language, even for systems programming.

As long as you wrap RATFOR around your FORTRAN :-)  Seriously, speaking as
an ex PL/1 and FORTRAN jock, it's been my experience that non-structured
programs are hard to maintain.  So hard in fact to often be impossible to
maintain.  Yes, I know that C can be written as spaghetti-like as FORTRAN
can, but the language-training you get (from schools, books, courses whatever)
*usually* leads a person into programming in more-or-less the same mind-set as
everbody else.  FORTRAN is usually spaghetti.  C is usually not.  [But there
is a University around here that teaches FORTRAN IV programming style in
PL/1 and C...]

(Actually, RATFOR *is* pretty good for systemy stuff.)

>Fortran has been used as the basis for a number of system implementations.
>Now C bigots will note that C has modules and internal procedures, and, yes,

I did.

>it does have advantages as a system implementation languages.  But, for a
>Fortran replacement it is hopeless.  The syntax is confusing and more error
>prone than Fortran, 

This is of course open to debate.  You can kill yourself with the ol'

	while(something);
		do something
    or
	a = sin(1);
    or
	if (a = b)
	    something

    problems in C, but there's probably just as many in FORTRAN:

	DO I = 1 10
    
	call f(2)

    subroutine f(a)
	a = 4
	end
    
    problem (and a horde of others) in FORTRAN too (going back into the
    history of FORTRAN for my examples).  At least, *most* of the versions
    of C will behave the same way to silly syntactical mistakes.  FORTRAN
    does not.  Yes, C programmers do sometimes depend on byte order and
    NULL-dereference behaviour.  Most of the problems with USENET-distributed 
    software is not due problems like this.  They're mostly due to operating 
    system differences (Xenix vs. BSD vs. SV vs. DOS), not language problems.
    Sure, Linpack will port real nice in FORTRAN - but try writing the netnews
    software (or any other multi-program, system-dependent thing like a
    mail system like I did) in FORTRAN.  Then move it from an IBM MVS 
    Fortran-H to a DEC VMS F77 environment.  Or even just Fortran-G to H.
    Then you'll find out about FORTRAN incompatibility!

    Though, you're right.  I wouldn't do major number crunching in C.
    Probably not FORTRAN either.  (perl is the ticket! ;-)

>but even worse, because C doesn't have dynamic array
>dimensioning you can't use it for separately compiled libraries like
>Linpack.

Doesn't have dynamic array dimensioning?  I will admit that using dynamic
bounds multi-dimensional arrays is sometimes a bit hard, but dynamic length
vectors is certainly no problem (the C libraries are chock full of routines
that will handle variable-length vectors - eg the str* routines).  And 
there's lots of libraries that will handle arrays of arbitrary objects
(eg: qsort).  And C can dynamically allocate storage - can FORTRAN?  
Can FORTRAN handle arbitrary numbers of dimensions?  I don't think so.  
C can.  Can FORTRAN handle complex data structures?  Eg: dyamically 
allocated trees, linked lists etc.?  "unions"  (variant records)?  Nope.
Most versions of FORTRAN I've used can't even handle character data types 
for heck's sake (I stopped using FORTRAN just as F77 came out...).

Mind you, the lack of dynamic length arrays as parameters is the single 
most important reason why I hate Pascal (I know some dialects support them,
but not all) and some PL/1 subsets (eg: DRI PL/1G for CP/M...).

Actually, if you think about it, I think C is more portable than FORTRAN when
you compare the number of variants of FORTRAN (Fortran II, IV, 66, WATFOR,
WATFIV, 77, SWATFIV and specialized versions from specific vendors (ala
FORT-G, H, FORT-VS, F4+, F77 etc. etc. etc.) and C (which boils down to: 
pre-K&R V6, K&R-conformant (V7 and most others), and post-K&R - very 
little actually changed at all.  Except for Intel processors.  Sigh...)

FORTRAN has changed a *lot* more over the years than C has.  And those
*really* old FORTRAN compilers are *still* around haunting us.
-- 
Chris Lewis, Spectrix Microsystems Inc,
UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis
Phone: (416)-474-1955