merits of Lisp vs Python

[Jon Harrop]

Raffael Cavallaro wrote:
> On 2006-12-17 07:54:28 -0500, Jon Harrop <jon at ffconsultancy.com> said:
>> What if eager impurity isn't the "very nature" of the problem but,
>> rather, is the very nature of Tilton's chosen solution?
> 
> That's the whole point which you keep missing - that a programming
> language is expressive precisely to the extent that it allows you to
> express the solution in the *programmer's* chosen form, not the
> paradigm imposed by the language.

That is the ideal, yes.

In practice, different languages encourage you to use different solutions.
For example, when faced with a problem best solved using pattern matching
in Lisp, most Lisp programmers would reinvent an ad-hoc, informally
specified and bug-ridden pattern matcher of their own. Do you not think
that Lispers typically "compile" their high-level algorithms into low-level
Lisp constructs like COND or IF?

> You look down your nose at cells, but if that's the way kenny conceived
> of the problem - as a graph of changing state, why should he be forced
> to reconceptualize it according to someone else's notion of programming
> correctness (be that pure functional or any other paradigm)?

Kenny isn't being forced to do anything.

> By asking this question you've implicitly admitted that to solve it *as
> he thought of it* in a pure functional language would require
> reconceptualizing it (i.e., the aforementioned "jumping through
> hoops").

You are saying that solving it as he solved it requires a different
solution. How does that make Lisp any different to the next language?

> We don't want to reconceptualize everything according to a 
> particular paradigm, we want the flexibility to write the solution to
> the problem in the terms we think and talk about it, not the
> procrustean bed of pure functional semantics.

Of the programming paradigms that can be implemented in Lisp, Lisp doesn't
exactly make them easy. Moreover, every time you pick a random Lisp library
off the wall to implement some feature already found in most other
languages, you fragment the already tiny user base into even fewer people.

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