Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!noao!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: What does an anti-perl look like
Message-ID: <4377@optima.cs.arizona.edu>
Date: 18 Jun 91 19:13:23 GMT
Sender: news@cs.arizona.edu
Lines: 49

In article  <1991Jun18.004338.23499@jpl-devvax.jpl.nasa.gov> Larry Wall writes:
]In article <2154@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:
]:a philosophy that Lisp folks
]: have been preaching for years.  In perl, one is partly abandoning the
]: the notion of small, stand-alone tools that do one thing well, and
]: instead adopting the monolithic everything-in-one-language approach that
]: Lisp has always had.  You know.  "Swiss army chainsaw."

]That's not too far off the mark...

Actually, _is_ off the mark.  This characterization of Lisp as a
"Swiss army chainsaw" comes from Unix types who are trying to
characterize lisp as a "tool" so that they can have a nice mental box
to put it in.  However putting Lisp in a group with lex, yacc, make,
awk, etc. is not quite correct.  It would be no less (and no more)
accurate to characterize Lisp as an operating system.

Basically Unix works on the principle that all tools are seperate
programs, loaded seperately by the operating system.  This has several
disadvantages -- most obviously that running a seperate program as a
seperate process is expensive.

Another problem with this approach is that communication between tools
is awkward and inefficient because it is all done through character
streams or disk files.  For tools that want to communicate complex
data (like a parser communicating with a code generator), each one has
to be able to read and write character representations of the data.
This is expensive in both developement time and execution time.

The Lisp philosophy is to have a system where tools communicate
through high-level data structures, and where communication between
tools is no different from communication between procedures within a
tool.  Lisp tries to tie everything into single model and avoid the
two-level system of Unix.  In Lisp, the development language, the
shell, the "pipes", the "file system" and sometimes the process
handler are all the same system (Lisp) and the tools are Lisp
procedures.  This isn't any more monolithic than Unix, it is just that
the divisions are put in different places.

You can have the "tools" approach in Lisp, but there is no distinction
between a tool and a library routine.  In Lisp, you don't need both an
"rm" and an "unlink()".  If you have "cp" you don't have to code your
own "copy_file()".  And when you write a compiler, you don't have to
decide whether to put the parser and code generator in a single
program for speed, or seperate them for maintainability.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman