Object Oriented vs Functional

I'll start this off with the caveat that I have not had much personal experience with functional languages, so take what I say with a grain or so of salt.

One of the things that I liked about this paper was that they clearly laid out everything that could immediately be considered wrong with it at the beginning. That they would acknowledge the small sample size, author bias, and other factors like that is very nice to see because it allows me the ability to immediately start adjusting my expectations to compensate. Seeking another source to help offset that is also a welcome touch.

The main advantage, which was talked about in the Emacs paper, and from what I've seen from systems built using functional languages is that because everything has been deconstructed to small modules and functions extending the functionality is a very quick process. Everything you need is typically there in that function call, so it is up to you to do what you'd like to the output to get at your own needs. This seemed to be the strength of the Emacs construction, which demonstrated the power and flexibility of that approach. But the issue for me is that this same power and flexibility can make maintaining a hierarchy much more difficult since developers get the access they want to the functions they want where ever they want them. With and object-oriented system you can set up interfaces, scopes, and inheritance patterns so that extending functionality can be done relatively painlessly, but still maintain the control over component access. Of course, as we spent the whole first portion of this course saying that if you're going that route you better have a good architect so the system doesn't become prohibitively complex or pointlessly over-layered.

When it comes to designing and your languages impact it seems that the purpose of the language drives the focus of your efforts. Functional languages naturally build from small problems into larger ones, so the breakdown of problems into small tasks is going to be the guiding force behind your construction architecture. Care will have to spent (as this article discussed) in making sure that the tasks can work in such a way that the problem you're abstracting still gets solved with enough generality that it is useful and reusable. Whereas the way we're taught to approach object-oriented software design is to breakdown the problem space into nouns and model those first, then their interactions. So we arrive in roughly the same location, it's just a matter of if we're concentrating on "bake pudding" or "bake pudding".

One nice feature of functional languages is that since the concentration is on breaking a problem down into small methods that each solve an individual part of the problem it should not be too difficult to start separating independant sections of the problems into tasks that can be shipped off to different processors.

@Randy Blamo: Fruit Salad

Yummy yummy