merits of Lisp vs Python

[Slawomir Nowaczyk]

On Tue, 12 Dec 2006 10:30:40 -0700
Robert Uhl <eadmund42 at NOSPAMgmail.com> wrote:

#> Imagine if one could write this in Python:
#> 
#>   defsyntax unless(condition, commands):
#>     if not condition:
#>       commands
#> 
#> And use it like this:
#> 
#>   unless day == 'Sunday':
#>     work()
#> 
#> That'd be pretty cool, right?

Left... What is cool in this?

Sure, I love "unless" in Lisp, where it save me a whole one pair of
parentheses, but in Python both of those are equally readable

if not day == 'Sunday'
unless day == 'Sunday'

and the first one is standard, while the second is not.

#> As mentioned above, macros can make one's life significantly nicer.

Sure. I sometimes (when writing code) wish we had macros in Python. I do
know they can be useful. But then, when reading code, I am actually glad
we do not have them. Their benefits in a language like Python would
hardly pay off.

#> Wouldn't it be nice to have a macro with-open-file?
#> 
#>   filefor line in path:
#>           foo(line)
#>           bar(line)
#>           baz(line)

Not really. *If* this code bothers you, just do

def with-open-file(path,fun):
    file = open(path,"r")
    for line in file:
        fun(line)
    file.close()

def handle-line(line):
    foo(line)
    bar(line)
    baz(line)

with-open-file("path",handle-line)

Sure, it takes some time to get used to this, and at the beginning you
really miss full-blown lambda, but it does have its own benefits.

#> o Speed
#> 
#> Lisp interpreters are several orders of magnitude faster than Python,
#> and Lisp compilers are faster yet. Speed's not the most important
#> thing, but it is _an_ important thing; all other things being equal,
#> the faster solution is better.

Sure. But in 20-30 years, Python might get there.

#> o Symbols
#> 
#> In Lisp, a symbol is essentially a hashed string; two symbols are alike
#> if their names are alike, but comparison of symbols is a constant-time
#> operation.  Thus where in Python I have lots of string comparisons for
#> constants, and in C I have #defined integers, in Lisp I have symbols.
#> It's not just a performance hack--symbols are part of why macros and
#> packages work--but when I miss them, I miss them for the performance
#> side of things

Well, you could fake symbols for most of the typical uses pretty
easily... It won't look as good as it does in Lisp, but it will solve
most problems.

OTOH, if dictionary of strings is too slow, than maybe you are not using
the right tool.

#> o CLOS
#> 
#> The Common Lisp Object System is a really remarkable piece of work.
#> Among other things, it has generic functions instead of methods. E.g.
#> in Python or most other OO languages object.method(arg1, arg2) is
#> really just a fancy piece of syntactic sugar for method(object, arg1,
#> arg2); method does different things depending on the type of object,
#> its first argument.
#> 
#> Wouldn't it be nice to be able to specialise a method on _any_ subset
#> of its arguments, not just its first one? Well, CLOS offers that.
#> (method object1 object2) could be specialised on the first argument,
#> the second or both. This can be very powerful.

There are modules for Python offering exactly that.

However, the Pythonic solution is not to rely on types too much anyway,
in the first place.

#> Wouldn't it be nice to specify that some action be taken before or
#> after a superclass's method, rather than over-riding that method
#> entirely? Sure, one can over-ride the method and then call it within
#> one's own code, but that obscures the meaning of what one's doing.

You can easily create a decorator which will do just that. I suppose you
could also create a metaclass which would do that, but it's too late for
me to be sure ;)

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( Slawomir.Nowaczyk at cs.lth.se )

The nice thing about standards is that there are so
many of them to choose from.