> 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"...
No, this style is also unreadable to advanced programmers, in particular when you fail to include the functions you use, and leave the reader with guesswork. > 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... You misunderstood indeed. Splitting a large algorithm into smaller parts is good if the original algorithm cannot be easily understood in a single piece. By splitting it, you introduce new abstractions that can help to simplify the original algorithm. OTOH, adding these abstractions also requires the reader to familiarize himself with the abstractions. There is a tradeoff, and the optimum is somewhere in the middle. Splitting code into tiny functions certainly is *not* good software engineering. > 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... Please go back to my formulation - it doesn't use any of this, and I agree that the formulations with zip, generators, etc are indeed more difficult to read (perhaps *precisely* because they come closer to FP). Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
