[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Macros and little languages

Paul Graham wrote:
> As for having taken multiple tries, it is not merely common
> for advanced technologies to take decades to be adopted by
> the mainstream, it is the default.  If anything, the takeup
> of Lisp ideas has been encouragingly fast.  15 years ago,
> mainstream programmers were using C, and we Lisp hackers
> were trying to convince them that dynamic typing and gc
> were good ideas.  

I was trying to convince people to embrace those ten years ago. They
said: (partially true, partially false) "the hardware isn't fast
enough." Even today, performance is one of the primary arguments against
Python. (it isn't a primary argument against Lisp but that should tell
you something about what is holding Lisp back...)

If we had today's computers in the 1970s, then I claim that we would
have been using garbage collection and maybe dynamic type checking for
the last thirty years. It wasn't that it took that long for the memes to
spread. I took that long for the hardware and compiler technology to
catch up.

But the next category of features has nothing to do with performance. In
fact, both parened syntax and macros are very helpful on small machines
(to transfer runtime processing to compile time, and reduce parse time,

IMHO, some of Lisp's ideas were stalled by hardware/techniques and
others were rejected. It is not helpful to conflate them because it
leads to the wrong conclusions.

> ... Now you have advanced so far that our
> only remaining gripes are the lack of macros (which I think
> will be found to require prefix notation),

If you are right, then I guess macros will never catch on. ;)

> ... the pointless
> traditional distinction between statements and expressions
> (which Javascript and Smalltalk have already tossed, and
> Perl at least hides), 

The distinction encourages a coding style that most programmers (at
least Python programmers) prefer. For instance:

 * http://mail.python.org/pipermail/python-dev/2001-October/017965.html

(the feature is one that will probably get in, one day, but the response
is emblematic of a design style that would argue strongly against, for
example, expression try/except, or multi-statement lambda, or
expression-based class definitions)

> ... and a few other minor bugs and
> restrictions accumulated in the process of getting the
> answer by successive approximations instead of using the
> closed-form solution.

It is possible to prefer a thing and yet recognize that it is a
preference and not a reflection of the underlying structure of the

I proposed that lambda be made more like Lisp's (based on my experience
with Scheme) when I started with Python six or so years ago. I was told
that the patch to make it more like Lisp's had been coded several years
before that and nobody wanted it. Once I got to understand the Zen of
Python, I understood why.

 Paul Prescod