One of my goals this winter is to clear my head of as much OOP dogma as I comfortably can, fill it with as much DevEx thinking as possible, and read Christopher Alexander, A Pattern Language, from that frame of reference.

My very hot take is that we will start referring to everyone who bought first editions of the Design Patterns book as the Lost Generation, because we have completely misinterpreted Alexander's work, as it could apply to software.

I usually recommend "Designing Elixir Systems with OTP: Write Highly Scalable, Self-Healing Software with Layers" (2019 James Edward Gray, II, Bruce A. Tate)

One may also find it interesting how Elixir/Phoenix-framework uses the OTP to greatly simplify implementation. =)

I think the missed or perhaps unspoken observation in this thread is that if the language provides it, and you're using it, you're tying yourself to the language, which tends to last a lot longer than frameworks.

Switching languages obviously requires a rewrite. But you aren't also rewriting the framework integration too. Some languages have work-alike frameworks, but they aren't ever exactly the same behavior and semantics. There are always subtle but important differences.

A clean pattern does not emerge naturally with a polyglot stack, as multiple languages with many library dependencies only lead to maintenance issues, duplicated code, and kludges.

I guess my point was that while it is sometimes necessary to pipe messages though multiple languages & platforms under special circumstances (see BSON over AMQP post above alluding to decomposing multiple hardware-dependent programs/codecs into a standardized cluster API.) In general, it is cleaner to have a simple distributed framework that hides the fact it is _not_ a monolith from _most_ developers.

We can agree to disagree on this matter, as everyone's use-case differs. =)

I’ve read the original and was underwhelmed from a software epiphany standpoint. Design patterns are just names for deliberate design decisions, so you can communicate them to others who can then deliberately make those decisions themselves. Half the industry still seems to think the GoF book is about C++ not having first class functions.

The problem is that they are milquetoast. They are “design decisions” in the same way that white space is technically code style but really distracts from the real elements of style like structure and meaning (don’t create three meanings for the same word, for example).

Architecture is much bigger than making sure the doors open the correct direction.

Well, there are many collections of patterns, GoF doesn't claim to be exhaustive. Enterprise Integration Patterns is more high level, for example. But for everyone who hand waves away something like the Strategy pattern as trivial, I have to work with a dozen libraries which accept a massive dictionary of static options to configure their behaviour instead of allowing me to choose an arbitrary, dynamic policy at runtime. I don't think that's a conscious design decision on behalf of most API developers. I suspect it's because the industry largely received the original GoF book as a bunch of cut and pasteable code and later rejected it as symptomatic of Java-esque OO excess. We could instead have received it as a network of signposts telling us what's possible, when and why. Not earth-shattering stuff (neither is Christopher Alexander's original) but useful nonetheless.

I think, wrapping an api or a few methods is okay. But wrapping a whole platform/framework is just wtf.

I had seen someone decided to wrap a simple pixi.js project with a whole mvp framework and tons of command / facade / proxy patterns to make it like a oop program. So I hate it.

I heard it's wrote by a c# guy picked up for the project because no one had time to do so I could probably understand why. But, damn. It's so painful to read.