3 ms·

The core illusion of OOP is that it makes the design of large-scale system simpler by hiding away the complexity behind the facade of objects exchanging message

The core illusion of OOP is that it makes the design of large-scale system simpler by hiding away the complexity behind the facade of objects exchanging messages. When in fact you can have architecturally separated modules without objects just fine, and all objects bring is the complexity of finite state machines talking to each other via complex message protocols. Sometimes you indeed need some virtual dispatching, but most of the time procedure is a better abstraction, and function is even better. Instead of making complex parts of the system simpler, OOP usually makes simple parts complex. Hence the need for frameworks. In functional or procedural worlds people just take libraries and glue them together. In OOP world it's nearly impossible because of how complicated object protocols are, so if you have objects from different libraries, you'll most likely need to write lots and lots of facades. Hence OOP evolved towards megalibraries which have it all. > Lets hope your not in charge of building that new complex air traffic control system, bank lending system, or large inventory management system. Many of these are doing fine being written in procedural style though.

al_mandi 4y ago
> In OOP world it's nearly impossible because of how complicated object protocols are, so if you have objects from different libraries, you'll most likely need to write lots and lots of facades. That's not a direct result of OOP. Languages can have extension functions or type classes or delegation to address this. And it's not like the problem magically goes away for procedural code.
- ernst_klim 4y ago
  > That's not a direct result of OOP. It's actually the core definition of objects. Objects are entities supporting open recursion, self-polymorphism and late binding. There is a difference between "having type-classes" and "having object as a core formalism of computation" > Languages can have Languages can have objects, or actors, or other entities alike. This doesn't mean it's prudent to design your code around the idea of message-exchanging FSMs. Sometimes at some scale objects or actors are useful. > And it's not like the problem magically goes away for procedural code. This is empirically not true, and the frameworks example is the best proof of it. In languages like (functional) Scala, Go, OCaml, libraries do compose well enough, and gluing them is cheap. Any hardcore OOP language eventually brings frameworks like Spring, Rails, etc, because gluing objects is expensive, and for no reason, if functional/procedural alternative is so much cheaper. Even natural transformations between monads are very cheap compared to objects' composition.
aryehof 4y ago
> makes the design of large-scale system simpler by hiding away the complexity behind the facade of objects exchanging messages. This Kay-esque focus on _messages_ has fudded the OO space for too long now. The so called "magical view" of OO - "it's all about messages". The actual original inventors saw an object as a representation of a phenomena, real or imagined. They (particularly Kristen Nygaard) sought a way to model phenomena, concepts and the interactions between them. Consider that this is the design viewpoint that Bjarne Stroustrup actually sought to add to the C language. Step back from a focus on state machines, message protocols and a technical plumbing viewpoint. FP has its place, particularly where the focus is on the transformation of data. But don't extrapolate that as applicable to all types of computing application. As I mentioned elsewhere, the predominant design paradigm for large complex projects outside of computing and the data sciences for over a decade was Structured Analysis. That involved data modeling and typically separately modeling the functional processes that modified that data. Did we learn anything?
- ernst_klim 4y ago
  > This Kay-esque focus on _messages_ has fudded the OO space for too long now. Sure, people nowadays tend to prefer writing procedural/functional code in OO languages, using objects as mere modules. > But don't extrapolate that as applicable to all types of computing application. Any formalism can be used for any kind of computation. Actors, objects or lambda calculus/simple referentially transparent FP lang are interchangeable. The only difference is the latter is the simplest, hence easier to reason about and compose. But any kind of system can be built on top of any of these. > As I mentioned elsewhere, the predominant design paradigm for large complex projects outside of computing and the data sciences for over a decade was Structured Analysis. This is not a paradigm, that's a methodology, and it's totally unrelated to what kind of language paradigm is used, or to original take about "programs = algorithms + data structures". Besides, most modern reactive systems are built on top of something like RX or Akka streams anyways, and functional in principle.

al_mandi 4y ago

> In OOP world it's nearly impossible because of how complicated object protocols are, so if you have objects from different libraries, you'll most likely need to write lots and lots of facades. That's not a direct result of OOP. Languages can have extension functions or type classes or delegation to address this. And it's not like the problem magically goes away for procedural code.

ernst_klim 4y ago
> That's not a direct result of OOP. It's actually the core definition of objects. Objects are entities supporting open recursion, self-polymorphism and late binding. There is a difference between "having type-classes" and "having object as a core formalism of computation" > Languages can have Languages can have objects, or actors, or other entities alike. This doesn't mean it's prudent to design your code around the idea of message-exchanging FSMs. Sometimes at some scale objects or actors are useful. > And it's not like the problem magically goes away for procedural code. This is empirically not true, and the frameworks example is the best proof of it. In languages like (functional) Scala, Go, OCaml, libraries do compose well enough, and gluing them is cheap. Any hardcore OOP language eventually brings frameworks like Spring, Rails, etc, because gluing objects is expensive, and for no reason, if functional/procedural alternative is so much cheaper. Even natural transformations between monads are very cheap compared to objects' composition.

aryehof 4y ago

> makes the design of large-scale system simpler by hiding away the complexity behind the facade of objects exchanging messages. This Kay-esque focus on _messages_ has fudded the OO space for too long now. The so called "magical view" of OO - "it's all about messages". The actual original inventors saw an object as a representation of a phenomena, real or imagined. They (particularly Kristen Nygaard) sought a way to model phenomena, concepts and the interactions between them. Consider that this is the design viewpoint that Bjarne Stroustrup actually sought to add to the C language. Step back from a focus on state machines, message protocols and a technical plumbing viewpoint. FP has its place, particularly where the focus is on the transformation of data. But don't extrapolate that as applicable to all types of computing application. As I mentioned elsewhere, the predominant design paradigm for large complex projects outside of computing and the data sciences for over a decade was Structured Analysis. That involved data modeling and typically separately modeling the functional processes that modified that data. Did we learn anything?

ernst_klim 4y ago
> This Kay-esque focus on _messages_ has fudded the OO space for too long now. Sure, people nowadays tend to prefer writing procedural/functional code in OO languages, using objects as mere modules. > But don't extrapolate that as applicable to all types of computing application. Any formalism can be used for any kind of computation. Actors, objects or lambda calculus/simple referentially transparent FP lang are interchangeable. The only difference is the latter is the simplest, hence easier to reason about and compose. But any kind of system can be built on top of any of these. > As I mentioned elsewhere, the predominant design paradigm for large complex projects outside of computing and the data sciences for over a decade was Structured Analysis. This is not a paradigm, that's a methodology, and it's totally unrelated to what kind of language paradigm is used, or to original take about "programs = algorithms + data structures". Besides, most modern reactive systems are built on top of something like RX or Akka streams anyways, and functional in principle.