Beyond OOP and the future of development experience
Posted by bennett-dev@reddit | programming | View on Reddit | 6 comments
Posted by bennett-dev@reddit | programming | View on Reddit | 6 comments
Onheiron@reddit
So what's the difference between a class and a (typed?) higher order function?
What's the difference between your js file with functions and a class with only static methods?
What's the difference between checking "weapon is Longsword" and "weapon.type = 'longsword'"?
What's the difference between an abstract factory and a lambda returning some JavaScript Object?
What I mean is that to me, those are just patterns. You're not supposed to subjectively choose and mix them: they represent specific scenarios and you must use them to carefully represent your problem.
So my issue with OOP is just that it shoves the class pattern down your throat. Well at least until java got lambdas... That was like OOP rising their hand and saying "ok, maybe we messed up!"
bennett-dev@reddit (OP)
This is of course completely true. Two notes:
Fixation on single-paradigms like OOP is natural, perhaps for any industry. Most, f.ex businesses want you to code in predictable, popular ways and don't care as much about things like trying to further software architecture philosophy or ensuring deep multi-paradigm understanding from their devs.
OOP’s dominance has entrenched the single-paradigm mindset across the industry, to real, industry-wide degradation of architectural know-how. So when you mention “carefully representing problems with the right patterns,” that is arguably the most important skill in software architecture, but not something many people even realize you can do beyond applying a GoF pattern.
Onheiron@reddit
totally agree!
Zomgnerfenigma@reddit
My biggest grief is that OOP tries to encode too much into hard to explore (meaningless) abstractions, just for the sake of making a method looking clean. If things get messy, just show it to me and don't hide it.
In addition it's an sociotechnological issue now. If your code doesn't even try to disguise as grand OOP architecture, then peers will puke into their mouth.
Onheiron@reddit
I totally agree with your second point and I see how this leads to meaningless abstractions for the sake of "looking very OOP".
Zomgnerfenigma@reddit
Boom.
Just half way through the article, but it picks up my thinking that we need to take effort to focus explicit and deliberate API design at the edges of runtime systems. With runtime systems I mean coarser grained modules or components that are useful to integrate. An library would be the opposite, a highly flexible and composable tool for it's domain, exposing internal architecture for composition. The contrast is that modules/components don't need to expose as much and the internal architecture design can be simplified just to satisfy it's external API.
Or simply put, most systems are over engineered out of habit.