merits of Lisp vs Python

[Kaz Kylheku]

Paul Rubin wrote:
> Raffael Cavallaro <raffaelcavallaro at pas-d'espam-s'il-vous-plait-mac.com> writes:
> > For example, a common lisp with optional static typing on demand would
> > be strictly more expressive than common lisp. But, take say, haskell;
> > haskell's static typing is not optional (you can work around it, but
> > you have to go out of your way to do so); haskell's pure functional
> > semantics are not optional (again, workarounds possible to a limited
> > extent). This requires you to conceive your problem solution (i.e.,
> > program) within the framework of a particular paradigm. This lock-in
> > to a particular paradigm, however powerful, is what makes any such
> > language strictly less expressive than one with syntactic abstraction
> > over a uniform syntax.
>
> 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.

> It's in fact the absence of those features that lets
> garbage collection work reliably.

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.

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.

Wheas programs can't be made to conform to the pure functional paradigm
by adjusting the semantics of some API function. Programs which don't
conform have to be rejected,

>  Reliable GC gets rid of a large and
> important class of program errors and makes possible programming in a
> style that relies on it.

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

> You can make languages more powerful by removing features as well as by adding them.

Note that changing the storage liberation request from an imperative to
a hint isn't the removal of a feature. It's the /addition/ of a
feature. The new feature is that objects can still be reliably used
after the implementation was advised by the program that they are no
longer needed. Programs which do this are no longer buggy. Another new
feature is that programs can fail to advise the implementation that
some objects are no longer needed, without causing a leak, so these
programs are no longer buggy. The pool of non-buggy programs has
increased without anything being rejected.

Okay, that is not quite true, which brings me back to my very first
point. GC does (effectively) reject programs which do nasty things with
pointers. For instance, hiding pointers from being visible to GC.
However, such things can be made to coexist with GC. GC and non-GC
stuff /can/ and does, for pragmatic reasons, live in the same image.

Likewise, functional programming and imperative programming can also
coexist in the same image.

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