I think this problem may be while I enjoy functional programming so much. I believe that the functional programming tends to build from the data up, from the a

I think this problem may be while I enjoy functional programming so much. I believe that the functional programming tends to build from the data up, from the actual instances it then adds definitions of behavior, instead of trying to group behaviors and fit the various arrangements of data in that hierarchy. Usually you start with some data. It might be some loose tuple in a dynamic language like erlang, or an algebraic data type in a language like Haskell (not that there are many like it). It's like saying, I have a Cat or I have a Bat. You haven't said anything about the two yet other than that they are different. You could then add more information, such as the number of legs or color. You add behavior by defining functions that can act on that data and create changes from them. For example, two cats can reproduce, so you define a function that takes two Cats and makes a kitten (new Cat). Bats might also reproduce, so you can write the function more generally to take any two data objects that have the minimum prerequisites (such as identical internal representations) and produces a new one that's a combination. When a new data type is needed, you simply add it and it automatically gains all this functionality based on its form. Essentially, OOP seems to want to start from the behaviors and have that define the data. When writing functionally I tend to define the data, then build behavior on top of it which is driven more by the form of the data than any idealized class hierarchy. I'm not sure I'm explaining this terribly lucidly, but hopefully this can start a discussion among the more articulate posters.