Why don't people like lisp?

[Pascal Costanza]

Andrew Dalke wrote:

> That's not Alex's argument.  Python has the ability to do exactly
> what you're saying (domain language -> AST -> Python code or AST ->
> compiler).  It's rarely needed (I've used it twice now in my six years
> or so of Python), so why should a language cater to make that
> easy at the expense of making frequent things harder?

Maybe you have only rarely used it because it is hard, and therefore 
just think that you rarely need it. At least, this is my assessment of 
what I have thought to be true before I switched to Lisp.

>>In Lisp, tinkering with the syntax and semantics is done even in
>>trivial programs.
> 
> And that's a good thing?  That means that everyone looking at
> new Lisp code needs to understand the modifications to the syntax
> and semantics.  That may be appropriate for an insular organization,
> but otherwise it makes it harder for others to understand any code.

That's true for any language. In any language you build new data 
structures, classes, methods/functions/procedures, and everyone looking 
at new code in any language needs to understand these new definitions. 
There is no difference here _whatsoever_.

Modifying syntax and creating new language abstractions only _sounds_ 
scary, but these things are like any other activity during programming 
that take care, as soon as the language you use supports them well.

>>By the way, your use of ``fundamental'' suggests a misunderstanding:
>>namely that some kind of destructive manipulation of the language is
>>going on to change the foundations, so that existing programs are no
>>longer understood or change in meaning. This is not so: rather, users
>>extend the language to understand new constructs. The fundamental
>>syntax and semantics stay what they are; they are the stable target
>>language for the new constructs.
> 
> 
> Alex and others have responded to this argument many times.  The
> summary is that 1) in practice those who extend the language are most
> often not the domain experts so the result doesn't correctly capture
> the domain, 

Are these non-experts any better off with just data structures and 
functions?

> 2) because it's easy to do, different groups end up with
> different, incompatible domain-specific modifications,

Do they also come up with different APIs? How is divergence of APIs 
solved in practice? Can't you use the same solutions for macro libraries?

> 3) rarely
> is that approach better than using OOP, HOF and other approaches,
> where better is defined as more flexible, easier to read, more
> succinct, etc.

Are you guessing, or is this based on actual experience?

BTW, macros are definitely more flexible and more succinct. The only 
claim that I recall being made by Pythonistas is that macros make code 
harder to read. The Python argument is that uniformity eases 
readability; the Lisp argument is that a better match to the problem 
domain eases readability. I think that...

(with-open-file (f "...")
   ...
   (read f)
   ...)

...is much clearer than...

try:
    f=open('...')
    ...
    f.read()
    ...
finally:
    f.close()

Why do I need to say "finally" here? Why should I even care about 
calling close? What does this have to do with the problem I am trying to 
solve? Do you really think it does not distract from the problem when 
you first encounter that code and try to see the forest from the trees?

BTW, this is one of the typical uses for macros: When designing APIs, 
you usually want to make sure that certain protocols are followed. For 
the typical uses of your library you can provide high-level macros that 
hide the details of your protocol.

Here is an arbitrary example that I have just picked from the 
documentation for a Common Lisp library I have never used before:

(with-transaction
  (insert-record :into [emp]
               :attributes '(x y z)
                :values '(a b c))
  (update-records [emp]
     :attributes [dept]
     :values 50
     :where [= [dept] 40])
  (delete-records :from [emp]
     :where [> [salary] 300000]))

(see 
http://www.lispworks.com/reference/lw43/LWRM/html/lwref-460.htm#pgfId-889797 
)

What do you think the with-transaction macro does? Do you need any more 
information than that to understand the code?

BTW, note that the third line of this example is badly indented. Does 
this make reading the code more difficult?



Here is why I think that Python is successful: it's because it favors 
dynamic approaches over static approaches (wrt type system, and so on). 
I think this is why languages like Ruby, Perl and PHP are also 
successful. Languages like Java, C and C++ are very static, and I am 
convinced that static approaches create more problems than they solve.

It's clear that Python is a very successful language, but I think this 
fact is sometimes attributed to the wrong reasons. I don't think its 
success is based on prettier syntax or uniformity. Neither give you an 
objectively measurable advantage.


Pascal

-- 
Pascal Costanza               University of Bonn
mailto:costanza at web.de        Institute of Computer Science III
http://www.pascalcostanza.de  Römerstr. 164, D-53117 Bonn (Germany)