For a while now a number of people myself included (but my opinion has shifted slightly) have lamented the state of OOP, not the idea itself but rather how it, for the most part, is often interpreted which usually results in poorly constructed, monolithic and messy applications that nobody enjoys working on.

Though created with the best of intentions to fix perceived failings in the language or paradigm, the huge range of design patterns which was supposed to help the developer create loosely coupled, easy to maintain code has in reality contributed to the complexity, piling abstraction on top of abstraction and adding to the cognitive overload of the already burdened software developer.

It seems though that for some the tide is slowly turning. Functional languages, once the preserve of academia, now appear to be looming on the horizon for many software development shops as the next silver bullet to get them out of the hole they currently find themselves in.

For a while, I was there. I started to embrace the functional paradigm. I briefly played with Scala, then, as a natural progression for a C# developer, I focused on F# and I do like it but I quickly realised that whilst the paradigm and syntax may be vastly different, in the words of Led Zeppelin, the song remains the same.

I see functional programming as more complex and less well understood than OO. I can easily envisage the code -bases that will come of this movement in typical enterprise shops and the result won't be pretty. The terse syntax and more abstract concepts that can result in some very hard to read code will make things worse not better, especially in the hands of the journeymen programmers who don't see it as a craft. I dread to think of the "clever" code they'll come up with. Some of us will have to pick up the pieces.

It's often said that whilst we can't avoid essential complexity, we should certainly strive to avoid accidental complexity in our code. Apply that maxim to our programming languages and tools and you might say we've failed completely. Whether it be OO and a multitude of frameworks and patterns, or functional programming and its often more complex syntax and concepts and I think it's fair to say that neither paradigm does much to help stop us from shooting ourselves in the foot. In years to come we may well be hearing the same moans and gripes about functional code-bases that we hear today about OO and then, once again, we'll be looking for the next big thing to get us out of the mess we're in.

I guess what I'm trying to say is that just because we may feel that OO is broken, we shouldn't automatically assume that functional is the answer. Functional is a shift sideways into uncharted waters for a lot of shops with no guarantee things will be better. No language or paradigm can solve all the problems caused by us, the developers. It may well do some things better or easier than OO but before jumping ship we need to get better at simplifying our existing code and resisting the urge to over-engineer. Less abstraction, fewer frameworks, and some common sense might just be enough to get things back on track. And if we can't manage that in languages and paradigms we know well, what chance do we stand in those we don't?