Functional Programming Guidelines a la SOLID?

The recent kerfuffle between “Uncle Bob” Martin and Joel Spolsky involves the SOLID Principles,some object-oriented design guidelines that compress into a pleasing acronym.

While there are weaknesses in the mainstream OOP languages, I believe that OOP has a great advantage in that it is teachable. You can start with “objects are nouns, methods are verbs,” draw some class diagrams, and move on to SOLID… all of which could be criticized as overly abstract and ungrounded in the business of turning inputs into outputs, but y’know, darn it, there are teachable principles.

Functional programming fits well with test-driven approaches to development and provides some guidance on concurrency issues. In the Jolt Judges discussions this year, nothing has engendered as much discussion as Haskell and Scala.

But from a pedagogical standpoint, I think that functional programming has a big problem. To the extent that you get anything in terms of principles, it’s mathematical category theory. How do you determine when a function is too big? When should you split a data structure into sub-structures? How can you tell a well-thought-out function from a poorly-thought-out one?

Functional programming needs answers to these types of questions and those answers can’t be of the “once you understand it, you’ll develop a feel for it,” ilk.