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

101–110 of 212 posts

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

#101

Post by ivan_gammel »

protomyth wrote: post #97
pacala wrote: post #90

Earlier quoted context omitted.

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.

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.

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

#102

Post by sb8244 »

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…

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.

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

#103

Post by mercer »

sb8244 wrote: post #102
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…

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.

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

#104

Post by aryehof »

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…

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

Actually, for many if not most, programming today means using procedures and subroutines, organized through functional decomposition, just like was done in the 1950s and 60s. We haven't gotten that far have we.

OO is a different paradigm from organizing the concepts in a domain through functional decomposition, and understanding how it is different, is key to understanding OO and messaging.

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

#105

Post by mercer »

pkroll wrote: post #64
hackits wrote: post #62

Earlier quoted context omitted.

Not saying its a key part. Im in the camp you better have a damn good reason to use inheritance that composition will suffice. The whole notion that everyone has their own perspective on oop makes it a mute point.

Actually that's "moot point": http://www.dictionary.com/browse/moot-point But yes, the number of variant perspectives on OOP make it a less descriptive term than would be ideal.

Or a cow's opinion!

No but seriously, I think both you and hackits make it clear that there's a lot of discussion over what OOP actually is. Which makes me curious: is there any research on the characteristics of OOP as it implemented in practice across languages? I'd be very interested in such research, because it seems to me that what is possible is often not practiced.

So, for example, Ruby might be all about 'message passing' as others, and all the tutorials and books I've read indicate, but in practice it might be indistinguishable from just calling methods on objects, or whatever distinguishes message passing from other OOP styles.

If no such research exists, how difficult would it be to scan codebases on Github to analyse this? I might be wrong, but it seems like this would be a worthwhile investigation: how do people actually use languages and what is 'OOP' or 'FP' actually like in codebases that claim to be one or the other.

Otherwise we're just getting tangled up in definitions and it's all a moo point.

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

#106

Post by mercer »

gagege wrote: post #77
huuu wrote: post #75

Earlier quoted context omitted.

Does queuing occur when cells communicate?

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.

That sounds more event-based, no? The cells trigger events, and the compatible proteins are listeners.

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

#107

Post by mercer »

lacker wrote: post #22
stevedonovan wrote: post #18

Earlier quoted context omitted.

OOP made sense to people who already knew structured programming and understood functional decomposition (what we now call 'refactoring'). Perhaps education should start with that and then justify OOP? I remember reading about the original LOGO experiments; one thing kids do not spontaneously do is break up their monolithic actions into sensible functions.

Yeah "breaking up a complex function into simpler functions" is a great example of something that isn't taught well today, yet is simpler and more critical than what we try to teach people in intro courses. I think of it in analogy to math. OOP is like topology - it's definitely useful in some cases, it's not too hard for an experienced mathematician to get the basics, and yet in a lot of situations it's irrelevant a…

Perhaps inheritance is easier to teach, which might be completely unrelated to how useful it is in practice? That would explain a lot.

It reminds me a bit of how I was taught basic economics, where societies go from barter to currency. Apparently this is not true at all, but it's a story that is easy to teach.

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

#108

Post by mercer »

userbinator wrote: post #79
lacker wrote: post #14

IMO the problem with object-oriented programming is that it turned into the standard curriculum for peoples' first semester of computer science, rather than being yet another interesting concept that advanced programmers would ponder. And the way we handle "the standard CS curriculum" sucks. (In the USA at least.) For example, AP Computer Science requires Java and tries to teach stuff like designing inheritance hiera…

OOP should be something you only get into after you have written some practical programs I'd modify that to "practical programs that are nontrivial enough to benefit from OOP ", just like how I advocate not teaching about functions until they become useful. IMHO the CS curriculum should start with the low-level basics and work up from there in a natural progression: - Representation and interpretation of binary data.…

Would it make sense to not jump to only OOP after 'grouping data together', but to provide FP approaches in parallel?

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

#109

Post by cheshire_cat »

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.

He said "[...] it is encouraged to think of it that way rather than calling functions."

This is what Sandi Metz talks about when she speaks about message/responsibility centric design vs data-centric design in OOP. The conceptual difference is said to lead to different designs. You don't start out your design by thinking about what data you hold but you think about which responsibilities/roles you have and create objects around those by thinking how they might talk to each other to reach their goals. (I'm currently reading POODR by Sandi Metz, so this is still new to me, if I got anything wrong there then please feel free to correct me)

https://www.practicingruby.com/articles/responsibility-centr...

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

#110

Post by hackits »

aryehof wrote: post #104
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…

>>> This is not how we program in the 21st century. Actually, for many if not most, programming today means using procedures and subroutines, organized through functional decomposition, just like was done in the 1950s and 60s. We haven't gotten that far have we. OO is a different paradigm from organizing the concepts in a domain through functional decomposition, and understanding how it is different, is key to unders…

Could you elaborate leading by example `how it is different`?

Seriously because unless you can define it, and quantify it then it is just rhetoric.

Post reply on HN