Live data from Hacker News

Alan Kay on the Meaning of “Object-Oriented Programming” (2003)

purl.org

41–50 of 58 posts

Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)

#41
post #3

Towards the end: But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with "Remote Procedure Call" instead of thinking about objects and messages. Sic transit gloria mundi. Can somebody explain to me what distinction he's drawing here? What's the issue with RPC that's solved by Objects+Messages?

That might be not what Alan Kay meant, but here's one description of fundamental problems with RPC: [1]

[...] the fundamental problem is that RPC tries to make a distributed invocation look like a local one. This can't work because the failure modes in distributed systems are quite different from those in local systems, so you find yourself having to introduce more and more infrastructure that tries to hide all the hard details and problems that lurk beneath. That's how we got Apollo NCS and Sun RPC and DCE and CORBA and DSOM and DCOM and EJB and SOAP and JAX-RPC, to name a few off the top of my head, each better than what came before in some ways but worse in other ways, especially footprint and complexity. But it's all for naught because no amount of infrastructure can ever hide those problems of distribution. Network partitions are real, timeouts are real, remote host and service crashes are real, the need for piecemeal system upgrade and handling version differences between systems is real, etc. [...]

[1] http://erlang.org/pipermail/erlang-questions/2008-May/035209...

Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)

#42
post #3

Towards the end: But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with "Remote Procedure Call" instead of thinking about objects and messages. Sic transit gloria mundi. Can somebody explain to me what distinction he's drawing here? What's the issue with RPC that's solved by Objects+Messages?

A remote procedure call is analogous to an ordinary function call, extended to a remote machine. It is static, perhaps even specifying the code to be executed, and therefore limited. But objects can be understood as independent agents (Kay calls them "real computers"), where a message is a request for some behavior. How the object is to implement that behavior is not specified in the message. Kay gives the example of…

CSS (or more generally the dream of content and presentation separated HTML) might be considered message passing since the browser usually has some freedom with regards to on screen layout (implementation), although in practice many sites specify the message so precisely that only one implementation is possible.

Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)

#43
post #3

Towards the end: But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with "Remote Procedure Call" instead of thinking about objects and messages. Sic transit gloria mundi. Can somebody explain to me what distinction he's drawing here? What's the issue with RPC that's solved by Objects+Messages?

In a Smalltalk-style message passing system, each object has its own little parser. When you send it a message, the object will parse and interpret it however it wishes. Essentially, you send the object a sequence of tokens, it parses the tokens and generates some executable code that it then invokes.

In C# (or Java), it would look something like this:

    interface Message : IEnumerable
    {
    
    }
    
    
    public class Foo
    {
    
    	public void Consider(Object sender, Message msg)
    	{
    		//possibly validate sender...
    	
    		Executable result = this.Parse(msg);
    		
    		if(result.IsValid)
    			sender.Consider(result.Execute(this));
    		else
    			sender.Consider(new MethodMissing());
    	}
    	
    	private Executable Parse(msg)
    	{
		//the ability to parse the message depends on the state of this object
	}
    }
The basic idea is that the object is always in control of what it does. Methods are extremely late-bound because the code for the method may not even exist until the object first creates it in response to a received message.

But, the big idea is that an object is just a little computer, and in a computer system, a computer is the smallest thing that you want to recapitulate.

Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)

#44
post #12

A lot of the recent trend towards OOP-bashing comes from bad implementations of OOP, just as bashing design patterns is more to do with badly thought out architectures and overuse of those patterns. In fact, the origins of OOP are basically what we would now call microservice architecture (CSP-inspired languages like Go being a specialisation of this). Each service can be as stateless or as stateful as it needs to be…

In sports, training coaches sometimes forbid to use some play element. In OOP classes there should be an assignment to design a system without inheritance. Just to show what is most important in OOP.

In Ada, I remember reading that you can limit the inheritance depth.

Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)

#45
> I wanted to get rid of data.

What exactly does he mean by that? How does one get rid of data?

> The B5000 almost did this via its almost unbelievable HW architecture.

I've heard about the B5000 numerous times here on HN. What was so fantastic about it?

Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)

#46
post #12

A lot of the recent trend towards OOP-bashing comes from bad implementations of OOP, just as bashing design patterns is more to do with badly thought out architectures and overuse of those patterns. In fact, the origins of OOP are basically what we would now call microservice architecture (CSP-inspired languages like Go being a specialisation of this). Each service can be as stateless or as stateful as it needs to be…

In sports, training coaches sometimes forbid to use some play element. In OOP classes there should be an assignment to design a system without inheritance. Just to show what is most important in OOP.

How would you design something like :

Person --> Full Time Employee --> Manager

Person --> Contract Employee

Without inheritance assuming that salary calculation is the only thing which differentiates them.

Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)

#47
post #12

Earlier quoted context omitted.

In sports, training coaches sometimes forbid to use some play element. In OOP classes there should be an assignment to design a system without inheritance. Just to show what is most important in OOP.

How would you design something like : Person --> Full Time Employee --> Manager Person --> Contract Employee Without inheritance assuming that salary calculation is the only thing which differentiates them.

Something like...

   Person HAS A IEmploymentRelationship
   ContractEmployment IMPLEMENTS IEmploymentRelationship
   FullTimeEmployment IMPLEMENTS IEmploymentRelationship
   FullTimeEmployment HAS A IDirectReport
   Manager HAS A Person
   Manager IMPLEMENTS IDirectReport
And then salary() is a polymorphic function declared by the IEmploymentRelationship interface, where FullTimeEmployment instances use the manager somehow, and ContractEmployment doesn't.

You can even put some sugar on that by having a salary() function on Person that calls the salary() function on its IEmploymentRelationship—but I wouldn't, for the same reason I wouldn't denormalize a relational database.

Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)

#48
post #35

Earlier quoted context omitted.

First sentence of the next paragraph.

Thanks. I still find it fascinating people do good work without fully understanding an area. It's as if you're not supposed to. I wonder if this could be used as a guiding principle in making things. If what you are working on originally looks understandable, you should be alarmed.

I presume by 'understanding an area' you mean being familiar with established abstract models of that area? I think that often in practical conditions the abstract models are not the area under work. They are the mapping of the area to some formal system. And that the 'area' under question - whatever it may be - can be mapped to an infinite amount of formal systems. For lots of practical purposes, there is some 'obvious' algebra of a thing one wants to do - in these instances all that is needed is an individual who can map the problem to any logically coherent structure, even just a private one in their head, and a willingness to solve the problem - and great stuff can ne done without a literature review. Sometimes the establishes models are really, really good since they either simplify a messy looking problem and/or point out to some not so obvious aspects of a system at which point an expert in the field can have an advantage over the clever layman. I think sometimes the knowledge of existing formal models can make a person blind to certain facets of the system they are working with.

Also, if one approaches a thing by a burning desire just to implement one single thing on top of it they will probably have an internal model that is very much focused on the problem they are solving.This practical need can induce them to create a new formal model or just sidestep lots of non-issues that would be a burden to deal with.

Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)

#49
post #47

Earlier quoted context omitted.

How would you design something like : Person --> Full Time Employee --> Manager Person --> Contract Employee Without inheritance assuming that salary calculation is the only thing which differentiates them.

Something like... Person HAS A IEmploymentRelationship ContractEmployment IMPLEMENTS IEmploymentRelationship FullTimeEmployment IMPLEMENTS IEmploymentRelationship FullTimeEmployment HAS A IDirectReport Manager HAS A Person Manager IMPLEMENTS IDirectReport And then salary() is a polymorphic function declared by the IEmploymentRelationship interface, where FullTimeEmployment instances use the manager somehow, and Contr…

Got it. Thank you.

Re: Alan Kay on the Meaning of “Object-Oriented Programming” (2003)

#50
post #16
post #9

Earlier quoted context omitted.

It seems to me that you can't really do message passing in most languages with high efficiency? (Objective-C and Swift being the exceptions.)

I think it's a bit charitable to call what Objective C does to be "message passing". The messages are not asynchronous and have only a single recipient, so in practice I would say they're method calls with late binding.

However, they can easily be made asynchronous and address multiple recipients. See Higher Order Messaging[1][2], first implemented in Objective-C[3]. So for example:

    [[myView onMainThread] setNeedsDisplay:YES];

    result = [[someObject future] someMessage:arg];

    combined = [[prefixes collect] stringByAppendingString:[suffixes each]];
The reason this is easy in Objective-C is because its brand of message passing is just (barely) powerful enough to qualify as message passing. In fact, if you squint just a little, you can see it as fully reified message passing with the common-case (a synchronous method is invoked) optimized.

[1] http://en.wikipedia.org/wiki/Higher_order_message

[2] http://www.metaobject.com/papers/Higher_Order_Messaging_OOPS...

[3] https://github.com/mpw/MPWFoundation

Post reply on HN