4 ms·
Many systems people want to build with computers cannot be easily conceptualised as graphs of largely self-contained objects, interacting through swapping messa
by stupidcar 7y ago
Many systems people want to build with computers cannot be easily conceptualised as graphs of largely self-contained objects, interacting through swapping messages. These problems instead revolve around complex data processing, and are more easily conceptualised as data flowing through a network of functions, and into and out of containers.
It is possible to build these systems using OO, by reifying the network of functions and the data into objects. But all you are really doing is reinventing functional programming with a layer of OO cruft on top of it, and it is always going to be easier to build the equivalent system in a language that lets the functions and the data structures be unencumbered.
For programming tasks that actually are best conceptualised as objects, OO works quite well. These usually involve the provisioning of some largely static virtual environment, such as a UI, game world, or inversion of control container. Here, objects are long-lived, genuinely independent, and interact in well-defined ways via actions and events, usually swapping only small pieces of state.
My guess is that the advent of GUIs and sophisticated games in the 80s and 90s pushed programmers to be more interested in this latter type of problem, and this was reflected in the languages that evolved. Then the advent of the internet and machine learning in the 2000s and 2010s revived interest in data processing and data flow, and so language design began to shift back.
I suspect in 100 years, if humans are still doing any programming, all popular languages will be mixed-paradigm, and the question of OO vs functional will simply be a blend decided by needs of the problem at hand, rather than the kind of dogmatic arguments of this era, which will be viewed through a historical lens as rather quaint and silly.
- 1kGarand 7y agoThis is such an awesome answer.
- munificent 7y ago> I suspect in 100 years, if humans are still doing any programming, all popular languages will be mixed-paradigm What makes you think we'll need to wait that long? C#, C++, JavaScript, Java, Swift, Kotlin, Dart, Scala, Python, and Ruby all have objects, methods, polymorphism, first-class functions, lambdas, closures, and higher-order functions.
- jeremyjh 7y agoThe current trend in computer game architecture is also away from OOP/inheritance and to Entity-Component-System designs where you have entities without behavior (often just an Id) that are composed of components (pure data structures) that are operated on by systems specialized to single or small sets of components (functions).
- hatmatrix 7y agoIf messages that are swapped contain data, I find that FP (functional programming), if implemented with type checking, can include as much or if not more boilerplate than OOP, where object methods implicitly access the data (object attributes). This may sometimes lead to code that is difficult to reason out... but if you have a few objects and many functions, OOP can be less verbose than FP. I say this as a stronger supporter of FP than OOP.
- darkteflon 7y agoThis answer is very, very good.
- nickthemagicman 7y agoI really like this take. Especially the idea that OOP is used for specific OOP use cases and not applicable to solving every problem at large. Data Processing is a great example
- DeathArrow 7y ago> For programming tasks that actually are best conceptualised as objects, OO works quite well. These usually involve the provisioning of some largely static virtual environment, such as a UI, game world, or inversion of control container. Actually data oriented design and entity component systems work much better for games. You don't have hidden states and data flows much nicer from system to system. Actually, ECS is a good solution for implementing GUIs, too.