If there is one thing I'd love to see more here then it's design patterns. Code or architectural, they are important and there's too much noise about code formatting or frameworks and too little material on design patterns.
Small advice though : would be great to break this into a proper series. Each segment, including the history bit could be its own short article. Would make it so much easier to follow (limited time and attention span and all)
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Most design patterns are tied to a given paradigm, language (as the OP said, to workaround language weaknesses, flaws or lack if features) and even outdated in newer versions (e.g. Java supports lambdas since quite a few by now).
You can spend some time learning OOP design patterns, then switch to FP rendering most of them totally unnecessary.
It's not that FP can solve all things with built-in features, as example, side-effects are a pain in pure FP, hence you got monads (which one can agree that are a sort of design pattern in FP).
Despite that, on most of the rest is like... Factory pattern? Here yo got a lambda.
In multi-paradigm languages like JavaScript it's totally absurd to apply design patterns because you can use the best paradigm in each situation, hence using design patterns can be either overengineering or lack of understanding of core language features or programming paradigms.
If there is one thing I'd love to see more here then it's design patterns. Code or architectural, they are important and there's too much noise about code formatting or frameworks and too little material on design patterns.
Small advice though : would be great to break this into a proper series. Each segment, including the history bit could be its own short article. Would make it so much easier to follow (limited time and attention span and all)
Most design patterns are tied to a given paradigm, language (as the OP said, to workaround language weaknesses, flaws or lack if features) and even outdated in newer versions (e.g. Java supports lambdas since quite a few by now).
You can spend some time learning OOP design patterns, then switch to FP rendering most of them totally unnecessary.
It's not that FP can solve all things with built-in features, as example, side-effects are a pain in pure FP, hence you got monads (which one can agree that are a sort of design pattern in FP).
Despite that, on most of the rest is like... Factory pattern? Here yo got a lambda.
In multi-paradigm languages like JavaScript it's totally absurd to apply design patterns because you can use the best paradigm in each situation, hence using design patterns can be either overengineering or lack of understanding of core language features or programming paradigms.
Would be easier to read if was multiple short articles on different design patterns and how to apply them!