merits of Lisp vs Python

[Ken Tilton]

mystilleef wrote:
> Bill Atkins wrote:
> 
>>Are any of these not subjective?
> 
> 
> Objectivity is in the eye of the beholder.
> 
> 
>>Lisp is much more than a functional language.
> 
> 
> Maybe so. But I've only ever appreciated its functional aspects. I
> wouldn't choose Lisp or its derivatives for OO related tasks even if
> I'm high.

But CLOS is the best OO there is. The OMG said so. It can do anything 
any other OO can do. Why /specifically/ would you not use it? This type 
of thread has no educational value unless one is specific; we already 
know what the posters like and prefer, so the only added value comes 
from being specific about language details. And funny put-downs. :)

> 
> 
>>Uh huh.  Can you cite examples of this?  Sounds like you're just
>>making stuff up here.  Contrary to popular belief, writing a Lisp
>>macro that warps your mind and introduces a totally un-CL-like
>>semantics is extremely difficult.  Most of the people who are good
>>enough at CL to do it (I'm certainly not one of them) are also
>>experienced enough to know when it's the right choice.
> 
> 
> Any sizable Lisp applications will make extensive use of macros.

Hopefully, because any sizeable app will have its sum functionality 
compartmentalized into internal little sub-APIs. These five/ten data 
structures and functions have been created to handle this recurring 
problem faced by higher-order functions. Sometimes dealing with that API 
requires boilerplate code to be written. Set things up. Make a call. 
Check the return status for xyz. etc etc. That boilerplate can become a 
macro, such as WITHOUT-C-DEPENDENCY:

(defmacro without-c-dependency (&body body)
   `(let (*call-stack*) , at body))

*CALL-STACK* is internal to Cells and should not be exposed. It is cool 
that all I need do to defeat the entire Cells engine is bind one special 
variable, but maybe someday that will get hairier. if so, no problem, I 
just change the macro. Btw, without special variables, you would need:

  (let ((save-stack *call-stack*)
     (setf *call-stack* nil)
     <your code here, possibly trapping errors>
     (setf *call-stack* save-stack))

If you want to use a function instead of a macro and still hide the 
boilerplate, it would have to be:

   (without-c-dependency (lambda () <your-code-here>))

Not the end of the world and at least one Lisp legend thinks that makes 
macros unnecessary.


> Emacs
> and magic ( the web framework) come to mind. My experience has shown
> that nobody but the person who writes the DSL extension can maintain
> their code.

You and GvR are thinking of the case where a macro is used to create a 
whole new syntax, like LOOP (a mildly controversial part of standard 
Lisp). I have written more macros than you can imagine and only once 
even came close to it (but the language was just a list of things to do, 
nothing incomprehensible). I have never seen a macro which introduced a 
new language.

Of course, we all keep saying this and you all keep repeating the 
opposite, so we do appreciate the excuse to repeatedly explain how 
macros are really used. :)

> The benefits of extending a language in a domain specific
> manner are exaggerated.

Careful, there are laws now against cruelty to straw men.

> My observation is that macros are important to
> Lisp and it's derivative because they lack libraries to begin with.

Damn! Exactly which macro would have saved me creating bindings to 
OpenGL? (I think you have a little category error going here.)

> Common problems solved using macros in Lisp and friends are solved
> using specialized libraries in most other languages.

Damn! Exactly which macro would have saved me creating bindings to 
OpenGL? (I think you have a little category error going here.)

> And I like the
> specialized libraries route. 

Damn! Exactly which macro would have saved me creating bindings to 
OpenGL? (I think you have a little category error going here.)

> Meta-programming just doesn't tickle my
> fancy. It just spells maintainance nightmare.

The whole idea of meta-programming is reducing coding and simplifying 
maintenance, so I have to wonder how much experience you have writing 
macros. Could you post a few?

Macros come into play when we find a pattern in out code that is a level 
more abstract than straight token replacement (ala C) will support. My 
simple example above is just about avoiding typing LAMBDA, which I hate. 
:) More interesting macros take a look at the input source to the acro 
invocation and, instead of subsituting in a fixed template as does the C 
preprocessor, actively assembles template bits and input bits to produce 
the final result.

Of course one has to be clever enough to see higher-order patterns and 
appreciate the vast productivity increase available in return for the 
effort of thinking through a macro -- well, i should note that often I 
do not create the macro until I see also that this bit of internal API 
will be coming up often enough (or will be changing often enough as I 
come to understand it) to make the effort of carving out a macro 
worthwhile -- or, yes, the point of macros will be lost on you.

That's OK. I once knew a guy who cut and pasted code to create tens of 
duplicates rather than create a function. He was not stupid, but clearly 
there was something wrong upstairs. I think to him it was somehow 
"simpler" than getting involved with these complicated function things.

Sound familiar? :)

>>And Lisp environments all support getting the macroexpansion,
>>documentation, and source of any unfamiliar macro you might happen
>>upon, so really this is not as much of a problem as you might
>>fantasize it to be.
> 
> 
> How's this a good thing? I don't need a Python environment to grok
> Python code.

How would that be a bad thing? Do you do a lot of programming without a 
Python environment. But I love the wall of flak you are throwing up. :)


> 
> 
>>I don't agree with a lot of what you say in this paragraph, but I
>>you're right that libraries are crucial.  That's why I wish there were
>>more people writing Lisp libraries instead of being scared away by
>>sheer fabrications like the stuff that's appearing in this thread.
> 
> 
> People only contribute to things they understand and appreciate.

<cough>

> More
> people would be writing Lisp libraries if it was worthwhile.

We are, now that a few application programmers have landed on her 
shores. Most Lispniks are just useless groupie wannabes coding Java all 
day to pay the bills with no energy for programming when they get home.

> Apparently, it doesn't seem to be. A few years ago, I tried to write an
> editor is Scheme. The experience was appalling.

Damn. I wish this was the quarterly Lisp vs Scheme flamewar.

> I was able to write a
> fully functional prototype editor in less than a week in Python.
> Shockingly, at the time, I had no experience in Python. Guess which
> community I was inclined to contribute to afterwards. I hear stories
> similar to mine time and again, yet the Lisp community won't take heed.
> They'd rather squeal about the superiority of macros and whine about
> their frustrations in Python news groups.
> 

You seem to be the unhappy one. We are just here correcting FUD. We are 
ecstatic with Lisp and would not want anyone to miss out on it because 
of your misnformation. No one cares if you try it and decide against or 
do not try it based on good information.

But for someone to miss out on Lisp because of your deliberate 
misrepresentation would be a shame.

ken


-- 
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
    -- Smiling husband to scowling wife, New Yorker cartoon