Why SOLID principles are still the foundation for modern software architecture

The way before and after hooks are applied seems pretty terrible. Imagine doing this everywhere. It's also not a pattern I've ever seen in any FP codebase.

If you need to do something before or after you could just, you know, do it from the callers side. Or wrap the original thing in a new thing which does this. If the only way of composing things is by passing increasingly elaborate callbacks around (have fun with error handling, return early, and so on, from these functions) then I think you really missed a good abstraction level in your code.

Lastly, dependency inversion is actually a pretty big topic in FP languages, especially since they often experiment with effect systems. It's a shame that this paragraph read so anemic.

Honestly this article is exactly the kind of shallow content I've come to expect from this blog.

Hexagonal architecture helps much more than SOLID helps. Applying hexagonal results in SOLID code with much less burden. Why? Because SOLID is all about the S and the S is much easier to grasp in hexagonal then it is in theory. Moreover how can one achieve the S but not the OLID? How can one achoive the O without the LID? It probably takes a lot of effort but they are all very imterconnected.

Why does the language change when demonstating what "modern" solid is. Changing the language also changes a bunch of properties independant of what they are trying to show solid is, unless they are saying you need to use javascript to do modern solid.

Can I do "modern" solid in Java or C# ?