Joe, IMHO: Classes in OOP have several purposes, one of which is to manage the mutation of state so as to put a lid on the complexity that could result. The inside of an OOP class is usually a C program, and the outside is (ideally) a semi-functional program with interfaces that are simple at the level of abstraction where they operate. The single responsibility principle exists to stop the C programs getting big and messy, and to help the programmer to build neat layers of abstraction on top of each other by having more abstract classes constructed out of less abstract ones. Functional programming essentially takes the C part away and makes the whole program into a layering of abstractions, even at the lowest level. An FP function more-or-less maps to an OOP class, and the reason why it can be a much lighter-weight structure is because the need to manage mutation has been removed. I think the same principle applies, though - an FP function should have only one responsibility. Perhaps in FP the need for this principle to be explicitly stated and carefully observed is not so great, though. If an FP function does two things and can be split up, it's not such a big deal, because re-factoring is easy in an FP language. By comparison in OOP, splitting a big messy class up is a lot of work with a great risk of breakage. This amplifies the importance of applying the single responsibility principle before you start writing the class. Steve Joe Van Dyk wrote:
So I'm still pretty new to functional programming.
In OOP, you have the concept of each class having a single-responsibility (or reason for changing). See http://en.wikipedia.org/wiki/Single_responsibility_principle
I'm having problems seeing how that concept maps to functional programming. Perhaps it doesn't?