merits of Lisp vs Python

[Raffael Cavallaro]

On 2006-12-17 12:49:46 -0500, Jon Harrop <jon at ffconsultancy.com> said:

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

No, I think most of us would use an exising lisp pattern matcher, like 
cl-unification.


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

Give kenny some credit for not being a complete idiot. Cells was 
originally designed to keep UI elements in sync with an internal 
application model. The UI domain is I/O, i.e., a side effect. To do 
this lazily invites situations where an inherently unpredictable user 
action forces a complex series of constraints to be computed before 
anything can be displayed to the user, so the user must wait while the 
lazy system catches up. To do this eagerly means that at any time, any 
unpredictable user action will cause already computed state to be 
displayed, because everything has been kept up to date automatically 
all along.

I'm saying that he conceived of the problem in the most natural way - 
state with mutations - and implemented it that way. He was not forced 
by his language to reconceive it purely functionally, have haskell 
implement the default lazy semantics, only to require the programmer to 
find an escape hatch from this default laziness since what he really 
wants is eager evaluation of side effects (i.e., I/O - syncing of model 
state with GUI display).

People habitually think of the world as state and mutations of state. 
We've been doing so for a minimum of tens of thousands of years, quite 
possibly a million or more. People are good at thinking about mutation. 
Maybe this should tell us something about the desirability of certain 
programming language semantics and that referential transparency is a 
bit overrated.

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

Not all lisp programmers will be solving the same sorts of problems as 
each other, so naturally they'll be using different sets of libraries. 
This use of different sets of libraries for different tasks doesn't 
constitute laguage fragmentation.