Live data from Hacker News

Why Objective-C

inessential.com

81–90 of 160 posts

Re: Why Objective-C

#81
post #41

Earlier quoted context omitted.

>[1] https://github.com/swiftlang/swift-evolution/blob/main/propo ... -- apologies to the authors, but even as a previous C++ guy, my brain twisted at that. Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C. These kinds of features are not intended for use in daily application development. They're systems-language features designed for building high performance,…

The "Swift has too many keywords now" meme makes me want to go insane. The vast majority of Swift code never runs into any of that stuff; so, what advocates of it are saying is in effect "we don't want Swift to expand into these new areas (that it has potential to be really good at) even if it's in a way that doesn't affect current uses at all." That said, the Swift 6 / Strict Concurrency transitions truly have been…

Swift's concurrency story is what happens when a multi-year project meets Apple's fixed six month Swift release timeline. And being written by highly knowledgeable but low level engineers who've never written an iOS app in their life, means that there was a huge approachability hole they've only recently worked their way out of, but even that has major issues (MainActor default on in Xcode but not Swift itself).

Re: Why Objective-C

#82
post #67

I do not get this argument at all. A long time ago I ported a simple sudoku solver to Objective-C by using the foundation classes, like NSMutableArray. It was terribly slow. All those messaging sending just to do what should have been a single instruction (or less!) That’s when I realized that if you want speed in an Objective-C app, you really are going to reach for the C subset. The objective part is really good fo…

That is one advantage of C++ - you can use higher level features like generic data types/algorithms, member functions, constructors, destructors, and iterators and still have performant code. You can use object-orientation without having to heap allocate each object and pay the cost of "virtual" calls. (which many other object-oriented languages couple together)

Re: Why Objective-C

#84

Earlier quoted context omitted.

One of my recurring language design hot takes is that it's easier to design for speed and then make it easy to use than it is to make it easy to use and then try to speed it up.

C++ is trying to make C easier to use for 40 years, and it's still not there. So I wouldn't call that easier.

C++ is trying to make something EASIER to use?

Re: Why Objective-C

#85

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.

Obj-C does have a "nonnull" annotation now (apparently added to assist Swift interop). One of the final jigsaw pieces turning it into a really pleasant language.

nonnull doesn't really do anything in pure objc. It warns if you assign the nil literal to a nonnull pointer and that's it. The annotation is almost entirely for the sake of Swift interop (where it determines if the pointer is bridged as an Optional or not).

Re: Why Objective-C

#86

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.

The one really funny feature of Objective-C++ is that it lets you write C++ using modern C features that haven't been pulled into C++, and you don't have to actually use the Objective part. Designated initializers before C++ got them were the main actually useful application of this.

Re: Why Objective-C

#87
post #28

Earlier quoted context omitted.

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…

> That is, after all, what sets "object-oriented" apart from having objects alone.

I wouldn't say so, most object-oriented languages don't work like Objective-C/Smalltalk. Today, I think most programmers would agree that inheritance is the defining feature of object-orientation.

Re: Why Objective-C

#88
I still love Objective-C and you can pry it from my cold dead hands - tho I basically just call in to it from Rust these days for convenience reasons (cargo).

That aside, I was glancing through the source code for the engine and noticed this:

https://codeberg.org/brentsimmons/SalmonBay/src/branch/main/...

I wonder why they opted to do this instead of NSJSONSerialization - maybe I'm just misunderstanding the use for the class tho.

Re: Why Objective-C

#89
post #28

Earlier quoted context omitted.

> 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…

> That is, after all, what sets "object-oriented" apart from having objects alone. I wouldn't say so, most object-oriented languages don't work like Objective-C/Smalltalk. Today, I think most programmers would agree that inheritance is the defining feature of object-orientation.

Okay, that's what sets what was classically known as "object-oriented" apart.

Understandably, language evolves. If OO means something different today, what do most programmers call what used to be known as OO? I honestly have never heard anyone use anything else. But I am always up for refreshing my lexicon. What did most programmers settle on for this in order to free up OO for other uses?

Re: Why Objective-C

#90
post #82
post #67

I do not get this argument at all. A long time ago I ported a simple sudoku solver to Objective-C by using the foundation classes, like NSMutableArray. It was terribly slow. All those messaging sending just to do what should have been a single instruction (or less!) That’s when I realized that if you want speed in an Objective-C app, you really are going to reach for the C subset. The objective part is really good fo…

That is one advantage of C++ - you can use higher level features like generic data types/algorithms, member functions, constructors, destructors, and iterators and still have performant code. You can use object-orientation without having to heap allocate each object and pay the cost of "virtual" calls. (which many other object-oriented languages couple together)

Yes! The idea of zero cost abstractions became popular in the C++ world. It was never a thing for Objective-C.
Post reply on HN