approach to writing functions

[Joe Mason]

In article <40292DAE.FBC3872D at engcorp.com>, Peter Hansen wrote:
> Agreed.  On the other hand, there's *excellent* reasons to write it 
> as three or four functions in the first place, especially if one is
> trying to learn how to write well crafted code.  You can't learn how
> best to make use of "functions" (or any other software construct) by
> just listening to others spout off about it... you gotta try it out 
> yourself (advice to the OP).

I disagree with that, too, actually.  There's a point at which splitting
up into tiny, tiny functions makes it hard to ingest code.  If I want to
track exactly what the program is doing here (spawn 4 procs, read lines
from them, and output the results), it's easier to actually have that in
front of me than to have to dig through a large call tree of nicely
decoupled functions to find each step.  Poorly designed oode leads to
spaghetti, but overdesigned code can lead to the overall system being
harder to learn.

Oops, gotta go - I was going to expand on this but my test seems to have
started spewing data at me, so it's back to work.

Joe