4 ms·

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 t

by kccqzy 8mo ago

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 for building GUIs, but not for pure computation.

kridsdale3 8mo ago
When I was writing apps at Apple for the low-integer-version-numbered iOSes, this is what we typically did (since we had a single-core CPU in the MHz and <1GB). UI shell in UIKit Obj-C, over a C++ or CoreFoundation (C) business layer, talking directly to sqlite. I haven't seen the source of Apple apps and frameworks in over 10 years now, but I hope for their sake a lot of it has moved to Swift by now. If I were CFed I'd mandate 2026 as the Year of Claude Code Radar Burndown. Their backlogs are insane and Apple actually addresses maybe 5% of what it knows to be wrong in a given year. Make it 2% when a UI Refresh is mandated.
csb6 8mo ago
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)
- kccqzy 8mo ago
  Yes! The idea of zero cost abstractions became popular in the C++ world. It was never a thing for Objective-C.
favorited 8mo ago
One of the great things about Objective-C, as a direct superset of C, is that you can identify the slow parts of your app and just implement them in C, inline with the rest of your code. You don't even need to move it outside of your class's @implementation.

by kccqzy 8mo ago

kridsdale3 8mo ago

When I was writing apps at Apple for the low-integer-version-numbered iOSes, this is what we typically did (since we had a single-core CPU in the MHz and <1GB). UI shell in UIKit Obj-C, over a C++ or CoreFoundation (C) business layer, talking directly to sqlite. I haven't seen the source of Apple apps and frameworks in over 10 years now, but I hope for their sake a lot of it has moved to Swift by now. If I were CFed I'd mandate 2026 as the Year of Claude Code Radar Burndown. Their backlogs are insane and Apple actually addresses maybe 5% of what it knows to be wrong in a given year. Make it 2% when a UI Refresh is mandated.

csb6 8mo ago

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)

kccqzy 8mo ago
Yes! The idea of zero cost abstractions became popular in the C++ world. It was never a thing for Objective-C.

favorited 8mo ago

One of the great things about Objective-C, as a direct superset of C, is that you can identify the slow parts of your app and just implement them in C, inline with the rest of your code. You don't even need to move it outside of your class's @implementation.