Regarding Message Passing and Late-binding, I think it's important to take into account that Alan Kay was working on Smalltalk -- a system that was image based; a system where you could change things as it was running. I think that message passing and late-binding are often championed but then sort of fall flat given standard deployment techniques: build & deploy (often to a ephemeral runtime / container).
Smalltalk can use build & deploy. (Image as cache, not archive.)
"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager."
1984 "Smalltalk-80 The Interactive Programming Environment" page 500
On classes, I get it... tbf though I'm fine with prototype inheritance as well, there's positives and negatives to both approaches... not to mention, there are benefits to not really having either and just having objects you can interrogate or even that are statically assigned at creation (structs).
What's funny on the Method Syntax for me, is that I actually don't like mixing classes that hold data and classes that do things more often than not. I mean, I get the concepts, but I just don't generally like the approach. The only exception might be a controller with a handle to a model(state) and the view... but even then, the data itself (model) is kind of separated as a reference, and don't tend to attach too many variants of state to anything... I'm generally a fan of the single state tree approach (often used for games, and famously via Redux).
On information hiding... I'm generally not too much of a fan of hiding members of an object used to hold data... I mean, I can see filters when you're passing something to the edge of a system, like a hashed password on a user object exposed via an api. But internally, I'd almost rather see immutability as a first class over locking bits and pieces down, then exposing member methods to mutate the object internally. Just my own take.
On Encapsulation, like above... I'm more on the side of the Data oriented design approach. To me this is where you have API surfaces and like above I tend to separate modules/classes that do things, from templates/models/classes that hold data.
I'm mixed on Interfaces.. they're definitely useful for plugin systems or when you have multiple distinct implementations of a thing... but after a couple decades of C#, they're definitely overrated and overused.
No strong opinions on Late Binding pr Dynamic Dispatch... other than I do appreciate it at times in dynamic language environments (JS).
Inheritance and SubTyping imo are, similar to Interfaces, somewhat overrated... I just try to avoid them more than use them. There are exceptions, I'm actively using this in a project right now, but more often than not, it just adds undue complexity. With prototype based inheritance, it's also possible to really slow down certain processes unintentionally.
Strong proponent of Message Passing approaches... it often simplifies a solution in terms of the surface you need to be aware of at a given point. Allows you to construct decision trees and pipelines of simpler functions.
Interesting overall... but still not a fan of some of the excesses in OOP usage in practice that I've had to deal with. I just prefer to break problems up slightly differently... sometimes blurring clear lines of separation to have a simpler whole, sometimes just drawing the lines differently because they make more sense to me to break up for a given use case.
My OO projects were usually in Java with a DB. They all ran afoul of what Martin Fowler calls the Anemic Domain Model. Basically your objects are data-only, so there's no benefit. In addition Spring injection became ubiquitous, and further killed objects with behavior. The only project using a DB and had objects with behavior was an old one that happened to use TopLink as an OR mapping.
> Basically your objects are data-only, so there's no benefit.
This makes me wonder why most of us use Java at all. In your typical web app project, classes just feel like either:
1) Data structures. This I suspect is a result of ORM's not really being ORM's but actually "Structural Relational Mappers".
- or -
2) Namespaces to dump functions. These are your run-of-the-mill "utils" classes or "service" classes, etc.
The more I work in Java, the more I feel friction between the language, its identity(OO beginning to incorporate functional ideas), and how people write in it.
OO fatigue is a healthy symptom of readiness to move to clojure, where data and functions are free to live without encapsulation. No king of nouns, no king of execution!
I think the biggest mistake was to teach inheritance as a main feature of OOP. I have done some stuff with inheritance but it was very specialized and it would have been fine without inheritance.
> The industry and the academy have used the term “object-oriented” to mean so many different things.
I think we can safely stick to how IEEE defines OOP: the combination of three main features: 1) encapsulation of data and code 2) inheritance and late binding 3) dynamic object generation (from https://ethw.org/Milestones:Object-Oriented_Programming,_196...).
The article assumes that C++, Java, and Smalltalk implement completely different subsets of OOP features, which is not true at all. Those languages, including Smalltalk (starting with Smalltalk-76), all implement the Simula 67 object model with classes, inheritance and virtual method dispatch. Simula 67 was the first object-oriented programming language (even if the term was only applied ~10 years later in a 1976 MIT publication for the first time, see https://news.ycombinator.com/item?id=36879311). Message passing (the feature the article claims is unique to Smalltalk) is mathematically isomorphic to virtual method dispatch; and also Smalltalk uses method dispatch tables, very similar to C++ and Java.
I'd love a deeper dive on how Objects work in NeXTSTEP. From their brochures, they talk about objects being persistent and distributable, that in a workgroup of people everyone can rely on the objects being up to date.
I've always been so curious what the broader technical ecosystem looks like here. Presumably there are still processes running on systems. But these processes have lots of objects in them? And the objects are using Mach message passing to converse with other processes elsewhere? Within an application, are objects communicating across Mach too?
This is a fun work. It feels like the brief outline for a Speaking for the Dead for OOP. Huge amount of things to lots of different people over time.
Seconding @rawgabbit's recommendation for Casey Muratori's The Big OOPs: Anatomy of a Thirty-five-year Mistake, which really is hunting back and back for the cosmogenesis of objects, and covers so much terrain. Objectogenesis?
https://youtu.be/wo84LFzx5nI
There is a good methodological principle stated by a Soviet philosoph Ilyenkov: to understand the nature of a thing build or describe a minimal working model of the thing. So simple that if you remove any single detail it ceases to work. He himself gave an example of radio: to understand what radio is build a minimal radio sender and receiver of three or four details each. Do not start with a household radio unit that comes in a polished box with lights and knobs; it has way too many unrelated details.
This works very well both for concrete things like radio and for more abstract things like math or Marx's notion of private property. This is also the principle employed by religious and mystical parables or the book "A pattern language".
OOP basically means Java or things like Java. Not how it started ofc, but that's what it's been for decades. Minus the lambdas and stuff they added relatively later to compromise on OOP.
For me, the fundamental gestalt was/is binding behavior to data. I found/find it useful for modeling how things work. I was always inspired by one of Alan’s seed inspiration for Smalltalk, how biological cells accomplish computation through interacting with each other. I did Smalltalk for many years before polyglotting.
The trick is to say "codata" instead of "object-oriented programming", and then you can use OOP and still be a programming hipster. (I am a programming hipster.)
I'm only somewhat joking. I actually find this view very useful. Codata is basically programming to interfaces, which we can think of as OO without confusing implementation approaches like inheritance. Codata is the dual to (algebraic) data, meaning we can convert one to the other. We can think of working with an abstract API, which we realise as codata or data depending on what best suits the project. More in the book I'm writing [1].
In general I agree with the author. There are a lot of concepts tangled up in OOP and discussion around the benefits of OOP are rarely productive.
> I feel that prototypes are harder to wrap one’s head around compared to classes.
This is sad to read because prototypes are conceptually easier to understand than classes. It’s unfortunate that most developers experience with them is JavaScript, because its implementation is extremely poor. I recommend trying Io which is very Self inspired as well as Lua.
"The notion of an interface is what truly characterizes objects - not classes, not inheritance, not mutable state. Read William Cook's classic essay for a deep discussion on this."
> The industry and the academy have used the term “object-oriented” to mean so many different things. One thing that makes conversations around OOP so unproductive is the lack of consensus on what OOP is.
There has been different terms and meaning to it - but we all know the "OOP" thrown about since the mid-to-late 90s is the Java way.
A typical Java book back then would have 900 pages.. half of which is explaining OOP. While not focusing fully on Java, it does help transition that knowledge over to Delphi or C++ or.. eventually.. C#, etc.
Overall -- we all knew what "Must have good OOP skills" means on a job advert! Nobody was confused thinking "Oh.. I wonder which OOP they mean?"
I have a love/hate relationship with OOP. If I have to use a language that is OOP by default then I use it reasonably. While the built in classes will have theor own inheritence -- I tend to follow a basic rule of no higher that 2. Most of the time it is from an interface. I prefer composition over inheritence.
In C#, I use static classes a fair bit. In this case, classes are helpful to organise my methods. However, I could do this at a namespace level if I could just create simple functions -- not wrapped inside a class.
OOP has its place. I prefer to break down my work with interfaces. Being able to use to correct implementation is better than if/switch statements all over the place. However, this can be achieved in non OOP languages as well.
I guess my point is that OOP was shoved heavily back in the day. It was shutup and follow the crowd. It still has it's place in certain scenarios - like GUI interfaces.
> Another criticism comes from functional programmers, who argue that you don’t need to maintain invariants and thus don’t need much information hiding if data is immutable.
Yep
> Information hiding also encourages people to create small, self-contained objects that “know how to handle themselves,” which leads directly into the topic of encapsulation.
This is where it all goes wrong. No module is an island. There's always relationships between different objects/modules/actors in your system.
Who delivers a letter: Postman or Letter? Who changes a light globe, Handyman or LightGlobe?
Things rarely handle themselves - and if they do, it's probably just a pure function call - so why use Objects?
If you start bending over backwards to implement Letter.deliver(Postman p) (and then make it "general" by changing it to IPostman) you'll never stand up straight again. What if I have a List<Letter>, where does the deliver() code go now?"
If you instead write Deliver(Postman p, Letter l), the opportunities to rewrite/refactor/batch just present themselves.
Yes, and for just cause. OOP was invented in Simula76 (1976) and popularized in C++ (1982). OOP solved a very real problem of allowing applications to logically scale in memory constrained systems by allowing logic to grow independently and yet retain access to memory already claimed by a parent structure. Amazing.
Now fast forward and you get languages like Java, Go, and JavaScript. These languages are garbage collected. Developers have absolutely no control over memory management in those languages. None at all. It really doesn't matter because the underlying runtime engines that power these languages are going to do whatever is in the best interest of execution speed completely irrespective of application or memory size. We just don't live in a world where the benefits offered by OOP exist. Technology has moved on.
The only reason for OOP today is code culture. Its a form of organizational vanity that continues to be taught because its what people from prior generations were taught. Most new languages from the last 15 years have moved away from OOP because it contains a lot of overhead as decoration with no further utility.
I used "Open Recursion" in many large (ObjectPascal / C++) projects. With simple interfaces, a large project becomes a collection of smaller components. I noticed many programmers do not understand it. Pure OOP languages (like Smalltalk or Ruby or Scala) are the best languages to understand how it could work. They usually have closures where other languages would have "patterns".
The problem is that the components are often connected to different interfaces/graphs. Components can never be fully separated due to debug, visualization and storage requirements.
In non-OOP systems the interfaces are closed or absent, so you get huge debug, visualization and storage functions that do everything. On addition to the other functionality. And these functions need to be updated for each different type of data. The complexity moves to a different part. But most importantly, any new type requires changes to many functions. This affects a team and well tested code. If your product is used by different companies with different requirements (different data types), your functions become overly complex.
30 comments
[ 3.0 ms ] story [ 41.1 ms ] thread"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager."
1984 "Smalltalk-80 The Interactive Programming Environment" page 500
On classes, I get it... tbf though I'm fine with prototype inheritance as well, there's positives and negatives to both approaches... not to mention, there are benefits to not really having either and just having objects you can interrogate or even that are statically assigned at creation (structs).
What's funny on the Method Syntax for me, is that I actually don't like mixing classes that hold data and classes that do things more often than not. I mean, I get the concepts, but I just don't generally like the approach. The only exception might be a controller with a handle to a model(state) and the view... but even then, the data itself (model) is kind of separated as a reference, and don't tend to attach too many variants of state to anything... I'm generally a fan of the single state tree approach (often used for games, and famously via Redux).
On information hiding... I'm generally not too much of a fan of hiding members of an object used to hold data... I mean, I can see filters when you're passing something to the edge of a system, like a hashed password on a user object exposed via an api. But internally, I'd almost rather see immutability as a first class over locking bits and pieces down, then exposing member methods to mutate the object internally. Just my own take.
On Encapsulation, like above... I'm more on the side of the Data oriented design approach. To me this is where you have API surfaces and like above I tend to separate modules/classes that do things, from templates/models/classes that hold data.
I'm mixed on Interfaces.. they're definitely useful for plugin systems or when you have multiple distinct implementations of a thing... but after a couple decades of C#, they're definitely overrated and overused.
No strong opinions on Late Binding pr Dynamic Dispatch... other than I do appreciate it at times in dynamic language environments (JS).
Inheritance and SubTyping imo are, similar to Interfaces, somewhat overrated... I just try to avoid them more than use them. There are exceptions, I'm actively using this in a project right now, but more often than not, it just adds undue complexity. With prototype based inheritance, it's also possible to really slow down certain processes unintentionally.
Strong proponent of Message Passing approaches... it often simplifies a solution in terms of the surface you need to be aware of at a given point. Allows you to construct decision trees and pipelines of simpler functions.
Interesting overall... but still not a fan of some of the excesses in OOP usage in practice that I've had to deal with. I just prefer to break problems up slightly differently... sometimes blurring clear lines of separation to have a simpler whole, sometimes just drawing the lines differently because they make more sense to me to break up for a given use case.
This makes me wonder why most of us use Java at all. In your typical web app project, classes just feel like either:
1) Data structures. This I suspect is a result of ORM's not really being ORM's but actually "Structural Relational Mappers".
- or -
2) Namespaces to dump functions. These are your run-of-the-mill "utils" classes or "service" classes, etc.
The more I work in Java, the more I feel friction between the language, its identity(OO beginning to incorporate functional ideas), and how people write in it.
Java has had "data carriers" in the form of records for a while now. Immutable(ish), low boilerblate, convenient.
Records are great when doing more "data oriented programming".All the other stuff, like polymorphism, encapsulation, etc., I consider "addons."
I think we can safely stick to how IEEE defines OOP: the combination of three main features: 1) encapsulation of data and code 2) inheritance and late binding 3) dynamic object generation (from https://ethw.org/Milestones:Object-Oriented_Programming,_196...).
The article assumes that C++, Java, and Smalltalk implement completely different subsets of OOP features, which is not true at all. Those languages, including Smalltalk (starting with Smalltalk-76), all implement the Simula 67 object model with classes, inheritance and virtual method dispatch. Simula 67 was the first object-oriented programming language (even if the term was only applied ~10 years later in a 1976 MIT publication for the first time, see https://news.ycombinator.com/item?id=36879311). Message passing (the feature the article claims is unique to Smalltalk) is mathematically isomorphic to virtual method dispatch; and also Smalltalk uses method dispatch tables, very similar to C++ and Java.
https://youtu.be/wo84LFzx5nI
I've always been so curious what the broader technical ecosystem looks like here. Presumably there are still processes running on systems. But these processes have lots of objects in them? And the objects are using Mach message passing to converse with other processes elsewhere? Within an application, are objects communicating across Mach too?
There's so much high level rhetoric about. Such as this bit. But I'd love a real technical view at what was happening, what objects really were here. https://computerhistory.org/blog/the-deep-history-of-your-ap... https://news.ycombinator.com/item?id=42111938
This is a fun work. It feels like the brief outline for a Speaking for the Dead for OOP. Huge amount of things to lots of different people over time.
Seconding @rawgabbit's recommendation for Casey Muratori's The Big OOPs: Anatomy of a Thirty-five-year Mistake, which really is hunting back and back for the cosmogenesis of objects, and covers so much terrain. Objectogenesis? https://youtu.be/wo84LFzx5nI
This works very well both for concrete things like radio and for more abstract things like math or Marx's notion of private property. This is also the principle employed by religious and mystical parables or the book "A pattern language".
I'm only somewhat joking. I actually find this view very useful. Codata is basically programming to interfaces, which we can think of as OO without confusing implementation approaches like inheritance. Codata is the dual to (algebraic) data, meaning we can convert one to the other. We can think of working with an abstract API, which we realise as codata or data depending on what best suits the project. More in the book I'm writing [1].
In general I agree with the author. There are a lot of concepts tangled up in OOP and discussion around the benefits of OOP are rarely productive.
[1]: https://scalawithcats.com/
This is sad to read because prototypes are conceptually easier to understand than classes. It’s unfortunate that most developers experience with them is JavaScript, because its implementation is extremely poor. I recommend trying Io which is very Self inspired as well as Lua.
But json wins out because it can be learned much more quickly.
Something similar could be said with OOP vs Functional Programming.
- Gilad Bracha
https://gbracha.blogspot.com/2022/06/the-prospect-of-executi...
http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf
There has been different terms and meaning to it - but we all know the "OOP" thrown about since the mid-to-late 90s is the Java way.
A typical Java book back then would have 900 pages.. half of which is explaining OOP. While not focusing fully on Java, it does help transition that knowledge over to Delphi or C++ or.. eventually.. C#, etc.
Overall -- we all knew what "Must have good OOP skills" means on a job advert! Nobody was confused thinking "Oh.. I wonder which OOP they mean?"
I have a love/hate relationship with OOP. If I have to use a language that is OOP by default then I use it reasonably. While the built in classes will have theor own inheritence -- I tend to follow a basic rule of no higher that 2. Most of the time it is from an interface. I prefer composition over inheritence.
In C#, I use static classes a fair bit. In this case, classes are helpful to organise my methods. However, I could do this at a namespace level if I could just create simple functions -- not wrapped inside a class.
OOP has its place. I prefer to break down my work with interfaces. Being able to use to correct implementation is better than if/switch statements all over the place. However, this can be achieved in non OOP languages as well.
I guess my point is that OOP was shoved heavily back in the day. It was shutup and follow the crowd. It still has it's place in certain scenarios - like GUI interfaces.
Yep
> Information hiding also encourages people to create small, self-contained objects that “know how to handle themselves,” which leads directly into the topic of encapsulation.
This is where it all goes wrong. No module is an island. There's always relationships between different objects/modules/actors in your system.
Who delivers a letter: Postman or Letter? Who changes a light globe, Handyman or LightGlobe?
Things rarely handle themselves - and if they do, it's probably just a pure function call - so why use Objects?
If you start bending over backwards to implement Letter.deliver(Postman p) (and then make it "general" by changing it to IPostman) you'll never stand up straight again. What if I have a List<Letter>, where does the deliver() code go now?"
If you instead write Deliver(Postman p, Letter l), the opportunities to rewrite/refactor/batch just present themselves.
Yes, and for just cause. OOP was invented in Simula76 (1976) and popularized in C++ (1982). OOP solved a very real problem of allowing applications to logically scale in memory constrained systems by allowing logic to grow independently and yet retain access to memory already claimed by a parent structure. Amazing.
Now fast forward and you get languages like Java, Go, and JavaScript. These languages are garbage collected. Developers have absolutely no control over memory management in those languages. None at all. It really doesn't matter because the underlying runtime engines that power these languages are going to do whatever is in the best interest of execution speed completely irrespective of application or memory size. We just don't live in a world where the benefits offered by OOP exist. Technology has moved on.
The only reason for OOP today is code culture. Its a form of organizational vanity that continues to be taught because its what people from prior generations were taught. Most new languages from the last 15 years have moved away from OOP because it contains a lot of overhead as decoration with no further utility.
Really, is this happening??? From the job listings I have seen, this is not so.
The problem is that the components are often connected to different interfaces/graphs. Components can never be fully separated due to debug, visualization and storage requirements.
In non-OOP systems the interfaces are closed or absent, so you get huge debug, visualization and storage functions that do everything. On addition to the other functionality. And these functions need to be updated for each different type of data. The complexity moves to a different part. But most importantly, any new type requires changes to many functions. This affects a team and well tested code. If your product is used by different companies with different requirements (different data types), your functions become overly complex.