Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!husc6!ut-sally!utah-cs!utah-orion!shebs
From: shebs@utah-orion.UUCP (Stanley T. Shebs)
Newsgroups: comp.lang.lisp
Subject: Re: Fortran
Message-ID: <182X@utah-orion.UUCP>
Date: 21 Jan 88 00:00:00 GMT
References: <332@siemens.UUCP>
Reply-To: shebs@orion.utah.edu.UUCP (Stanley T. Shebs)
Organization: PASS Research Group
Lines: 58

In article <332@siemens.UUCP> steve@siemens.UUCP (Steve Clark) writes:

>By being such a pervasive standard, Fortran held back the practice of Computer
>Science for many years after the state of the art had advanced beyond it.

This is an old chestnut, at least to CS types.  David Gries (or Kenneth
Wilson?) wrote something a couple years ago, to the effect that scientific
programmers kept using Fortran because all the new languages offered few or
no advantages.  For one thing, most of the languages are procedural, so the
process of converting specification ("use an adaptive grid method") to code
("do i = 1, 50") remains basically the same.  We in CS make a big fuss over
recursion, data structures, etc, but users of languages have more important
concern.  Claims that "language X has held back the practice of Y" are pretty
suspect - I find the hard parts of CS to be things like logics, algorithms,
and representations, which have relatively little to do with programming
languages.

>Unix is doing the same thing in the realm of operating systems, although
>to a lesser degree.  Somehow Unix is more flexible and adaptable than Fortran,
>even though it is just about as widespread and just about as standardized.

I don't see Unix holding anything back either.  What I see is that the term
"Unix" is being applied to almost any operating system with the capability
for forked processes in separate address spaces. 1/2 :-)

>2) I assert that Emacs is the Fortran of editors.

Fine by me.  As a user of editors, I'm more interested in mundane issues
like how many machines it's on and how reliable it is.  I agree that Emacs
has numerous deficiencies - I've blown away whole buffers with ^W, have never
been comfortable with the idea of deleting things to make copies of them,
and hate to use the control key.  But what I hate even more is editors that
only work on one kind of terminal, and using seven different editors.

>In conclusion, I assert (admittedly without much argument) that Emacs and
>CL are, at least with respect to files and editing, Fortrans.  The "new"
>ways (which aren't that new) are database-type files and structure editing.

I also agree that these are new ways.

What I *don't* agree with here is the unstated assumption that "old" ways
should be abandoned the moment "new" ways come along.  There have been too
many times I've watched people screwing around with something new and fancy -
and inefficient and unreliable and nonportable.  I really hate having my
productivity cut into by some half-thought-out and half-implemented system!

In the case of database files and structure editing, no one has yet come
up with something that offers clear and immediate benefits without a host
of caveats and drawbacks.  Interlisp could have been the standard Lisp of
the 80s if people had put as much thought and effort into its design and
implementation as have gone into Emacs and Unix and Common Lisp, instead of
patching kludges with worse kludges.  The success of a software idea depends
as much on the quality and availability of an implementation, as on the worth
of the idea itself.  The history of CS is full of examples of this, but of
course those who are ignorant of history *inevitably* repeat it...

							stan shebs
							shebs@cs.utah.edu