Benefits of moving from Python to Common Lisp?

[Manoj Plakal]

Marco Antoniotti wrote:

> "Morten W. Petersen" <morten at thingamy.net> writes:
> Apart from the existence of very good native compilers, there are a
> number of nice features - all standard - that allow you to use Common
> Lisp as a "language kit": something very few other language are good at.
> 
> Take for example one of the latest additions to Python: list
> comprehension.
> 
> This is essentially incorporating regular set-theoretic notation in
> the language. I.e. to have notation that allows you to say things like
> 
> 	{x | even(x) /\ x >= 0 /\ x <= 100}
> 
> (the set of "numbers" between 0 and 100 - assuming integers or rational,
> this is a finite, enumerable set).
> 
> To get this kind of notation into Python (alas a similar one), AFAIU,
> the (1) parser had to be modified, and (2) the interpreter had to be
> modified as well. This are not things that (AFAIK) where done in
> Python itself.
> 
> In Common Lisp you just changed the "readtable" to recognize the
> special nature of the characters #\{, #\}, #\[, and #\] (think of
> Emacs and what it does with characters) and you write a couple of
> macros.  The code is all written in CL and the above example may be
> rendered as
> 
> 	{x / x in (range 0 100) / (evenp x)}
> 
> This effectively constructs a list of the even integers.  All of this is
> all CL and it is all compiled down to native code. (The above expression
> "expands" into a LOOP, which is happily compiled by the CL system.  The
> code runs on all CL implementations and it can be used to shorten your
> programs.
 

          I'm curious (I haven't done much programming in Lisp).

          Doesn't this make CL programs harder to read? I can see
          why a programmer would love it since it allows you to
          define your own little language that fits your way
          of thinking and a problem domain. I've heard of Lisp
          programmers going gaga over the macro facility.

          But isn't it going to be difficult for someone other
          than the original programmer to come along and try to
          figure out what's going on? They're going to have to absorb
          the macro definitions before trying to read even
          a small part of the code that uses these macros.

          A similar thing happens when
          people go nuts with the C preprocessor or C++
          operator overloading. You get either innocent-looking
          code that actually has very different semantics
          than what you thought, or completely baroque code
          which can only be understood by reading a whole
          lot of other code that is defining macros and stuff.

          How much of a problem is this in practice for CL?

          Manoj