Lisp mentality vs. Python mentality

[anonymous.c.lisper at gmail.com]

On Apr 25, 2: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.

(equal a b) or (equalp a b)

Next question??

I understand where you are going with the analogy, but I think a lot
of what you describe as 'over-thinking' of the problem in lisp comes
from people having an honest desire to answer the /right/ question.

Lisp gives you a bit of granularity with regard to certain things
(like comparison), that in many languages amount to a single '=='
operator. I /believe/ that this is because of its origins in symbolic
programming.

You don't compare numeric functions in Perl and C, and then say 'Oh
those silly C programmers over-thinking things, they must have 10
different types of numbers!'