On Apr 25, 2:06 am, Carl Banks 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!'
--
http://mail.python.org/mailman/listinfo/python-list
