Lisp mentality vs. Python mentality

[Vsevolod]

On Apr 25, 9:06 am, Carl Banks <pavlovevide... at gmail.com> wrote:
> In answering the recent question by Mark Tarver, I think I finally hit
> on why Lisp programmers are the way they are (in particular, why they
> are often so hostile to the "There should only be one obvious way to
> do it" Zen).
>
> Say you put this task to a Lisp and a Python programmer: Come up with
> a good, generic, reusable way to compare two lists.  What are their
> respective trains of thought?
>
> Lisp programmer:
>
> Well, there is a standard function called mismatch that does it, but I
> can't recommend it.  First of all, you don't know where that
> function's been.  Anyone and their mother could have worked on it, did
> they have good, sound programming practice in mind when they wrote
> it?  Of course not.  Let's be real here, we have to implement this by
> hand.
>
> (defun lists-are-equal (a b)
>    (or (and (not a) (not b))
>        (and (= (car a) (car b)) (lists-are-equal (cdr a) (cdr b))))
>
> There, much better than the standard function, and better yet, it's in
> the *absolute minimal form possible*.  There is no way to express list
> comparison in a more reduced form.  It's almost erotic how awesome it
> is.  I'm---whoa, ok, I'm getting a little excited now, settle down.
> Well, come to think of it, that's really not that good.  First of all
> it's a function.  I mean, it just sits there and does nothing till you
> call it.  How boring is that?  It can't react to the current
> situation.  Plus it compares all lists the same way, and that is
> really inefficient.  Every list compare is a new problem.  Different
> lists need different comparative strategies.  This function simply
> won't do.  I need a macro that can intelligently compile the right
> list compare methodology in.  For instance, if we want to compare two
> lists that are known at compile time, we don't want to waste time
> comparing them at runtime.  No, the macro must detect constant
> arguments and special case them.  Good start.  Now, we have to
> consider the conditions this comparison is being done under.  If the
> user is passing the result of a sort to this macro, it's almost
> certain that they are trying to see whether the lists have the same
> elements.  We can do that a lot more efficiently with a countset.  So
> let's have the macro check to see if the forms passed to it are all
> sort calls.  Better yet, let's check for my own powerful sort macro.
> Hmm.  Wait... I think my 4600-line sort macro already checks its
> calling context to see if its results are being fed to a list
> comparison.  I'll have to refactor that together with this macro.  Ok,
> good, now I am sure other users will eventually want to customize list
> comparison for their own use, after all every list comparison is
> different and I can't possibly anticipate all of them.  A user needs
> to be able to adapt to the situation, so it's vitally important to
> create a plug-in infrastructure to give them that flexibility.  Now,
> what about exceptions, there's a millions ways to deal with that...
>
> ...and so on until eyelids can no longer stay open....
>
> Python programmer:
>
> a == b.  Next question.
>
> 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.
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 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?

P.S. Btw the other issue with CL's mismatch is that it provides a
possibility to use any test and keyword extraction function.

Best regards,
Vsevolod Dyomkin