Lisp mentality vs. Python mentality

[Ciprian Dorin, Craciun]

On Mon, Apr 27, 2009 at 2:14 AM, Dan Sommers <somm1105 at bellsouth.net> wrote:
> On Sun, 26 Apr 2009 12:30:40 +0300, Ciprian Dorin, Craciun wrote:
>
>> On Sun, Apr 26, 2009 at 12:08 PM, "Martin v. Löwis" <martin at v.loewis.de>
>> wrote:
>
>>> 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.
>
>>> 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...
>
> Also from the Zen:  flat is better than nested.  One of the aspects of
> flatter call trees and object hierarchies is that I hit the bottom
> (language features or the standard library) sooner, and I "should"
> already have the language and its standard library in my brain.  That
> said, I also tend to break my programs into layers, but I do try to make
> each layer as thin as possible (but no thinner).


    I agree with your opinion about keeping the abstraction layers
shallow, but in my view high-order and helper functions do not
comprise a new abstraction layer. For example in Lisp, using map,
reduce (fold), or any other high-order function is just like using
for, or while in a normal imperative language.

    Another example is the simple Observer pattern. How many think of
it as a new layer? Instead anytime we see a method that is named
add_listener we already have an idea of what it does... So we could
say that in FP world there are some patterns that involve "delegating
control" to them.

    And also I would like to point out that "hitting the language
sooner", means to know every function in the standard Python library
(which is by far uncomprehensible, its huge) and most of the times you
also need the documentation. And if we go this path, when debugging we
could use a smart IDE, which should show as tool-tip-text for function
names their documentation, and in this way all we have to do to
understand a particular function is just to point it out.

    Ciprian.


>>     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...
>
> I finally got it through my thick head that I've been *doing* functional
> programming with [*nix] shells and pipes for years, well back into my non-
> guru days.
>
> Dan
>
> --
> Dan Sommers                                   A death spiral goes clock-
> <http://www.tombstonezero.net/dan/>           wise north of the equator.
> Atoms are not things. -- Werner Heisenberg              -- Dilbert's PHB