Path: utzoo!mnetor!uunet!ncc!alberta!cdshaw From: cdshaw@alberta.UUCP (Chris Shaw) Newsgroups: comp.arch Subject: Re: FORTRAN Horror Message-ID: <1135@pembina.UUCP> Date: 18 Mar 88 09:25:04 GMT References: <24861@yale-celray.yale.UUCP> Reply-To: cdshaw@pembina.UUCP (Chris Shaw) Organization: U. of Alberta, Edmonton, AB Lines: 65 In article <24861@yale-celray.yale.UUCP> leichter@yale-celray.UUCP (Jerry Leichter) writes: > >Maybe the >REASON the scientific community like FORTRAN is that it ALLOWS them to "play >around". ... >A common thing >to do is to allocate a large one-dimensional array and carve variable-sized >2-D arrays out of it. The way this is done is ugly, because FORTRAN has no >inherent ability to deal with dynamic memory allocation so it all has to be >faked. ^^^^^^^^^^^^^^^^^^^ ^^^^^ > If the code had been done in C, for example, the space would have been >allocated with malloc(). Of course, that doesn't really give the a compiler >much more to go on than was available in the FORTRAN case! Not true! >Before proposing to remove something so central to large codes, you'd better >understand WHY it's central, and what you can provide to replace it with. > -- Jerry I think the reason that the scientific community likes FORTRAN is that the scientific community likes FORTRAN. There are huge libraries of code that solves most of the boring details of your problem, so all you have to do is code up the I/O and the mainline (gross amounts of handwaving here) and bob's your uncle. Well fine. But it's a software engineering horror, and everyone knows it. Just because it's standard to carve a chunk out of an array doesn't mean that this is the best way of doing things. Jerry carelessly mentions the possibility of doing numerical codes in C, and basically states that things would be no different. Well, I HAVE done this and the benefits are considerable. I translated a subset of SPARSPAK, a sparse matrix package, to C. Although there is not much difference on the face of it, there is substantially less effort spent on garbage programming. True, you get arrays with unknown initial sizes. But 1) Somebody else is doing the garbage collection and storage management. This is the way it SHOULD be. It's the compiler's job. No-one's going to claim for a moment that a scientist who can barely program coherently is going to spend the amount of time it takes to get his storage management right. The scientist wants answers, and storage management doesn't give answers. 2) There is no compiled-in upper bound on the size of the problem you have to solve. With malloc, you can either solve the problem on the machine or you can't. Given flexible code, there is never going to be a situation where you have to dink with the code every time a new-sized problem comes up. The point being, of course, that creating flexible programs is MUCH easier in C than FORTRAN. In sum, the reason WHY the carve-array paradigm is central to FORTRAN is that one is FORCED into using it. Getting back to the SPARSPAK example, I found that solving stuff with C-SPARSPAK was much easier than the FORTRAN version, since I only had to compile once. This allowed me to concentrate almost entirely on the problem at hand. -- Chris Shaw cdshaw@alberta.UUCP (via watmath, ihnp4 or ubc-vision) University of Alberta CatchPhrase: Bogus as HELL !