Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 exptools; site ho95e.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ho95e!wcs
From: wcs@ho95e.UUCP (x0705)
Newsgroups: net.lang
Subject: Re: What language do you use for scientific programming?
Message-ID: <169@ho95e.UUCP>
Date: Sun, 18-Aug-85 21:44:10 EDT
Article-I.D.: ho95e.169
Posted: Sun Aug 18 21:44:10 1985
Date-Received: Tue, 20-Aug-85 21:06:52 EDT
References: <909@oddjob.UUCP> <163@ho95e.UUCP> <367@ttrdc.UUCP>
Organization: AT&T Bell Labs, Holmdel NJ
Lines: 53

> dan levy ..!ihnp4!ttrdc!levy
> In article <163@ho95e.UUCP>, wcs@ho95e.UUCP (x0705) writes:
> > ...
> >I find the biggest
> >weaknesses fortran has for scientific programming are:
> >	- no recursion - makes everything tough, especially multiple integration
> I was under the impression that Fortran-77 allows recursion in the sense that
> a routine may call itself either ......  > am I mistaken?

The f77 compilers provided with AT&T UNIX systems and Berkeley 4.* all allow
recursion; they're based on the C compiler and making them NON-recursive would
have taken a lot of work, as well as depriving them of a valuable feature.
However, the Fortran 77 Standard doesn't allow recursion, and I try to avoid
non-standard language extensions whenever possible - most of my fortran code
has been written in Fortran IV, though I do break down and use if-then-else's
jsut to keep sane.

The reason is that fortran code might get used on all kinds
of brain-damaged environments, many of which don't even support full fortran-4,
much less fortran77 with UNIX extensions.  When I do use fortran, it's mainly
because I'm working with existing, "working" code, and I want to reuse it, and
add to it in ways that can be returned to its original environment and used.
("Working" often means "this unmaintainable piece of spaghetti still runs on my
IBM 370";  C programmers have a similar disease called "doesn't *everyone* use
VAXes?")
	If I wanted to write new code that only ran on UNIX systems, you can
bet I'd rather use C than f77.
> 
> >	- no dynamically dimensioned arrays ( though C is kind of clumsy also)
> True in the general case--some operating systems (like VMS) provide extensions
> which allow dynamic memory allocation (is this what is being referred to?).

What I was referring to was the PL/I feature that lets you write code like:
	subroutine hackarray( a, b, n );	/* Please excuse the syntax; */
	declare n integer;			/*    it's been a long time. */
	declare a(n,n), b(n,n) float binary(32);
	...
Most fortran compilers at least have some syntax for saying
	subroutine HAKARR( a, b, n )
	integer n
c
c	a and b are 1-D real arrays, size n depending on the calling routine
c
	real*4  a(1), b(1)

Most modern languages at least let you pass an array to a routine, with the
array size determined at routine-execution time rather than compile-time;
it's not always easy to create ANOTHER array within the subroutine.
Unfortunately PASCAL doesn't even let you do that; if you need to hack
arrays of size N and also size M, you need to write separate subroutines to do
it.
-- 
## Bill Stewart, AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs