Live data from Hacker News

Alan Kay on the meaning of "object-oriented programming" (2003)

notes.shixiangxi.com

61–70 of 95 posts

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#61
post #4

Earlier quoted context omitted.

> 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 int…

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

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#62
post #13

Earlier quoted context omitted.

private data, convenience Which can be easily achieved without OOP.

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

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#63

Earlier quoted context omitted.

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

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

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

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#64

Earlier quoted context omitted.

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 int…

private data, convenience Which can be easily achieved without OOP.

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.

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#65
post #44

Earlier quoted context omitted.

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

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#66
post #55

Earlier quoted context omitted.

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 fi…

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.

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#67
post #57

Earlier quoted context omitted.

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 fi…

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.

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#68
post #65

Earlier quoted context omitted.

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.

Re: Alan Kay on the meaning of "object-oriented programming" (2003)

#69
post #57

Earlier quoted context omitted.

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 somewha…

I have fond memories of bricking my Smalltalk environment several times trying to get instance behaviour working :-)
Post reply on HN