Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

notes.shixiangxi.com

Post reply on HN
Print view View original

81–90 of 95 posts

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

#81

Post by Mikhail_Edoshin »

sph wrote: post #15
Mikhail_Edoshin wrote: post #11

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…

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

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:

    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.

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

#82

Post by Mikhail_Edoshin »

watt wrote: post #12
Mikhail_Edoshin wrote: post #11

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…

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

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

#83

Post by klibertp »

klibertp wrote: post #78
tskj wrote: post #49

Earlier quoted context omitted.

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

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

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

#84

Post by sirwhinesalot »

saint-evan wrote: post #80
sirwhinesalot wrote: post #76

Earlier quoted context omitted.

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, un…

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…

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.

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

#85

Post by sph »

mccoyb wrote: post #57
sirwhinesalot wrote: post #37

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.

Linda: https://en.wikipedia.org/wiki/Linda_(coordination_language)

By Syndicate you mean syndicated actors?

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

#86

Post by sph »

paolfs wrote: post #42

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.

Actors are great, but it’s just making objects large enough so one thinks carefully before architecting a whole hierarchy of them to solve a simple problem.

As someone else said in this thread, OOP is fine for modularity, the problem is people don’t know how modular a problem should be and are driven to overcomplicate the design of any application.

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

#87

Post by sph »

Mikhail_Edoshin wrote: post #79
sdfsdfs34dfsdf wrote: post #63

Earlier quoted context omitted.

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

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

This is known as the object lambda duality which Guy Steele wrote about. If you think hard enough, you reach this core idea that objects and closures are just yin and yang, inseparable.

https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent

So why have objects when you have closures? I believe that by externalising the decision on how to behave when a method (selector) is called, into a concept like a vtable, you can apply greater levels of optimisations.

In other words, a closure is a object that encapsulates (keeps private) the list of function pointers it is able to respond to. This is not necessary, and Piumarta (linked by me elsewhere in this thread) shows you can reach this generalisation well within the OOP system, by making vtables themselves objects which respond to a lookup method that returns a function pointer.

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

#88

Post by saint-evan »

sirwhinesalot wrote: post #84
saint-evan wrote: post #80

Earlier quoted context omitted.

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…

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

I see your angle now. Thanks for the conversation!

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

#89

Post by Kinrany »

sirwhinesalot wrote: post #47
Kinrany wrote: post #41

Earlier quoted context omitted.

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.

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

Ignoring the singleton for now, because I don't quite see the need.

What's the alternative? Which part of this is actually caused by OOP? If you want to isolate IO, which you should, then you need to inject things that do IO and you need to specify a contract for them. And then it's nice to instantiate things or call functions without explicitly instantiating the whole tree of their dependencies.

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

#90

Post by shevy-java »

ahartmetz wrote: post #5
mycall wrote: 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…

> Alan Kay's distaste for (static) types is just his opinion and an original contribution of IMO rather dubious value.

Not at all. matz, creator of ruby, also dislikes static types.

You may begin to realise that good designers and good thinkers dislike something because there are specific trade-offs.

> 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

This refers more to the practicality of an implementation. Ruby was always better implemented than smalltalk, for instance, even though I think most would say that smalltalk is the more "pure" language. Ruby is more practical though, IMO.

I disagree on the "good fit for some domains" by the way. A great programming language is a great fit in any domain. It just also has to designed well, which is hard, and a trade-off.

Post reply on HN