Comment by ramesh31
1 year ago
>"Also, everything just feels "backwards" to me if that makes any sense."
Because it is. Obj-C comes from the Smalltalk lineage by way of Alan Kay, using message passing [0] versus method invocation. It's a subtle difference with huge implications to how you design systems. Method invocation won out mostly because of Java and C++, but there was a time it wasn't clear which was the better OO paradigm.
Message passing belongs up there with lisp, forth and pure functional programming as paradigms that are worth learning for "the profound enlightenment experience you will have when you finally get it." But I often see that my peers in the profession lack the kind of growth mentality that enables a person to see past the alienness of less algol-y languages.
Quote from "How To Become a Hacker" by Eric S. Raymond: http://www.catb.org/esr/faqs/hacker-howto.html
see my comment above: https://news.ycombinator.com/item?id=42132104 i can't tell the difference and therefore i don't see what profound enlightenment experience i am supposed to have.
fwiw
'what matters about an object is its protocol: the set of messages that it understands, and the way that it behaves in response to those messages. Nowadays, this is sometimes also referred to as the objectʼs interface. The key idea is that when we use an object, we focus on how it appears from the outside, and “abstract away from” its internal structure: more simply, that the internal structure of an object is hidden from all other objects. Thatʼs why I said “the set of messages that it understands,” and not “the set of methods that it implements.” In many languages they are the same, but I wanted to emphasise the external rather than the internal view.'
"Object-oriented programming: Some history, and challenges for the next fifty years" Andrew P. Black
https://doi.org/10.1016/j.ic.2013.08.002
So, a matter of emphasis?
If you can't tell the difference, you didn't actually learn it.
Doesn't mean you have to like it, but they are different.
9 replies →
Java is heavily based in Smalltalk and Objective-C, even if it has a C++ like syntax for mainstream adoption.
https://cs.gmu.edu/~sean/stuff/java-objc.html
Even Java EE was actually a rebooted Objective-C based project done internally at Sun during the OpenSTEP days, aka Distributed Objects Everywhere.
i have learned smalltalk, common lisp, java, python, ruby, perl, php, C, javacript and a few other languages, and i still do not understand the difference between message passing and function invocation. they look the same to me. according to wikipedia the difference is
"In contrast to the traditional technique of calling a program by name, message passing uses an object model to distinguish the general function from the specific implementations. The invoking program sends a message and relies on the object to select and execute the appropriate code."
Method invocation won out mostly because of Java and C++
but according to the wikipedia article java uses message passing.
supposedly the distinction is that i can have a generic method that gets called if a named method can not be found. in smalltalk that's doesNotUnderstand: in ruby it's method_missing. javascript used to have __noSuchMethod__, in php i can overload __call, in pike i do the same with defining a method called `(), and many more.
so are they all using message passing? and then if java is supposed to use message passing and javascript removed __noSuchMethod__ it seems that alone can't be the distinction.
if there is a distinction at all then it look more like an implementation detail that does not actually affect what kind of code you can write, and more importantly, based on that it is not at all clear that method invocation won out.
This is another example of where you've got to read Wikipedia with a skeptical eye. That one in-passing mention of Java is incorrect. I don't know why it's in there, WikiBlame indicates that it's been there since 2004, which was the early days of Wikipedia when it was particularly unreliable.
So, the gist of the difference is this: object-oriented programming is, at its core, about late binding. Specifically, delaying decisions about what code will run when until run-time. But there's still some wiggle room to decide how late certain decisions are made. Most mainstream object-oriented languages like Java and C# more-or-less wait until the start of run-time to decide, but at that point the mapping from argument type to which code is run is pretty much settled. (This isn't necessarily 100% true, but it's the general rule.)
In a system that uses message passing, it's pushed even later, to method invocation time. Basically, each object (actor, whatever) gets to decide what code will be executed to handle a message every time it receives a new message, even for messages of the same type. In practice, most the time it's always the same code. But the point is that this level of dynamicism is a first-class language feature and not just a thing you can accomplish with hacks.
i understand your explanation, but i still don't see how i am supposed to tell the difference as a programmer. to be a first class language feature it has to be something the programmer can see and use consciously. the only feature there is the ability to have catchall methods, but while the existence of such a feature is an indication that very late binding happens, the absence of it does not indicate otherwise. so it goes back to pretty much all dynamic languages with a runtime probably use message passing because they either do have such a feature or could have it. but i don't see that claim supported anywhere. everyone just seems to talk about how smalltalk is somehow different, but i can't see how it is different from javascript, php, pike or other dynamic languages.
and i believe what you say about java and wikipedia. it just shows again that the distinction is not obvious.
i found this discussion on stackexchange: https://softwareengineering.stackexchange.com/questions/3352...
but reading that doesn't help me to tell the distinction between java and smalltalk either. the point appears to be that all OO is message passing, and the only distinction as far as i can tell is that java doesn't have extreme late-binding of all things, but that is something i can't know just by looking at the language. it's a hidden implementation detail. not being able to tell how the message is processed is another feature that message passing is supposed to have, btw.
the stackexchange answer however also shows why i am not seeing any revelation when using smalltalk. if all OO is supposed to be message passing then it's no wonder, it all looks the same to me.
note that i don't want to argue either way. i don't know enough about this to make any kind of argument. and i am trying to figure out the right questions to ask so i can learn and understand more. your comment did help me move forward at least. thanks.
If the "message passing" implementation blows the stack when something sends a message to itself, then you know that they are calling function calls "message passing".
Bona fide message passing is asynchronous. A message is sent and the send operation immediately returns, without blocking for a reply.
Nothing else should be called "message passing".
Nah...IMHO message-passing is a generalization.
The point is that it encompasses all of these things: synchronous, asynchronous, local, distributed, late-bound, early bound, point-to-point, broadcast, multicast.
And ideally, you should be able to select which kind you want on a case-by-case basis. With ease.
Rather than having to choose a different programming language.
i agree with that definition but then smalltalk nor any other language are using message passing for regular method calls because they are not asynchronous unless they use explicitly asynchronous methods.
The difference is NSInvocation. A function pointer doesn't capture the arguments to the function, but a message does.
Also, you can change the destination of a message send at runtime, but you can't change the destination of a function call unless you're dtrace and can do code patching.
ok, so that means message passing needs a runtime, and it can be assumed that pretty much every language that has a runtime uses message passing. more evidence that it is message passing that won out.
and the profound enlightenment ( https://news.ycombinator.com/item?id=42130432 ) is not specific to message passing but about a dynamic language runtime. being able to intercept messages/function calls is just one of the benefits of that.
2 replies →