🚀 go-pugleaf

> It pays to study carefully why something is successful before you
> mimic it. Following the C/Unix model might seem to make sense, but we
> should understand, not guess, why it succeeded. 

Well, maybe it's because I've never been a big user of Lisp machines,
but the way I use Lisp is fairly close to the C/Unix model.  That is,
I have some source files that I edit using a text editor (Emacs), I
have a makefile or a defsystem, and I compile the files to produce
a loadable system.  I don't live in a Lisp image that persists from
day to day.

On the other hand, I wouldn't want to go further towards C and
have to recompile and relink my system every time I make a change
and every time I want to mix in some other stuff.  So, in the
short term I do live in a Lisp world that I modify.

Most of the time this is fine.  But some people don't want to
live in the Lisp world.  They don't mind having something written
in Lisp, but they don't want to have to be in Lisp to use it.
I feel this way when I want to use Lisp to write a Unix command
I can invoke from the shell, for instance.

Unix/C is successful, and it's pretty clear by now that many
people don't want to move into Lisp instead.  They don't want
to adapt to Lisp; and they'll use Lisp only if it adapts to
their way of doing things.

In short, I think there's a case for adapting even if we don't
know _why_ Unix and C are successful; and I would probably be
somewhat happier myself if Lisp made some moves in this direction.

That said, however, I agree that we should try to figure out
why UNix and C are successful, and I'm not all that happy with
some of the things people are doing to move closer to C and Unix.
For instance, I don't want to get rid of EVAL.

-- jd