Lisp mentality vs. Python mentality

[Carl Banks]

On Apr 26, 5:40 am, Vsevolod <vselo... at gmail.com> wrote:
> On Apr 25, 9:06 am, Carl Banks <pavlovevide... at gmail.com> wrote:
> > Carl Banks, who might be exaggerating
>
> > ...a little.
>
> I think you're exaggerating. Go ask this question in c.l.l and the
> first answer you'll get is mismatch.

What could have made you think I was exaggerating.  Could it be the
line where I said "Carl, Banks who mighe exaggerating"?? :)


> But, from the other point of view your exaggeration makes sense: Lisp
> unlike Python, IMO, is the language, where it's pleasant to program
> not only applications, but the internals as well. So some people may
> find interest in reprogramming what's already there. In lisp
> programmer's mentality it's good to know, that you have that ability.

And yet, the impression I get from Lisp programmers is that they
prefer to program internals.  They will say it's an advantage of Lisp
that their list type is handled with low-level primitives like car,
cdr, and cons, rather than high-level operations like indexing,
appending, etc.  Why would that be an advantage unless they are doing
that kind of stuff all the time?


> And let's look at my recent experience with Python: I wanted to
> implement a daemon process and stumbled at a simplest problem with
> threading: neither Thread, nor Threading module provides thread-
> killing possibility. Surely, I'm not so experienced in Python as in
> Lisp (in which I'd definitely be able to solve this problem by
> extending the library), but I don't see an obvious solution, which
> will stay inside the language: I have to either use the shell or stick
> to the limited set of provided options and skew my program design to
> work with them. Any other suggestions?

Say you are running a thread and you want the power to be able to kill
it at any time.  The thread is either communicating with the rest of
the program periodically, or it isn't.  If it is, then there are ample
opportunities to tell the thread to terminate itself.  If it isn't,
then you might as well use a separate process which you can kill.
Next question.


Carl Banks