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.
Anyone know if this is or ever was the basis for Apple's iCloud web apps on iCloud.com (e.g. Keynote / Pages / Notes etc.)? Those apps are heroic attempts to replicate the desktop app experience in the browser. I'm curious what web framework is underlying it. Side note - if I could install 3rd party apps w/ similar UIs in my iCloud dashboard that would be interesting.
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.
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.
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.
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.
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/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.
> Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C.
Rust? Rust is basically a simpler Swift. The objective-c bindings are really nice too, and when you're working with obj-c you don't have have worry about lifetimes too much, because you can lean on the objective-c runtime's reference counting.
I think the way to think about it is that with Rust, it's as if all the goodness in Swift was implemented with in the "C" level, and the Objective-C but is still just library-level a runtime layer on top. Whereas Swift brings it's own runtime which greatly complicates things.
I would absolutely not call Rust a simpler Swift. Swift doesn't have and ownership/borrowing system, explicit lifetime for objects, much more expressive (and therefore complex) macro support...
I get that there's a tradeoff. Rust requires you to be way more explicit about what you're intending upfront and that can, in the long term, lead to simpler code -- but there's no dimension (depth-wise or breadth-wise) that I'd call Rust simpler.
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.
Except the entire design of swift is meant to make everything more automated.
* automated exclusivity with value types and value witness tables, classes as arc types (ie Arc<Mutex<T>>)
* automated interop with C/C++/Obj-C through the clang ast importer
Maybe they could have started with rust and added on what they needed, but why not build a new language at that point where things so fundamental are involved?
>[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, safe, very-low-level code. It will be entirely optional for the average Swift developer to learn how to use these features, just in the same way that it's optional for someone to learn Rust.
Obj-C’s simplicity can be nice, but on the other hand I don’t miss having to bring in a laundry list of CocoaPods to have features that are standard in Swift. I don’t miss maintaining header files or having to operate in old codebases that badly manage Obj-C’s looseness either.
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.
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
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.
+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.
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.
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
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.)
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
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.
> 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.
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:
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'.
> 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.
> can respond to messages that it doesn't have a method for.
Clang produces a warning in that case though (something along the lines of "object might not respond to ..."), I don't think that feature is particularly useful in practice (also because it kills any sort of type safety) :)
It was incredibly useful in the olden days. The NeXT/Apple ecosystem leaned on it heavily.
We have new ways to approach problems nowadays, so it may be fair to say that object-oriented programming is a relic of the past. I mean, it is telling that Smalltalk, Objective-C, and Ruby are the only languages to ever go down that road. Still, if you are using an OO language, then it makes sense to lean into OO features. Otherwise, why not use a language better suited to your problem?
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.
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.
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.
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
https://www.cappuccino.dev/learn/objective-j.html
Sad that they got acquired because it was just fascinating what they were doing, even if I was never going to use it.
[1]: https://github.com/daboe01
[1] https://duneroadrunner.github.io/scpp_articles/PoC_autotrans...
Having done both ObjC with nonnull annotations, and Swift, I agree that it’d be hard to forgo the having first-class support for Optionals
(There's a decent argument it encountered it in iOS and macOS too.)
[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.
[2] https://medium.com/goodones/pareto-optimal-apple-devtools-b4...
Rust? Rust is basically a simpler Swift. The objective-c bindings are really nice too, and when you're working with obj-c you don't have have worry about lifetimes too much, because you can lean on the objective-c runtime's reference counting.
I think the way to think about it is that with Rust, it's as if all the goodness in Swift was implemented with in the "C" level, and the Objective-C but is still just library-level a runtime layer on top. Whereas Swift brings it's own runtime which greatly complicates things.
I get that there's a tradeoff. Rust requires you to be way more explicit about what you're intending upfront and that can, in the long term, lead to simpler code -- but there's no dimension (depth-wise or breadth-wise) that I'd call Rust simpler.
* automated exclusivity with value types and value witness tables, classes as arc types (ie Arc<Mutex<T>>)
* automated interop with C/C++/Obj-C through the clang ast importer
Maybe they could have started with rust and added on what they needed, but why not build a new language at that point where things so fundamental are involved?
These kinds of features are not intended for use in daily application development. They're systems-language features designed for building high performance, safe, very-low-level code. It will be entirely optional for the average Swift developer to learn how to use these features, just in the same way that it's optional for someone to learn Rust.
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
I just wish there were Objective-C bindings for more CF classes without having to mess with C.
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.)
[1] https://git.nil.im/ObjFW/ObjFW
How easy is it to port, say, a Leopard-era Objective C app to ObjFW?
- 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
That's all. Enjoy yourselves.
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/76cd084676acdf16cfd014cbb...
Nah, they are perfectly sane. They look like little ASCII envelopes because that's exactly the metaphor. Square brackets send messages.
https://developer.apple.com/documentation/ObjectiveC/objc_ms...
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'.
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.
Clang produces a warning in that case though (something along the lines of "object might not respond to ..."), I don't think that feature is particularly useful in practice (also because it kills any sort of type safety) :)
We have new ways to approach problems nowadays, so it may be fair to say that object-oriented programming is a relic of the past. I mean, it is telling that Smalltalk, Objective-C, and Ruby are the only languages to ever go down that road. Still, if you are using an OO language, then it makes sense to lean into OO features. Otherwise, why not use a language better suited to your problem?
I guess Simula, which is older than Smalltalk, doesn't get a say.
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.
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.
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.
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