Functional OO

Let me preface this by saying that my only foray into functional programming has been through a languages & compilers course as an undergrad, so my experiences are limited.

I feel that this chapter was quite heavily biased towards OO techniques, but though it certainly colored the conclusions drawn, I find it neither inaccurate nor particularly unfair.  The problem domain clearly emphasized structure over compact expressiveness, so within this problem domain, OO has a clear advantage.  Functional languages excel at expressing a fixed set of computation in a certain way, as well as extension through substitutability of chunks of functionality.  Functional languages benefit from a reduced set of ways to express some piece of computation.  Whereas in OO, there are structural decisions that affect how a system will be composed, there are fewer such decisions in functional languages, leading to more unified conventions.

The aforementioned structural decisions in OO are, however, one of its greatest advantages.  By encoding a great deal of the problem domain knowledge into the structure, the programmer can plan for future expansion and enforce a much stronger separation of concerns.  In my opinion, OO is a better technique for any problem domain dealing with data, behavior, and variations of these.

While functional languages gain the benefit of mathematical models which automatically facilitate a certain amount of architectural reasoning, OO benefits from the experience of the rest of the world, in that it can be used to more closely model real world things and scenarios.