Object-Oriented Programming is Bad (2016) [video]

It is perfectly sensible, easier even, to apply DDD concepts to small functional services. Define a bounded context and aggregates. Under the hood (inside the context) there are a number of strategies for handling side effects, data structures, and state transitions.

I'm finding DDD + functional languages + serverless architectures work quite well together, so far.

Good grief.

The reason that OO, FP, functional decomposition, entity relation diagrams, methodology de jure sucks is because modeling is hard.

--

These rules apply to all programming paradigms:

Favor composition over inheritance.

Try to not share state.

Favor dumb objects over active objects.

Favor shorter call stacks, less indirection.

Try to bunch like things together.

Try to DRY.

I really liked the first half - he provides some insightful thoughts on both why OOP doesn't quite deliver on the promise, and why it continues to be popular anyway.

I am also becoming increasingly enamored of procedural programming as a default approach. Functional is also good - it's one of my first loves - but I find that it can be similarly prone to encouraging premature abstraction. Like OOP, that problem isn't going to become so apparent until you start using it in a large, long-lived business system with ever-shifting business requirements.

That said, I think that I've got to part ways with the video around about the part where it switches to talking about how the speaker thinks good code should be structured. Especially the bit about not keeping functions small - the problem with that is, it makes it way too easy for spaghetti code to sneak in. In the same way that, in the heat of the moment, a developer in an OO language is going to start tangling together the connections among objects a bit too liberally, a developer working in a 300-line procedural function is going to start fiddling with any variable that happens to be in scope a bit too liberally. Factoring out your functions does mean you have to name all those functions (which, I realize takes effort, but I also can't agree that it's a waste of effort), but it also serves as a way of making sure everyone stays honest about shared mutable state. Maybe it wouldn't be so bad in a language that has that "nested functions that aren't closures" feature, but, like he says, such a language does not currently exist.

One of the seminal books that people read about object modeling “Domain Driven Design” by Eric Evans writes about “transaction scripts”. Not everything needs to be modeled.

There are two major concerns in software, performance and legibility. These concerns are somewhat orthogonal but neither can be abandoned, and the challenge is balancing them. By contrast in bridge-building (etc.) the two main concerns (performance and aesthetics) have been largely separated by discipline, into engineering and architecture, the former a purely mechanical discipline, the latter almost entirely artistic.

The main result of Modernism has been the subservience of the latter to the former, and in general the almost wholescale abandonment of aesthetic concerns. This is starting to come apart a little bit as people realize that this separation is unhealthy, and maybe we shouldn't build brutal, ugly flyovers through our cities because they have measurable effects on happiness, and thus property values, etc. (i.e., aesthetic concerns have functional consequences).

Similarly I think many software "engineers" take a long time to realize that one of their main functions is writing code that others can read; this is an aesthetic, artistic discipline that I think many developers reject as outside their domain. This, too, is starting to come apart as we slowly figure out that code's maintainability is a key determinant of its long-term success - that is, aesthetic concerns have functional consequences.