Ciprian Dorin, Craciun wrote:
On Sun, Apr 26, 2009 at 12:08 PM, "Martin v. Löwis" <mar...@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.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list
