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.
Didn't expect to see cappuccino mentioned ever again. It was so wild, you can use AppKit documentation for cappuccino. Apps were so pretty and yet so fast.
I remember back in 2009 I really liked their coffee machine icon. I emailed the devs, they referred me to some design studio, and then to my surprise they replied and said that it's Francis Francis X1. Now I'm looking at it in my home office.
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.
I think originally Apple was using SproutCore, which had similar aspirations to produce "desktop quality" web apps, and was one of the early frameworks to implement things like two-way data binding. This was back when iCloud was called MobileMe.
SproutCore 2.0 became Ember.js 1.0, but I don't know if Apple are still using it.
Cappuccino was not an Apple project, so I doubt that is what Apple used to develop those projects. That, and 280 North eventually got acquired by Motorola.
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.
Best I can tell, it turned into Google Web Designer!
I'm on the outside, but best I can tell:
- You're thinking of a UI design tool called "Ninja"
- Google purchased Motorola Mobility and the Ninja project got cancelled
- Google launched Google Web Designer, that basically had an almost identical UI. As far as I can tell the internals are different, but probably shared some code or at least design work.
Possibly! The tool was definitely named Atlas when it was going to be an open source tool made by 280 North [1]. But it could have been renamed Ninja after Moto acquired it.
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.
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.
You can simply import Swift packages and either they expose an Objc interface or you can provide it yourself – by wrapping it in Swift and exposing the things you need via @objc etc. You can - at the same time - also hide the wrapped framework and make it an impl. detail of the wrapper so that you could switch the wrapped framework while keeping your app code mostly stable. This also reduces the number of imported symbols… import 3rdPartyFramework imports all symbols, extensions, classes, types etc. vs. import MyWrapper only brings in the things you really need.
I don't miss @ and [] all over the place, even if Objective-C has some cool ideas into it.
I do agree Swift's design has gone a bit overbord, we wanted Delphi and got Haskell instead.
However note the same phenomen happening with other languages, as soon as you have a team being paid to develop a language, their job depends on adding features in every single release.
Programming languages are products, even those that praise C's simplicity have certainly not read compiler manuals about language extensions, or the mailings from WG14 proposals.
> However note the same phenomen happening with other languages, as soon as you have a team being paid to develop a language, their job depends on adding features in every single release.
Users also request those features. You said yourself that programming languages are products. In that sense, people are always evaluating them through the lenses of utility (the economics concept), and if they have to pick between two languages, with similar capabilities, they will pick up the one that maximises that utility.
This to weird design decisions getting inserted into the fabric as a consequence (the current state of C++ comes to mind). And given developers are too opinionated about everything, we get politics as a side effect.
Ideally Swift would have been something with compile speed of Delphi, its RAD capabilities, strong typing with a good enough type system to support the transparent migration path from Objective-C, and that was it.
Instead we have quite a few type systems ideas going back and forth, with some hard changes across language versions, as if playing with Haskell type system, and GHC feature flags.
> Users also request those features.
Some users request those features, most of them come from team themselves roadmap, regarding what cool features to add next.
Then as politics get into the game, naturally the process of what features land into the stable implementation, and what fail by the wayside depends pretty much how they get pushed into adoption.
>[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.
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 rough and confusing. It's not super clear to me that much of it could have been avoided (maybe if the value of Approachable Concurrency mode had been understood to be important from the beginning?), and the benefits are real, but my gut feeling is that a lot of the "Swift is too complicated" stuff is probably just misplaced annoyance at this.
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).
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 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]
I love Obj-C, but the Swift version isn't as bad as you say:
if let myObject {
// myObject is non-nil in here
}
The Swift version is also usingfirst-class optionals. In Obj-C there is very small chance you'll confuse `NULL` with `nil` or `0`. Or that you'll message `nil` resulting in `nil`.. and in well-built software you have to guard against that.
Aside: Obj-C is narrowly focused on adding objects (in the Smalltalk sense) to C whereas Swift is trying to deliver a compiler and language with memory safety _guarantees_... Turns out that means you need a lot more language. Not to mention the `async` syntax/feature explosion.
Obj-C is "hippie" and Swift is "corporate suit" + "we're doing serious work here!"
Finally I want to say: I believe Obj-C was a huge competitive advantage and secret weapon that let Apple deliver an OS with so much more built-in functionality than any competitor for years and years. (Obj-C is great for system APIs) That's under-appreciated.
Even with that there is nothing from you accidentally using [i]. Also there are just a ton of Swift APIS and bridge API that take an index and then crash… for full coverage you would need hundreds of safe wrappers… (doing what you propose though at least gives you. Some peace of mind..
Also Swift has a lot of other areas where it just lacks any safeguards… Memory issues are still a thing. It’s using ARC under the hood after all.
Infinite recursion is still a thing (not sure if this would even detectable - probably not).
Misuse of APIs.
And it introduces new issues: which methods are being called depends on your imports.
In my experience Swift lulls you into a false sense of safety while adding more potential safety issues and “only” solving some of the less important ones. objc has null ability as well. Which can warn u if used appropriately. objc also has lightweight generics. In practice this is all you need.
> And it introduces new issues: which methods are being called depends on your imports.
also depending on how you casted it, it will call the method of the cast, not the actual one in the instance (which completely caught be off-guard when i started swift)
> objc also has lightweight generics. In practice this is all you need.
i feel this too sometimes; sometimes simple really is best... tho i think some of these decisions around complexity is to allow for more optimization so c++ can be chucked away at some point...
> 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.
While Swift now has the `borrowing` and `consuming` keywords, support for storing references is nonexistent, and the only way to return/store `Span`s, etc, is only possible through using experimental `@lifetime` annotations.
Swift is a nice language, and it's new support for the bare necessity of affine types is a good step forward, but it's not at all comparable with Rust.
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?
Source: I worked in lattners org at the time of swifts inception (on an unrelated backend) but that was the motivation. I also worked on the swift compiler for a little bit some years later on in my career.
> Maybe they could have started with rust and added on what they needed
Unlikely, I think, because of timelines. Swift’s first public release was in June 2014. Rust is a few years older (first public release in January 2012), but that wasn’t the rust we have today. It still had garbage collection, for example (https://en.wikipedia.org/wiki/Rust_(programming_language)#20...)
Rust is still more complicated than Swift, but you needn't worry - the Swift team is flexing their muscles hard to ensure that Swift becomes the biggest, most complicated language on Earth and wins the complexity, cognitive burden and snail performance once and for all eternity. Their compiler already times out on the language, soon even an M7 will also give up.
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.
It kind of is, when the goal was to be TypeScript for C, before this was even a concept.
Now ideally we would all be using Modula-2, Ada, Delphi, VB, C#,.... and co, but given that even C compilers are nowadays written in C++, we make do with what we have, while avoiding C flaws as much as possible.
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.
Writing objective-c code for mac os GUI apps was one of those things that finally made "interfaces"/"protocols" really click for me as a young developer. Just implement (some, not even all) method in "FooWidgetDelegate", and wire your delegate implementation into the existing widget. `willFrobulateTheBar` in your delegate is called just before a thing happens in the UI and you can usually interfere or modify with the behavior before the UI does it. Then `didFrobulateTheBar` is called after with the old and new values or whatever other context makes sense and you can hook in here for doing other updates in response to the UI getting an update. If you don't implement a protocol method, the default behavior happens, and preserving the default behavior is baked into the process, so you don't have to re-implement the whole widget's behavior just to modify part of it.
It's probably one of the better UI frameworks I think I've used (though admittedly a lot of that also is in part due to "InterfaceBuilder" magic and auto-wiring. Still I often wish for that sort of elegant "billions of hooks, but you only have to care about the ones you want to touch" experience when I've had to use other UI libraries.
> 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.
it seems like everybody prefers ios, but i really still think after all these years i prefer appkit; it really is so well documented and the quality of the api is the best i've seen by a long mile
> Reading all the really, super old documentation that explains entire subsystems in amazingly technical depth
Any links?
> Maybe this is also why Smalltalk fiends are such fans.
I started getting interested in Smalltalk after I tried writing a MacOS program by calling the Objective-C runtime from Rust and had a surprisingly good time. A Smalltalk-style OO language feels like a better base layer for apps than C.
Generally everything in that documentation archive is absolutely amazing. I don't know why it's an archive; presumably they laid off or reassigned the entire team working on it and there will be no more. The closest thing today would probably be Technotes: https://developer.apple.com/documentation/technotes
> 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.
> 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.
Oops, you are right about COM. I got them mixed up because I was thinking of the integration in WordPad.
> 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.
Mac apps are Mac native because the APIs are amazing and the ROI can be really really good. It takes so much effort to do the same from scratch, especially cross-platform, that, you're right, I can smell anything written in Qt (because the hitboxes and layout are off) or GTK (because the widget rendering is off).
With that said though, wxWidgets seems to translate EXTREMELY well to macOS, though last I used it, it didn't have good support for Mojave's dark mode. Maybe support is better nowadays. For example, Audacity appears to me as just a crammed Mac-native app rather than blatant use of a cross-platform toolkit, and wxPython used well can be completely mistaken for fully native.
wxWidgets calls the underlying native controls directly; Qt uses it to inform how to render but still does its own thing, at least according to a discussion I had with a Qt engineer some years back.
(I am open to being corrected)
wxWidgets has properly supported dark mode for a bit now.
9front can mount old DOC/XLS documents as OLE 'filesystems' first and then extract the tables/text from them.
As for sandboxing, 9front/plan9 uses namespaces, but shared directories exist, of course. That's the point on computing, the user will want to bridge data in one way or another. Be with pipes, with filesystems/clipboard (or a directory acting as a clipboard with objects, which would be the same in the end).
Welcome to Smalltalk, Lisp, Java and .NET, which alongside NeXTSTEP/OS X, share a common linage of tooling ideas, and programming language features.
Hence why given the option I rather stay in such environments.
Now Android Studio is the product of Google's mess, and I am glad to have moved away from Android development, it also doesn't have anything to do with enjoying pure Java development on desktop (Swing, SWT, JavaFX) and server.
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.
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
> 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.
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
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).
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.
That is an API choice from Apple that isn't something inherent to objc. This is true of any method. It is up to the person who wrote it to decide how to handle a nil being passed in.
Frankly, all of this is an API and ABI choice from Apple. It was not the case that sending a message to nil always returned nil/NULL/0 before Apple's Intel transition, and the subsequent introduction of their modern Objective-C ABI. From Apple's 2006 Cocoa coding guidelines:
> If the message sent to nil returns anything other than the aforementioned value types (for example, if it returns any struct type, any floating-point type, or any vector type) the return value is undefined
And from the Intel transition guide:
> messages to a nil object always return 0.0 for methods whose return type is float, double, long double, or long long. Methods whose return value is a struct, as defined by the Mac OS X ABI Function Call Guide to be returned in registers, will return 0.0 for every field in the data structure. Other struct data types will not be filled with zeros. This is also true under Rosetta. On PowerPC Macintosh computers, the behavior is undefined.
This wasn't just a theoretical issue, either. You could run the same Objective-C code on a PPC Mac, an Intel Mac, the iPhone Simulator, and an iPhone – you'd get a zero-filled struct on Intel and the Simulator, while you'd get garbage on PPC and on real iPhone hardware.
When Swift 1 came out, I was migrating an ObjC app that used CoreData to it and found a bug where nullable cols in the CoreData schema got non-nullable properties in the autogenerated Swift. Found out when I had a non-nullable property actually get set to null at runtime, and the compiler wouldn't let me add a check that it's null.
The Swift way is safer, but I don't like it much either. The ? explicitly says you want to ignore null, so that's fine. The problem is there's no convenient way to throw exception if null, so you're encouraged to overuse ?, as I think you alluded to. (! will crash the entire program instead.) Swift error handling is overall pretty complex too.
Ironically the JS or Py error handling is actually the safest for high-level code. Exceptions are easy to work with and hard to ignore by accident. Very few ways to crash entirely. And Rust's errors are good for systems code.
Not really, because doSomething is not called if reference/pointer is null, whereas in Objective-C there is still a message that is sent to the NULL recipient.
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.
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.
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.
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.
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.
In GCC and Clang it's quite relaxed since their C++ frontends pull in a couple of modern C features as non-standard C++ extensions, but MSVC has a strict separation between the C++ and C frontend and doesn't allow this sort of 'cross-pollution'.
As a quick example, this C99 code block has at least 4 features that don't work in C++:
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
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.
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) :)
And the reason it’s a warning and not an error (like in C++) is that it’s actually possible that the object can respond to such a message but the compiler doesn’t know about it.
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?
> 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?
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 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
Metal is the last Mac OS framework that was fully done in Objective-C, however contrary to Microsoft, at least Apple does provide first class bindings to Swift.
To this day, .NET is not welcomed on the Windows division, and they rather go out of their way producing stuff like WinRT/UWP with the outcome we all know.
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 have my suspicion that it is still used heavily inside Apple. It especially caters to programmers that are control freaks like me -- you are a little closer to the metal (pun intended).
It's not difficult to determine where different languages are used – you can run `symbols -noDemangling BINARY | grep _Z`, where BINARY is a path to any binary, and see how many symbols use Itanium C++ name mangling. You'll see it sprinkled in enough places to get an idea of which parts of the system use it more than others.
Of course, parts of the Objective-C runtime are written in Objective-C++, so someone more pedantic than I might claim that fact alone counts as it being "used heavily."
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.
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'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
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 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
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:
> 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.
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.
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.
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)
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.
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.
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
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
Didn't expect to see cappuccino mentioned ever again. It was so wild, you can use AppKit documentation for cappuccino. Apps were so pretty and yet so fast.
I remember back in 2009 I really liked their coffee machine icon. I emailed the devs, they referred me to some design studio, and then to my surprise they replied and said that it's Francis Francis X1. Now I'm looking at it in my home office.
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.
Holy shit, it’s still being actively developed and maintained https://github.com/cappuccino/cappuccino
More amazingly the guy doing the most recent maintaining[1] is a medical Professor at Freiburg Uni.
[1]: https://github.com/daboe01
And wow, it's basically a web version of Cocoa! Check this out: https://ansb.uniklinik-freiburg.de/ThemeKitchenSinkA3/
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.
I think originally Apple was using SproutCore, which had similar aspirations to produce "desktop quality" web apps, and was one of the early frameworks to implement things like two-way data binding. This was back when iCloud was called MobileMe.
SproutCore 2.0 became Ember.js 1.0, but I don't know if Apple are still using it.
Oh wow I didn’t know that’s where Ember came from.
Cappuccino was not an Apple project, so I doubt that is what Apple used to develop those projects. That, and 280 North eventually got acquired by Motorola.
Weren't they acquired by Motorola?
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!
Best I can tell, it turned into Google Web Designer!
I'm on the outside, but best I can tell:
- You're thinking of a UI design tool called "Ninja"
- Google purchased Motorola Mobility and the Ninja project got cancelled
- Google launched Google Web Designer, that basically had an almost identical UI. As far as I can tell the internals are different, but probably shared some code or at least design work.
Possibly! The tool was definitely named Atlas when it was going to be an open source tool made by 280 North [1]. But it could have been renamed Ninja after Moto acquired it.
[1] https://arstechnica.com/gadgets/2009/03/atlas-a-visual-ide-f...
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.
[2] https://medium.com/goodones/pareto-optimal-apple-devtools-b4...
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.
You can simply import Swift packages and either they expose an Objc interface or you can provide it yourself – by wrapping it in Swift and exposing the things you need via @objc etc. You can - at the same time - also hide the wrapped framework and make it an impl. detail of the wrapper so that you could switch the wrapped framework while keeping your app code mostly stable. This also reduces the number of imported symbols… import 3rdPartyFramework imports all symbols, extensions, classes, types etc. vs. import MyWrapper only brings in the things you really need.
I don't miss @ and [] all over the place, even if Objective-C has some cool ideas into it.
I do agree Swift's design has gone a bit overbord, we wanted Delphi and got Haskell instead.
However note the same phenomen happening with other languages, as soon as you have a team being paid to develop a language, their job depends on adding features in every single release.
Programming languages are products, even those that praise C's simplicity have certainly not read compiler manuals about language extensions, or the mailings from WG14 proposals.
> we wanted Delphi and got Haskell instead
Please elaborate.
> However note the same phenomen happening with other languages, as soon as you have a team being paid to develop a language, their job depends on adding features in every single release.
Users also request those features. You said yourself that programming languages are products. In that sense, people are always evaluating them through the lenses of utility (the economics concept), and if they have to pick between two languages, with similar capabilities, they will pick up the one that maximises that utility.
This to weird design decisions getting inserted into the fabric as a consequence (the current state of C++ comes to mind). And given developers are too opinionated about everything, we get politics as a side effect.
> Please elaborate.
Ideally Swift would have been something with compile speed of Delphi, its RAD capabilities, strong typing with a good enough type system to support the transparent migration path from Objective-C, and that was it.
Instead we have quite a few type systems ideas going back and forth, with some hard changes across language versions, as if playing with Haskell type system, and GHC feature flags.
> Users also request those features.
Some users request those features, most of them come from team themselves roadmap, regarding what cool features to add next.
Then as politics get into the game, naturally the process of what features land into the stable implementation, and what fail by the wayside depends pretty much how they get pushed into adoption.
>[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.
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 rough and confusing. It's not super clear to me that much of it could have been avoided (maybe if the value of Approachable Concurrency mode had been understood to be important from the beginning?), and the benefits are real, but my gut feeling is that a lot of the "Swift is too complicated" stuff is probably just misplaced annoyance at this.
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).
Such a mess. You can tell the people that designed it never wrote a client or an app in their lives. It is pure academic pendatry in display.
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.
A few years from now O'reilly will publish a bestseller called Swift: The Good Parts
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]
I love Obj-C, but the Swift version isn't as bad as you say:
The Swift version is also usingfirst-class optionals. In Obj-C there is very small chance you'll confuse `NULL` with `nil` or `0`. Or that you'll message `nil` resulting in `nil`.. and in well-built software you have to guard against that.Aside: Obj-C is narrowly focused on adding objects (in the Smalltalk sense) to C whereas Swift is trying to deliver a compiler and language with memory safety _guarantees_... Turns out that means you need a lot more language. Not to mention the `async` syntax/feature explosion.
Obj-C is "hippie" and Swift is "corporate suit" + "we're doing serious work here!"
Finally I want to say: I believe Obj-C was a huge competitive advantage and secret weapon that let Apple deliver an OS with so much more built-in functionality than any competitor for years and years. (Obj-C is great for system APIs) That's under-appreciated.
[0] https://forums.swift.org/t/draft-adding-safe-indexing-to-arr...
Even with that there is nothing from you accidentally using [i]. Also there are just a ton of Swift APIS and bridge API that take an index and then crash… for full coverage you would need hundreds of safe wrappers… (doing what you propose though at least gives you. Some peace of mind..
Also Swift has a lot of other areas where it just lacks any safeguards… Memory issues are still a thing. It’s using ARC under the hood after all.
Infinite recursion is still a thing (not sure if this would even detectable - probably not).
Misuse of APIs.
And it introduces new issues: which methods are being called depends on your imports.
In my experience Swift lulls you into a false sense of safety while adding more potential safety issues and “only” solving some of the less important ones. objc has null ability as well. Which can warn u if used appropriately. objc also has lightweight generics. In practice this is all you need.
> 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.
> I would absolutely not call Rust a simpler Swift. Swift doesn't have and ownership/borrowing system
Swift already does have those things but unlike Rust, they are opt-in.
Not going to argue which language is simpler, but sorry, you don't seem like someone who knows Swift very well.
While Swift now has the `borrowing` and `consuming` keywords, support for storing references is nonexistent, and the only way to return/store `Span`s, etc, is only possible through using experimental `@lifetime` annotations.
Swift is a nice language, and it's new support for the bare necessity of affine types is a good step forward, but it's not at all comparable with Rust.
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?
Source: I worked in lattners org at the time of swifts inception (on an unrelated backend) but that was the motivation. I also worked on the swift compiler for a little bit some years later on in my career.
> Maybe they could have started with rust and added on what they needed
Unlikely, I think, because of timelines. Swift’s first public release was in June 2014. Rust is a few years older (first public release in January 2012), but that wasn’t the rust we have today. It still had garbage collection, for example (https://en.wikipedia.org/wiki/Rust_(programming_language)#20...)
Rust is still more complicated than Swift, but you needn't worry - the Swift team is flexing their muscles hard to ensure that Swift becomes the biggest, most complicated language on Earth and wins the complexity, cognitive burden and snail performance once and for all eternity. Their compiler already times out on the language, soon even an M7 will also give up.
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.
It has been there for me since 1993, in every single scenario as alternative to C, when the choice boils down to either of them.
Since 1993, I only have used C when required to do for various reasons out of my control, or catching up with WG14 standards.
how would you write something like
in CEven better example,
Sure, there are nice parts of C++. And there are also brain-dead parts that add needless complexity such as:
* rvalue references
* the difference between auto, decltype, typeof
* unreadable template monstrosities
* various different flavors of "smart" pointer
* the continued existence of footguns relating to UB, dangling pointers, unexpected temporary lifetimes, etc
* total absence of a build system or package management
* legacy APIs that still take raw pointers
* concepts, a half-assed attempt at generic constraints
No worries, you get some of those in C23, and C2y.
Where is C's build system and package management?
Yeah, because using _Generic alongside typeof and preprocessor macros isn't half-assed attempt at generics.
You misunderstood. Perpetuating C's weaknesses, and then adding additional complexity, is not a defense.
It kind of is, when the goal was to be TypeScript for C, before this was even a concept.
Now ideally we would all be using Modula-2, Ada, Delphi, VB, C#,.... and co, but given that even C compilers are nowadays written in C++, we make do with what we have, while avoiding C flaws as much as possible.
C++ if any made C user friendly.
C++ is trying to make something EASIER to use?
Examples?
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.
Writing objective-c code for mac os GUI apps was one of those things that finally made "interfaces"/"protocols" really click for me as a young developer. Just implement (some, not even all) method in "FooWidgetDelegate", and wire your delegate implementation into the existing widget. `willFrobulateTheBar` in your delegate is called just before a thing happens in the UI and you can usually interfere or modify with the behavior before the UI does it. Then `didFrobulateTheBar` is called after with the old and new values or whatever other context makes sense and you can hook in here for doing other updates in response to the UI getting an update. If you don't implement a protocol method, the default behavior happens, and preserving the default behavior is baked into the process, so you don't have to re-implement the whole widget's behavior just to modify part of it.
It's probably one of the better UI frameworks I think I've used (though admittedly a lot of that also is in part due to "InterfaceBuilder" magic and auto-wiring. Still I often wish for that sort of elegant "billions of hooks, but you only have to care about the ones you want to touch" experience when I've had to use other UI libraries.
> Reading all the really, super old documentation that explains entire subsystems in amazingly technical depth
Any links?
> Maybe this is also why Smalltalk fiends are such fans.
I started getting interested in Smalltalk after I tried writing a MacOS program by calling the Objective-C runtime from Rust and had a surprisingly good time. A Smalltalk-style OO language feels like a better base layer for apps than C.
> Any links?
For example, this guide I was reading just earlier: https://developer.apple.com/library/archive/documentation/Co...
Generally everything in that documentation archive is absolutely amazing. I don't know why it's an archive; presumably they laid off or reassigned the entire team working on it and there will be no more. The closest thing today would probably be Technotes: https://developer.apple.com/documentation/technotes
> 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.
> 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.
Oops, you are right about COM. I got them mixed up because I was thinking of the integration in WordPad.
> 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.
Mac apps are Mac native because the APIs are amazing and the ROI can be really really good. It takes so much effort to do the same from scratch, especially cross-platform, that, you're right, I can smell anything written in Qt (because the hitboxes and layout are off) or GTK (because the widget rendering is off).
With that said though, wxWidgets seems to translate EXTREMELY well to macOS, though last I used it, it didn't have good support for Mojave's dark mode. Maybe support is better nowadays. For example, Audacity appears to me as just a crammed Mac-native app rather than blatant use of a cross-platform toolkit, and wxPython used well can be completely mistaken for fully native.
wxWidgets calls the underlying native controls directly; Qt uses it to inform how to render but still does its own thing, at least according to a discussion I had with a Qt engineer some years back.
(I am open to being corrected)
wxWidgets has properly supported dark mode for a bit now.
9front can mount old DOC/XLS documents as OLE 'filesystems' first and then extract the tables/text from them.
As for sandboxing, 9front/plan9 uses namespaces, but shared directories exist, of course. That's the point on computing, the user will want to bridge data in one way or another. Be with pipes, with filesystems/clipboard (or a directory acting as a clipboard with objects, which would be the same in the end).
Welcome to Smalltalk, Lisp, Java and .NET, which alongside NeXTSTEP/OS X, share a common linage of tooling ideas, and programming language features.
Hence why given the option I rather stay in such environments.
Now Android Studio is the product of Google's mess, and I am glad to have moved away from Android development, it also doesn't have anything to do with enjoying pure Java development on desktop (Swing, SWT, JavaFX) and server.
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.
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
> 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.
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
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).
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 `nil`, but the inverse isn't universally true. APIs like
will throw an `NSInvalidArgumentException` if `other` is nil.That is an API choice from Apple that isn't something inherent to objc. This is true of any method. It is up to the person who wrote it to decide how to handle a nil being passed in.
Frankly, all of this is an API and ABI choice from Apple. It was not the case that sending a message to nil always returned nil/NULL/0 before Apple's Intel transition, and the subsequent introduction of their modern Objective-C ABI. From Apple's 2006 Cocoa coding guidelines:
> If the message sent to nil returns anything other than the aforementioned value types (for example, if it returns any struct type, any floating-point type, or any vector type) the return value is undefined
And from the Intel transition guide:
> messages to a nil object always return 0.0 for methods whose return type is float, double, long double, or long long. Methods whose return value is a struct, as defined by the Mac OS X ABI Function Call Guide to be returned in registers, will return 0.0 for every field in the data structure. Other struct data types will not be filled with zeros. This is also true under Rosetta. On PowerPC Macintosh computers, the behavior is undefined.
This wasn't just a theoretical issue, either. You could run the same Objective-C code on a PPC Mac, an Intel Mac, the iPhone Simulator, and an iPhone – you'd get a zero-filled struct on Intel and the Simulator, while you'd get garbage on PPC and on real iPhone hardware.
You can send messages to null, sendings messages to a deallocated pointer is going to be a bad time.
It’s nice not to crash, but unexpected null can still cause bugs in ObjC when the developer isn’t paying attention.
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
When Swift 1 came out, I was migrating an ObjC app that used CoreData to it and found a bug where nullable cols in the CoreData schema got non-nullable properties in the autogenerated Swift. Found out when I had a non-nullable property actually get set to null at runtime, and the compiler wouldn't let me add a check that it's null.
Objective-C did not have null pointer exceptions, though some libraries added them.
If you use Objective-C objects, operations on null pointers are just a no-op, so there is not such thing as chasing exceptions.
So you silently ignore something being null when you don't expect it to be? That sounds even worse.
It's just that
is the default. Le horreur!The Swift way is safer, but I don't like it much either. The ? explicitly says you want to ignore null, so that's fine. The problem is there's no convenient way to throw exception if null, so you're encouraged to overuse ?, as I think you alluded to. (! will crash the entire program instead.) Swift error handling is overall pretty complex too.
Ironically the JS or Py error handling is actually the safest for high-level code. Exceptions are easy to work with and hard to ignore by accident. Very few ways to crash entirely. And Rust's errors are good for systems code.
Not really, because doSomething is not called if reference/pointer is null, whereas in Objective-C there is still a message that is sent to the NULL recipient.
No, the messenger identifies the NULL recipient and does not send the message.
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.
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.
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_autotrans...
I think C++ have caught up with C99 already. So it's late 90s, not mid-90s :)
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.
What C features can you not realistically use from C++?
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.
C++ has its own atomics, threads etc. And variable length array's work just fine in C++ in both clang and GCC.
C++ also has it's own designated initializer like syntax.
>C++ has its own atomics, threads etc.
It does indeed, but they are not compatible and at least the C atomics cannot be used from C++.
>C++ also has it's own designated initializer like syntax.
One that is far more limited. This is valid C, but not C++.
Indeed, and some of those, thankfully as C++ is TypeScript for C.
Any language feature added in C99 and later.
In GCC and Clang it's quite relaxed since their C++ frontends pull in a couple of modern C features as non-standard C++ extensions, but MSVC has a strict separation between the C++ and C frontend and doesn't allow this sort of 'cross-pollution'.
As a quick example, this C99 code block has at least 4 features that don't work in C++:
https://github.com/floooh/sokol-samples/blob/91bd8c6f9f52149...
- taking the address of an adhoc-created struct in a function call
- random array access in struct initialization
- designator chaining in struct initialization
- designators can be out-of-order in C but not C++
...also using unions as different views on the same memory is actually useful sometimes.
Nothing of value was lost
People shoudld realize that since long ago C and C++ are not sub/supersets, but interesecting sets.
Smalltalk is like pizza. Even when it's bad, it's still pretty good.
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
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?
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
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.
> [[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.
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.
They're not direct function calls, but sugar for objc_msgSend():
https://developer.apple.com/documentation/ObjectiveC/objc_ms...
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'.
> 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) :)
And the reason it’s a warning and not an error (like in C++) is that it’s actually possible that the object can respond to such a message but the compiler doesn’t know about it.
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?
> 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?
Then what does it mean if "composition over inheritance" is also taught as a good practice in OO?
That's a rule-of-thumb to help beginners in making judgement calls. It doesn't mean inheritance should never be used.
True, but if the defining feature of something is a feature you should use sparingly, doesn't that mean other features are more definitive?
> a 'true' OOP language, like Smalltalk.
I guess Simula, which is older than Smalltalk, doesn't get a say.
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 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
Metal is the last Mac OS framework that was fully done in Objective-C, however contrary to Microsoft, at least Apple does provide first class bindings to Swift.
To this day, .NET is not welcomed on the Windows division, and they rather go out of their way producing stuff like WinRT/UWP with the outcome we all know.
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.
Obj-C++ was used for some hall-of-fame OS X apps, e.g. TextMate
I have my suspicion that it is still used heavily inside Apple. It especially caters to programmers that are control freaks like me -- you are a little closer to the metal (pun intended).
It's not difficult to determine where different languages are used – you can run `symbols -noDemangling BINARY | grep _Z`, where BINARY is a path to any binary, and see how many symbols use Itanium C++ name mangling. You'll see it sprinkled in enough places to get an idea of which parts of the system use it more than others.
Of course, parts of the Objective-C runtime are written in Objective-C++, so someone more pedantic than I might claim that fact alone counts as it being "used heavily."
I made some camera and GPU-heavy features in the Facebook and Instagram app in ObjC++, and yes, it was nice to have that impedance match.
I don't work there anymore, I wonder if they're using the C++ - Swift interop that now exists.
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.
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'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
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 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
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.
> 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/76cd084676acdf16cfd014cbb...
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.
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.
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.
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.
Any popular cross-platform GUI toolkits? How do you find GNUstep?
The most difficult part of Objective-C is its ARC rules, and mixing ARC and non-ARC code in the same project.
Someone should vibe code Objective-C 3.0
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
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.
Why should they vibe code it?
libobjc is simply great. Old school, but great.
That's it, I'm pivoting my startup technically and rewriting everything in ObjC! /s
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
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.
[dead]
[objC retain]
Hopefully, you're using ARC by now, so that's a no-op!