2008-12-17

Functions And Objects – The State Connection

I'm sure that many of you will disagree with me when I say this, and that's the beauty of opinion: there's always more than one.

If you've read by blog you'll know that I've been leaning towards object-oriented programming of late. With that in mind I'll try to leave my own personal bias out ;).



The universe in which we operate is inherently stateful. This is reflected in the languages that we use to write computer programs. This is simultaneously, the reason that functional programming and object-oriented programming exist… and the reason most people feel they're irreconcilably distinct.

I don't believe this to be the case.

In my not so humble opinion functional and object-oriented programming are as two sides of the same coin, trying to solve the same fundamental problems in opposing ways. While functional programming languages eschew state object-oriented programming languages attempt to make it manageable.

A language without side-effects (and the resulting state) would be pretty useless. In the end both object-oriented programming and functional programming languages are trying to manage the unavoidable!

The difference is in the how.

In object-oriented languages state is encapsulated using objects. In functional languages other approaches are used. Monads can be used to isolate such stateful regions of programs in Haskell.

So how are functional and object-oriented languages that different? There must be larger differences.

Perhaps the biggest difference is in the accepted feature set, but even this isn't as big a difference as it first appears. Many of the features assigned to functional programming have also been present in other paradigms for decades, and are not strictly indicative of the paradigm. Others are not limited to functional programming and may be applied in other paradigms.

Of course, the same can be said about any paradigm, including object-oriented programming.

Note: what many people see as adoption of functional programming through mainstream object-oriented languages is really just the reintroduction of features that were present in some of the first object-oriented languages. Thanks to the increased interest in functional programming! :)

To be clear, I'm not saying that functional programming has nothing to offer. The point of this post was to show that the differences are largely ideological. The disagreement about how state and side-effects should be managed is not a reason for us to fight as intensely as we have been recently.

We should help as much as much as we can. After all, we're going in the same direction.

On the other-hand, maybe I'm wrong?!


If you have any comments, corrections or contributions please feel free to shout.

2 comments:

keithb said...

"Big" Dave Thomas has observed many times that OO an functional programming are duals: one is the other turned inside-out. In OO we start with an environment and then work out what expression to evaluate in it, with functional programming we start with an expression and then work out in what environment to evaluate it.

Meanwhile, encapsulation has been much misunderstood, I think. Really good OO programs in strongly OO languages emphatically do not have loads of Java-style "member variables" floating around getting mutated all the time.

Mark Lee Smith said...

keithb:

I completely agree but should add:

The line between methods and functions becomes blurred to the point of transparency when you introduce multiple-dispatch into an object-oriented language. In these languages you can start with the expression or the environment, or the expression and the environment (as you put it).