Fortran
Steve Clark
Unix is the Fortran of operating systems.
----------------------------------------
Somebody once gave a talk with this title, about 7 years ago, at Carnegie-
Mellon U. It turns out he is fairly correct, but not as correct as he thought.
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.
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 have two new points to make today:
1) Why isn't Lisp a Fortran? Will Common Lisp be the Fortran of Lisp?
(Answer left as an exercise to reader. Scheme fans will no doubt have
different answers than most of the rest of us.)
2) I assert that Emacs is the Fortran of editors.
Once you learn Emacs well (I mean really well, like just about everyone
reading this list), it is hard to find an editor worth the trouble of learning,
isn't it? Even if the editor has theoretically superior features, you'd
rather stick with trusty old Emacs. Besides, the new editor doesn't even
have EQUIVALENCE - oops, I mean paren-balancing. Its proponents say you
don't need paren-balancing, it has a different way of achieving the same effect.
Well, if it's doing the same thing, then what's so great about it?
Besides, I would have to throw away my personal bag of tricks I've developed
to get around all the deficiencies of Emacs.
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.
Peter Schachte
> ... Will Common Lisp be the Fortran of Lisp?
No, CommonLisp is more like the Ada of Lisps. A standardized committee
effort, designed to include everything including the kitchen sink. Why
didn't CommonLisp take the more modern approach of having most of the
goodies out in libraries (Modules to CommonLispers)?
> 2) I assert that Emacs is the Fortran of editors.
The really sad thing about emacs is that it doesn't have a way to
highlight selected regions of a buffer. This renders a mouse pretty
much useless except for positioning. If emacs could hightlight
regions, one could select words, sentences, and paragraphs with a mouse
and then delete them or copy them with a single keystroke. I've used
a version of emacs that uses a mouse to do these sorts of things
WITHOUT highlighting them first, and this is worse than nothing. You
just don't know what you're doing until it's done. Sure, you can get
it back if you deleted something you wanted, but first you have to
figure out what happened. The visual feedback BEFORE the operation is
committed to is important.
All of you hardcore emacsers are screeching at the thought of handling a
rodent for editing, I know. But for manipulating chunks of text (or
structure), a mouse is the ideal tool. And the real idea is to use one
hand to move and click the mouse, and the other chording keys on the
keyboard to indicate WHAT to do with the chunk you are selecting with
the mouse. Interlisp-D uses the scheme that SHIFT means to copy what
you have selected to wherever your typein would go, and CONTROL means to
delete it. Of course, both means to move it. (Note that what you
select is not constrained to have your typein point at one end of it, as
does emacs.) I might even LIKE emacs if it could let me do that.
Except that in LISP mode, I'd want do be selecting S-expressions, and in
text mode, words and sentences. And I'd want emacs to do my formatting
for me completely automatically. Just like it can fill paragraphs as I
type.
Given emacs as it is now, thought, I'd say emacs is worse than a
FORTRAN. At least FORTRAN could handle new technology (terminals with
variable-length lines) when it came along. Emacs will need some work.
Or is there a hacked-up emacs that will do that now?
--
-Peter Schachte
p...@quintus.uucp
...!sun!quintus!pds
Barry Margolin
>The really sad thing about emacs is that it doesn't have a way to
>highlight selected regions of a buffer. This renders a mouse pretty
>much useless except for positioning. If emacs could hightlight
>regions, one could select words, sentences, and paragraphs with a mouse
>and then delete them or copy them with a single keystroke. I've used
>a version of emacs that uses a mouse to do these sorts of things
>WITHOUT highlighting them first, and this is worse than nothing. You
>just don't know what you're doing until it's done. Sure, you can get
>it back if you deleted something you wanted, but first you have to
>figure out what happened. The visual feedback BEFORE the operation is
>committed to is important.
What universal law says that an Emacs-style editor can't highlight
things or use a mouse? Zmacs, the Emacs-style editor on MIT-derived
Lisp Machines, does both of these things. When you invoke a command
that marks a region, the region is underlined (there is an option to
use inverse video instead of underlining). And I have used at least
one Unix implementation of Emacs that always shows the character under
the mark in inverse video (this can be confusing on a terminal whose
cursor is a non-blinking block, since you wouldn't be able to tell
point from mark except by typing Control-F and seeing which one
moves).
As for mouse support, Zmacs allows you to move around the buffer and
mark regions using the mouse. This is appropriately
context-sensitive, so that in Lisp Mode you can point to a parenthesis
and mark the entire S-expression with a mouse click. Symbolics Genera
7.0 and beyond implements much more extensive support; for example,
you can point to a line of code and set a breakpoint with the mouse.
GNU Emacs also implements mouse support when it is run under the X
Window System.
If you are going to complain about particular editors, do so. But
"EMACS" is generic, and refers to a large class of editors running on
a wide variety of computer systems ranging from PC's to mainframes.
---
Barry Margolin
Thinking Machines Corp.
bar...@think.com
seismo!think!barmar
Douglas J Roberts
>
> What universal law says that an Emacs-style editor can't highlight
> things or use a mouse? Zmacs, the Emacs-style editor on MIT-derived
> Lisp Machines, does both of these things. When you invoke a command
> that marks a region, the region is underlined (there is an option to
> use inverse video instead of underlining).
>
Gnu EMACS on a Sun also has a mouse interface, but I think the
highlighting (there currently is none that I know of) and paren
checking could be improved. Zmacs has an execllent paren checker that causes
the backward matching paren to blink, showing the matching paren at (just
before) the current cursor position.
If (when) Gnu is given better paren checking capabilities and mouse-selectable
region highlighting I will be quite happy to let my old Symbolics 3600
gather dust in the corner while I use Gnu with KEE and LISP on a Sun.
--Doug
--
---------------------------------------------------------------
Doug Roberts
dz...@lanl.gov
---------------------------------------------------------------
Alex S. Crain
>> What universal law says that an Emacs-style editor can't highlight
>> things or use a mouse?
Has anyone ever tried to implement highlighting in GNU? I would REALLY like
to have this but I haven't dug deep enough into the code to see how to do it.
If anyone has ever tried, I would appreciatteany leads to a starting point,
and or even a description off what I'm going to be looking at if//when I go in
myself.
ThanX in advance.
:alex.
Chan Benson
> even though it is just about as widespread and just about as standardized.
Just about as widespread?!... Gimme a break.
-- Chan
Jeffrey Jacobs
>In article <3...@siemens.UUCP>, st...@siemens.UUCP (Steve Clark) writes:
>> ... Will Common Lisp be the Fortran of Lisp?
>No, CommonLisp is more like the Ada of Lisps. A standardized committee
>effort, designed to include everything including the kitchen sink.
I have to disagree; Common LISP is the PL/I of Lisps. Too big and
too incomprehensible, with no examiniation of the real world of
software engineering.
ADA, while it has is problems, is a very well though out, well constructed
language. The process that resulted in ADA and the process that resulted
in Common LISP are worlds apart, the only similarity is the use of the
term "committee". The CL effort resembles a bunch of spoiled children,
each insisting "include my feature or I'll pull out, and then we'll all
go down the tubes". Everybody had vested interests, both financial
and emotional.
CL is a nightmare; it has effectively killed LISP development in this
country. It is not commercially viable and has virtually no future
outside of the traditional academic/defense/research arena. It should
be embarassing to everybody in the field that most shells and tools are
no longer written in LISP.
To quote Dick Gabriel, the "father of Common LISP":
"Common Lisp is a significantly ugly language. If Guy and I had been locked
in a room, you can bet it wouldn't have turned out like that" - WESTEX 86
(or maybe 85). Dick has also stated that the attempt to make Common LISP
a commercial standard is a disaster.
(One must in fairness point out that a father is not totally responsible for
his offsprings behaviour).
ADA, despite it's problems, is o well thought out, engineered language.
Any comparision with CL is odious; but comparing CL to PL/I, that incredibly
ancient monster, is perfect...
Jeffrey M. Jacobs
CONSART Systems Inc.
Technical and Managerial Consultants
P.O. Box 3016, Manhattan Beach, CA 90266
(213)376-3802
CIS:75076,2603
BIX:jeffjacobs
USENET: jja...@well.UUCP
Rodney Peck
>In article <13...@beta.UUCP> dz...@beta.UUCP (Douglas J Roberts) writes:
>>> What universal law says that an Emacs-style editor can't highlight
>>> things or use a mouse?
>
>Has anyone ever tried to implement highlighting in GNU? I would REALLY like
>If anyone has ever tried, I would appreciatteany leads to a starting point,
The Symbolics Lisp machines have an editor called Zmacs which supports highlighting
and mouse control. Perhaps you should find a Symbolics machine and mimic it.
I think that mousing and highlighting would be great. I'm using a sun 3/50
right now.
Rodney
Skef Wholey
did a good job with this guy last time, but is sitting this round out.
I'll take a turn at it, not because I believe that a person this far
gone can be straightened out, or because I'm afraid his ignorance is
contagious, but because I'm collecting some memory-usage statistics on
this Lisp-based text editor I'm using, and I need the keystrokes...
>In <47...@well.UUCP>, jja...@well.UUCP (Jeffrey Jacobs) writes:
>I have to disagree; Common LISP is the PL/I of Lisps. Too big and
>too incomprehensible, with no examiniation of the real world of
>software engineering.
Incomprehensibility, like boredom, usually springs from a deficiency in
the beholder rather than the beheld.
>It should
>be embarassing to everybody in the field that most shells and tools are
>no longer written in LISP.
I assume that by "the field" he means AI, and that by "shells" he means
expert system shells and the like. The reason a lot of applied AI and
expert systems work is being done in other languages has little to do
with Common Lisp. The development of Common Lisp was coincident with a
lot of work that pinned down just how one should go about implementing
rule-based systems, effectively removing such systems from the arena of
exploratory programming.
Exploratory programming is what Lisp is all about -- it also happens to
be what a lot of AI is about: that's why they've existed side by side
for so long. But neither has any hard ties to the other. You can do AI
in C, and you can write window systems in Lisp. When the cost of such
things as software maintenance and delivery vehicles for "AI" systems is
important, C can often beat Lisp hands down. Any Lisp. There are far
more C hackers and C compilers out there than there are Lispers and
Lisps, and I doubt that this will ever change. However, the latter
numbers have grown by leaps and bounds since the introduction of Common
Lisp.
>To quote Dick Gabriel, the "father of Common LISP":
Funny that he goes on to quote a man who is profiting from the
commercial viability that, earlier, he asserts doesn't exist. Also,
Gabriel is "a father" of CL, not "the father." Every one of the five
principal designers will tell you he could have designed a better
language by himself, or with one or two of the others, and many were
trying to do just that when the standards effort began. If all had
proceeded undisturbed, there might be several beautiful Lisps by now,
but they would be largely incompatible, and each would run only on one
or a few machines. Probably none would be supported by any large
computer manufacturers.
Common Lisp is not perfect. The problem with perfection is that
different people have different ideas of what it is. When you put a
group of smart, experienced people together and tell them to create
something, you'll usually end up with a compromise. If you're lucky
(and I believe in the case of Common Lisp we were lucky), that
compromise will not be so bad.
I imagine that JJacobs wasn't around when the initial design of Common
Lisp was going on over the ARPAnet, and I'm sure he wasn't at either of
the two face-to-face meetings. I'll bet that he hasn't even read any of
the old Common Lisp mailing list archives, in which much of the
rationale for various design points of Common Lisp can be found. Sorry,
JJacobs, but you're just not very well informed.
>ADA, despite it's problems, is o well thought out, engineered language.
>Any comparision with CL is odious; but comparing CL to PL/I, that incredibly
>ancient monster, is perfect...
When one stretches a metaphor hard it often becomes limp and useless
(that's a meta-metaphor!). The more one tries to draw from these
comparisons the less meaningful they become. I suppose I could say,
"Jeffrey M. Jacobs is the punched card of the comp.lang.lisp community,"
but I would risk the possibility that someone might find something nice
to say about punched cards.
-- Skef Wholey (Who...@C.CS.CMU.EDU)
Charles Hedrick
>Lisp was going on over the ARPAnet, and I'm sure he wasn't at either of
>the two face-to-face meetings. I'll bet that he hasn't even read any
Well, I was around. I participated in the distributed committee,
including the votes, and I was at one of the meetings. I believe
JJacobs' description of the process has a certain basis in fact, but
that the result was inevitable given the goals that CL was intended to
meet. It is true that many people suggested features. On a number of
occasions I tried to get people to simplify the language, and found
that it was *much* easier to get a feature added than to get one
removed. I was a voice crying in the wilderness, aided only by the
folks at Utah now and then. Like Jacobs, I also heard comments in
private suggesting that threats of withdrawl from the project had been
used to keep features in the language. Knowing this sort of thing, I
doubt that there were really any overt threats, just signs that people
whose influence was crucial to the project would likely become much
less enthusiastic if the language wasn't a reasonably large subset of
LM Lisp.
Despite all of these things, I think the image of CL as a union of
features drawn from a bunch of random users is simply not right. It
was intended from the start to begin with existing dialects of
Maclisp, including Lisp Machine Lisp, and to provide something that
was sort of like an intersection, but cleaned up and made consistent.
It is in fact reasonably consistent. The main design issue was how
close it should be to LM lisp in size. I believed (and still believe)
that LM lisp is a monster, and that CL should not use it as a model.
However LM lisp was very influential within the Maclisp community at
the time, and after all CL was supposed to represent the concensus of
the Maclisp community as to what a base Lisp should look like. In
this context, it was perfectly reasonable for people to have believed
that the language should be on the same scale as LM Lisp, and one need
not imply that nefarious motivations were involved. I happen to think
that they were wrong. I'd like to see a Lisp which is practical to
use for things other than large AI programs running on huge machines.
I am simply offended by a language of this size. But CL did achieve
its goal, and it's not clear that reducing the number of people
involved in its design would have made it much smaller. As long as
there was a concensus among the Maclisp community that they wanted a
substantial subset of LM Lisp, the result was bound to have been on
the same scale as CL. From the beginning, almost all of the community
involved in the design wanted a big lisp. It didn't get there feature
by feature, with people stepping back in shock when they saw how it
ended up. There were explicit discussions about size, and people said
that they would rather have all the functions that are commonly used
present, so people didn't constantly have to reinvent them. Guy may
have been picked because he had previously designed a small, elegant,
Lisp, but he was given the job of coordinating the design of a big
Lisp.
Barry Shein
I've had my misgivings about CL, and there are certainly dubious
features I would have thrown out the window (the most dubious of which
is probably multiple-value-returns, there simply to support some
machines with a little fast stack hardware, I mean really, why not
just return a list even if it's faked onto the stack?) but I find it
useful nonetheless. I mean, car is car and all that.
In fact, it's not the "bigness" that's the problem. The perceived
bigness is mostly due to the minutiae it deals with (most of which is
reasonably useful.) Rip everything out of the CL book that you didn't
need to read and I think you won't find a whole lot left (assuming
you've been around the community, that's not a criticism by the way.)
The problem is how little it standardized, that's where I think the
final evaluation of CL will find its criticisms.
The fact that it doesn't cover things like fonts, windows, networking
primitives (well, sort of), object-oriented interfaces, real operating
system environment details (eg. a mandated file system view rather
than "oh, it'll take whatever string the host system does"), debuggers
and other development tools etc etc is the problem.
Without dealing with these issues one ends up with a relatively
non-portable language because all these things end up in programs
anyhow and just create problems. The lack of devpt environment details
of course impacts the portability and standardization of people.
Swell, now we got Lucid/Sun hackers who would probably be totally lost
on a lisp machine CL.
Now, I'd be the first to admit that getting all that right would have
been hard and a lot of work (no one said claiming to have standardized
LISP was supposed to *easy*), but I think it was critical to its
possibility of finding any large-scale commercial success.
The problem was that too many people were thinking in terms of some
least-common denominator, they should have subsetted that perhaps. I
have little doubt that the conversations between the DEC/VMS folks and
the Lisp Machine community (LMI, Symbolics, Xerox) must have been
amusing at best (fonts?! no fonts no way, heck, we don't even want
lower case!!)
It really was a case of a standardization of a language within a
least-common denominator view as it existed some time in the late 70's
on largish dumb-terminal oriented time-sharing systems. That's too bad
but it's not surprising, such people tend to have had their 10+ years
under their belts and got their way via seniority, so we got a
standard that looks real compatible with a DEC-10 just as the last one
rolled off the line...I guess standards have a way of looking
backwards only.
It would be nice to hear that people consider the possibility of a
Common Lisp '90 or some such is open to discussion. Perhaps there's
still a chance to make it a viable language and reflect modern needs.
-Barry Shein, Boston University
Stanley T. Shebs
a few spare moments to counterflame...
In article <47...@well.UUCP> jja...@well.UUCP (Jeffrey Jacobs) writes:
>ADA, while it has is problems, is a very well though out, well constructed
>language. The process that resulted in ADA and the process that resulted
>in Common LISP are worlds apart, the only similarity is the use of the
>term "committee".
Jacobs must be angling for DoD money or something. I don't think I've ever
heard anybody, not in the pay of the DoD, say anything good about Ada...
Tony Hoare's Turing lecture certainly had some critical remarks, to the
effect that we risk missiles hitting our own cities by using Ada.
(I don't know what he thinks about CL.)
The process resulting in Ada had the advantage of a sponsor deciding in
advance that it was going to be successful (the DoD *never* has failures, of
course!), while the CL folks had to design the language for acceptability
to an uncoercable community, and it was not at all certain whether it would be
successful. I would say that its success over many competitors is an
indication that, by and large, CL is a pretty good language.
CL has also been victimized by rising expectations; years ago it was
criticized for being too radical and too ambitious, for instance by
adopting lexical scoping as the default. Now lexical scoping seems to
be taken for granted, and CL is criticized for allowing dynamic variables...
>CL is a nightmare; it has effectively killed LISP development in this
>country.
You're going to need some facts to back up that assertion. I see plenty
of Lisp work going on.
>It is not commercially viable and has virtually no future
>outside of the traditional academic/defense/research arena.
People outside this arena don't generally have any interest at all in
higher-level languages. There are *no* successful general-purpose languages
above the level of C/Pascal/Ada (4GLs are fairly specialized). CL in fact
has the best shot at success, but it needs some good cheap implementations.
>It should
>be embarassing to everybody in the field that most shells and tools are
>no longer written in LISP.
It *is* embarassing, but CL is not the reason; the same thing would have
happened if (for instance) Scheme had been standardized on. I place the
blame on lazy and timid Lisp implementors who forgo optimizations because
"they would compromise Lisp tradition", and companies who get away with
selling shoddy systems because there is little or no competitition.
>To quote Dick Gabriel, the "father of Common LISP":
>
>"Common Lisp is a significantly ugly language. If Guy and I had been locked
>in a room, you can bet it wouldn't have turned out like that" - WESTEX 86
>(or maybe 85).
Yeah, it would have looked like APL, been partially implemented once, and
ended up on the giant dustheap of forgotten languages. 1/2 :-)
To take another quote from Gabriel, this time from the 1984 Lisp conf:
"... the world is better off having a Common Lisp than not."
I seem to remember that last year or the year before or sometime, Jacobs
was hinting at a fantastic new Lisp dialect that was going to supplant
Common Lisp and presumably start a revolution in computing... wonder whatever
happened to it?
stan shebs
sh...@cs.utah.edu
Stanley T. Shebs
>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
sh...@cs.utah.edu
Gary Fritz
> Tony Hoare's Turing lecture certainly had some critical remarks, to the
> effect that we risk missiles hitting our own cities by using Ada.
> (I don't know what he thinks about CL.)
Hoare's lecture should be required reading for all computer scientists.
The passage Stan refers to is:
"...I appeal to you, representatives of the programming profession in
the United States, and citizens concerned with the welfare and safety
of your own country and of mankind: do not allow this language [Ada]
in its present state to be used in applications where reliability is
crucial, i.e. nuclear power stations, cruise missiles, early warning
systems, anti-ballistic missile defense systems. The next rocket to
go astray as a result of a programming language error may not be an
exploratory space rocket on a harmless trip to Venus. [*] It may be
a nuclear warhead exploding over one of our own cities."
[*] Refers to a Mariner Venus probe reportedly lost because of the lack
of compulsory declarations in FORTRAN
Judging by his comments on ALGOL 60, ALGOL 68, PL/I and Ada, I would guess
that Hoare is probably not an ardent fan of Common Lisp.
Hoare's lecture can be found in the September 1981 issue of BYTE, pp 414ff,
and I imagine in CACM around the same time.
Gary Fritz