Side note... I feel similarly about the Java to Kotlin transition. Sooo much better. Although, I don't hate Java NEARLY as much as Obj-C.
It is magical the way I can just use the C libraries with all the dynamic goodness Obj-C.
Also, you're 100% right. The square brackets are what immediately repulsed me and continued to befuddle me even after years of experience with it. Also, everything just feels "backwards" to me if that makes any sense. Coming from Java/C#/JavaScript everything just seemed unintuitive to me at all times. Also, I think this was heavily compounded by using xCode which (at the time) was incredibly laggy. So, I'd mess up the Obj-C syntax and the IDE wouldn't tell me for what felt like forever. Often I'd make a change and hit "play" before the syntax highlighting caught up and that always felt infuriating.
I last used xCode about 4 years ago and it was still an issue then (even with swift).
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.
I think that one of the tragedies of older programming languages is that they survive long enough for people to forget the technical - and technological - constraints that influenced their design. Swift is great, but there are reasons why there weren't any Swift-like languages being developed in or around 1984.
Similar feelings about Java. It is definitely not my favorite programming language. (I suppose Kotlin isn't either, but it's in the top n.) But it's hard for me to actually hate it. Java walked so that Kotlin could run.
For collaborative projects on the other hand, it can become a handful to maintain if everybody contributing isn't staying on top of hygiene with null checks, type checks, etc. Swift helps to keep all of that under control.
I've observed some folks have a visceral reaction to having to use Xcode, I don't really understand it myself. I can understand being annoyed at having to use a specific IDE to write iOS and Mac apps, e.g., it's harder to bring your own text editor like you usually can, it's going to make your life a lot harder if you try to to avoid using Xcode. But comparing Xcode to any IDEs like the JetBrains IDEs I've used (mainly the discontinued AppCode), Android Studio (also JetBrains under the hood), or other similarly complex development environments like Unreal or Unity, I don't see any of these as a clear winner. Personally I'd prefer using Xcode to any of those. I suspect this comes down to just whether you like native Mac apps or not, Xcode is a native Mac app and if you like that aesthetic than you'll like Xcode. I suspect most of the dislike for Xcode is really just folks who dislike the Mac platform (e.g., the UI toolkit) overall.
It's really kind of a bummer that we don't have well-known examples of "skinnable" programming languages already. The closest we get are the ones that let you choose your set of keywords for different locales in case you don't want to work with an English-based PL and those block based languages that let you manipulate them as blocks or edit the textual form. I firmly believe that PL skinning would really benefit so many otherwise worthwhile languages that get short-shrift because of negative reactions to the surface-level details. I'm referring in particular languages like those in the Pascal family. (You could also conceive of e.g. a skin for Golang that doesn't have leading caps be the determiner for whether a function is public or not. There are lots of applications for this, and the variations are a non-issue when you have an ecosystem with strong norms about applying a code formatter (like gofmt), which can dictate the format of the canonical on-disk representation.)
Quote from "How To Become a Hacker" by Eric S. Raymond: http://www.catb.org/esr/faqs/hacker-howto.html
No other language comes close to this incredible source-level interop. Here be dragons, but there's also lots of opportunity (and fun, from a programming languace theory perspective).
Maybe one it they will rewrite the Objective-C, who knows.
Kotlin transition is a Google thing, outside Android barely anyone notices that it exists.
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.
https://blog.metaobject.com/2019/12/the-4-stages-of-objectiv...
Its first two stages are just that, but it has moved beyond, for good reasons.
Even the Object Pascal to C++ transition at Apple was mostly caused by increased UNIX adoption, and Apple programmers wanting to offer similar experiences, thus MPW was born.
Same on other platforms, until C and C++ eventually won everywhere, at least until several new kids decided to challenge them in various fronts.
One that you seldom see nowadays, outside games, is pure GUI frameworks using C or C++.
"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.
I feel like so much awesome engineering in XNU around security and portability, as well as innovations like IOKit are swept under the rug because "it's just FreeBSD."
I still think it's a shame that more people don't take advantage of the Mach side of XNU more. Launchd and Mach ports are a powerful combination IMO.
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.
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.
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".
Kotlin hardly does more than 10% of JVM workloads, and it isn't as if any JVM vendor is replacing Java with Kotlin on their JVM implementation.
Besides Google with ART, which is anyway not a JVM proper, not fully TCK compliant to start with.
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 can provide you the public statement on that, if you feel like not searching yourself.
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.
i did see differences. the most awesome was when i wrote some code to respond to an http request, the code failed, the http request stalled, i fixed the code live, and then the http request resumed.
but i can do the same in pike if i tried, and i expect in lisp and other languages too.
and if that is the case then it supports my understanding that most OO languages use message passing. where then is the great revelation that comes from smalltalk?
> i did see differences.
Spot the difference. ;-)
> but i can do the same in pike if i tried, and i expect in lisp and other languages too.
Absolutely you can! You can even do it in C: write yourself a message-passing library in C. You might want to call it Objective-C. Or do a VM for Smalltalk.
> where then is the great revelation that comes from smalltalk?
The claim was not that the great revelation came from Smalltalk, but that it came from message passing:
>>> 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."
Smalltalk isn't even mentioned in that little section about the enlightenment.
And in fact, Smalltalk's form of message-passing is pretty limited, it only just extends beyond method invocation and it certainly can be (and is) frequently used just like method invocation. If you want to do more sophisticated things, you mostly have to go via the DNU handler, which is a bit hacky.
And in fact, Alan Kay's famous OOPSLA '97 quip "I made up the term object oriented. And I can tell you I did not have C++ in mind." was followed immediately with the slightly less famous "So, the important thing here is: I have many of the same feelings about Smalltalk". https://www.youtube.com/watch?t=634&v=oKg1hTOQXoY&feature=yo...
And even message-passing is much broader: for example, with Higher Order Messaging, you can control how messages are delivered: to collections, on different threads, delayed, distributed (combine distributed + delayed and you get TeaTime/Croquet), conditionally only if the receiver understands the message, etc.
https://en.wikipedia.org/wiki/Higher_order_message
https://www.youtube.com/watch?v=GBtqQwcJoN0
And even that just scratches the surface. When you look at something like the Enterprise Integration Patterns, that's distributed asynchronous messaging, which opens up a whole other universe. Also: Erlang.
https://www.enterpriseintegrationpatterns.com
https://stackoverflow.com/questions/3431509/is-erlang-object...
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.
Are you sure about that?
]pwd
objc4/runtime/Messengers.subproj
]rg malloc
]
And of course NeXT used objc_msgSend() in the kernel, to good effect, so that's pretty low-level.
>> i can't tell the difference
> i did see differences.
Spot the difference. ;-)
well the first refers to the difference between message passing and function calling. which i couldn't see because all languages i worked with are using message passing.
the second refers to the difference between smalltalk and other languages, which owes to the particular implementation of smalltalk, and not just message passing.
in summary, you are confirming what i thought i understood. it appears i need to do the reverse and actually explore languages that don't do message passing to see the difference.
That turns out not to be the case. C++ is not. Java is not.
Of course, many would say that those two are not object-oriented, so that way around you can make it work.
> which i couldn't see because all languages i worked with are using message passing.
That still is not the case. So your explanation for the contradiction in your statements also makes no sense.
> in summary, you are confirming what i thought i understood.
No, I am most emphatically not doing that, and what I've written makes that very, very clear. There is little I can add to that, I could only repeat myself.
Have a nice day.
i meant all the languages besides those. if you make a list of all known OO languages, most of them will be dynamic languages with message passing. C++ and java and a few others will be the exception.
> which i couldn't see because all languages i worked with are using message passing.
That still is not the case
do you know which languages i have worked with? which of those do not use message passing?
what I've written makes that very, very clear
well it appears we are talking past each other, and therefore it doesn't.
'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?