Live data from Hacker News

Alan Kay on the misunderstanding of OOP (1998)

lists.squeakfoundation.org

91–100 of 212 posts

Re: Alan Kay on the misunderstanding of OOP (1998)

#91

I don't really understand this obsession with messages. We're moving away from it. This is not how we program in the 21st century. The last popular language that supported this paradigm (Objective C) is being replaced and will probably be all but gone in just a few years as Swift (not message based) takes it place. Besides, this idea of message passing is really not that useful for modern programming anyway but a lot…

Erlang and Elixir may not meet your criteria of popular, but message passing is one of several closely linked features (including immutability) that collectively make distributed, robust systems much easier.

No, it's not a silver bullet, but neither is it some misbegotten relic of an earlier era as you posit.

Re: Alan Kay on the misunderstanding of OOP (1998)

#92
post #57

Why didn't he call it Message Oriented Programming then? Would have been a much clearer name. But now we have all these clunky OO-systems, that focus on objects and classes and still use functions/methods instead of messages...

Calling a method on an object is a kind of message passing - please take those arguments here, do your thing with them and send me back whatever return value you calculated. This really is just a synchronous exchange of two messages between the caller and the callee (plus you also give your processor to the callee to do his work because while you are waiting for the response you don't need it anyway).

Re: Alan Kay on the misunderstanding of OOP (1998)

#93
post #51

I might be wrong, but I think people like Alan Kay and Christopher Alexander have in common that they: * see that things can be done better (not as in upgrade but best); * have a global idea/feeling of how this could be done; * take a lot of ideas from nature. And somehow I think they have a lot of trouble expressing the 'how'. My take: we should take a good look at nature because this is closest to what we are. For…

Maybe they're reluctant to pick "the" how, too soon.

If you're in a field from the early days, you probably have more of a pioneer or explorer mentality. Later come settlers, who pick areas for utility. Even later come residents, born and raised there, most of whom don't really question what is given.

This probably seems weird and frustrating to the explorers -- why settle so soon? Yes it seems comfortable and convenient, here, but there is so much left to explore.

That's how I understand Alan Kay. He doesn't want to sell us some snazzy next big thing. He wants more of us to spend more time imagining and trying new things.

Re: Alan Kay on the misunderstanding of OOP (1998)

#94

I don't really understand this obsession with messages. We're moving away from it. This is not how we program in the 21st century. The last popular language that supported this paradigm (Objective C) is being replaced and will probably be all but gone in just a few years as Swift (not message based) takes it place. Besides, this idea of message passing is really not that useful for modern programming anyway but a lot…

> The last popular language that supported this paradigm (Objective C)

Ruby.

Re: Alan Kay on the misunderstanding of OOP (1998)

#95

I don't really understand this obsession with messages. We're moving away from it. This is not how we program in the 21st century. The last popular language that supported this paradigm (Objective C) is being replaced and will probably be all but gone in just a few years as Swift (not message based) takes it place. Besides, this idea of message passing is really not that useful for modern programming anyway but a lot…

[deleted]

Re: Alan Kay on the misunderstanding of OOP (1998)

#96
post #82
post #77

Earlier quoted context omitted.

Sort of. AFAIK, cells basically just send out signals and the nearest available cell with a compatible protein that can "read" the signal picks it up.

Well I asked because lets say queuing does not occur, then you might want to design a system that can send and receive messages in without queue.

Definitely. Designing a system where the order of procedures is not certain would be a very interesting challenge and could be very useful.

Re: Alan Kay on the misunderstanding of OOP (1998)

#97
post #90

Earlier quoted context omitted.

What about e.g. HTTP? The dynamics of server to server communication are all about message passing (REST is just a message conveying state, if you ignore the other rules). Look at things like Erlang and Elixir processes. Akka and the actor model. Map/Reduce to a certain extent. These are all founded on the idea of giving a task out with enough information that the worker can reasonably go and work on the task without…

Message passing implies one way broadcast. Think GOTO. HTTP is a request / reply protocol, i.e. a function call. Map / Reduce is an implementation device for SQL-like collection-based processing, modern Map / Reduce systems [Google's Flume / Dataflow] offer directly the collection API, using Map / Reduce as an implementation detail. FRP is a device for adding a collection API on top of streams of events. Collection A…

> Message passing implies one way broadcast.

Can you explain that since its contrary to my experience. PDO and normal Objective-C methods had a return and are not one way.

Re: Alan Kay on the misunderstanding of OOP (1998)

#98
post #82
post #77

Earlier quoted context omitted.

Sort of. AFAIK, cells basically just send out signals and the nearest available cell with a compatible protein that can "read" the signal picks it up.

Well I asked because lets say queuing does not occur, then you might want to design a system that can send and receive messages in without queue.

...that would be a function call (if synchronous) and a simple event in the asynchronous case.

Re: Alan Kay on the misunderstanding of OOP (1998)

#99

Earlier quoted context omitted.

As defined in both RFC 1945 and 2616 (that is, as always has been defined): "The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI." The thing is that there's no difference between abstract and concrete semantics in terms of definition of what is a function or message and what is not. You can send a message or call a function with very concrete semantics ("plea…

HTTP GET was initially defined to "Please transfer a named document back." [1]. The idea of interpreting the path to dynamically generate a document came later. If you like, you can think of it as a shift from Apache-circa-1999 servers that expect to deal primarily in files, to Rails-style servers that primarily route requests to dynamic code. You're right that design patterns like Facade are often used instead of ex…

Well, the remark about the acceptable format in the same definition from 1992 means that there's dynamic processing of the request, which may involve the document conversion at least. And it does not say "file", which means that there can be a database as a document storage. In 1999 the web was mostly dynamic (I myself was using PHP, Informix WebConnect, Java and C for web development by that time) and more abstract RFC 1945 came in 1996 (just 4 years later), 1 year after Amazon went online. The period of time, when GET could mean only "give me a file" was in fact very short, if ever existed.

Then, you write that Facade is "tightly coupled". In fact, it's not more coupled than any native messaging. Let's say, the client code wants an object, representing a coffee machine, to prepare latte with temperature about 40C. There are other things, that coffee machine can do (e.g. self-check), so you need to pass 3 facts to it: "prepare drink", "drink type is latte", "temperature is 50C". You indeed can send a message to this object, containing these 3 facts as message data. Or you can call a method "prepare" of API with 2 parameters. See, there's no difference in amount of information you use for this operation: either way, there are 3 facts, for which you use 2 different syntactic forms. Coupling by definition is amount of shared information about mutual state and behavior between components (number of facts fixed in interaction contract). Here it's the same.

With all that in mind, modern languages are so rich in syntax, that there's almost no use case for messages as the means of interaction between objects at this moment. When you mention reflection, I'd say it's not the same. You use reflection to discover the address of the routine to call (that is, do not rely on infrastructure for delivery), rather than deliver the message to the object so it could dispatch it itself. Well, of course, there's one remark - this depends on how you define the message. Reflective calls are late binding just the same way as dependency injection: in runtime some container or reflection API provides an address of the code, implementing given interface, that will be invoked. If reflection means messages, then DI means messages, then VMT means messages, then messages=methods and all this talk is about outdated definition of what everyone uses.

Web crawlers are a bit different story: search engines do not deal with objects, they always deal with documents, that do not expose any behavior. The only thing in the net that comes to my mind is the semantic web. There were talks about it in early 2000s, when there was a lot of hype about web services, runtime discovery, web ontology language etc, but it's now as dead as CORBA.

Re: Alan Kay on the misunderstanding of OOP (1998)

#100
post #85

Earlier quoted context omitted.

That makes me wonder though, if i send a message to the same object from two different senders, will the first message affect the outcome of the second? If not then there is plainly little difference between the two, as either action gets a new pristine instance. All in all, this seems to be a whole lot of syntactical hair splitting.

What an object does when it receives a message is hidden, and entirely up to that object. >>> All in all, this seems to be a whole lot of syntactical hair splitting Or, simply a case of not understanding.

Or not having the 10000 feet outlook.

Checking some links to Kay's responses elsewhere, i get the impression that unless we basically toss the notion of a programs as a singular compiled file of binary, and replace it with some kind of abstract notion of work that can happen on a single computer, or across the net as a whole, the distinction between a message and a method is academic at best.

Because for message as a concept to make sense, it has to be seen as someone standing on a rooftop shouting "can someone please hit that nail?!", and then wait around until someone shouts back "done!".

Without that you just end up with a carpenter talking to himself "hit nail, done, hit nail, done, hit nail, done".

Post reply on HN