How to Organise Code ?
Types vs Interfaces
Functions vs Classes
Composition vs Composition
Partial Functions vs Dependency Injection
Monads vs Messages, Callbacks, Exceptions
Recursion vs State Machine
Left Brain Programmers have come with up a way to organise code.Right brain programmers have come up with a way to organise code. If we don’t understand ourselves we can never understand each other.
I agree with your premise of being aware of your own though processes and preferences, and striving to understand the thought processes and preferences of others.
However, I am morally obliged to point out that the Left-Brained-Right-Brained dichotomy w.r.t. human personalities and high-level preferences is, at best, grossly misunderstood research filtered through years the blurry lens of pop culture, and at worst is outright psuedoscience.
Back on topic the topic, I want to pick at “Design Patterns” as a bad idea.
I put forward that design patterns (lowercase) are not bad when they emerge from solving a problem, and then become a common short-hand manner of conveying the presence of a particular, possibly nuanced, solution. Saves breath, saves time, the same as any other jargon, and you might recognize them again when solving a different problem.
Where Design Patterns (capitalized) become a bad idea is when people treat them like a permanent buffet from which to eat. The only food you eat is from the buffet (the only code is Patterns from the book), where you just walk down the line and load up on as much as you can, without regard to if you will really need all of that food (abstraction/indirection). Also, you are discouraged/forbidden from getting into the kitchen and cooking up your own food/patterns. That’s for the Professionals.
I was introduced to design patterns in the first sense, and only later ran up against it in the second definition out in the wild. So in that sense I have a forgiving view of the term, because to me they’re just a way to describe a useful “pattern” that you’ve discovered is showing up in your “design” of various projects.
This is a good point, and one I was debating elaborating on. Design patterns and category theory are both ways of describing behavior: “things that look like this behave like that,” with the implied inverse of “if you want to do that you might consider an approach like this.” Both can be abused (as mr-foobar said in his other comment, but maligning the idea of identifying patterns and categories of behavior is not workable – it’s the foundation of our profession.
I also think that the two concepts are related, actually. For example, the null object pattern is essentially an ungeneralized “Maybe” monad.
You are using Right Brain reasoning btw (much like myself). I would be truly surprised if you have written monadic libraries in Haskell. Brain has areas dedicated for types of reasoning - Metaphoric, Sequential, Emotional, Procedural. We can ascertain this is a fact and not pop-sci because physiological damage or over stimulation in one area can cause gross behaviour changes.
You can be dominant or damaged in these types of reasoning. I would consider RMS to be dominant in procedural reasoning but damaged in all others.
Identification is one thing, abuse is another. What reasoning you use to identify is equally important. If it looks like this do that. Penny roger has goats <more, more, more> so we should all milk the cat is how I would describe metaphorically, Sequential Reasoning. To claim one is superior to the other feels like a moral blizzard at a very fundamental pedagogical level.
Maybe there is no silver bullet, but a silver, golden and a copper bullet but as a profession we are just pissing on each other than putting the bullet in the head.
Kind of weird to put “Category Theory” in the “bad ideas” section, since it necessarily subsumes the creation and description of types.
I could have elaborated on that. Category theory is just the Design Patterns for the FP people. From this perspective both are equally prone to needless abuse – AbstractFactoryProxyController vs partialApplicativeFunctorCurryMonoid.
Do you need anything other than Closures or Closure like design patterns for advanced ways to Organise code ?
Probably not in almost 99% of the use cases.