Why don't people like lisp?

[Kenny Tilton]

Lulu of the Lotus-Eaters wrote:

> Kenny Tilton <ktilton at nyc.rr.com> wrote previously:
> |People don't like Lisp because of misconceptions, and threads like that
> |help dispel those.
> 
> In my own mind, the biggest impediment to really liking Lisp is not the
> annoying parentheses and awful syntax... it's many Lispers (especially
> those like Tilton).

So you would charge right out and use Lisp, except you do not like me? 
Hmmmm....

> 
> As soon as I try to learn more by reading discussions, I am bombarded
> with weirdly fanatical (and very long) posts that are overwrought with
> many misrepresentations (e.g.  Python has "Lisp DNA", when pointedly it
> does not by GvR's indication).

I phrased that with a vague metaphor precisely to avoid saying anything 
about Python's history and motivation, about which I am largely 
ignorant. I have no idea where the ideas for garbage collection, 
first-class functions, and a MOP came from, but Peter Norvig, a Python 
fan, writes:

"Basically, Python can be seen as a dialect of Lisp with "traditional" 
syntax (what Lisp people call "infix" or "m-lisp" syntax). One message 
on comp.lang.python said "I never understood why LISP was a good idea 
until I started playing with python." Python supports all of Lisp's 
essential features except macros, and you don't miss macros all that 
much because it does have eval, and operator overloading, and regular 
expression parsing, so you can create custom languages that way."

That's at: http://www.norvig.com/python-lisp.html

Note that Norvig is not saying how Python ended up so close to Lisp, 
just that it has. Me neither/too.


> Not that different Lispers even bother
> with the same misrepresentations--just so long as they are clear that
> programmers of all other languages are ignorant and stupid.

Nonsense. We actually hope a few Pythonistas will come help us build up 
some free libraries for Lisp to solve a weak point for us. We recognize 
Pythonistas as (a) Early Adopters who (b) groove on interactive, 
dynamic, powerful languages.

We are recruiting, not flaming.

> Or tortured threads about things that are only possible in Lisp... but
> as soon as any example is presented, it is obvious that the same thing
> is not only possible, but much easier and more direct, in (some) other
> languages.  

It's funny this never occurred to me, but my own Cells hack uses macros 
big time. Here is a before/after in which I manually macroexpanded the 
code and spliced the output back into where it would have expanded:

Before:

(make-instance 'boiler1
   :temp  (cv 20)
   :status (c? (if (< (temp self) 100)
                   :on :off))
   :vent (c? (ecase (^status)
               (:on :open)
               (:off :closed))))

After:

(make-instance 'boiler1
   :temp  (make-c-variable :value 20)
   :status (make-c-dependent
            :rule (lambda (c &aux (self (c-model c))
                                  (.cache (c-value c)))
                    (if (< (temp self) 100) :on :off)))
   :vent (make-c-dependent
          :rule (lambda (c &aux (self (c-model c))
                                (.cache (c-value c)))
                  (ecase (let ((*synapse-factory* nil))
                           (status self))
                    (:on :open) (:off :closed)))))

Some observations:

(1) This is an extreme case, because Cells is an ambitious hack. But the 
principles are the same for simpler applications

(2) If I did not have macros, I could compress the above 20%, but no more

(3) Expanding the macros exposes implementation details. I use Cells a 
lot, and I refactor a lot. Exposing internals is not just a theoretical 
no-no, I'd be dead.

(4) So as not to overstate my case, I snipped this clause from the 
actual expansion:

       :code '((ecase (let ((*synapse-factory* nil))
                           (status self))
                    (:on :open) (:off :closed)))

That is just plain scary. What I am doing is not only expanding the user 
code into a lambda form, but also generating /this/ code to dynamically 
(at run-time) stuff the code's source (in symbolic form, what the macro 
gets its hands on at compile-time) into a slot in the cell data 
structure to help with debugging at crash-time. (ie, the source level 
debugging on my particular implementation could be a lot better (I just 
learned they are working on it) but I have anyway worked around that 
with macros.

(5) Leaving aside exposed implementation (a fatal problem, mind you) "I 
can do that in Python without macros" is /not/ an objection, unless the 
code comes out as terse as the "before". One thing we Lispniks should 
have emphasized early on is that one thing macros do is compress and 
prettify the code. Surely Pythonistas will acknowledge the value of that.

(6) Paul Graham says it better: http://www.paulgraham.com/onlisp.html

kenny


-- 
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
  http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey