Why don't people like lisp?

[Andrew Dalke]

Kaz Kylheku:
> Ah, but in Lisp, this is commonly done at *compile* time.

Compile vs. runtime is an implementation issue.  Doesn't
change expressive power, only performance.  Type inferencing
suggests that there are other ways to get speed-ups from
dynamic languages.

> Moreover,
> two or more domain-specific languages can be mixed together, nested in
> the same lexical scope, even if they were developed in complete
> isolation by different programmers.

We have decidedly different definitions of what a "domain-specific
language" means.  To you it means the semantics expressed as
an s-exp.  To me it means the syntax is also domain specific.  Eg,
Python is a domain specific language where the domain is
"languages where people complain about scope defined by
whitespace." ;)

Yes, one can support Python in Lisp as a reader macro -- but
it isn't done because Lispers would just write the Python out
as an S-exp.  But then it wouldn't be Python, because the domain
language *includes*domain*syntax*.

In other words, writing the domain language as an S-exp
is a short cut to make it easier on the programmer, and not
on the domain specialist.  Unless the domain is programming.
And you know, very few of the examples of writing a domain
specific language in Lisp have been for tasks other than
programming.

> Do people write any significant amount of code in the
> Python parse tree syntax?

No.  First, it isn't handled as a syntax, it's handled as
as operations on a tree data structure.  Second -- and
this point has been made several times -- that style of
programming isn't often needed, so there of course isn't
a "significant amount."

> Can you use that syntax in a Python source file and have
> it processed together with normal code?

Did you look at my example doing just that?  I built
an AST for Python and converted it into a normal function.

> What is Python's equivalent to the backquote syntax, if I
> want to put some variant pieces into a parse tree template?

There isn't.  But then there isn't need.  The question isn't
"how do I do this construct that I expect in Lisp?" it's "how
do I solve this problem?"  There are other ways to solve
that problem than creating a "parse tree template" and to
date there have been few cases where the alternatives were
significantly worse -- even in the case of translating a domain
language into local syntax, which is a Lisp specialty, it's only
about twice as long for Python as for Lisp and definitely
not "impossible" like you claimed.  Python is definitely worse
for doing research in new programming styles, but then
again that's a small part of what most programmers need,
and an even smaller part of what most non-professional
programmers need.  (Eg, my science work, from a computer
science viewpoint, is dead boring.)

There's very little evidence that Lisp is significantly better
than Python (or vice versa) for solving most problems.
It's close enough that it's a judgement call to decide which
is more appropriate.

But that's a Pythonic answer, which acknowledges that
various languages are better for a given domain and that it's
relatively easy to use C/Java bindings, shared memory, sockets,
etc to make them work together, and not a Lispish answer,
which insists that Lisps are the best and only languages
people should consider.  (Broad brush, I know.)

                    Andrew
                    dalke at dalkescientific.com