Exactly. You can just as easily learn cargo cult programming from a book. Design Patterns anyone?

I mean, they're great when applied correctly, but someone looking specifically to apply design patterns will often end up CCPing.

Just read:

- Clean Architecture
- Design Patterns: Elements of Reusable Object-Oriented Software
- Domain-Driven Design: Tackling Complexity in the Heart of Software
- Clean Agile

and forget the rest. Life is short and those books are more than enough.

> I've purchased three OOP books (in the order I've read them): ...

If your gonna pick three books on OOP it should include Design Patterns at the top of the list. At least if you want to understand why OO is a thing people still use and talk about.

I don't think those are the same "problems". "Design patterns" is about code, not solving business problems. To stay in the well known books in OOP, DDD would be about solving business problems.

Yes, function composition is one kind of glue, and it's good that we have it. But it's only one kind of glue, and often not particularly useful (see the part of the post about algorithm DSLs).

As John Hughes put it in Why Functional Programming Matters, we need more kinds of glue.

See https://blog.metaobject.com/2019/02/why-architecture-oriente...

As to Design Patterns: the Smalltalk version of the Design Patterns book is a small booklet, most of the patterns just go away. As to the video: tried to watch, got to the "it's functions, functions functions and again functions" slide. For OO, it would be "it's objects, objects, objects and again, objects". Sadly, most FP-centered critiques of OO are at this level, or even worse. :-/

Overall, you're going to have more patterns in FP because its model of computation is less powerful. (See Concepts, Techniques, and Models of Computer Programming https://www.info.ucl.ac.be/~pvr/book.html for a definition of relative power ).

I thing the big difference is that software is gradually becoming more declarative. It's less about coding how it does things, more about coding what it is doing. This has been the flow for many decades, but it's more common now than 5 years ago.

Something like React is the norm now. It's not necessarily any simpler or faster, but it's more efficient past N hours, which is the case for many larger companies.

It's also why functional programming has regained popularity, or at least writing functions the way you would for functional (immutable, output of one is the input of another).

However, we're still using a lot of old techniques. The best book on Design Patterns was written in 1997. Pragmatic Programmer was written in 1999 (though revisited a few years ago). The best TDD book is still from 2002; a lot of modern takes on TDD gets the philosophy completely wrong. TDD was meant to reduce fear, not improve test coverage.

It actually was a problem.

From the article:

> In his book on Business Object Notation, Bertrand Meyer lists twenty-six competing methods. I remember reading documents that listed over fifty, but I can’t seem to find them again so it might be a false memory.

I also distinctly remember how difficult it was to learn from other's designs. Back then, there was no Stack Overflow or Google. Developers like me obsessed over the latest books (like this new Design Patterns book, have you heard about it?!?)

It isn't a problem today because that's not how design ideas get communicated anymore. You have blog posts, and GitHub repos with examples and Markdown. This is better. But in the mid to late 90s, UML really helped.

Disclaimer: I was on many of those OMG committees for Model Driven Architecture and UML back in its heyday. I've also sat in Sushi restaurants after conference proceedings during dinner with some of the people mentioned in the article. The talk was of how we were going to change the industry. I smile to think of how things moved on without our dreams. :)