Let me tell you a secret; Design patterns are the natural consequences of programming idioms and paradigms that are so inferior that it's impossible to create working code without them. Design patterns are like wheel chairs, they're trying to fix that which is already broken. A piece of advice, if you can of course, try to rather avoid getting into a wheel chair in the first place (read; Use OOP that is) - Than to run to the wheel chair arguably the same way junior software developers are running to OOP these days ...

A really great programming language doesn't need design patterns in fact. This is true to the extent of that I once saw a super senior developer going through all the original 23 design patterns from the Gang of Four, and proved how 19 of them made absolutely no sense what so ever for Lisp, which we all know is a far superior programming language than any "modern" programming languages of course (duh!)

The reasons are of course that OOP is fundamentally brain damaged, to the extent of that we should warn children about it, the same way we warn them about traffic, strangers in the night, and drugs.

However, don't believe me, ask any of the founding fathers of computing, such as Alan Kay, Dijkstra, Linus Torvalds, Richard Stallman, etc, etc, etc. If you get any of these guys to tell you the truth of the matter, most of them will tell you that OOP is the worst disaster that could possibly have occurred to the software development profession. For instance, go through SOLID programming, one character at the time, at which point you'd of course realise that it's not even possible in theory to violate SOLID if you're using a functional programming language. With OOP it's almost impossible to not violate SOLID.

This is because each character in SOLID is basically a different method to say "verb", and in a functional programming language, each function is a verb by the very definition of the term. Besides, no objects, no mutations. In a functional programming language things are immutable by default. Each function takes some input, and returns some output, typically encapsulating a single verb. Single responsibility; Check, Open Closed principle; Check, etc, etc, etc. As to Liskov Substitution Principle? Well, do I really have to explain this one ...? ;)

In FP there is no inheritance. No inheritance, no LSP problems

I could walk you through the rest of the characters, but I suspect you get the point by now ...

In OOP you have to create virtual methods, and/or interfaces to be able to reuse logic, resulting in that everything becomes entangled with everything else. In a functional programming language, you pass in the function as is to some other function, and whatever original function you had, all of a sudden automagically starts using your new and shiny stuff. Don't get me wrong here, when I am forced to code in OOP, I use the constructs I have to use, in order to be able to adequately separate my concerns, and I love IoC, interfaces, strongly typing, etc - When I'm in OO land. But the same constructs are a gazillion times simpler in non-OO land.

So what is that one freakin' design pattern that replaces every single design pattern on the planet then you might ask? Well, the answer is pretty obvious at this point; It's the one that renders the entirety of OOP obsolete; Active Events or Super Signals.

• Read an old MSDN article I wrote about these buggers here ...

When I discovered Active Events some 11 years ago, I was mind blown at how much simpler it became for me to loosely couple my modules and components. Simply because there was zero shared dependencies in my code. And if you think about SOLID and design patterns, their sole purpose is to reduce dependencies. No dependencies, no problem - Capiche?

Let me show you an example of a Super Signal ==> Version slot in Magic. That's it! One simple attribute, one simple interface, with one method, taking one argument. Then try to explain to me how you'd violate SOLID or any other software development methodologies when everything is tied together like this ...

Hint; You CAN'T!

With the Super Signals/Active Events design pattern, it's not even possible in theory to violate SOLID.

At this point the observant reader will argue; But that's C#. And yup, it is in deed, however the above design pattern is the entire axiom around which Hyperlambda and Magic evolves. Implying using only that design pattern, I was able to use C# (a fundamentally brain damaged OOP language) to create a perfectly working functional programming language (Hyperlambda), and such completely encapsulate all the garbage OO constructs from C#, to end up with something that's not fundamentally brain damaged. In case you missed it, let me repeat it once more, this time in slow motion ...

using magic.node;
using magic.signals.contracts;

namespace magic.backend.slots
{
    [Slot(Name = "version")]
    public class Version : ISlot
    {
        public void Signal(ISignaler signaler, Node input)
        {
            input.Value = "v9.9.1";
        }
    }
}

That's it. Consider OOP to be thoroughly "encapsulated" ... ^_^

No OOP, no problem!

Psst, this article is a comment to one of the comments in one of my other articles ...

... where I explain why Entity Framework is fundamentally brain damaged ... :/

You see, it's not about EF per se, but rather about the fact that the entire axiom of OOP is fundamentally brain damaged, implying it's (almost) impossible to build something useful on top of the axiom ...