merits of Lisp vs Python

[Paul Rubin]

"Kaz Kylheku" <kkylheku at gmail.com> writes:
> > Incorrect, I believe.  The above is like saying Lisp's lack of
> > optional manual storage allocation and machine pointers makes Lisp
> > less powerful.
> 
> That is true. By itself, that feature makes Lisp less poweful for
> real-world software dev, which is why we have implementation-defined
> escape hatches for that sort of thing.
> ...
> This is a bad analogy to the bondage-and-discipline of purely
> functional languages. [/] The removal for the need for manual object
> lifetime computation does not cause a whole class of useful programs
> to be rejected.

Did you just say two conflicting things?  It's that very rejection
that necessitates the escape hatches.  

> In fact, all previously correct programs continue to work as before,
> and in addition, some hitherto incorrect programs become correct.
> That's an increase in power: new programs are possible without losing
> the old ones.

There's more to power than making more programs possible.  We also
want to be able to distinguish correct programs from incorrect ones.
Lisp has the power to eliminate a large class of pointer-related
errors that are common in C programs, so Lisp is more powerful than C
in that regard.  Increasing the number of programs one can write in
the unfounded hope that they might be correct is just one way to
increase power.  You can sometimes do that by adding features to the
language.  Increasing the number of programs you can write that are
demonstrably free of large classes of errors is another way to
increase power.  You can sometimes do that by REMOVING features.
That's what the Lisp holdouts don't seem to understand.

> Right. GC gets rid of /program errors/. Pure functional programming
> gets rid of /programs/.

GC also gets rid of programs.  There are programs you can write in C
but not in Lisp, like device drivers that poke specific machine
addresses.

> /Pure/ functional programming isn't about adding the feature of
> functional programming. It's about  eliminating other features which
> are not functional programming.

It seems to me that Haskell does some mumbo-jumbo to be purely
functional only in some theoretical sense.  In practice, its purity is
enforced only in functions with a certain class of type signatures
(i.e. most functions).  You can write impure code when needed, by
adding certain monads to the type signature of your function.  The
point is Haskell's static type system can then tell exactly which
parts of your code are pure and which are impure.  If you do something
impure in a funciton with the wrong signature, you get a compile time
error.  You can choose to write in a style that separates pure from
impure functional code in a Lisp program, but the compiler can't check
it for you.  If you get it wrong and call an impure function from your
"pure" code (say in a lock-free concurrent program), all kinds of
obscure bugs can result, like pointer errors in a C program.