How Class-based Programming Sucks (2011)

I agree - in my experience object-orientation is at it's best at structuring a representation of the problem domain and functional thinking fits well with solutions. I've written a lot of code over the last few years that models large scale industrial systems and the general style is very much functional processes over immutable objects and this has worked pretty well.

>The thing about [OOP] is that it allows you to model a problem domain in real-world terms.

That's only true on a superficial level. Sure, in CS 101 it's easy to explain how to make a Point object and add a Move() method to it. But dive into any real-world code base and you're more likely to meet RectangleCollectionColorPickerFactory instead. Let's face it, writing a large program is an exercise in abstract symbol manipulation. Trying to make it correspond to "real" objects is about as hopeless as basing literature on coloring books.

Yes. The article correctly points out potential pitfalls of OOP but glosses over its benefits:

> See, mutable state makes shorter English sentences, and the agent concept helps make analogies with our fellow humans. In the end, this first impression trumps the fact that avoiding mutable state where possible ultimately yield simpler programs.

- But shorter English sentences are awesome.

- Good analogies are awesome.

- Effectively communicating with our fellow humans is awesome.

Indeed, all these things contribute to simplicity.

I find that often critiques of OOP are actually critiques of poorly implemented OOP. When it's done well, it can retain many benefits of immutability while still mapping more naturally to domain concepts. This talk by Gary Bernhardt is a great discussion of using functional concepts in OOP, and doing OOP well:

https://www.destroyallsoftware.com/talks/boundaries

The talk "Functional Core, Imperative Shell" is also a must see.

Class-based programming works great for GUI toolkits. In most other contexts, the suitability is variable. OO is a horrible match for compilers, for example.

The article is chasing down the wrong tree when he tries to build an Option type in C++, though. The normal OO way to handle the same class of functionality as ADT sum types is to use separate subclasses. What he's not acknowledging is that OO and functional+ADTs both only handle half the expression problem[1], in different ways. There's no absolute superiority for either model. It depends on the domain.

Less mutability is good almost everywhere though. The lack of persistent data types is a blight on almost all non-functional container libraries.

http://en.wikipedia.org/wiki/Expression_problem

As an aside, my final year project for my CS degree included benchmarking different sets of SK combinators for efficiency as well as looking at different reduction algorithms.

What I found out pretty quickly is that, especially as I was running my code on a mid 80s mini computer, I had to spend as much time on allocation and garbage collection strategies as anything else. Indeed, my only really "difficult" bug was caused by my premature re-use of application nodes - I thought I was being clever re-using them immediately but it caused problems months later when I started writing recursive expressions using the non-native Y-combinator. I had no idea what was causing the problem and was really quite worried, I was stumped for days and then I had a flash of insight from nowhere while sitting on a bus that fixed the problem.