4 ms·

> 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 _messa

> 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.

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.