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

Alan Kay on the misunderstanding of OOP (1998)

lists.squeakfoundation.org

Post reply on HN
Print view View original

191–200 of 212 posts

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

#191

Post by jstimpfle »

endlessvoid94 wrote: post #181
jonahx wrote: post #178

Earlier quoted context omitted.

So the idea, essentially, is that TCP/IP is like a "free form field" where people can write whatever they want, and then everyone is free to create their own structure on top of that, to suit their needs. In contrast to some protocol that accepted only, say, XML? His point, then, is that not forcing such structure was a crucial ingredient in the internet's success?

The TCP messaging analogy here is that the design was a protocol, which focused on how different components in a TCP system communicate with each other. Rather than a design that focused on how each component worked internally. The inter-communication was the central design, not the intra-communication. Many OOP programmers today spend the bulk of their time thinking about how their objects should work rather than ho…

> Many OOP programmers today spend the bulk of their time thinking about how their objects should work rather than how they should communicate.

Which is the "proof" that OOP was oversold. This is called "structured programming". It's not evil :-)

http://www.yegor256.com/2014/05/05/oop-alternative-to-utilit...

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

#192

Post by llamaz »

hackits wrote: post #74
llamaz wrote: post #54

Earlier quoted context omitted.

> I've seen too many project's that have drunken the cool aid and has resulted in 5-10 level deep inheritance tree's with their own branching logic trying to fit behavior to a specific taxonomy. I don't think you understand Alan Kay's version of OOP, if you think inheritance is a key part of OOP. I was interested in this stuff during the summer and I wrote up the following question/answer if you're interested on what…

I read your essay on programming languages. I found it was awesome btw. I saw you made the comment `o be concrete - object oriented programming is easy in python, because it's possible to program methods of an object in a way that doesn't assume a particular representation.` I thought you would be really interested in usage of polymorphism in python ( http://neverworkintheory.org/2016/06/13/polymorphism-in-pyth... ).…

Thanks for the links :) I've saved them and hope to eventually make my way through them

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

#193

Post by jdmichal »

jstimpfle wrote: post #190
jdmichal wrote: post #172

Earlier quoted context omitted.

They are definitely still "functions", barring the fact that Java doesn't have first-class functions and SAMs are the closest thing. C# does have first-class functions, and it is even more liberal in its closure rules. (Java can only close over `final` variables, which are immutable variable bindings. C# doesn't even have immutable variable bindings, only member bindings.) Also, they can still be "pure functions". Pu…

You are kind-of making my point. It's clearer to use "function" fore pure, mathematical functions, and otherwise "procedure"/"object"/"proxy"/"closure" whatever. Even if some popular languages misuse the term "function". > Even then, it's a somewhat loose definition -- is allocating memory a side effect? This is leading nowhere. Is loading a value into a register a side effect? If you care.

I mean, if you're only point is that programmers use the term "function" to mean something other than a pure mathematical mapping from one set to another... You won't get any arguments from me.

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

#194

Post by DougMerritt »

k__ wrote: 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...

> Why didn't he call it Message Oriented Programming then?

He eventually said much the same thing (many people remember him as using your exact phrase, but I'm less sure about that):

> [Kay:] I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging"...

[ Alan Kay, Usenet, 1998 ]

http://c2.com/cgi/wiki?AlanKayOnMessaging

Somewhere I read him saying that a key moment was when he was looking at (IIRC) Sussman's highly optimized Lisp dispatch of continuations, and realized that it was essentially the same thing as what Kay had in mind for Smalltalk. Something roughly like that.

It may have been the first "X is a poor man's Y" observation.

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

#195

Post by al2o3cr »

mercer wrote: post #103
sb8244 wrote: post #102

Earlier quoted context omitted.

Is message passing that you're referring to different than the Ruby concept of messages? Objects respond to messages in Ruby, and it is encouraged to think of it that way rather than calling functions.

Is that actually the case in practice? I haven't used Ruby enough to know, but my experience so far is that most of the time the approach is still mostly just plain method calling in practice. I vaguely recall Rails moving away from some usage of method_missing (which I'd argue is one explicit example of message passing vs method calling). Honest question, btw, I really don't know.

Anything you can call with `foo.bar` you can also call with `foo.send(:bar)`. Messages all the way down.

Whether that conforms to Kay's (or your) definition of "message passing" is left to the reader.

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

#196

Post by coldtea »

kmiroslav wrote: post #80

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…

>I don't really understand this obsession with messages. We're moving away from it.

On the contrary. We use it more than ever -- only similarly to Greenspun's tenth rule -- in "ad-hoc" and crappier implementations.

What do you think REST microservices are beneath the surface for example? Or AJAX, WebWorkers, SOAP. Etc. The bad parts of messaging without the flexibility (or even the performance of Smalltalk of the 90s) (Incidentally, Erlang/Elixir gets this right, Akka, etc). Or, all the Rabbit, Duck, Donkey MQs, ZeroMQs, pub/sub, event emitters etc out there.

>This is not how we program in the 21st century

That's more of a problem of the 21st century that messages.

>Besides, this idea of message passing is really not that useful for modern programming anyway but a lot of people still have this weird idea that message passing magically solves the problem of data integrity in parallelism. It doesn't. It does nothing to solve it. You can still have deadlocks and you can still have data corruption.

Deadlocks are not related to data integrity, so they're another story. As for "data corruption", messages where values are copied (and thus immutable) are not really prone to it compared to "how we program in the 21st century".

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

#197

Post by coldtea »

pacala wrote: post #90
_asummers wrote: post #84

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.

Where did you see that? That's not what the kind of messages we talk about are (e.g. in Smalltalk).

Perhaps (as some other commenter said) you have modern message queues in mind?

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

#198

Post by coldtea »

infinite8s wrote: post #122
ivan_gammel wrote: post #101

Earlier quoted context omitted.

In modern enterprise programming message is very different concept (probably more widespread, if we'll look at popularity of Java and .Net, compared to Objective-C), which is not related to OOP. It's a pattern of integration, in which systems exchange with messages through a message broker, that abstracts them from each other. By their nature such messages are asynchronous and unidirectional.

That was also the original model of messaging in Smalltalk (well, without the necessity of a broker).

Smalltalk receivers returned values to the senders of the message. Plus, they were synchronous.

So, while indeed still messaging, I'm not sure about the similarity to message queues/brokers in modern enterprise, where, as the parent said "By their nature such messages are asynchronous and unidirectional".

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

#199

Post by ivan_gammel »

specialist wrote: post #162
ivan_gammel wrote: post #87

Earlier quoted context omitted.

HTTP is closer to RPC. You always know the address of the routine to call, so it's not actually a message (except in HATEOAS, in which you first need to learn the next address from last API call). Closest analogy is the message queue (e.g. ESB) like Active MQ or Rabbit MQ (and the whole JMS tech), in which you do actually send a message and infrastructure does actually figure out who will receive and process it.

HTTP(S) is the opposite of RPC (meaning: message-based). Both SOAP and XML-RPC tried to remedy that.

How exactly it is opposite?

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

#200

Post by the_why_of_y »

felixgallo wrote: post #126
kmiroslav wrote: post #80

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…

We're accelerating towards messages at a very high rate of speed. This is in fact how we're starting to program in the 21st century and all programming will be of that type in the 22nd century. The last popular languages that support this paradigm (Go, Rust, Erlang, Elixir) are exploding in popularity and entering the mainstream. Message passing does in fact magically solve the problem of data integrity in parallelis…

Rust does many a nice thing, but nothing to solve deadlocks.
Post reply on HN