Why don't people like lisp?

[Marco Antoniotti]

Andrew Dalke wrote:
> Marco Antoniotti:
> 
>>Yes.  The point is that you can do that in CL easily.  Not so in Python.
> 
> 
> But, but, but, ... I do it all the time in Python.
> 
> 
>>cl-prompt> (symbolp '|1-1'-(ethylenediimino)di-2-proponal|)
>>T
> 
> 
> Again, that's forcing the domain language to fit the requirements
> of the implementation language.  It's a shortcut, and requires the
> domain experts to have more knowledge of the implementation
> and means the domain language cannot be reimplemented outside
> of a Lisp environment.  (Yes, I know, why would you want to.
> Answer: because that's the way life is.)
> 
> 
>>In Python there is no equivalent AFAIK, in Java you can to
> 
> 
> Indeed.  In Python I wouldn't translate such a system directly
> into Python.  Eg, I would write an emulator for that language
> in Python, or my translation would do some munging for me.
> 
> 
>>This is just a few reader macros away (and the use of the INFIX package).
>>
>>In Python, you always have to com up with you full fledged parser.
> 
> 
> You use reader macros for that.  I use parser generators.  You
> cheat by storing the domain language directly as s-exps, I cheat
> by storing the domain language in native Python data structures.
> I fail to see a fundamental difference.

You fail to see the point because your objective is to show that there 
are tasks that are equally difficult in either Python or Common Lisp.

If you have to write a parser for a any language (say Ada 9x, just for 
the heck of it), then obviously you have to resort to the full parse 
toolchain (tokenizer, AST constructor etc etc).  It does not matter if 
you use INTERCAL or Python.

But, and here your argument does not hold, in Common Lisp you have an 
extra trick up your sleeve.  You can make your "domain language" S-expr 
based (instead of inventing an XML format :) ).  This is *in addition* 
to what you can achieve with Python or other languages.  And this 
*addition* makes CL more powerful.  Not only that.  With reader macros, 
CL has even more flexibility for achieving these effects.  So, yes, it 
is a trick.  It is a trick that makes the language more usable.

> 
> The point of my exercise was to show that such a task is
> not hard in Python.  Yes, it's about twice as long as the Lisp
> code - this is a place where Lisp shines,

Yes.  The CL code also compiles down to fast native code (how close is 
Psyco to ECL?).  Another place where Common Lisp shines.  Especially 
when you have to do numerical computations.

Cheers
--
Marco