I'm reminded of the whole "in c easy things are easy and hard things are hard, whereas in higher level languages its the opposite". If you have hard things that are easier to define than easy things, it incentivises overcomplicating things. Rust gives us a bunch more abstractions than c, but keeps easy things easiER than hard things, which is the correct thing if you want to incentivise simple solutions.
Really good talk and perspective! It reminds me btw a lot of the functional core, imperative shell approach (afaik Gary Bernhardt coined this concept). To be honest I'm not a big fan of OOP myself but it seems you use it in a very similar way I've been doing it: for "big" stateful services (aka actors). I also use it for "small things" that don't depend on anything else but contain a lot of state and functions on this state - so mostly container-like types. My main issue with OOP was always how bad it is at modelling domain problems and how OOP-abstraction increases actually tight coupling and decreases modularity. With data and functions it's simple: they are already "objects"/atoms/... so you model the data with these atoms, and you write the functions that transform this data and you put everything into modules to logically group it - everything is nicely separated and decoupled but logically grouped. Every function can work on a variety of data, so it's easier to model transformations between a variety of data - you don't have to think: where does function A belong? to object B,C or D? With objects on the other hand you create a "functional" relationship - data and functions are tightly coupled. In some cases that's perfectly valid, but more often it's not and you just created an abstraction over an abstraction for no reason. I often compare it to database relationships: in OOP you can only model 1:n relationships (1 class, which is also the state/data : n functions. I'm talking purely about the modeling side, so not how it is at runtime where you can have multiple objects for the same class). Most systems have a lot of n:m relationships though (n state/data : m functions, e.g. some_function(data a, data b, data c, ...)). So in OOP you need an extra layer of abstraction to "translate" to this n:m relationship. That's why I often see things like e.g. *Manager classes in OOP code. Nowadays whenever I encounter a "SomethingManager" class I consider it code-smell. The moment I have some inter-dependency of objects like: obj1.method(obj2) I usually refactor it so that they all depend only on pure data/functions not objects, like: obj1.method(just_some_simple_data). After all every dependency on an object makes it automatically depend on everything(!) else that object depends on: it's internal state, all the methods, class hierarchy, etc. You literally got the banana together with the gorilla and the jungle! Passing references to objects between objects is just crazy and I'm pretty sure that's not what Alan Kay had in mind. It's the lazy developers way of pulling in dependencies without specifying them explicitly, cheap in the beginning, but you pay double (and more) later. Some OOP-purists call me crazy but I have a very good track record of systems that are well designed this way - while they still discuss how to use design patterns to somehow manage their OOP mess ;)
And now with Rust, we have to constantly fight the gorilla (AKA Borrow Checker) to get the banana, making a serious mess of the jungle. 😁More seriously, OOP's a great toolbox but you've got to learn how to use them. Inheritance, that so many like to bash, particularly in the Rust community, is a combination of features that helps tremendously in some situations. Sadly, some people are misusing it, like any other feature, then complain years later that it's broken and recite a mantra about composition vs inheritance (which meant something entirely different when the original authors phrased it). Each tool is better suited to a specific job, so the important take-away: learn what does what and don't apply general principles automatically without understanding what's behind them.
![SAFEPLANET - ดาวเคราะห์ [ THE PLANET ]](http://i.ytimg.com/vi/4X1XL3I_k3c/mqdefault.jpg)
Absolutely fabulous talk! 👏
This guy gets it.
I'm reminded of the whole "in c easy things are easy and hard things are hard, whereas in higher level languages its the opposite". If you have hard things that are easier to define than easy things, it incentivises overcomplicating things. Rust gives us a bunch more abstractions than c, but keeps easy things easiER than hard things, which is the correct thing if you want to incentivise simple solutions.
Really good talk and perspective! It reminds me btw a lot of the functional core, imperative shell approach (afaik Gary Bernhardt coined this concept).
To be honest I'm not a big fan of OOP myself but it seems you use it in a very similar way I've been doing it: for "big" stateful services (aka actors). I also use it for "small things" that don't depend on anything else but contain a lot of state and functions on this state - so mostly container-like types.
My main issue with OOP was always how bad it is at modelling domain problems and how OOP-abstraction increases actually tight coupling and decreases modularity. With data and functions it's simple: they are already "objects"/atoms/... so you model the data with these atoms, and you write the functions that transform this data and you put everything into modules to logically group it - everything is nicely separated and decoupled but logically grouped. Every function can work on a variety of data, so it's easier to model transformations between a variety of data - you don't have to think: where does function A belong? to object B,C or D?
With objects on the other hand you create a "functional" relationship - data and functions are tightly coupled. In some cases that's perfectly valid, but more often it's not and you just created an abstraction over an abstraction for no reason.
I often compare it to database relationships: in OOP you can only model 1:n relationships (1 class, which is also the state/data : n functions. I'm talking purely about the modeling side, so not how it is at runtime where you can have multiple objects for the same class).
Most systems have a lot of n:m relationships though (n state/data : m functions, e.g. some_function(data a, data b, data c, ...)). So in OOP you need an extra layer of abstraction to "translate" to this n:m relationship. That's why I often see things like e.g. *Manager classes in OOP code. Nowadays whenever I encounter a "SomethingManager" class I consider it code-smell.
The moment I have some inter-dependency of objects like: obj1.method(obj2) I usually refactor it so that they all depend only on pure data/functions not objects, like: obj1.method(just_some_simple_data). After all every dependency on an object makes it automatically depend on everything(!) else that object depends on: it's internal state, all the methods, class hierarchy, etc. You literally got the banana together with the gorilla and the jungle! Passing references to objects between objects is just crazy and I'm pretty sure that's not what Alan Kay had in mind. It's the lazy developers way of pulling in dependencies without specifying them explicitly, cheap in the beginning, but you pay double (and more) later.
Some OOP-purists call me crazy but I have a very good track record of systems that are well designed this way - while they still discuss how to use design patterns to somehow manage their OOP mess ;)
Good talk.
And now with Rust, we have to constantly fight the gorilla (AKA Borrow Checker) to get the banana, making a serious mess of the jungle. 😁More seriously, OOP's a great toolbox but you've got to learn how to use them. Inheritance, that so many like to bash, particularly in the Rust community, is a combination of features that helps tremendously in some situations. Sadly, some people are misusing it, like any other feature, then complain years later that it's broken and recite a mantra about composition vs inheritance (which meant something entirely different when the original authors phrased it). Each tool is better suited to a specific job, so the important take-away: learn what does what and don't apply general principles automatically without understanding what's behind them.