Live data from Hacker News

Why Objective-C

inessential.com

21–30 of 160 posts

Re: Why Objective-C

#21

I bounced off of Objective-C not because of its message-passing OO. That was the actual cool part. I bounced off because of the insane amount of boilerplate prototyping and headers required to use it. I think every OO language should be using Smalltalk's message-passing style rather than holding hard references, and Objective-C is a great model. But discard the rest.

Apple should have made a modern Smalltalk on top of the Objective-C object model as a replacement for Objective-C instead of Swift.

I want to love Swift, but the funny thing is that as they solve more problem with Swift they also add so much complexity that you wonder if all the problems they solved just added new problems.

Re: Why Objective-C

#23

At this point in my career, I can't go back to a language that doesn't have support for Optionals or compiler validation of nullable types. I can sacrifice async or fancy stream apis, but I will never go back to chasing null pointer exceptions on a daily basis.

I don't think objc has the equivalent of a null pointer exception. You can freely send messages to a deallocated object. Since ARC, it is rare, at least in my experience, running into any memory related issues with objc.

You can send messages to null, sendings messages to a deallocated pointer is going to be a bad time.

Re: Why Objective-C

#25
post #16

Earlier quoted context omitted.

They're function calls right? I can't square the "message passing" conceit (implying putting message objects on queues, dequeuing etc) with the claim that Obj-C is just C with some extra stuff.

Absolutely not. It only sends a message. The receiver doesn't have to have a corresponding method and can do with that message what it will. Objective-C is a 'true' object-oriented language, like Smalltalk.

In the end though most of those 'sending a message' actions are just fancy virtual method calls (e.g. an indirect jump), everything else would be much too slow:

https://www.mikeash.com/pyblog/friday-qa-2017-06-30-dissecti...

IMHO the whole 'message' and 'sending' lingo should be abandondend, the job of objc_msgSend is to look up a function pointer by certain rules. There are no 'messages' involved, and nothing is 'sent'.

Re: Why Objective-C

#26
I really enjoyed Obj-C when I did some iOS work back in 2015/2016. It was my first non-JS language, and it taught me so much that I didn't understand since I started out doing web dev.

Re: Why Objective-C

#28
post #16

Earlier quoted context omitted.

Absolutely not. It only sends a message. The receiver doesn't have to have a corresponding method and can do with that message what it will. Objective-C is a 'true' object-oriented language, like Smalltalk.

In the end though most of those 'sending a message' actions are just fancy virtual method calls (e.g. an indirect jump), everything else would be much too slow: https://www.mikeash.com/pyblog/friday-qa-2017-06-30-dissecti... IMHO the whole 'message' and 'sending' lingo should be abandondend, the job of objc_msgSend is to look up a function pointer by certain rules. There are no 'messages' involved, and nothing is 'se…

> There are no 'messages' involved, and nothing is 'sent'.

The conceptual difference is significant as an object can respond to messages that it doesn't have a method for. You are, conceptually, just sending a message and leave it up to the object what it wants to do with it (e.g. forwardInvocation:). That is, after all, what sets "object-oriented" apart from having objects alone. Optimizations that can be made under the hood don't really affect the language itself.

Re: Why Objective-C

#29
IMHO the one great feature of Objective-C (compared to C++) is that it doesn't interfere with any C language features. In C++ the C 'subset' is stuck in the mid-1990s, while Objective-C "just works" with any recent C standard.

Re: Why Objective-C

#30

I still find Objective-C++ useful for writing MacOS apps that make heavy use of C++ libraries (e.g.; Eigen, OpenCV). The caveat is I have done a lot of Objective-C programming and Swift is still not as seamless as I would like bridging with modern C++ and the the STL.

I've been playing around with low-level Metal a bunch lately, any many of their docs and samples seem still be mostly in Objective-C/C++ and not Swift, so have been forcing myself to get into it.

At first I had the usual revulsion to the syntax, but after a few days getting used to it, I actually don't mind it at all now. (I still wouldn't say it's "elegant", but I can live with it).

Being Metal shader code is basically C++ anyway, and C++ is a language I'm familiar with, having a couple of .mm files to hold the Objective-C++ for API bridging and working in regular .cpp (and .h) files for the rest is pretty straight forward compared to having to learn Swift. (Especially with all the complaints I've heard about its complexity, including from Chris Lattner himself lately, which aligns with some of the other comments here).

Though to be fair, "Swift seems overly complex so use C++ instead" seems like a tough argument to make with a straight face ;-p

Post reply on HN