On the difference between functions and objects, FP and OOP, tiny things and big things

gistfile1.txt

"what are functions if not tiny, mostly stateless objects? (Honest question)"

Classic OOP says you should break things down as small as possible. It's better to have 10 classes, each
doing 1 specific thing, then it is to have 1 class doing 10 different things. Methods should be very small.
I've seen guidelines on how many lines your methods should be.

What I've noticed about OO projects that involve lots of tiny classes, is that as the number of classes
increases, it becomes increasingly difficult to keep track of how the system as a whole works, because
there are so many individual components of it. Figuring out how the system performs some task X is a
spelunking expedition, as you need to dig through sometimes dozens of classes before finally finding the
one that you're looking for. Once you've reached the end of the call chain, it's difficult (for me) to keep
that entire call chain in my head, and remember how all of those pieces fit together as you backtrack to
where you started. There's mental overhead for every bit of indirection, and at some threshold, there's
more energy being expended keeping track of the indirection than the actual job of the code.

On one hand, you've gained clarity at the micro-level, where each piece is focused. On the other hand,
you've lost clarity at the macro-level, where now it's not enough to know what each piece does, but you
also have to know how they all work together. Brent Simmons mentions in his article that he's "just
shuffling complexity around rather than reducing it" and that's a sentiment that I identify with.

There's also a tendency with OO systems to create a new kind of object for every task that needs to be
done. You need to do something, you create a class for it, that class has it's own unique public and
private API, its own internal state, etc. Every class is different, and highly specific for what it's
doing. This adds to the mental overhead.

I don't have as much experience with FP as I have with OOP.  My limited experience so far suggests
that the nested function call hierarchy tends to be a bit more shallow, and easier to digest. Rather than
having highly specific objects for each task, you have generic objects like lists and maps, and the
functions you write are how you customize the behavior. There's little (if any) state to keep track of.

On the surface, it sounds like functions and objects are very similar. So far, they feel very
different. It's hard to draw any conclusions about this until I've had a chance to build something a
bit more complex in a functional language.