Lisp mentality vs. Python mentality

[Scott David Daniels]

Ciprian Dorin, Craciun wrote:
> On Sun, Apr 26, 2009 at 12:08 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>>>     From your comments I understand that the only problem with my code
>>> proposal are the function names...
>> No, the problem is that you are using way too many functions, that do
>> too little. The problem with that is then that you have to give names
>> to all the functions, which then find people difficult to read because
>> they don't just need to the code in question itself; they also need to
>> dozen of helper functions that it relies on.
>>>     And about the find_index, we could rename it to
>>> first_matching_index. About the negation optional parameter, we could
>>> eliminate it if we allow either: to have another function
>>> first_missmatching_index, but this leads to namespace bloat, or we
>>> have a function named negate, that takes another function, and negates
>>> it meaning.
>> Or you could avoid introducing the function altogether, to make it more
>> readable. This makes it more pythonic, also: readability counts (from
>> the Zen of Python).
> 
>     So if I'm reading right you are saying something in the lines:
> "using too many functions is bad just because it is unreadable and
> non-understandable to average (could I say mediocre?) programmers"...
> Unfortunately I thought that delegating responsibilities to other
> functions, and thus writing small chunks of code, is what good
> software engineering is... Well my bad...
>     (As a side-note, maybe this is a reason why some of my students
> find it hard to understand functional programming -- too many
> functions that is -- I shall have to revise my teaching, and tell the
> students to inline everything, maybe they'll understand it like this
> :) )
>     Although you have a point -- that of being hard to comprehend by
> average programmers -- but this doesn't mean it is a wrong (as in
> ugly) solution... Also, with respects, but the "pythonic" solution
> involving generators (or iterators) and "zip" or "all" function --
> although I appreciate it as it comes close to FP -- is not what I
> would call readable and understandable by non-guru programmers...

Writing software is writing for a reader: the maintainer or extender
of the code you are writing.  That that person may be you in three
years is incidental.  You should struggle to write clearly, and take
any clues you can get about how to make the code clearer.  This doesn't
mean you must explain the language; you may assume the reader knows
(or can quickly find in manuals) what any particular language feature
means.  What you must explain is how you are solving the problem at
every point in the code where the code itself does not make that clear.

I don't remember who, but something famously said, in effect:
     Debugging is hard, maybe twice as hard as writing the code in
     the first place.  Unless you are one of those nonexistent few
     who always write correct programs from the word go, you will
     have to debug your own code before it works fully correctly.
     Therefore, you had better write code so simple that you can
     know what is going wrong with it.  If your code is too hard
     to understand for the average programmer, you are either four
     times as brilliant as those "average" programmers or you are
     in big trouble.

--Scott David Daniels
Scott.Daniels at Acm.Org