I studied the history of OOP a while back because I was curious, and I organized what I learned into my personal wiki[1]. From what I remember, there were quite a few different perspectives on it. One view traces OOP's practical ancestry back to Ole-Johan Dahl's Simula. From Alan Kay's perspective, on the other hand, an object was something like a small computer of its own.
The two main lineages of OOP are Simula and Smalltalk. But from what I recall, modern languages actually inherited more from the Simula side in practical terms, while the terminology and philosophy were influenced more by Smalltalk.
[1]https://www.makonea.com/en-US/wiki/object-oriented-programmi...
Which corresponds pretty well with the Simula I concept, published 1966 in the Communications of the ACM. A Simula event notice (time, process) in the sequencing set is just a message step(process, time) in a priority mailbox; the two are the same mathematical object, making Simula's discrete-event active processes and Kay's message-passing active objects trivially isomorphic.
“I wanted a scripting language that was more powerful than Perl, and more object-oriented than Python" and "Ruby's class library is an object-oriented reorganization of Perl functionality--plus some Smalltalk and Lisp stuff" (see "An Interview with the Creator of Ruby", 2001, https://web.archive.org/web/20041220041220/http://www.linuxd...).
This comment was dead for some reason; I vouched for it. Casey Muratori is a well-known developer with a GUI/game engine background, which gives him a valuable perspective on OOP. In both domains, OOP is both popular and problematic, and his experience suggests that he might know what he's talking about. I didn't watch the whole video, but from the description and intro, it seems to fit the discussion we're having here.
Too late to edit, I watched the talk. Really well-researched and entertainingly told story.
I'd say games are a bit special, though. Smalltalk works pretty well in interactive applications - while it's true that encapsulation is an important part of the language, it also provides all the tools to pry objects open when needed. Out of the box, it's much better at that than C++. The problem is that video games demand very high performance, and Smalltalk is even slower than normal when you use reflection. If not for that, it's perfectly doable (if not very convenient) to treat a Smalltalk image as a soup of data with behavior attached. Casey also mentioned the focus on education in Alan Kay's projects: it's probably one of the reasons Smalltalk is largely devoid of modules, namespaces, packages, and even files with source code - things that are very useful when collaborating in teams, consuming external dependencies, etc. There are Smalltalk implementations that provide those, but they're either very niche or very niche and extremely expensive... And still slow.
Still, interactive software that doesn't have the performance requirements of games is definitely more convenient to write in Smalltalk than in C++! I have high hopes for GToolkit, I just need to port a few ideas from VisualWorks and figure out how to actually set up a project structure friendly to external agents (the GT agent harness is very nice, but it forces you to use an API, which is way too expensive for the results you get...)
I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages
It was originablly conceived as a simulation of a distributed system.
Distributed systems can be useful but does anyone really believe that they are simpler or easier to develop and maintain?
The amazing part to me is that so many were trained and convinced to accept that adopting this simulation could make all programming easier or somehow "better". As if adding complexity would magically lead to simplification.
Generally speaking, toy examples can always be made to look simple. In reality it often means the “hard part” was moved into the shadows, not actually solved.
Graphical programming like LabVIEW looks very appealing. The product demo practically sells itself. Sure, it fits well for a very narrow class of use cases. But even fairly simple things in a textual language quickly become an unwieldy mess. (Try factoring an integer in it…)
There are formal models for distributed systems often solve the “easy” problems that didn’t need solving while making various practical concerns harder/impossible such as timeouts or node failure.
> Distributed systems can be useful but does anyone really believe that they are simpler or easier to develop and maintain?
I believe that programs written in languages made for distributed systems are simpler and easier to maintain.
Also I believe that one of the major problems in modern computing is that most languages we use do not understand that even trivial programs require ‘communication’ and OS/hardware facilities that have behaviours of distributed systems such as latency, transient faults, etc.
Just a guess, it may be that he understood distribution more as the static distribution of meaning in fine grain entities (objects) to allow a wide range of context, flexibility. Not necessarily the time aspect of distribution.
People are going to come out of the woodwork to argue about OO specifically, and I'd probably join in, but the higher-level view that I've come to over the years is that one programming paradigm is not the best in all situations. It really helps to work on a lot of different systems that are not all in the same class and look at a lot of code written by people of all skill levels. It's not possible to really talk about all programs, but I will say that the OO way of thinking can very easily be overdone and end up a giant mess. Similarly, the FP way of thinking can also be very easily be overdone and end up a giant mess. The old-style procedural programming (C with a pile of global variables) can easily be overdone and end up a giant mess. Yet all three of those can actually work out great at the right scale on the right problem!
I think the problem is that we can't really architect a program well until after it works and fulfills all of its design requirements. Those are usually in flux and then we have to engineer dimensions of extensibility to prevent committing to the wrong architecture in the beginning. Those extra dimensions of extensibility come at some cost too, as they often mean indirection and cognitive overhead.
We often don't write the same program twice, or even three times, unless it's a really important program or a we just like doing it. Contrast to other fields, e.g. building houses, where we have lots and lots of examples of how to do it and they started to form archetypes. We try to call those design patterns in programming, but they're actually pretty vague and low-level. Can you imagine going to build a house and thinking "yeah, I think I need to use the wood-and-nails design pattern here, and I think I'll do rafters-and-shingles there, with some brick-and-mortar there." Yeah, real specific ideas on how to do it.
I actually do wonder whether we're going to see more of a prevalence of people building one off software due to an increasing use of LLM's which makes the house building model you're describing more common in software
I think the underlying error - is the assumption that everyones model is going to be equal when looking on the world, as a world of objects. That holds up- for a surprisingly small number of objects we all interact with.
Then it breaks down- depending on how deep your abstraction level goes (A car has 4 tires. 4 tires are made of: xyz). It also breaks down, with the abstraction in the real world above the modeler. Some think in organization, some in physics, some in tribalist constructs, some imagine a god object above them some don't. It was communicated as a tool using "shared" state as a communication helper.
IMO, the most important philosophy in all of software engineering is "Separation of responsibilities." The best way to achieve it is through the principle of "High cohesion, loose coupling."
OOP is just another layer of philosophy which builds on top of that. It's more specific, imposes additional guardrails. It requires objects with state encapsulation (locality) and message-passing as the mechanism for components to interact with each other; each component is responsible for changing a subset of the state of the system. Each component is responsible for handling messages (calls to action) by performing local state changes and potentially also sending messages to other components which have more specific sub-responsibilities.
OOP without "High cohesion, loose coupling" is almost worthless IMO. It must build on top.
I think were most people fail with OOP is that they think coming up with good separation of concerns, good abstractions is easy. They just start implementing the first idea which comes out of their heads and then figure out the scope of responsibilities as they go.
The test for good separation of concerns is that you should be able to explain your architecture to someone with the intellect of a 9 year old child who happens to understand the business domain. I'm not exaggerating. It has to be that obvious or else you will not be able to maintain clean separation... You will not be able to maintain alignment in your team.
If the responsibilities of a specific object are somewhat vague, what will happen is that the scope of responsibilities between objects will soon blur and the messages between objects will start to look increasingly elaborate; your system will look like a bunch of horrible incompetent managers trying to micromanage junior employees using long, convoluted instructions and occasionally throwing chairs at them...
If your system is passing around object references all over the place; that's usually a sign of poor separation of concerns; passing around complex objects by reference is tight coupling, by definition. Each object, each person should be able to fulfill their responsibilities and finish the job using communication only.
I agree "high cohesion, loose coupling" is a good architectural property to strive for, but OOP is terrible at it and there's no reason to use it for this.
Trying to achieve "high cohesion, loose coupling" in OOP has led to the creation of (supposedly) best practice recommendations like the SOLID principles, and the development of monstrosities like dependency injection frameworks.
If OOP was actually good at "high cohesion, loose coupling", you wouldn't need them.
I think this is looking at what OOP has become (as implemented by systems and programming languages that don't care a wit about what OO was meant to be) rather than what Alan Kay described.
If you think about something like a web server as an object, it has arbitrarily high cohesion and arbitrarily low coupling. You can only communicate to it through messages (HTTP); binding happens at the point in time that the message arrives (notwithstanding that this may be cached in all sorts of interesting ways in the implementation of any given server); and the web server is fully encapsulated (security flaws notwithstanding).
I think it's perfectly reasonable to argue that much of what gets called OOP doesn't deliver on the promise, but then it doesn't deliver on the premise either, and I think these are inextricably linked.
The Alan Kay variant of OOP is superior in this regard, and I'd argue the Erlang variant even more so (Actors are just asynchronous objects).
But both of them are still suboptimal because they allow objects to instantiate one another and to directly communicate with whomever they come in contact with. That creates strong coupling and you have to "fight the paradigm" to avoid it.
Other engineering domains have this figured out: components can only send and receive data through ports, they are never aware of their siblings. Only a component at a higher level of abstraction can decide how the ports of lower level components connect to one another. That completely eliminates coupling.
(You can of course replicate this type of architecture with OOP, but you can also replicate it with any turing complete paradigm, that's neither here nor there)
Yes, for example if you are doing any sort of mechatronic systems engineering (cars, planes, rockets, etc.), you're typically using tools like Simcenter Amesim or Modelica or Simulink/Stateflow to digitally prototype the system.
These tools are all oriented around blocks with ports. They receive data on their input ports and emit data on their output ports. They do not know where that data is coming from nor where it is going. They cannot instantiate other blocks.
To create a new block you either create a primitive one (described directly in terms of differential equations, since these are physical simulations, or as actual code, be it C or MATLAB or whatever else), or you connect blocks together to form a larger block.
This creates a strict hierarchy, connections between blocks can only happen at the same level of abstraction. You can just rip out a component and replace it with another with the same ports, or with multiple components each filling in part of the job, or you can plop another component in the middle that's only used to process the data inbound and redirect it somewhere else.
This makes coupling extremely loose by design. The paradigm enforces it.
'in->func()->out' work cleanly for physical engineering domains because blocks of computations (or functions) have no memory basically. There's no DB and there's usually no global state in the way you'd mean with classes. I've observed that when you work on complex software, you could play by the ear to enforce 'high cohesion and loose coupling' up to the point to where you've now got a data store holding system state. Based on what I've worked on, this system state is actually user data and then some derivative of the system's own interaction on this user data, both of which are necessary for the 'continuity of system runtime'. For example, working with redis as the primary data store, I extracted different types of redis calls for specific keys, (like set [specific_key], get [specific key], etc.) into functions, then I put these functions into a StateStore class so I can simply call StateStore.get_user_data() or StateStore.set_user_data() etc from any module across the entire system. From first principles, this is great modularity and high cohesion but it's very tight coupling around a single module i.e. StateStore. Any change in that module means I'd have to find all references for that updated function and cross check for any contract violations.
It's difficult for me to see how software can purely be 'High Cohesion and Loose Coupling' regardless of paradigm or architectural pattern. There's always gonna be an unavoidable and inevitable principle violation that's simple a result of a large complex system actually doing many little things that come together to actually do one big thing. The software itself, no matter how complex, IS the blackbox where data goes in and something comes out but that's the user perspective not ours as the programmer.
I think the idea I'm trying to hint at is that software cannot have every module independent of every other one. That's impossible. If nothing depended on anything else, the system wouldn't do anything. Rather than have every module know redis keys, States tore actually concentrates coupling into one place, which is exactly what high cohesion tries to accomplish.
I think that's the idea I'm chasing.
It's not really true that components in physical engineering domains have no memory. The behavior of many physical components can only be described with access to a recent history. Other components, specially controllers, are typically state machines (which obviously have state).
But it is true that there will always be parts of a software system that are highly coupled. I'm not even sure if that's even a problem, unless the coupling is also highly tangled (meaning the connections are coming from too many places).
But if you want to decrease coupling between parts of a system, OOP by itself is not particularly good at it. Even something like an Entity Component System is usually less coupled than most OOP codebases because while each System is heavily coupled to the components they do work on, the Systems are usually fully independent from one another and easily replaceable.
Yeah you're right. It's an oversimplification to say components in physical engineering domains have no memory. I was thinking about how logic gates are reasoned about. But that's not the exact point... It's that the argument is usually that OOP cannot decrease coupling. I can't see how exactly. OOP seems to strike a balance between good enough modularity and expressive power enough to keep your system directionally loosely coupled. Infact, I'd say that, I my experience, lots of the coupling between modules is inherent to the 'specifics' of the system's design requirements itself. This is where sometimes within the same logical subsystem/component you could find multiple design patterns all deployed in the bid to reduce coupling. I don't think this is OOP's fault directly as opposed to the 'devil that is in the details'. But maybe I don't have enough experience or exposure yet (I'm a 2nd-year junior)
No it is not a fault of OOP, it is just that OOP does not really provide the tools to help either. It is the fault of people with the wrong expectations or of those trying to sell snake oil.
OOP allows to create decoupled systems but it doesn't help in creating them. It is not an inherent property of the paradigm, but many people sold it as such.
"Use OOP and your application is now magically more modular! Buy my latest book to find out how!"
Since you mentioned you are a junior I guess this sort of nonsense is from before your time. No worries, that just means you won't have stupid dogma shoved down your throat. Use whatever paradigm if it helps you and avoid whatever gets in the way.
Linda and Syndicate figured this out - it’s just that most engineers are not programming language designers or researchers, and most researchers are not designing robust scalable language implementations.
It's crazy to me that Linda came out 40 years ago. I think our field is completely blind to what was achieved in the past.
Smalltalk is to me the most obvious case where people somehow don't realize we had a fully live environment, where the entire IDE (or really the whole operating system) could have open heart surgery done on it while it was running, in the late 1970s!
And that's a language that is at least somewhat in the public consciousness, languages like Linda? Nobody knows them. Synchronous languages like Lustre and Esterel? Some engineers know them (and pay good money for them), but not software engineers.
I dislike OOP as much as the next HN commenter, but dependency injection tools are good in principle. OOP just uses them much more and for bad reasons.
OOP isn't why they are used. OOP may enable injection more than others, but it is not encouraged. Bad programmers and bad architects is why it is overused not OOP. Keep the blame in the right place.
Dependency Injection frameworks are a workaround for limitations of the paradigm, much like Design Patterns also are. They're necessary (by a very stretched definition of necessary) because people want to do certain things and the paradigm is fighting them.
Some part of the code wants to do logging. The paradigm-native solution is to just instantiate a logger object directly, but that's not really what you want to happen, because there are application-level concerns as to where those logging messages should go.
So instead of a direct new, you create a Logger interface (extra work), then use the Factory pattern (extra work) to hide the concrete logger objects that get instantiated. Ok, but now you are still creating multiple independent loggers, which will trample on each other.
So you employ the Singleton pattern (extra work), but now you can't use different loggers for different parts of the codebase.
Ok, let's instead have the application instantiate the proper loggers, and then thread them through method arguments as needed (extra work).
But now passing all those loggers around is super annoying and extremely noisy, so you create a framework that can inject them where they are needed.
Great, now you have a whole framework just to pass some logger objects around. The framework is not the problem per se, it exists for a reason, the problem is that someone felt the need for it. And it is a massive pile of complexity that is NOT worth it.
There are definitely cases where you could have a module with distinct responsibilities; so you can definitely get high cohesion and loose coupling without OOP, that's true, but there are cases where you may want to:
- Control the timing of when a module is activated (instantiated).
- Have multiple instances of a module with variations in functionality where those variations are not a concern to the parent module/instance.
For me, this is when OOP becomes most useful. If I can write some code once and later use it to create any number of independent instances with the same functionality which can clean up after themselves, this is generally a lot more maintainable than having one module to keep track of all the different states in an array and micromanaging (for example) the rendering and cleanup work associated with multiple distinct pieces of state.
To be clear I'm not arguing against objects here, I don't disagree with anything you wrote. I'm only arguing against the somewhat commonly held idea that OOP helps with loose coupling.
Interfaces (a feature of OOP) can be used to decrease coupling, but the paradigm itself doesn't really provide any assistance in regards to coupling.
The default is for objects to directly instantiate other concrete objects and to be able to directly communicate with any object they at any point come in contact with. That is strong coupling, by default.
You have to do extra work to get looser coupling. Smalltalk style OO is much better (regarding coupling) because you don't have explicit interfaces, you can always replace an object with another. You can also query all live objects of a certain type and replace all of them with a proxy if you so wish. Way better.
But you can go even further in regards to loosening coupling. You can have objects communicate through a tuplespace (Linda), you can have objects receive and send messages only through ports, you can have objects send a message to their implicit parent who is then responsible for redirecting it.
Mainstream OOP is a very poor paradigm full of issues that gets mogged by everything.
Composition-over-inheritance is an admission of defeat for a paradigm that lacks native delegation support (good on Kotlin for realising this).
It even gets mogged by languages like Haskell that introduced the more loosely coupled idea of typeclasses, which were inherited by Rust (traits), Swift (protocols), Go (interfaces, not to be confused with declaration-time interfaces as in Java).
We dug a suboptimal hole and stuck our head in there for 50 years.
I think OOP helps to build loosely coupled systems but it doesn't protect you from tight coupling. You have to know what you're doing.
I think OOP languages made some pragmatic decisions. Sometimes a feature which is harmful 95% of the time could be genuinely useful and safe 5% of the time... Some languages like Haskell might choose to not allow that feature at all and force the developer to find another approach which is almost as effective for that 5% of cases; that's fair enough. It's a different philosophy.
I feel like that about passing mutable objects by reference. I find it harmful most of the time but there are rare cases were it's convenient and beneficial. I've worked on open source projects were I wanted the user to be able to use the software with any database so my function accepted a database adapter as an argument.
I could have achieved a similar goal in another way but I would have had to sacrifice separation of concerns slightly. I wanted the ability to substitute any database but also wanted the component to be responsible for the persistence and recovery of its own state as this was within its responsibilities. Also this was the only violation in the entire codebase so I deemed it acceptable. It didn't pose any problems at all in practice.
I think dogma is far worse than "tight coupling" or introducing mutation or even inheritance when it is the simplest and most direct solution to a problem. People get too hung up on the "ideal" way to do things.
I can criticize a paradigm while also using it anywhere and everywhere it benefits me ;)
This resonates strongly with me, which is why I find more important having some form of namespacing than anything else.
OOP has been muddied so much too, it would be interesting if we taught only the "separation of responsibilities" part and principles related to that.
Often it comes up: who has write authority, that's something we don't teach as part of OOP, yet realizing that only one thing should do writing improves the code dramatically.
> I think the actor model comes closest to Kay's objects.
It's rather the other way round. There is no pre-Hewitt implemented semantics matching Kay's later 2001 claims; Smalltalk-72 was a synchronous token-stream interpreter rather than a system of independently active message-driven agents; FLEX shows processes, scheduling and quasi-parallel control, not objects, not messaging, not actor-style autonomous entities.
I too think that microservices and REST are Kay OOP, although through a network boundary of course
The separation of objects and usage of network protocols naturally forces interaction via communication and not data sharing, so perhaps as an emergent phenomenon it converges on Kay OOP. Although no doubt Netflix Microservice OG engineers were influenced by both Kay and Java.
For most developers OOP seems to be just a handful of memes they are vaguely aware of and a kind of generally irritating sense of things not quite working in Java. No amount of writing, discussions, examples and history will change this.
AFAIU, Simula focused more on types and inheritance and less on late-binding, in particular not of "all things".
Alan Kay's distaste for (static) types is just his opinion and an original contribution of IMO rather dubious value.
After the dust has settled, it seems like the most valuable parts of OOP are private data, convenience (no need to repeat the class name in a method call), good fit for some domains, and interfaces.
And the price for this is constrained flexibility and utility.
Data has value and utility on it's own --- as much as if not more than code that manipulates it. It is often not possible to foresee all the ways it can and will need to be used. So why bind anything to it?
Relational databases were invented to provide flexibility with regard to data. OOP tries to encumber it --- often referred to as an "impedance mismatch".
Proper designed modules also don't expose more than the essentially necessary on their public interface.
Failure to understand this is what leads many into microservice hell, as they try to impose a OS process wall as solution to having failed to properly design a modular architecture.
So what could perfectly be a module with direct calls, ends up being a process talking over IPC mechanisms and much higher latency, with the added fun of distributed systems.
Ironically pretty much OOP without any of the language support.
It's really not clear whether Rust does it or not and it just sidesteps the issues by calling them “structs” and “enums” but fields can be private of course.
Scheme Structs are rather interesting, when you define a struct the language by default also exports getter and setter functions with a predictable name though you can override the default name to give them any name, privacy is simply created by choosing to not export these getter and setter functions from the module.
Privacy on the module level rather than on the class level is a far better pattern to be honest. As in other classes defined in the same module can still have access to them.
> After the dust has settled, it seems like the most valuable parts of OOP are private data, convenience (no need to repeat the class name in a method call), good fit for some domains, and interfaces.
Kay also considers CLOS and related things “true OO” and those do repeat class name in method call.
In particular the "Smalltalk-72 school" which had indeed something like "message passing" (though still synchronously). Starting from Smalltalk-76, and particularly in Smalltalk-80, which is the Smalltalk we know today, the object model pretty much corresponds to Simula-67, with compiled methods dipatched via virtual method tables. The only difference is, that in Smalltalk, the dispatch goes via the internalized string address of the selector (vs. method index as e.g. in Simula-67, C++ or Java). See e.g. https://dl.acm.org/doi/10.1145/3386335.
There was a Soviet philosopher, Evald Ilyenkov, whose books taught me about a "minimal working model". I'll explain it in my own words.
People do not think with words: people think with things. Words serve merely as pointers to things. Some things are easy to point at; Ilyenkov talks about a cow. Some things are much harder to point at; Ilyenkov, being a Marxist, wanted to point to private property, we need to point to an object. Usually we try to talk about them using definitions, that is some sequences of words that are supposed to describe a thing. Such discussions are notoriously unproductive. The reason is that words are not really good as pointers: we have much more things than we have words and we have to reuse the same words to point to different things in different contexts. Yet in a phrase words look same so we tend to conflate these different things. As a result we get lost and go around in circles.
So instead of definitions Ilyenkov talks about a notion. Notion is something that reliably points to a thing that is hard to point at. It does not have to be an abstract thing: for example, we cannot point to radio. We can point to a household radio apparat but it has way too many parts completely unrelated to radio as a principle. So instead we build a minimal radio that has like three or four parts yet is capable of emitting or receiving radio waves.
We can do the same with abstract things too using the same approach. Let's build a minimal working model of a thing. "Working" so that the model indeed has the quality we are after; and "minimal" so that if we lose a single part, the quality is gone. Since the thing is abstract the model will also be abstract, that is it will be a sequence of words too, very much like a definition, but not quite.
(The same principle is widely used in parables: they describe some situation and thus try to guide your attention to certain qualities of it, hoping to trigger understanding. Sometimes it is hard to even name the thing they are pointing at, yet their pointing power is palpable. I myself often think about the parable about seven blind people and an elephant. You see I'm not naming the thing it points at: I don't have a good name for it.)
So let's go back to object oriented programming. What would be a minimal working thing that we can reliably call an object?
Here is what cannot be there. First, there must be no inheritance. If inheritance were required, then the first thing we build wouldn't be an object as it would have nothing to inherit from. Only the second thing would be an object and only because it inherited from the first. But this does not seem right. Second, there must be no polymorphism on the same grounds.
But at the same time if we do this:
class Aaaa
method bbbb():
...
then it is too minimal. It is hard to say how it is different from a function. It is not an object at all. Yet; there is a missing part that would turn this into a true object, but what the part is could be somewhat surprising.
side note, when first transistor-based portable radios showed up (as opposed to large lamp-based stationary devices), they were called "transistor". you would take not your portable radio with you, it was your transistor.
Data will indeed be necessary. But data in OOP are interesting: they are not supposed to be directly visible. They are like the method body: there is one, but it is not important what it is. So if we add data, it will be that:
Yes, it is an object now, at least in my book. Public/private is less important, there are examples of OOP systems with private data being optional or non-existent at all, for example in Python.
Thank you Mikhail. I'm reading a lot of metaphysics, and thinking hard about the nature of programming and object orientation, so I appreciate your philosophical approach to the problem. I wasn't aware of Ilyenkov.
To answer your question:
> What would be a minimal working thing that we can reliably call an object?
Also check out the primary author's work on COLA as well for mind-bending possibilities this would unlock.
> First, there must be no inheritance.
The paper uses inheritance, but I've been exploring the same concepts WITHOUT it, and it works as well, if not better. Composition and delegation are more flexible. My current working theory is that inheritance is overrated at best, and too dangerous in the hands of common mortals, because it makes you think on the level of idealized categories rather than concrete things.
Inheritance is both good and not so good. The problem it solves is in a way unique and the very fact that it solves it is indeed quite a feat. But the solution is rather crude.
In a comment nearby I put out a theory that an object is essentially a managed computation, a computation that is driven by external events. What inheritance does is that it allows us to meld two or more such computations together in a relatively seamless way.
Again, a simple but maybe not a minimal model could be that. We have a set of collections: linked list, queue, AVL tree, etc. Most of them do not have a built-in way to count the number of objects they contain. Some do; e.g. an array, but many do not. But, of course, it is not that hard to add it to any collection. Assuming we have 'Init', 'AddElem' and 'RemElem' all we have to do is to add a counter that is set to 0 at 'Init', increment on 'AddElem' and decrement on 'RemElem'. Then we could read the current value with 'NumElems'. At the same time if we do not need a counter, then we should not add it to avoid extra work. So it looks like it would be nice to somehow extract the idea of a counter into a separate computation and then add it to a collection as necessary.
Inheritance allows us to do that in a uniform and general way and this is surely a remarkable achievement. But its solution is not simple. E.g. I have no idea what is the best way to inherit here and am afraid we'll end up with a separate variation for each collection. Yet the concept of what we are after is basically that:
aaaa = new LinkedList;
bbbb = new LinkedList + Counter;
Of course it may require special definitions at the class level, but otherwise the result should be that simple, because these are all the distinctions that are important in this context.
I believe what's missing is not just data. That'd only grant it capabilities that upgrade it to a "record" type of entity. I believe an OOP object is more than a record. It's missing behavior triggered by messages. For an object to pass or receive a message we need to have a model of a message and that requires the notion of a sender and receiver, both objects again. Seems circular, but I'm sure it could be made to work if you properly define everything. Anyway, to my mind perhaps the minimal model of an object is not at all _one object_ but a _relation_ between two or more objects showcasing the minimal "message passing" semantics.
Weird take, but inheritance could be included if you accept something can inherit from itself. A is a type of A, I mean it doesn't strike me as wrong, but it is unconventional.
Behavior is a good clue. The current model, even with data, lacks behavior. It has a method, which is like a message we send to it. But it does not seem to give it enough behavior, even though we don't make any assumptions about its complexity.
Or maybe it could give it behavior if it were like that:
class Aaaa
[some data]
method handle(message, ...)
[some code]
This construction implies there are multiple messages. "Multiple" is the key difference. The part that was missing in the original sketch is a second method:
Now this is an object. For example, it can be a random number generator: we initialize it and then read next numbers. Or it could be a timer: we initialize it and then read the value. We do not need a fully object-oriented environment for that; there is a plenty of such things in C and other non-OOP systems.
Such a thing surely has some behavior and this is exactly what we use. We are not interested in the internal data much. In fact the internal data of an object play exactly the same role as a function stack frame: it is a private slice of memory a computation keeps for itself because this is how it works. As in knitting the size of the manipulator is tiny compared to the final result and to do anything substantial we need a place to keep stuff around until we are done. And we need to be sure data stay were we've put them, hence encapsulation.
So an object is very much like a function, it is a computation that uses some memory to do its job. It is different in that in an object the computation runs step-by-step guided by external events. A function is like an object that gets the whole sequence of events at once, runs from start to finish and in the end discards the working memory so we tend to forget it exists. An object runs from message to message and keeps the working memory, which we see as "object data". This is why objects arise naturally in areas like user interface where events are truly external. But an object is actually a primary form of computation: if you can process a single event, you can use it to process a sequence; but if you can only process the whole sequence, you cannot just switch to processing single events. There are many similarities with closures, coroutines and such; I'd say they are different ways to express the same principle.
(This also means that objects are naturally mutable. Immutable objects are an aberration that arose because we've got here in a very roundabout way.)
So you say an object is like a computation stretched over time and a function that same computation but compressed into a single invocation? Like an object is a computation whose execution is suspended between messages? I can see how that ties closures, co-routines, etc together. They are all machinery to preserve execution state across time.
Generally you could say computation is traversal through a space of states and in that frame objects expose the intermediate states, the guts so to speak, and functions hide them and only expose the in-out mapping.
I feel these are two poles of some deeper principle. Ah man, I'm not well-read enough to go further than this. I kind of worry why most developers are not deeply familiar with this material because these things will inform many foundational choices we make in system architecture and we'd definitely could use some better shared vocabulary and argumentative machinery than mere opinions and "that's how we always do it".
Yes, this is exactly what I'm saying. Objects, closures, co-routines and eventually state machines, which was the first concept, I think, all revolve around the same core thing.
We keep returning to it because this is the natural way to do computation using a machine, but we also try to escape because it is rather hard for a human. We like the functional form more: it looks sequential and goes nicely from start to end. With objects we quickly lose our way in a soup of small parts.
Foundational source nowadays. Cited by wikipedia on the topic of OOP
I have personally taken to calling OOP either Kay OOP or Java OOP to differentiate between the original more philosophical meaning, and the later language imposed features.
Alan Kay's definition of OOP is my favourite one, though
I actually extended it a bit; for instance, erlang/elixir
kind of have "failsafe, reliable objects". Now, barely anyone
would call these languages OOP, but IMO it follows just logically
similar to Alan Kay's definition. Probably a new language may be
required, which is hard to do (make it a succes, that is hard),
but along those lines of having a wider definition of OOP. What
I definitely hate is the limitation towards C++ and Java. Those
two languages really messed up the OOP term, and then we had
clown languages such as PHP just copy/pasting that definition
and not understanding what OOP is really all about.
I studied the history of OOP a while back because I was curious, and I organized what I learned into my personal wiki[1]. From what I remember, there were quite a few different perspectives on it. One view traces OOP's practical ancestry back to Ole-Johan Dahl's Simula. From Alan Kay's perspective, on the other hand, an object was something like a small computer of its own.
The two main lineages of OOP are Simula and Smalltalk. But from what I recall, modern languages actually inherited more from the Simula side in practical terms, while the terminology and philosophy were influenced more by Smalltalk. [1]https://www.makonea.com/en-US/wiki/object-oriented-programmi...
Cool; though a few facts on your landing page might need some reconsideration. See e.g. https://news.ycombinator.com/item?id=36879311.
> something like a small computer of its own
Which corresponds pretty well with the Simula I concept, published 1966 in the Communications of the ACM. A Simula event notice (time, process) in the sequencing set is just a message step(process, time) in a priority mailbox; the two are the same mathematical object, making Simula's discrete-event active processes and Kay's message-passing active objects trivially isomorphic.
thanks! I checked the link and there are indeed quite a few inaccuracies in the initial part. I'll go through it and make corrections.
The IEEE milestone about OOP is also worth reading: https://ethw.org/Milestones:Object-Oriented_Programming,_196...
Thank you so much. Sometimes I wish there were more documents out there that organized the historical aspects of programming like this.
You'd probably like the work of Tomas Petricek: https://tomasp.net/
He does research in "the history and philosophy of programming", amongst other things.
Amazing. This is exactly the kind of content I wanted to put on my homepage. Thank you
Depends on the language. I would argue that ruby inherited more from Smalltalk than from Simula, for instance.
“I wanted a scripting language that was more powerful than Perl, and more object-oriented than Python" and "Ruby's class library is an object-oriented reorganization of Perl functionality--plus some Smalltalk and Lisp stuff" (see "An Interview with the Creator of Ruby", 2001, https://web.archive.org/web/20041220041220/http://www.linuxd...).
You might like Casey Muratori's "The Big OOPs" talk about this, if you haven't seen it yet: https://www.youtube.com/watch?v=wo84LFzx5nI
It's my favorite deep dive into the subject, it's super thoughtful and well structured.
This comment was dead for some reason; I vouched for it. Casey Muratori is a well-known developer with a GUI/game engine background, which gives him a valuable perspective on OOP. In both domains, OOP is both popular and problematic, and his experience suggests that he might know what he's talking about. I didn't watch the whole video, but from the description and intro, it seems to fit the discussion we're having here.
Too late to edit, I watched the talk. Really well-researched and entertainingly told story.
I'd say games are a bit special, though. Smalltalk works pretty well in interactive applications - while it's true that encapsulation is an important part of the language, it also provides all the tools to pry objects open when needed. Out of the box, it's much better at that than C++. The problem is that video games demand very high performance, and Smalltalk is even slower than normal when you use reflection. If not for that, it's perfectly doable (if not very convenient) to treat a Smalltalk image as a soup of data with behavior attached. Casey also mentioned the focus on education in Alan Kay's projects: it's probably one of the reasons Smalltalk is largely devoid of modules, namespaces, packages, and even files with source code - things that are very useful when collaborating in teams, consuming external dependencies, etc. There are Smalltalk implementations that provide those, but they're either very niche or very niche and extremely expensive... And still slow.
Still, interactive software that doesn't have the performance requirements of games is definitely more convenient to write in Smalltalk than in C++! I have high hopes for GToolkit, I just need to port a few ideas from VisualWorks and figure out how to actually set up a project structure friendly to external agents (the GT agent harness is very nice, but it forces you to use an API, which is way too expensive for the results you get...)
I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages
It was originablly conceived as a simulation of a distributed system.
Distributed systems can be useful but does anyone really believe that they are simpler or easier to develop and maintain?
The amazing part to me is that so many were trained and convinced to accept that adopting this simulation could make all programming easier or somehow "better". As if adding complexity would magically lead to simplification.
Generally speaking, toy examples can always be made to look simple. In reality it often means the “hard part” was moved into the shadows, not actually solved.
Graphical programming like LabVIEW looks very appealing. The product demo practically sells itself. Sure, it fits well for a very narrow class of use cases. But even fairly simple things in a textual language quickly become an unwieldy mess. (Try factoring an integer in it…)
There are formal models for distributed systems often solve the “easy” problems that didn’t need solving while making various practical concerns harder/impossible such as timeouts or node failure.
> Distributed systems can be useful but does anyone really believe that they are simpler or easier to develop and maintain?
I believe that programs written in languages made for distributed systems are simpler and easier to maintain.
Also I believe that one of the major problems in modern computing is that most languages we use do not understand that even trivial programs require ‘communication’ and OS/hardware facilities that have behaviours of distributed systems such as latency, transient faults, etc.
Just a guess, it may be that he understood distribution more as the static distribution of meaning in fine grain entities (objects) to allow a wide range of context, flexibility. Not necessarily the time aspect of distribution.
>Distributed systems can be useful but does anyone really believe that they are simpler or easier to develop and maintain?
If you try to maintain a decentralized system, it will be hard yes.
However if you see the nirvana and try to maintain the parts of the system, it will be easier.
> Distributed systems can be useful but does anyone really believe that they are simpler or easier to develop and maintain?
Dinosaur. Whale.
I think these were success stories for a long time. So, it is possible to develop and maintain complex systems.
People are going to come out of the woodwork to argue about OO specifically, and I'd probably join in, but the higher-level view that I've come to over the years is that one programming paradigm is not the best in all situations. It really helps to work on a lot of different systems that are not all in the same class and look at a lot of code written by people of all skill levels. It's not possible to really talk about all programs, but I will say that the OO way of thinking can very easily be overdone and end up a giant mess. Similarly, the FP way of thinking can also be very easily be overdone and end up a giant mess. The old-style procedural programming (C with a pile of global variables) can easily be overdone and end up a giant mess. Yet all three of those can actually work out great at the right scale on the right problem!
I think the problem is that we can't really architect a program well until after it works and fulfills all of its design requirements. Those are usually in flux and then we have to engineer dimensions of extensibility to prevent committing to the wrong architecture in the beginning. Those extra dimensions of extensibility come at some cost too, as they often mean indirection and cognitive overhead.
We often don't write the same program twice, or even three times, unless it's a really important program or a we just like doing it. Contrast to other fields, e.g. building houses, where we have lots and lots of examples of how to do it and they started to form archetypes. We try to call those design patterns in programming, but they're actually pretty vague and low-level. Can you imagine going to build a house and thinking "yeah, I think I need to use the wood-and-nails design pattern here, and I think I'll do rafters-and-shingles there, with some brick-and-mortar there." Yeah, real specific ideas on how to do it.
I actually do wonder whether we're going to see more of a prevalence of people building one off software due to an increasing use of LLM's which makes the house building model you're describing more common in software
I think the underlying error - is the assumption that everyones model is going to be equal when looking on the world, as a world of objects. That holds up- for a surprisingly small number of objects we all interact with.
Then it breaks down- depending on how deep your abstraction level goes (A car has 4 tires. 4 tires are made of: xyz). It also breaks down, with the abstraction in the real world above the modeler. Some think in organization, some in physics, some in tribalist constructs, some imagine a god object above them some don't. It was communicated as a tool using "shared" state as a communication helper.
But we do not share as much state as expected.
IMO, the most important philosophy in all of software engineering is "Separation of responsibilities." The best way to achieve it is through the principle of "High cohesion, loose coupling."
OOP is just another layer of philosophy which builds on top of that. It's more specific, imposes additional guardrails. It requires objects with state encapsulation (locality) and message-passing as the mechanism for components to interact with each other; each component is responsible for changing a subset of the state of the system. Each component is responsible for handling messages (calls to action) by performing local state changes and potentially also sending messages to other components which have more specific sub-responsibilities.
OOP without "High cohesion, loose coupling" is almost worthless IMO. It must build on top.
I think were most people fail with OOP is that they think coming up with good separation of concerns, good abstractions is easy. They just start implementing the first idea which comes out of their heads and then figure out the scope of responsibilities as they go.
The test for good separation of concerns is that you should be able to explain your architecture to someone with the intellect of a 9 year old child who happens to understand the business domain. I'm not exaggerating. It has to be that obvious or else you will not be able to maintain clean separation... You will not be able to maintain alignment in your team.
If the responsibilities of a specific object are somewhat vague, what will happen is that the scope of responsibilities between objects will soon blur and the messages between objects will start to look increasingly elaborate; your system will look like a bunch of horrible incompetent managers trying to micromanage junior employees using long, convoluted instructions and occasionally throwing chairs at them...
If your system is passing around object references all over the place; that's usually a sign of poor separation of concerns; passing around complex objects by reference is tight coupling, by definition. Each object, each person should be able to fulfill their responsibilities and finish the job using communication only.
I agree "high cohesion, loose coupling" is a good architectural property to strive for, but OOP is terrible at it and there's no reason to use it for this.
Trying to achieve "high cohesion, loose coupling" in OOP has led to the creation of (supposedly) best practice recommendations like the SOLID principles, and the development of monstrosities like dependency injection frameworks.
If OOP was actually good at "high cohesion, loose coupling", you wouldn't need them.
I think this is looking at what OOP has become (as implemented by systems and programming languages that don't care a wit about what OO was meant to be) rather than what Alan Kay described.
If you think about something like a web server as an object, it has arbitrarily high cohesion and arbitrarily low coupling. You can only communicate to it through messages (HTTP); binding happens at the point in time that the message arrives (notwithstanding that this may be cached in all sorts of interesting ways in the implementation of any given server); and the web server is fully encapsulated (security flaws notwithstanding).
I think it's perfectly reasonable to argue that much of what gets called OOP doesn't deliver on the promise, but then it doesn't deliver on the premise either, and I think these are inextricably linked.
The Alan Kay variant of OOP is superior in this regard, and I'd argue the Erlang variant even more so (Actors are just asynchronous objects).
But both of them are still suboptimal because they allow objects to instantiate one another and to directly communicate with whomever they come in contact with. That creates strong coupling and you have to "fight the paradigm" to avoid it.
Other engineering domains have this figured out: components can only send and receive data through ports, they are never aware of their siblings. Only a component at a higher level of abstraction can decide how the ports of lower level components connect to one another. That completely eliminates coupling.
(You can of course replicate this type of architecture with OOP, but you can also replicate it with any turing complete paradigm, that's neither here nor there)
When you say other engineering domains have figured this out, can you give a more specific example?
Yes, for example if you are doing any sort of mechatronic systems engineering (cars, planes, rockets, etc.), you're typically using tools like Simcenter Amesim or Modelica or Simulink/Stateflow to digitally prototype the system.
These tools are all oriented around blocks with ports. They receive data on their input ports and emit data on their output ports. They do not know where that data is coming from nor where it is going. They cannot instantiate other blocks.
To create a new block you either create a primitive one (described directly in terms of differential equations, since these are physical simulations, or as actual code, be it C or MATLAB or whatever else), or you connect blocks together to form a larger block.
This creates a strict hierarchy, connections between blocks can only happen at the same level of abstraction. You can just rip out a component and replace it with another with the same ports, or with multiple components each filling in part of the job, or you can plop another component in the middle that's only used to process the data inbound and redirect it somewhere else.
This makes coupling extremely loose by design. The paradigm enforces it.
'in->func()->out' work cleanly for physical engineering domains because blocks of computations (or functions) have no memory basically. There's no DB and there's usually no global state in the way you'd mean with classes. I've observed that when you work on complex software, you could play by the ear to enforce 'high cohesion and loose coupling' up to the point to where you've now got a data store holding system state. Based on what I've worked on, this system state is actually user data and then some derivative of the system's own interaction on this user data, both of which are necessary for the 'continuity of system runtime'. For example, working with redis as the primary data store, I extracted different types of redis calls for specific keys, (like set [specific_key], get [specific key], etc.) into functions, then I put these functions into a StateStore class so I can simply call StateStore.get_user_data() or StateStore.set_user_data() etc from any module across the entire system. From first principles, this is great modularity and high cohesion but it's very tight coupling around a single module i.e. StateStore. Any change in that module means I'd have to find all references for that updated function and cross check for any contract violations. It's difficult for me to see how software can purely be 'High Cohesion and Loose Coupling' regardless of paradigm or architectural pattern. There's always gonna be an unavoidable and inevitable principle violation that's simple a result of a large complex system actually doing many little things that come together to actually do one big thing. The software itself, no matter how complex, IS the blackbox where data goes in and something comes out but that's the user perspective not ours as the programmer. I think the idea I'm trying to hint at is that software cannot have every module independent of every other one. That's impossible. If nothing depended on anything else, the system wouldn't do anything. Rather than have every module know redis keys, States tore actually concentrates coupling into one place, which is exactly what high cohesion tries to accomplish. I think that's the idea I'm chasing.
It's not really true that components in physical engineering domains have no memory. The behavior of many physical components can only be described with access to a recent history. Other components, specially controllers, are typically state machines (which obviously have state).
But it is true that there will always be parts of a software system that are highly coupled. I'm not even sure if that's even a problem, unless the coupling is also highly tangled (meaning the connections are coming from too many places).
But if you want to decrease coupling between parts of a system, OOP by itself is not particularly good at it. Even something like an Entity Component System is usually less coupled than most OOP codebases because while each System is heavily coupled to the components they do work on, the Systems are usually fully independent from one another and easily replaceable.
Yeah you're right. It's an oversimplification to say components in physical engineering domains have no memory. I was thinking about how logic gates are reasoned about. But that's not the exact point... It's that the argument is usually that OOP cannot decrease coupling. I can't see how exactly. OOP seems to strike a balance between good enough modularity and expressive power enough to keep your system directionally loosely coupled. Infact, I'd say that, I my experience, lots of the coupling between modules is inherent to the 'specifics' of the system's design requirements itself. This is where sometimes within the same logical subsystem/component you could find multiple design patterns all deployed in the bid to reduce coupling. I don't think this is OOP's fault directly as opposed to the 'devil that is in the details'. But maybe I don't have enough experience or exposure yet (I'm a 2nd-year junior)
No it is not a fault of OOP, it is just that OOP does not really provide the tools to help either. It is the fault of people with the wrong expectations or of those trying to sell snake oil.
OOP allows to create decoupled systems but it doesn't help in creating them. It is not an inherent property of the paradigm, but many people sold it as such.
"Use OOP and your application is now magically more modular! Buy my latest book to find out how!"
Since you mentioned you are a junior I guess this sort of nonsense is from before your time. No worries, that just means you won't have stupid dogma shoved down your throat. Use whatever paradigm if it helps you and avoid whatever gets in the way.
Linda and Syndicate figured this out - it’s just that most engineers are not programming language designers or researchers, and most researchers are not designing robust scalable language implementations.
It's crazy to me that Linda came out 40 years ago. I think our field is completely blind to what was achieved in the past.
Smalltalk is to me the most obvious case where people somehow don't realize we had a fully live environment, where the entire IDE (or really the whole operating system) could have open heart surgery done on it while it was running, in the late 1970s!
And that's a language that is at least somewhat in the public consciousness, languages like Linda? Nobody knows them. Synchronous languages like Lustre and Esterel? Some engineers know them (and pay good money for them), but not software engineers.
I have fond memories of bricking my Smalltalk environment several times trying to get instance behaviour working :-)
I dislike OOP as much as the next HN commenter, but dependency injection tools are good in principle. OOP just uses them much more and for bad reasons.
OOP isn't why they are used. OOP may enable injection more than others, but it is not encouraged. Bad programmers and bad architects is why it is overused not OOP. Keep the blame in the right place.
Dependency Injection frameworks are a workaround for limitations of the paradigm, much like Design Patterns also are. They're necessary (by a very stretched definition of necessary) because people want to do certain things and the paradigm is fighting them.
Some part of the code wants to do logging. The paradigm-native solution is to just instantiate a logger object directly, but that's not really what you want to happen, because there are application-level concerns as to where those logging messages should go.
So instead of a direct new, you create a Logger interface (extra work), then use the Factory pattern (extra work) to hide the concrete logger objects that get instantiated. Ok, but now you are still creating multiple independent loggers, which will trample on each other.
So you employ the Singleton pattern (extra work), but now you can't use different loggers for different parts of the codebase.
Ok, let's instead have the application instantiate the proper loggers, and then thread them through method arguments as needed (extra work).
But now passing all those loggers around is super annoying and extremely noisy, so you create a framework that can inject them where they are needed.
Great, now you have a whole framework just to pass some logger objects around. The framework is not the problem per se, it exists for a reason, the problem is that someone felt the need for it. And it is a massive pile of complexity that is NOT worth it.
There are definitely cases where you could have a module with distinct responsibilities; so you can definitely get high cohesion and loose coupling without OOP, that's true, but there are cases where you may want to:
- Control the timing of when a module is activated (instantiated).
- Have multiple instances of a module with variations in functionality where those variations are not a concern to the parent module/instance.
For me, this is when OOP becomes most useful. If I can write some code once and later use it to create any number of independent instances with the same functionality which can clean up after themselves, this is generally a lot more maintainable than having one module to keep track of all the different states in an array and micromanaging (for example) the rendering and cleanup work associated with multiple distinct pieces of state.
To be clear I'm not arguing against objects here, I don't disagree with anything you wrote. I'm only arguing against the somewhat commonly held idea that OOP helps with loose coupling.
Interfaces (a feature of OOP) can be used to decrease coupling, but the paradigm itself doesn't really provide any assistance in regards to coupling.
The default is for objects to directly instantiate other concrete objects and to be able to directly communicate with any object they at any point come in contact with. That is strong coupling, by default.
You have to do extra work to get looser coupling. Smalltalk style OO is much better (regarding coupling) because you don't have explicit interfaces, you can always replace an object with another. You can also query all live objects of a certain type and replace all of them with a proxy if you so wish. Way better.
But you can go even further in regards to loosening coupling. You can have objects communicate through a tuplespace (Linda), you can have objects receive and send messages only through ports, you can have objects send a message to their implicit parent who is then responsible for redirecting it.
Mainstream OOP is a very poor paradigm full of issues that gets mogged by everything. Composition-over-inheritance is an admission of defeat for a paradigm that lacks native delegation support (good on Kotlin for realising this).
It even gets mogged by languages like Haskell that introduced the more loosely coupled idea of typeclasses, which were inherited by Rust (traits), Swift (protocols), Go (interfaces, not to be confused with declaration-time interfaces as in Java).
We dug a suboptimal hole and stuck our head in there for 50 years.
I think OOP helps to build loosely coupled systems but it doesn't protect you from tight coupling. You have to know what you're doing.
I think OOP languages made some pragmatic decisions. Sometimes a feature which is harmful 95% of the time could be genuinely useful and safe 5% of the time... Some languages like Haskell might choose to not allow that feature at all and force the developer to find another approach which is almost as effective for that 5% of cases; that's fair enough. It's a different philosophy.
I feel like that about passing mutable objects by reference. I find it harmful most of the time but there are rare cases were it's convenient and beneficial. I've worked on open source projects were I wanted the user to be able to use the software with any database so my function accepted a database adapter as an argument.
I could have achieved a similar goal in another way but I would have had to sacrifice separation of concerns slightly. I wanted the ability to substitute any database but also wanted the component to be responsible for the persistence and recovery of its own state as this was within its responsibilities. Also this was the only violation in the entire codebase so I deemed it acceptable. It didn't pose any problems at all in practice.
I think dogma is far worse than "tight coupling" or introducing mutation or even inheritance when it is the simplest and most direct solution to a problem. People get too hung up on the "ideal" way to do things.
I can criticize a paradigm while also using it anywhere and everywhere it benefits me ;)
This resonates strongly with me, which is why I find more important having some form of namespacing than anything else.
OOP has been muddied so much too, it would be interesting if we taught only the "separation of responsibilities" part and principles related to that.
Often it comes up: who has write authority, that's something we don't teach as part of OOP, yet realizing that only one thing should do writing improves the code dramatically.
Now that you see it, seems so obvious
I think the actor model comes closest to Kay's objects.
An object holds it's own state and might change that state based on messages it receives.
Today you can find this in, for example, Elixir and Microsoft Orleans.
> I think the actor model comes closest to Kay's objects.
It's rather the other way round. There is no pre-Hewitt implemented semantics matching Kay's later 2001 claims; Smalltalk-72 was a synchronous token-stream interpreter rather than a system of independently active message-driven agents; FLEX shows processes, scheduling and quasi-parallel control, not objects, not messaging, not actor-style autonomous entities.
> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
This sounds a lot like microservice architecture.
I too think that microservices and REST are Kay OOP, although through a network boundary of course
The separation of objects and usage of network protocols naturally forces interaction via communication and not data sharing, so perhaps as an emergent phenomenon it converges on Kay OOP. Although no doubt Netflix Microservice OG engineers were influenced by both Kay and Java.
Taken to an extreme. It's not feasible with current microservice architecture to, for example, represent every Boolean in the program as a service.
Feasible with in-process REST.
https://news.ycombinator.com/item?id=48731266
I did not know that was something people had done! Thanks for the pointer!
If I were to quibble, though: in-process implies exactly the absence of the isolation guarantees that OOP!Kay and microservices share.
(The overhead on a Boolean also makes my inner Mel Kaye burst into tears, but that's neither here nor there in this discussion I suppose.)
> Thanks for the pointer!
You're welcome!
> in-process implies exactly the absence of the isolation guarantees that OOP!Kay and microservices share.
OOP objects are in-process and are isolated using language mechanisms rather than machine/process boundaries.
Very similar, yes.
Except that Kay did not envision the distinct computers communicating via REST.
https://blog.metaobject.com/2019/11/what-alan-kay-got-wrong-...
Also: microservices currently require at least process and frequently even VM/Container/Machine boundaries.
In-Process REST scales that down:
https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_...
Language support for In-Process REST:
https://dl.acm.org/doi/10.1145/3359591.3359729
https://objective.st/
For most developers OOP seems to be just a handful of memes they are vaguely aware of and a kind of generally irritating sense of things not quite working in Java. No amount of writing, discussions, examples and history will change this.
That's the Smalltalk school of OOP. There is also the Simula school. It is kind of unfortunate that they use the same name.
> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
How does Simula differ here?
AFAIU, Simula focused more on types and inheritance and less on late-binding, in particular not of "all things".
Alan Kay's distaste for (static) types is just his opinion and an original contribution of IMO rather dubious value.
After the dust has settled, it seems like the most valuable parts of OOP are private data, convenience (no need to repeat the class name in a method call), good fit for some domains, and interfaces.
private data, convenience
Which can be easily achieved without OOP.
That upfront convenience here leads to a long tail of job security when it inevitably goes spaghetti. Win-win!
Spaghetti ~ complexity ~ entropy.
That's the natural order of things that many people work in, I doubt any "general loosely defined paradigm" can be absent from the inevitable.
In fact, to a certain point of view, OOP is a way to have modules bind to variables, and being extensible.
And the price for this is constrained flexibility and utility.
Data has value and utility on it's own --- as much as if not more than code that manipulates it. It is often not possible to foresee all the ways it can and will need to be used. So why bind anything to it?
Relational databases were invented to provide flexibility with regard to data. OOP tries to encumber it --- often referred to as an "impedance mismatch".
Proper designed modules also don't expose more than the essentially necessary on their public interface.
Failure to understand this is what leads many into microservice hell, as they try to impose a OS process wall as solution to having failed to properly design a modular architecture.
So what could perfectly be a module with direct calls, ends up being a process talking over IPC mechanisms and much higher latency, with the added fun of distributed systems.
Ironically pretty much OOP without any of the language support.
It's really not clear whether Rust does it or not and it just sidesteps the issues by calling them “structs” and “enums” but fields can be private of course.
Scheme Structs are rather interesting, when you define a struct the language by default also exports getter and setter functions with a predictable name though you can override the default name to give them any name, privacy is simply created by choosing to not export these getter and setter functions from the module.
Privacy on the module level rather than on the class level is a far better pattern to be honest. As in other classes defined in the same module can still have access to them.
> Alan Kay's distaste for (static) types
Citation needed.
TFA quotes him saying almost the opposite:
> (I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.)
> After the dust has settled, it seems like the most valuable parts of OOP are private data, convenience (no need to repeat the class name in a method call), good fit for some domains, and interfaces.
Kay also considers CLOS and related things “true OO” and those do repeat class name in method call.
> That's the Smalltalk school of OOP
In particular the "Smalltalk-72 school" which had indeed something like "message passing" (though still synchronously). Starting from Smalltalk-76, and particularly in Smalltalk-80, which is the Smalltalk we know today, the object model pretty much corresponds to Simula-67, with compiled methods dipatched via virtual method tables. The only difference is, that in Smalltalk, the dispatch goes via the internalized string address of the selector (vs. method index as e.g. in Simula-67, C++ or Java). See e.g. https://dl.acm.org/doi/10.1145/3386335.
There was a Soviet philosopher, Evald Ilyenkov, whose books taught me about a "minimal working model". I'll explain it in my own words.
People do not think with words: people think with things. Words serve merely as pointers to things. Some things are easy to point at; Ilyenkov talks about a cow. Some things are much harder to point at; Ilyenkov, being a Marxist, wanted to point to private property, we need to point to an object. Usually we try to talk about them using definitions, that is some sequences of words that are supposed to describe a thing. Such discussions are notoriously unproductive. The reason is that words are not really good as pointers: we have much more things than we have words and we have to reuse the same words to point to different things in different contexts. Yet in a phrase words look same so we tend to conflate these different things. As a result we get lost and go around in circles.
So instead of definitions Ilyenkov talks about a notion. Notion is something that reliably points to a thing that is hard to point at. It does not have to be an abstract thing: for example, we cannot point to radio. We can point to a household radio apparat but it has way too many parts completely unrelated to radio as a principle. So instead we build a minimal radio that has like three or four parts yet is capable of emitting or receiving radio waves.
We can do the same with abstract things too using the same approach. Let's build a minimal working model of a thing. "Working" so that the model indeed has the quality we are after; and "minimal" so that if we lose a single part, the quality is gone. Since the thing is abstract the model will also be abstract, that is it will be a sequence of words too, very much like a definition, but not quite.
(The same principle is widely used in parables: they describe some situation and thus try to guide your attention to certain qualities of it, hoping to trigger understanding. Sometimes it is hard to even name the thing they are pointing at, yet their pointing power is palpable. I myself often think about the parable about seven blind people and an elephant. You see I'm not naming the thing it points at: I don't have a good name for it.)
So let's go back to object oriented programming. What would be a minimal working thing that we can reliably call an object?
Here is what cannot be there. First, there must be no inheritance. If inheritance were required, then the first thing we build wouldn't be an object as it would have nothing to inherit from. Only the second thing would be an object and only because it inherited from the first. But this does not seem right. Second, there must be no polymorphism on the same grounds.
But at the same time if we do this:
then it is too minimal. It is hard to say how it is different from a function. It is not an object at all. Yet; there is a missing part that would turn this into a true object, but what the part is could be somewhat surprising.
don't say "apparat" when you can say "device".
side note, when first transistor-based portable radios showed up (as opposed to large lamp-based stationary devices), they were called "transistor". you would take not your portable radio with you, it was your transistor.
I actually wanted to write "apparatus"; not sure if this would be any better though :)
Your example lacks data. An object is the combination of data and code manipulating the data with some syntactic sugar on top
Data will indeed be necessary. But data in OOP are interesting: they are not supposed to be directly visible. They are like the method body: there is one, but it is not important what it is. So if we add data, it will be that:
Do you think this is an object now?
Yes, it is an object now, at least in my book. Public/private is less important, there are examples of OOP systems with private data being optional or non-existent at all, for example in Python.
Thank you Mikhail. I'm reading a lot of metaphysics, and thinking hard about the nature of programming and object orientation, so I appreciate your philosophical approach to the problem. I wasn't aware of Ilyenkov.
To answer your question:
> What would be a minimal working thing that we can reliably call an object?
You might enjoy this paper a lot: https://piumarta.com/software/id-objmodel/objmodel2.pdf
Also check out the primary author's work on COLA as well for mind-bending possibilities this would unlock.
> First, there must be no inheritance.
The paper uses inheritance, but I've been exploring the same concepts WITHOUT it, and it works as well, if not better. Composition and delegation are more flexible. My current working theory is that inheritance is overrated at best, and too dangerous in the hands of common mortals, because it makes you think on the level of idealized categories rather than concrete things.
As further reading, your explanation of things vs words reminded me of prototypes vs classes, so I'll recommend this article by Henry Lieberman: https://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/D...
Thanks, will add that to my reading list.
Inheritance is both good and not so good. The problem it solves is in a way unique and the very fact that it solves it is indeed quite a feat. But the solution is rather crude.
In a comment nearby I put out a theory that an object is essentially a managed computation, a computation that is driven by external events. What inheritance does is that it allows us to meld two or more such computations together in a relatively seamless way.
Again, a simple but maybe not a minimal model could be that. We have a set of collections: linked list, queue, AVL tree, etc. Most of them do not have a built-in way to count the number of objects they contain. Some do; e.g. an array, but many do not. But, of course, it is not that hard to add it to any collection. Assuming we have 'Init', 'AddElem' and 'RemElem' all we have to do is to add a counter that is set to 0 at 'Init', increment on 'AddElem' and decrement on 'RemElem'. Then we could read the current value with 'NumElems'. At the same time if we do not need a counter, then we should not add it to avoid extra work. So it looks like it would be nice to somehow extract the idea of a counter into a separate computation and then add it to a collection as necessary.
Inheritance allows us to do that in a uniform and general way and this is surely a remarkable achievement. But its solution is not simple. E.g. I have no idea what is the best way to inherit here and am afraid we'll end up with a separate variation for each collection. Yet the concept of what we are after is basically that:
Of course it may require special definitions at the class level, but otherwise the result should be that simple, because these are all the distinctions that are important in this context.
Another commenter pointed it out already but might as well stress the point: objects are bundles of data and behavior. Your example is missing data.
That's super interesting. Thank you for that.
I believe what's missing is not just data. That'd only grant it capabilities that upgrade it to a "record" type of entity. I believe an OOP object is more than a record. It's missing behavior triggered by messages. For an object to pass or receive a message we need to have a model of a message and that requires the notion of a sender and receiver, both objects again. Seems circular, but I'm sure it could be made to work if you properly define everything. Anyway, to my mind perhaps the minimal model of an object is not at all _one object_ but a _relation_ between two or more objects showcasing the minimal "message passing" semantics.
Weird take, but inheritance could be included if you accept something can inherit from itself. A is a type of A, I mean it doesn't strike me as wrong, but it is unconventional.
Behavior is a good clue. The current model, even with data, lacks behavior. It has a method, which is like a message we send to it. But it does not seem to give it enough behavior, even though we don't make any assumptions about its complexity.
Or maybe it could give it behavior if it were like that:
This construction implies there are multiple messages. "Multiple" is the key difference. The part that was missing in the original sketch is a second method:
Now this is an object. For example, it can be a random number generator: we initialize it and then read next numbers. Or it could be a timer: we initialize it and then read the value. We do not need a fully object-oriented environment for that; there is a plenty of such things in C and other non-OOP systems.
Such a thing surely has some behavior and this is exactly what we use. We are not interested in the internal data much. In fact the internal data of an object play exactly the same role as a function stack frame: it is a private slice of memory a computation keeps for itself because this is how it works. As in knitting the size of the manipulator is tiny compared to the final result and to do anything substantial we need a place to keep stuff around until we are done. And we need to be sure data stay were we've put them, hence encapsulation.
So an object is very much like a function, it is a computation that uses some memory to do its job. It is different in that in an object the computation runs step-by-step guided by external events. A function is like an object that gets the whole sequence of events at once, runs from start to finish and in the end discards the working memory so we tend to forget it exists. An object runs from message to message and keeps the working memory, which we see as "object data". This is why objects arise naturally in areas like user interface where events are truly external. But an object is actually a primary form of computation: if you can process a single event, you can use it to process a sequence; but if you can only process the whole sequence, you cannot just switch to processing single events. There are many similarities with closures, coroutines and such; I'd say they are different ways to express the same principle.
(This also means that objects are naturally mutable. Immutable objects are an aberration that arose because we've got here in a very roundabout way.)
That's quite the thing to bring up. Wonderful.
So you say an object is like a computation stretched over time and a function that same computation but compressed into a single invocation? Like an object is a computation whose execution is suspended between messages? I can see how that ties closures, co-routines, etc together. They are all machinery to preserve execution state across time.
Generally you could say computation is traversal through a space of states and in that frame objects expose the intermediate states, the guts so to speak, and functions hide them and only expose the in-out mapping.
I feel these are two poles of some deeper principle. Ah man, I'm not well-read enough to go further than this. I kind of worry why most developers are not deeply familiar with this material because these things will inform many foundational choices we make in system architecture and we'd definitely could use some better shared vocabulary and argumentative machinery than mere opinions and "that's how we always do it".
Yes, this is exactly what I'm saying. Objects, closures, co-routines and eventually state machines, which was the first concept, I think, all revolve around the same core thing.
We keep returning to it because this is the natural way to do computation using a machine, but we also try to escape because it is rather hard for a human. We like the functional form more: it looks sequential and goes nicely from start to end. With objects we quickly lose our way in a soup of small parts.
Foundational source nowadays. Cited by wikipedia on the topic of OOP
I have personally taken to calling OOP either Kay OOP or Java OOP to differentiate between the original more philosophical meaning, and the later language imposed features.
Alan Kay's definition of OOP is my favourite one, though I actually extended it a bit; for instance, erlang/elixir kind of have "failsafe, reliable objects". Now, barely anyone would call these languages OOP, but IMO it follows just logically similar to Alan Kay's definition. Probably a new language may be required, which is hard to do (make it a succes, that is hard), but along those lines of having a wider definition of OOP. What I definitely hate is the limitation towards C++ and Java. Those two languages really messed up the OOP term, and then we had clown languages such as PHP just copy/pasting that definition and not understanding what OOP is really all about.