7 ms·

Why Objective-C

145 points by ingve 8mo ago

frityet 8mo ago
Good time to check out ObjFW [1], it's a cross platform ObjC framework that's just really awesome [1] https://git.nil.im/ObjFW/ObjFW https://git.nil.im/ObjFW/ObjFW
- vintagedave 8mo ago
  I hadn't come across this. Insane (if true, I've never tried) that GnuStep is not 100% compatible, surely that would be the point. How easy is it to port, say, a Leopard-era Objective C app to ObjFW?
  - steeleduncan 8mo ago
    I tried this with an old iOS only game a few years ago. It is clearly not a heavily used library, but it seemed to work ok - There was a bug or two I had to patch, but the code is readable, so it wasn't a big deal - OFString, etc aren't intended to be 1:1 replacements for NSString, etc. This wasn't a real problem. They mostly match, and all I needed to do was write a few categories - The runtime functions are not compatible at all, but most projects wouldn't touch those - CoreFoundation and the other C APIs are not there at all, so you'll need replacements - It is a replacement for Foundation framework, not AppKit, so if it is a GUI app you still have a lot of work to do
    - rweichler 8mo ago
      This is why I went with GNUstep. All of the APIs are 1:1 with Apple's, including the runtime (which is very important imo). It has AppKit support as well; its AppKit implementation is kind of half-baked, but at least it exists. Also, a lot of the APIs are kind of old. But looking at how Swift evolved over the years, maybe that's not a bad thing. My main complaint with GNUstep is the licensing. The runtime itself is MIT which is great, but its implementation of Foundation/AppKit is LGPL. ObjFW, including its runtime, is LGPL. At least with GNUstep one day I can create my own version of Foundation based on Cocotron or swift-corelibs-foundation or something, and not need to muck with rpaths + ship a bunch of .dll/.dylib/.so files with my app in order to comply with the license.
- apple4ever 8mo ago
  It really is really awesome! It's what I write in when I want to use it on Linux. GNUStep is stuck in 1995 sadly.
vintagedave 8mo ago
I really miss Objective-C, and in the world of Swift craziness [1] I'm reminded often of this blog post [2] wondering what would have happened if Apple hadn't encountered Second System Syndrome for its recommended language. (There's a decent argument it encountered it in iOS and macOS too.) [1] https://github.com/swiftlang/swift-evolution/blob/main/proposals/0507-borrow-accessors.md 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. [2] https://medium.com/goodones/pareto-optimal-apple-devtools-b47e79b6676f https://medium.com/goodones/pareto-optimal-apple-devtools-b4...
- tarentel 8mo ago
  I go back and forth. I do miss the simplicity of objc at times though. I think in a short amount of time someone can become close to an expert in objc. Swift is already incredibly complicated and there's no end in sight.
  - ardit33 8mo ago
    I hate how pendantic and useless some of the features of swift being pushed down by academics that don't write apps or services themselves. Simple example: Objective-C if myObject { } in swift if myObject != nil { } Also opitionals in swift could have totally be avoided if they adopted a prototype based langue (basically object are never nil). Lua did this, and it is very elegant But meanwhile, we got a half backed optional system, which is backwards (similiar to Java), and didn't help with the practicality of the language at all, and meanwhile you still can crash an app doing myArray[1]
    - andrekandre 8mo ago
      > you still can crash an app doing myArray[1] the first thing i do when starting a new project: extension Array { subscript(safe: Int) -> Element? { ... } } there was talk in the swift forms about adding that as standard that but it seems to have died off... [0] https://forums.swift.org/t/draft-adding-safe-indexing-to-array/10767/135 https://forums.swift.org/t/draft-adding-safe-indexing-to-arr...
waynecochran 8mo ago
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.
- iainmerrick 8mo ago
  Yeah, Objective-C++ is surprisingly great. It sounds like a terrible idea, but the bridging works pretty much seamlessly, and Obj-C and C++ don't actually overlap all that much so they don't step on each other's toes. Each language has strengths that shore up the weak spots in the other.
  - delta_p_delta_x 8mo ago
    +1 to Objective-C++. It makes for some surprisingly clean, compact code, best of both worlds, really. And the bridging between ARC and CF types is really quite magical, more languages should have that ability to be expressed in an older language without stripping everything out. I just wish there were Objective-C bindings for more CF classes without having to mess with C.
- billti 8mo ago
  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
9rx 8mo ago
> [[those squareBrackets] lookInsane:YES]. Nah, they are perfectly sane. They look like little ASCII envelopes because that's exactly the metaphor. Square brackets send messages.
- nmeofthestate 8mo ago
  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.
  - pavlov 8mo ago
    They're not direct function calls, but sugar for objc_msgSend(): https://developer.apple.com/documentation/ObjectiveC/objc_msgSend https://developer.apple.com/documentation/ObjectiveC/objc_ms...
  - 9rx 8mo ago
    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.
    - chuckadams 8mo ago
      > a 'true' OOP language, like Smalltalk. I guess Simula, which is older than Smalltalk, doesn't get a say.
      - 9rx 8mo ago
        What would it have to say about it? When "object-oriented" was first told, it was said that what defines it is message passing. Simula does not have message passing. It uses function calling. Simula does have objects, but having objects does not imply orientation.
    - flohofwoe 8mo ago
seanalltogether 8mo ago
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.
- iainmerrick 8mo ago
  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.
  - catoc 8mo ago
    It is a really pleasant language, but I think the <nonnull> annotation is for initialization only - compiler checking against initializing an object ptr with a null value - and does not prevent crashing when addressing an already released object
    - junofan 8mo ago
      > does not prevent crashing when addressing an already released object I don’t know what behavior you’d expect here or in what situation you’d encounter this for a nonnull reference. You’d have to be really living dangerously I’d imagine. The footgun was that nonnull isn’t enforced. And anyway, leaks were more the issue.
      - catoc 8mo ago
        That was exactly my point. GP mentioned ‘chasing null pointer exceptions’, then parent mentioned that the language ’now does have nonnull annotation’, prompting me to explain that that does not prevent null pointer exceptions. So, not living a dangerously. All that can be held against me is being “dangerously” imprecise on HN - definitely not good either
  - plorkyeran 8mo ago
    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).
netbioserror 8mo ago
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.
- socialdemocrat 8mo ago
  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.
  - andrekandre 8mo ago
    i really really like swift actually, it lets me express things that are harder in many languages... that being said, i also feel this as well... idk i feel like swift went too hard in the static direction which makes a lot of things harder than they should be such as hot-loading while developing etc
Naman-Dixit 8mo ago
> you’ll realize how small a language it is, how easy to hold in your palm and turn around and understand all sides of it I have never programmed in ObjC but was curious to learn how it works, and so I decided to write a ObjC runtime [0]. It took less than 2000 lines, and a large number of them are comments. Now I wonder how easy would it be to do dome lispy symbolic computing in it. Maybe something like a Prolog. [0] https://gist.github.com/namandixit/76cd084676acdf16cfd014cbbee7026d https://gist.github.com/namandixit/76cd084676acdf16cfd014cbb...
LoganDark 8mo ago
I recently started writing for macOS in Swift and, holy hell, the debuggability of the windowing toolkits is actually unparalleled. I've never seen something that is this introspectable at runtime, easy to decompile and analyze, intercept and modify, etc. Everything is so modular, with subclassing and delegation patterns everywhere. It seems all because of the Objective-C runtime, as without it you'd end up needing something similar anyway. You can reach into built-in components and precisely modify just what you want while keeping everything else platform-native and without having to reimplement everything. I've never seen anything like this before, anywhere. Maybe OLE on Windows wanted to be this (I've seen similar capabilities in REALLY OLD software written around OLE!) but the entirety of Windows' interface and shell and user experience was never unified on OLE so its use was always limited to something akin to a plugin layer. (In WordPad, for example) The only thing that even seems reminiscent is maybe Android Studio, and maybe some "cross-platform" toolkits that are comparatively incredibly immature in other areas. But Android Studio is so largely intolerable that I was never able to dig very far into its debugging capabilities. I feel like I must be in some sort of honeymoon phase but I 100% completely understand now why many Mac-native apps are Mac-native. I tried to write a WinUI3 app a year or two ago and it was a terrible experience. I tried to get into Android app development some years ago and it was a terrible experience. Writing GUIs for the Linux desktop is also a terrible experience. But macOS? I feel like I want to sleep with it, and I weep for what they've done with liquid glass. I want the perfection that led to Cocoa and all its abstractions. Reading all the really, super old documentation that explains entire subsystems in amazingly technical depth makes me want to SCREAM at how undocumented, unpolished and buggy some of the newer features have gotten. I've never seen documentation anything like that before, except for Linux, on Raymond Chen's blog, and some reverse-engineering writeups. I do love Linux but its userspace ecosystem just is not for me. Maybe this is also why Smalltalk fiends are such fans. I should really get into that sometime. Maybe Lisp too.
- kmeisthax 8mo ago
  > Writing GUIs for the Linux desktop is also a terrible experience. I've found the DX for GTK to be at least tolerable. Not fantastic, but I can at least look at a particular API, guess how the C-based GObject code gets translated by my language bindings of choice, and be correct more often than not. The documentation ranges from serviceable to incomplete, but I can at least find enough discussion online about it to get it to do what I want. Also, GTK apparently ships with a built-in inspector tool now. Ctrl-Shift-I in basically any GTK app opens it. That alone is extremely useful, and you basically have to do nothing to get it. It's free. I've never tried Qt. The applications that use it always seem off to me. As for OLE, you're actually thinking of COM, not OLE. They were co-developed together: COM is a cross-language object system (like GObject), while OLE is a set of COM interfaces for embedding documents in other arbitrary documents. Like, if you want to put a spreadsheet into a Word document, OLE is the way you have to do that. Microsoft even built much of IE[0] on top of OLE to serve as its extension mechanism. OLE is dead because its use case died. Compound documents as a concept don't really work in the modern era where everything is same-origin or container sandboxed. But COM is still alive and well. It's the glue that holds Windows together - even the Windows desktop shell. All the extension interfaces are just COM. The only difference is that now they started packaging COM objects and interfaces inside of .NET assemblies and calling it "WinRT". But it's the same underlying classes. If you use, say, the Rust windows crate, you're installing a bunch of language bindings built from WinRT metadata that, among other things, call into COM classes that have been there for decades. Mac apps are Mac native because Apple gives enough of a shit about being visually consistent that anyone using a cross-platform widget toolkit is going to look out of place. Windows abandoned the concept of a unified visual identity when Windows 8 decided to introduce an entirely new visual design built around an entirely new[1] widget toolkit, with no consideration of how you'd apply any of that to apps using USER.dll/Common Controls. As it stands today, Windows does not have a good answer to "what widget toolkit do I use to write my app", and even Microsoft's own software teams either write their own toolkits or just use Electron. [0] Petition to rename ActiveX to WebOLE [1] OK, yes, XAML existed in the Vista era, but that was .NET only, and XAML apps didn't look meaningfully different from ones building their own USER.dll window classes like it's 1993.
sgt 8mo ago
That's it, I'm pivoting my startup technically and rewriting everything in ObjC! /s
- Towaway69 8mo ago
  I wonder how well AI generates Obj-C - it might well produce better quality code for your token/buck! In a previous life, one would select the programming language according how expensive developers were. Nowadays it's the quality that an AI can generate. What a wonderful future we've put together. /s
  - GaryBluto 8mo ago
    I've been using Opus 4.6 to make myself a harness for old Macs that uses models offered by the Github Copilot subscription. From my experience, when it creates working Objective-C, it's great. When it slips up, it slips up majorly.
mghackerlady 8mo ago
I've always liked Objective-C. Despite me not really liking object-oriented programming, I appreciate that its one of a handful of languages to do actual smalltalk-esque oop
danielvaughn 8mo ago
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.
zarzavat 8mo ago
Smalltalk is like pizza. Even when it's bad, it's still pretty good.
flohofwoe 8mo ago
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.
- safercplusplus 8mo ago
  Interestingly, I recently auto-translated wget from C to a memory-safe subset of C++ [1], which involves the intermediate step of auto-converting from C to the subset of C that will also compile under clang++. You end up with a bunch of clang++ warnings about various things being C11 extensions and not ISO C++ compliant, but it does compile. [1] https://duneroadrunner.github.io/scpp_articles/PoC_autotranslation_of_wget https://duneroadrunner.github.io/scpp_articles/PoC_autotrans...
- j16sdiz 8mo ago
  I think C++ have caught up with C99 already. So it's late 90s, not mid-90s :)
  - flohofwoe 8mo ago
    No not really, for instance the designated init feature in C++20 is a distinctive C++ feature which is not compatible with C99's designated init. AFAIK the C subset hasn't changed since C++98.
- nly 8mo ago
  What C features can you not realistically use from C++?
  - anthk 8mo ago
    People shoudld realize that since long ago C and C++ are not sub/supersets, but interesecting sets.
  - 201984 8mo ago
    C11 atomics, C11 threads, variable length arrays, safely reading from an inactive union member, designated array initializers, compound struct literals, implicitly converting a void pointer to a typed one, and the list goes on.
mikehall314 8mo ago
Every so often I get weirdly obsessed with Objective-J, which "has the same relationship to JavaScript as Objective-C has to C". It is (was?) an absolutely bonkers project. I think it has more or less died since 280 North was acquired. https://www.cappuccino.dev/learn/objective-j.html https://www.cappuccino.dev/learn/objective-j.html
- ihumanable 8mo ago
  Same. I remember when this first came up and I was like "this is so weirdly interesting." Sad that they got acquired because it was just fascinating what they were doing, even if I was never going to use it.
- zffr 8mo ago
  Holy shit, it’s still being actively developed and maintained https://github.com/cappuccino/cappuccino https://github.com/cappuccino/cappuccino
  - Towaway69 8mo ago
    More amazingly the guy doing the most recent maintaining[1] is a medical Professor at Freiburg Uni. [1]: https://github.com/daboe01 https://github.com/daboe01
  - vintagedave 8mo ago
    And wow, it's basically a web version of Cocoa! Check this out: https://ansb.uniklinik-freiburg.de/ThemeKitchenSinkA3/ https://ansb.uniklinik-freiburg.de/ThemeKitchenSinkA3/
- sgt 8mo ago
  Weren't they acquired by Motorola?
  - mikehall314 8mo ago
    Yes, after which they announced they were canning their "Atlas" project, which was meant to be an Interface Builder for the web. Motorola decided they wanted to keep the technology in house. No idea if they ever did anything with it!
millerm 8mo ago
Wow, I haven't written any Objective-C since around 2012. I just went back and looked at some code I had written back then and that really brought back some memories. I was much happier then. I'm perpetually sad and unemployed now. That's all. Enjoy yourselves.
gwbas1c 8mo ago
One of the things I miss about Objective C is just how easy it is to call into a C API, or otherwise include a C function if that's the easiest way to call into a C API. I shipped a cross-platform C# project, and once I realized I could expose "ordinary C" from the Objective C part, it was very easy to integrate the two without using a framework. (It helped that the UI was 100% Objective C, so there wasn't much surface area between the C# and Objective C parts. We initially used MonobjC, but first I had to work around a shortcoming, and then we needed to remove MonobjC due to licensing and some of the newer C# integration layers were not available.)
rixtox 8mo ago
The most difficult part of Objective-C is its ARC rules, and mixing ARC and non-ARC code in the same project.
zerr 8mo ago
Any popular cross-platform GUI toolkits? How do you find GNUstep?
JSR_FDED 8mo ago
[objC retain]
- DerekL 8mo ago
  Hopefully, you're using ARC by now, so that's a no-op!
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.
klajddeda 8mo ago
[dead]
Klonoar 8mo ago
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/Modules/SalmonBayCore/Sources/SalmonBayCore/Utilities/SBJSONWriter.m 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.
monster_truck 8mo ago
Someone should vibe code Objective-C 3.0
- krackers 8mo ago
  What features do you think it needs, that wouldn't spoil the "elegance" of the language? I think one good feature would be higher order messaging, in fact there's already a PL paper discussing how it looks like in objective-c [1] which would add FP-like filter/map elegance that all modern languages have. This would go nicely with simpler "JS lambda" style block syntax to make functional-style programming easier in objc. [1] https://dl.acm.org/doi/epdf/10.1145/1146841.1146844 https://dl.acm.org/doi/epdf/10.1145/1146841.1146844
  - monster_truck 7mo ago
    Probably something like this, all it really needs to do is absorb the good parts of Swift and unfuck the actors/concurrency: https://github.com/doublemover/Slopjective-C https://github.com/doublemover/Slopjective-C I don't know if I like what that paper is suggesting, but I will give it a rip.
- avadodin 8mo ago
  If it makes Objective C 1.0 with ARC(but none of the swift-alpha Java syntax) and bindings for QT I won't even care it is made by AI.
  - monster_truck 7mo ago
    Can you elaborate on this? I learned Objective-C not long after 2.0 came out so I do not have much perspective on what exactly you'd want. I remember looking at it and thinking it was pretty fragile and boilerplate-y
    - avadodin 7mo ago
      The nice thing about Objective-C up to 2.0 was that it was 100% an extension over C and all new semantics were using a new syntax. So you knew that the C code was C and performing like C while the Scheme code was Scheme and performing like Scheme by looking at it. ARC semantics arguably follow this as you're using the Objective-C syntax for all occurrences of the Object. Reference counting is also great and predictable which is the main reason MRC was used in 1.0 until Apple decided it was too hard and introduced GC only for it to be canned shortly after as someone came up with the ARC solution. With property syntax sugar, however, you can't tell whether "a.length" is sending a bunch of messages or simply accessing a struct which are two very dissimilar operations.
carpe__diem 8mo ago
libobjc is simply great. Old school, but great.

145 points by ingve 8mo ago

Good time to check out ObjFW [1], it's a cross platform ObjC framework that's just really awesome [1] https://git.nil.im/ObjFW/ObjFW https://git.nil.im/ObjFW/ObjFW

vintagedave 8mo ago
I hadn't come across this. Insane (if true, I've never tried) that GnuStep is not 100% compatible, surely that would be the point. How easy is it to port, say, a Leopard-era Objective C app to ObjFW?
- steeleduncan 8mo ago
  I tried this with an old iOS only game a few years ago. It is clearly not a heavily used library, but it seemed to work ok - There was a bug or two I had to patch, but the code is readable, so it wasn't a big deal - OFString, etc aren't intended to be 1:1 replacements for NSString, etc. This wasn't a real problem. They mostly match, and all I needed to do was write a few categories - The runtime functions are not compatible at all, but most projects wouldn't touch those - CoreFoundation and the other C APIs are not there at all, so you'll need replacements - It is a replacement for Foundation framework, not AppKit, so if it is a GUI app you still have a lot of work to do
  - rweichler 8mo ago
    This is why I went with GNUstep. All of the APIs are 1:1 with Apple's, including the runtime (which is very important imo). It has AppKit support as well; its AppKit implementation is kind of half-baked, but at least it exists. Also, a lot of the APIs are kind of old. But looking at how Swift evolved over the years, maybe that's not a bad thing. My main complaint with GNUstep is the licensing. The runtime itself is MIT which is great, but its implementation of Foundation/AppKit is LGPL. ObjFW, including its runtime, is LGPL. At least with GNUstep one day I can create my own version of Foundation based on Cocotron or swift-corelibs-foundation or something, and not need to muck with rpaths + ship a bunch of .dll/.dylib/.so files with my app in order to comply with the license.
apple4ever 8mo ago
It really is really awesome! It's what I write in when I want to use it on Linux. GNUStep is stuck in 1995 sadly.

vintagedave 8mo ago

I really miss Objective-C, and in the world of Swift craziness [1] I'm reminded often of this blog post [2] wondering what would have happened if Apple hadn't encountered Second System Syndrome for its recommended language. (There's a decent argument it encountered it in iOS and macOS too.) [1] https://github.com/swiftlang/swift-evolution/blob/main/proposals/0507-borrow-accessors.md 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. [2] https://medium.com/goodones/pareto-optimal-apple-devtools-b47e79b6676f https://medium.com/goodones/pareto-optimal-apple-devtools-b4...

tarentel 8mo ago
I go back and forth. I do miss the simplicity of objc at times though. I think in a short amount of time someone can become close to an expert in objc. Swift is already incredibly complicated and there's no end in sight.
- ardit33 8mo ago
  I hate how pendantic and useless some of the features of swift being pushed down by academics that don't write apps or services themselves. Simple example: Objective-C if myObject { } in swift if myObject != nil { } Also opitionals in swift could have totally be avoided if they adopted a prototype based langue (basically object are never nil). Lua did this, and it is very elegant But meanwhile, we got a half backed optional system, which is backwards (similiar to Java), and didn't help with the practicality of the language at all, and meanwhile you still can crash an app doing myArray[1]
  - andrekandre 8mo ago
    > you still can crash an app doing myArray[1] the first thing i do when starting a new project: extension Array { subscript(safe: Int) -> Element? { ... } } there was talk in the swift forms about adding that as standard that but it seems to have died off... [0] https://forums.swift.org/t/draft-adding-safe-indexing-to-array/10767/135 https://forums.swift.org/t/draft-adding-safe-indexing-to-arr...

waynecochran 8mo ago

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.

iainmerrick 8mo ago
Yeah, Objective-C++ is surprisingly great. It sounds like a terrible idea, but the bridging works pretty much seamlessly, and Obj-C and C++ don't actually overlap all that much so they don't step on each other's toes. Each language has strengths that shore up the weak spots in the other.
- delta_p_delta_x 8mo ago
  +1 to Objective-C++. It makes for some surprisingly clean, compact code, best of both worlds, really. And the bridging between ARC and CF types is really quite magical, more languages should have that ability to be expressed in an older language without stripping everything out. I just wish there were Objective-C bindings for more CF classes without having to mess with C.
billti 8mo ago
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

9rx 8mo ago

> [[those squareBrackets] lookInsane:YES]. Nah, they are perfectly sane. They look like little ASCII envelopes because that's exactly the metaphor. Square brackets send messages.

nmeofthestate 8mo ago
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.
- pavlov 8mo ago
  They're not direct function calls, but sugar for objc_msgSend(): https://developer.apple.com/documentation/ObjectiveC/objc_msgSend https://developer.apple.com/documentation/ObjectiveC/objc_ms...
- 9rx 8mo ago
  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.
  - chuckadams 8mo ago
    > a 'true' OOP language, like Smalltalk. I guess Simula, which is older than Smalltalk, doesn't get a say.
    - 9rx 8mo ago
      What would it have to say about it? When "object-oriented" was first told, it was said that what defines it is message passing. Simula does not have message passing. It uses function calling. Simula does have objects, but having objects does not imply orientation.
  - flohofwoe 8mo ago

seanalltogether 8mo ago

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.

iainmerrick 8mo ago
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.
- catoc 8mo ago
  It is a really pleasant language, but I think the <nonnull> annotation is for initialization only - compiler checking against initializing an object ptr with a null value - and does not prevent crashing when addressing an already released object
  - junofan 8mo ago
    > does not prevent crashing when addressing an already released object I don’t know what behavior you’d expect here or in what situation you’d encounter this for a nonnull reference. You’d have to be really living dangerously I’d imagine. The footgun was that nonnull isn’t enforced. And anyway, leaks were more the issue.
    - catoc 8mo ago
      That was exactly my point. GP mentioned ‘chasing null pointer exceptions’, then parent mentioned that the language ’now does have nonnull annotation’, prompting me to explain that that does not prevent null pointer exceptions. So, not living a dangerously. All that can be held against me is being “dangerously” imprecise on HN - definitely not good either
- plorkyeran 8mo ago
  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).

netbioserror 8mo ago

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.

socialdemocrat 8mo ago
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.
- andrekandre 8mo ago
  i really really like swift actually, it lets me express things that are harder in many languages... that being said, i also feel this as well... idk i feel like swift went too hard in the static direction which makes a lot of things harder than they should be such as hot-loading while developing etc

Naman-Dixit 8mo ago

> you’ll realize how small a language it is, how easy to hold in your palm and turn around and understand all sides of it I have never programmed in ObjC but was curious to learn how it works, and so I decided to write a ObjC runtime [0]. It took less than 2000 lines, and a large number of them are comments. Now I wonder how easy would it be to do dome lispy symbolic computing in it. Maybe something like a Prolog. [0] https://gist.github.com/namandixit/76cd084676acdf16cfd014cbbee7026d https://gist.github.com/namandixit/76cd084676acdf16cfd014cbb...

LoganDark 8mo ago

I recently started writing for macOS in Swift and, holy hell, the debuggability of the windowing toolkits is actually unparalleled. I've never seen something that is this introspectable at runtime, easy to decompile and analyze, intercept and modify, etc. Everything is so modular, with subclassing and delegation patterns everywhere. It seems all because of the Objective-C runtime, as without it you'd end up needing something similar anyway. You can reach into built-in components and precisely modify just what you want while keeping everything else platform-native and without having to reimplement everything. I've never seen anything like this before, anywhere. Maybe OLE on Windows wanted to be this (I've seen similar capabilities in REALLY OLD software written around OLE!) but the entirety of Windows' interface and shell and user experience was never unified on OLE so its use was always limited to something akin to a plugin layer. (In WordPad, for example) The only thing that even seems reminiscent is maybe Android Studio, and maybe some "cross-platform" toolkits that are comparatively incredibly immature in other areas. But Android Studio is so largely intolerable that I was never able to dig very far into its debugging capabilities. I feel like I must be in some sort of honeymoon phase but I 100% completely understand now why many Mac-native apps are Mac-native. I tried to write a WinUI3 app a year or two ago and it was a terrible experience. I tried to get into Android app development some years ago and it was a terrible experience. Writing GUIs for the Linux desktop is also a terrible experience. But macOS? I feel like I want to sleep with it, and I weep for what they've done with liquid glass. I want the perfection that led to Cocoa and all its abstractions. Reading all the really, super old documentation that explains entire subsystems in amazingly technical depth makes me want to SCREAM at how undocumented, unpolished and buggy some of the newer features have gotten. I've never seen documentation anything like that before, except for Linux, on Raymond Chen's blog, and some reverse-engineering writeups. I do love Linux but its userspace ecosystem just is not for me. Maybe this is also why Smalltalk fiends are such fans. I should really get into that sometime. Maybe Lisp too.

kmeisthax 8mo ago
> Writing GUIs for the Linux desktop is also a terrible experience. I've found the DX for GTK to be at least tolerable. Not fantastic, but I can at least look at a particular API, guess how the C-based GObject code gets translated by my language bindings of choice, and be correct more often than not. The documentation ranges from serviceable to incomplete, but I can at least find enough discussion online about it to get it to do what I want. Also, GTK apparently ships with a built-in inspector tool now. Ctrl-Shift-I in basically any GTK app opens it. That alone is extremely useful, and you basically have to do nothing to get it. It's free. I've never tried Qt. The applications that use it always seem off to me. As for OLE, you're actually thinking of COM, not OLE. They were co-developed together: COM is a cross-language object system (like GObject), while OLE is a set of COM interfaces for embedding documents in other arbitrary documents. Like, if you want to put a spreadsheet into a Word document, OLE is the way you have to do that. Microsoft even built much of IE[0] on top of OLE to serve as its extension mechanism. OLE is dead because its use case died. Compound documents as a concept don't really work in the modern era where everything is same-origin or container sandboxed. But COM is still alive and well. It's the glue that holds Windows together - even the Windows desktop shell. All the extension interfaces are just COM. The only difference is that now they started packaging COM objects and interfaces inside of .NET assemblies and calling it "WinRT". But it's the same underlying classes. If you use, say, the Rust windows crate, you're installing a bunch of language bindings built from WinRT metadata that, among other things, call into COM classes that have been there for decades. Mac apps are Mac native because Apple gives enough of a shit about being visually consistent that anyone using a cross-platform widget toolkit is going to look out of place. Windows abandoned the concept of a unified visual identity when Windows 8 decided to introduce an entirely new visual design built around an entirely new[1] widget toolkit, with no consideration of how you'd apply any of that to apps using USER.dll/Common Controls. As it stands today, Windows does not have a good answer to "what widget toolkit do I use to write my app", and even Microsoft's own software teams either write their own toolkits or just use Electron. [0] Petition to rename ActiveX to WebOLE [1] OK, yes, XAML existed in the Vista era, but that was .NET only, and XAML apps didn't look meaningfully different from ones building their own USER.dll window classes like it's 1993.

sgt 8mo ago

That's it, I'm pivoting my startup technically and rewriting everything in ObjC! /s

Towaway69 8mo ago
I wonder how well AI generates Obj-C - it might well produce better quality code for your token/buck! In a previous life, one would select the programming language according how expensive developers were. Nowadays it's the quality that an AI can generate. What a wonderful future we've put together. /s
- GaryBluto 8mo ago
  I've been using Opus 4.6 to make myself a harness for old Macs that uses models offered by the Github Copilot subscription. From my experience, when it creates working Objective-C, it's great. When it slips up, it slips up majorly.

mghackerlady 8mo ago

I've always liked Objective-C. Despite me not really liking object-oriented programming, I appreciate that its one of a handful of languages to do actual smalltalk-esque oop

danielvaughn 8mo ago

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.

zarzavat 8mo ago

Smalltalk is like pizza. Even when it's bad, it's still pretty good.

flohofwoe 8mo ago

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.

safercplusplus 8mo ago
Interestingly, I recently auto-translated wget from C to a memory-safe subset of C++ [1], which involves the intermediate step of auto-converting from C to the subset of C that will also compile under clang++. You end up with a bunch of clang++ warnings about various things being C11 extensions and not ISO C++ compliant, but it does compile. [1] https://duneroadrunner.github.io/scpp_articles/PoC_autotranslation_of_wget https://duneroadrunner.github.io/scpp_articles/PoC_autotrans...
j16sdiz 8mo ago
I think C++ have caught up with C99 already. So it's late 90s, not mid-90s :)
- flohofwoe 8mo ago
  No not really, for instance the designated init feature in C++20 is a distinctive C++ feature which is not compatible with C99's designated init. AFAIK the C subset hasn't changed since C++98.
nly 8mo ago
What C features can you not realistically use from C++?
- anthk 8mo ago
  People shoudld realize that since long ago C and C++ are not sub/supersets, but interesecting sets.
- 201984 8mo ago
  C11 atomics, C11 threads, variable length arrays, safely reading from an inactive union member, designated array initializers, compound struct literals, implicitly converting a void pointer to a typed one, and the list goes on.

mikehall314 8mo ago

Every so often I get weirdly obsessed with Objective-J, which "has the same relationship to JavaScript as Objective-C has to C". It is (was?) an absolutely bonkers project. I think it has more or less died since 280 North was acquired. https://www.cappuccino.dev/learn/objective-j.html https://www.cappuccino.dev/learn/objective-j.html

ihumanable 8mo ago
Same. I remember when this first came up and I was like "this is so weirdly interesting." Sad that they got acquired because it was just fascinating what they were doing, even if I was never going to use it.
zffr 8mo ago
Holy shit, it’s still being actively developed and maintained https://github.com/cappuccino/cappuccino https://github.com/cappuccino/cappuccino
- Towaway69 8mo ago
  More amazingly the guy doing the most recent maintaining[1] is a medical Professor at Freiburg Uni. [1]: https://github.com/daboe01 https://github.com/daboe01
- vintagedave 8mo ago
  And wow, it's basically a web version of Cocoa! Check this out: https://ansb.uniklinik-freiburg.de/ThemeKitchenSinkA3/ https://ansb.uniklinik-freiburg.de/ThemeKitchenSinkA3/
sgt 8mo ago
Weren't they acquired by Motorola?
- mikehall314 8mo ago
  Yes, after which they announced they were canning their "Atlas" project, which was meant to be an Interface Builder for the web. Motorola decided they wanted to keep the technology in house. No idea if they ever did anything with it!

millerm 8mo ago

Wow, I haven't written any Objective-C since around 2012. I just went back and looked at some code I had written back then and that really brought back some memories. I was much happier then. I'm perpetually sad and unemployed now. That's all. Enjoy yourselves.

gwbas1c 8mo ago

One of the things I miss about Objective C is just how easy it is to call into a C API, or otherwise include a C function if that's the easiest way to call into a C API. I shipped a cross-platform C# project, and once I realized I could expose "ordinary C" from the Objective C part, it was very easy to integrate the two without using a framework. (It helped that the UI was 100% Objective C, so there wasn't much surface area between the C# and Objective C parts. We initially used MonobjC, but first I had to work around a shortcoming, and then we needed to remove MonobjC due to licensing and some of the newer C# integration layers were not available.)

rixtox 8mo ago

The most difficult part of Objective-C is its ARC rules, and mixing ARC and non-ARC code in the same project.

zerr 8mo ago

Any popular cross-platform GUI toolkits? How do you find GNUstep?

JSR_FDED 8mo ago

[objC retain]

DerekL 8mo ago
Hopefully, you're using ARC by now, so that's a no-op!

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.

klajddeda 8mo ago

[dead]

Klonoar 8mo ago

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/Modules/SalmonBayCore/Sources/SalmonBayCore/Utilities/SBJSONWriter.m 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.

monster_truck 8mo ago

Someone should vibe code Objective-C 3.0

krackers 8mo ago
What features do you think it needs, that wouldn't spoil the "elegance" of the language? I think one good feature would be higher order messaging, in fact there's already a PL paper discussing how it looks like in objective-c [1] which would add FP-like filter/map elegance that all modern languages have. This would go nicely with simpler "JS lambda" style block syntax to make functional-style programming easier in objc. [1] https://dl.acm.org/doi/epdf/10.1145/1146841.1146844 https://dl.acm.org/doi/epdf/10.1145/1146841.1146844
- monster_truck 7mo ago
  Probably something like this, all it really needs to do is absorb the good parts of Swift and unfuck the actors/concurrency: https://github.com/doublemover/Slopjective-C https://github.com/doublemover/Slopjective-C I don't know if I like what that paper is suggesting, but I will give it a rip.
avadodin 8mo ago
If it makes Objective C 1.0 with ARC(but none of the swift-alpha Java syntax) and bindings for QT I won't even care it is made by AI.
- monster_truck 7mo ago
  Can you elaborate on this? I learned Objective-C not long after 2.0 came out so I do not have much perspective on what exactly you'd want. I remember looking at it and thinking it was pretty fragile and boilerplate-y
  - avadodin 7mo ago
    The nice thing about Objective-C up to 2.0 was that it was 100% an extension over C and all new semantics were using a new syntax. So you knew that the C code was C and performing like C while the Scheme code was Scheme and performing like Scheme by looking at it. ARC semantics arguably follow this as you're using the Objective-C syntax for all occurrences of the Object. Reference counting is also great and predictable which is the main reason MRC was used in 1.0 until Apple decided it was too hard and introduced GC only for it to be canned shortly after as someone came up with the ARC solution. With property syntax sugar, however, you can't tell whether "a.length" is sending a bunch of messages or simply accessing a struct which are two very dissimilar operations.

carpe__diem 8mo ago

libobjc is simply great. Old school, but great.