merits of Lisp vs Python

[Steven D'Aprano]

On Sun, 10 Dec 2006 03:37:26 +0000, Kirk Sluder wrote:

>> 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.

Really?

>>> def import():
  File "<stdin>", line 1
    def import():
             ^
SyntaxError: invalid syntax


Nope, can't shadow or change keywords. (And yes, the error message could
be better.)


> 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."

Or because they can't mean just anything.


> 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.

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.


>> 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?

Because the tokens 1 and 2 cannot be anything but ints, and + with two
int args cannot be anything but addition.


>> 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.  

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?


-- 
Steven.