merits of Lisp vs Python

[Kirk Sluder]

In article 
<pan.2006.12.10.02.04.02.652133 at REMOVE.THIS.cybersource.com.au>,
 Steven D'Aprano <steve at REMOVE.THIS.cybersource.com.au> wrote:

> On Sat, 09 Dec 2006 21:55:19 +0000, Kirk Sluder wrote:
> 
> Who says they do? All forms of abstraction have been criticized. Sometimes
> the criticism is valid. Sometimes it warns against abuses of the
> abstraction. Just because a feature is useful sometimes doesn't
> necessarily mean the benefit outweighs the cost.

The primary focus of the criticism in this discussion has been that 
macros are a bad from of abstraction compared to libraries, (and I'm 
admittedly extending that to objects, functions and classes.)

> But at least you know that foolib is a module or package. You know what
> from and import do, and that can't change. And you know that bar is an
> object with a method also called bar, it is being called, and the
> argument is a string "somefile". Those things can't change. Imagine a
> hypothetical language where those two lines could mean *anything*.

But as was pointed out earlier in the thread, those keywords can be 
overshadowed by custom functions in python as well. The only reason 
that we don't assume those two python lines could mean *anything* is 
because those mechanisms are not well advertised, and most people 
don't have a need to shadow "import."

Of course, it is possible to abstract away all of the lisp in such a 
way that you have a completely new programming language. But is this 
really a problem? Perl5 and bash are abstractions of C. Python has 
been implemented on both C and java, and chunks of perl6 have been 
implemented on top of Haskell.  Completely new programming languages 
and frameworks develop their own base of knowledge and expertise 
separate from the parent language.

> My point isn't whether or not their claims are correct (a "couple" of
> macros? really?) but that things like this feed the perception that Lisp
> is close to that hypothetical language where anything could be anything.
> If anything could be anything, do you really know what (+ 1 2) means
> without reading every line of code?

How do you know that operator has not been shadowed or overloaded in 
python?  In most cases what you have to do is trust both the 
underlying implementation, and the author(s) of the libraries you 
use.

Both python and lisp share mechanisms to protect namespaces is part 
of the answer. So one way to protect myself is to run my code in 
it's own namespace, and require explicit addressing of imported 
functions and constructs. In this way I can be pretty certain that 
(+ 1 2) uses the lisp primitives, and has not been shadowed, while 
(SOMEPACKAGE:+ 1 2) should be treated with suspicion.

The process of writing lisp often involves access to the REPL, so I 
can have lisp expand the definition of any expression: 
CL-USER> (macroexpand '(+ 1 2))
(+ 1 2)
NIL
CL-USER> (macroexpand '(loop for i upto 100 collect i))
(BLOCK NIL
   ...<expansion snipped for brevity>...
)
T
CL-USER> 

This tells me that + is not a macro in my current environment. While 
loop is.

And at least one of the powerful aspects of lisp is than since lisp 
programs are nested stets of s-expressions, you can design something 
that walks through the code and highlights all macro calls, and 
foreign functions that shadow native functions. I don't how 
difficult this would be for languages such as python.

... extended argument snipped ...

> Or maybe it is only an advantage while Lisp programmers are a
> self-selected group of above-average skill. Wait until fifty million VB
> code monkeys start writing Lisp macros and maybe, just maybe, you'll wish
> they were using a less powerful and more restrictive language.

Perhaps it's because I'm a social scientist and not a programmer by 
training, but I find many arguments for *technical* solutions to 
*human performance* problems to be rather weak as a general 
practice.  In some cases, using a very restrictive language may be 
the best solution for the problem.  However, there are plenty of 
other ways around the problem that can be tailored to special needs.

In addition to sandboxing macros into packages and walking the code 
to detect macros, you could run a custom lisp image that does not 
permit DEFMACRO or enforces documentation on DEFMACRO. Or you could 
rely on social mechanisms like only using libraries from trusted 
sources, and better training of those code monkeys.