merits of Lisp vs Python

[Jon Harrop]

Kaz Kylheku wrote:
> The removal for the need for manual object lifetime computation does
> not cause a whole class of useful programs to be rejected.

Sometimes you must be able to guarantee that a resource has been disposed
before you can continue. That is why we have finalisers in OCaml and
dispose in .NET (to manage external resources).

> In fact, all previously correct programs continue to work as before,

Removing (external) resource allocation will break some programs.

> and in addition, some hitherto incorrect programs become correct.
> That's an increase in power: new programs are possible without losing
> the old ones.

It is a trade-off. Aside from managing external resources, GC has
performance implications that affect the design decisions of real-time
applications.

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

You can rephrase any impure program as a pure program (Turing).

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

Pure functional programming does not get rid of any programs.

Pure functional programming does get rid of program errors, e.g. concurrency
issues.

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

You have rejected all programs that rely upon a resource being disposed
before a certain point.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet