merits of Lisp vs Python

[Kirk Sluder]

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

> That depends. If somebody smart is designing a new programming language,
> then no, you get a new programming language.
> 
> If somebody not-so-smart is merely hammering the round peg of Lisp into
> the square hole of not-quite-Lisp-and-not-quite-anything-else, then yes,
> that will be a problem. But apparently, despite the talk of using macros
> to implement anything in Lisp, nobody actually does that.

Then what exactly is your argument here?

And BTW:
CL-USER> (defun + (a b))
Lock on package COMMON-LISP violated when setting fdefinition of +.
   [Condition of type SYMBOL-PACKAGE-LOCKED-ERROR]

While lisp doesn't prohibit such name conflicts, it does mean that 
anyone trying it will generate a fair number of errors each time the 
definition is compiled. 

> > 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.  
> 
> I don't know about you, but I'm not talking about VERY restrictive
> languages -- I'm using Python, which isn't very restrictive at all. But
> even Lisp has some restrictions -- you can't jump to an arbitrary memory
> location and treat whatever random bytes are there as executable code, can
> you?

Certainly, and I've even pointed out a few that would mediate 
against your claim of incompetent programmers being able to 
arbitrarily shadow core functions in a way that is invisible to 
anyone else.