[HN Gopher] Why Objective-C
___________________________________________________________________
Why Objective-C
Author : ingve
Score : 112 points
Date : 2026-02-28 12:41 UTC (2 days ago)
(HTM) web link (inessential.com)
(TXT) w3m dump (inessential.com)
| frityet wrote:
| 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
| vintagedave wrote:
| I hadn't come across this. Insane (if true, I've never tried)
| that GnuStep is not 100% compatible, surely that would be the
| point.
|
| How easy is it to port, say, a Leopard-era Objective C app to
| ObjFW?
| steeleduncan wrote:
| I tried this with an old iOS only game a few years ago. It is
| clearly not a heavily used library, but it seemed to work ok
|
| - There was a bug or two I had to patch, but the code is
| readable, so it wasn't a big deal
|
| - OFString, etc aren't intended to be 1:1 replacements for
| NSString, etc. This wasn't a real problem. They mostly match,
| and all I needed to do was write a few categories
|
| - The runtime functions are not compatible at all, but most
| projects wouldn't touch those
|
| - CoreFoundation and the other C APIs are not there at all,
| so you'll need replacements
|
| - It is a replacement for Foundation framework, not AppKit,
| so if it is a GUI app you still have a lot of work to do
| rweichler wrote:
| 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.
| vintagedave wrote:
| 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...
| tarentel wrote:
| I go back and forth. I do miss the simplicity of objc at times
| though. I think in a short amount of time someone can become
| close to an expert in objc. Swift is already incredibly
| complicated and there's no end in sight.
| ardit33 wrote:
| 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]
| cosmic_cheese wrote:
| 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.
| umpalumpaaa wrote:
| 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.
| nicoburns wrote:
| > 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.
| estebank wrote:
| 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.
| coliveira wrote:
| 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.
| astrange wrote:
| C++ is trying to make something EASIER to use?
| anthk wrote:
| C++ if any made C user friendly.
| zer0zzz wrote:
| 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.
| gbanfalvi wrote:
| 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.
| mojuba wrote:
| > 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.
| needlesslygrim wrote:
| 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.
| lenkite wrote:
| 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.
| anextio wrote:
| >[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.
| glhaynes wrote:
| 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.
| jshier wrote:
| 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).
| ardit33 wrote:
| 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.
| waynecochran wrote:
| I still find Objective-C++ useful for writing MacOS apps that
| make heavy use of C++ libraries (e.g.; Eigen, OpenCV). The caveat
| is I have done a lot of Objective-C programming and Swift is
| still not as seamless as I would like bridging with modern C++
| and the the STL.
| iainmerrick wrote:
| Yeah, Objective-C++ is surprisingly great. It sounds like a
| terrible idea, but the bridging works pretty much seamlessly,
| and Obj-C and C++ don't actually overlap all that much so they
| don't step on each other's toes. Each language has strengths
| that shore up the weak spots in the other.
| delta_p_delta_x wrote:
| +1 to Objective-C++. It makes for some surprisingly clean,
| compact code, best of both worlds, really. And the bridging
| between ARC and CF types is really quite magical, more
| languages should have that ability to be expressed in an
| older language without stripping everything out.
|
| I just wish there were Objective-C bindings for more CF
| classes without having to mess with C.
| billti wrote:
| 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
| frou_dh wrote:
| Obj-C++ was used for some hall-of-fame OS X apps, e.g. TextMate
| waynecochran wrote:
| 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).
| kridsdale3 wrote:
| 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.
| 9rx wrote:
| _> [[those squareBrackets] lookInsane:YES]._
|
| Nah, they are perfectly sane. They look like little ASCII
| envelopes because that's exactly the metaphor. Square brackets
| send messages.
| nmeofthestate wrote:
| They're function calls right? I can't square the "message
| passing" conceit (implying putting message objects on queues,
| dequeuing etc) with the claim that Obj-C is just C with some
| extra stuff.
| pavlov wrote:
| They're not direct function calls, but sugar for
| objc_msgSend():
|
| https://developer.apple.com/documentation/ObjectiveC/objc_ms.
| ..
| 9rx wrote:
| Absolutely not. It only sends a message. The receiver doesn't
| have to have a corresponding method and can do with that
| message what it will. Objective-C is a 'true' object-oriented
| language, like Smalltalk.
| chuckadams wrote:
| > a 'true' OOP language, like Smalltalk.
|
| I guess Simula, which is older than Smalltalk, doesn't get
| a say.
| 9rx wrote:
| What would it have to say about it? When "object-
| oriented" was first told, it was said that what defines
| it is message passing. Simula does not have message
| passing. It uses function calling. Simula does have
| objects, but having objects does not imply orientation.
| flohofwoe wrote:
| 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'.
| 9rx wrote:
| _> 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.
| flohofwoe wrote:
| > 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)
| :)
| 9rx wrote:
| 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?
| kccqzy wrote:
| 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.
| MaxBarraclough wrote:
| > 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.
| 9rx wrote:
| 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?
| Apocryphon wrote:
| Then what does it mean if "composition over inheritance"
| is also taught as a good practice in OO?
| MaxBarraclough wrote:
| That's a rule-of-thumb to help beginners in making
| judgement calls. It doesn't mean inheritance should never
| be used.
| Apocryphon wrote:
| True, but if the defining feature of something is a
| feature you should use sparingly, doesn't that mean other
| features are more definitive?
| seanalltogether wrote:
| At this point in my career, I can't go back to a language that
| doesn't have support for Optionals or compiler validation of
| nullable types. I can sacrifice async or fancy stream apis, but I
| will never go back to chasing null pointer exceptions on a daily
| basis.
| iainmerrick wrote:
| Obj-C does have a "nonnull" annotation now (apparently added to
| assist Swift interop). One of the final jigsaw pieces turning
| it into a really pleasant language.
| catoc wrote:
| 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
| plorkyeran wrote:
| 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).
| tarentel wrote:
| 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.
| Me1000 wrote:
| You can send messages to null, sendings messages to a
| deallocated pointer is going to be a bad time.
| e28eta wrote:
| 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
| coliveira wrote:
| If you use Objective-C objects, operations on null pointers are
| just a no-op, so there is not such thing as chasing exceptions.
| mpweiher wrote:
| Objective-C did not have null pointer exceptions, though some
| libraries added them.
| netbioserror wrote:
| I bounced off of Objective-C not because of its message-passing
| OO. That was the actual cool part. I bounced off because of the
| insane amount of boilerplate prototyping and headers required to
| use it.
|
| I think every OO language should be using Smalltalk's message-
| passing style rather than holding hard references, and
| Objective-C is a great model. But discard the rest.
| socialdemocrat wrote:
| 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.
| Naman-Dixit wrote:
| > 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...
| LoganDark wrote:
| I recently started writing for macOS in Swift and, holy hell, the
| debuggability of the windowing toolkits is actually unparalleled.
| I've never seen something that is this introspectable at runtime,
| easy to decompile and analyze, intercept and modify, etc.
| Everything is so modular, with subclassing and delegation
| patterns everywhere. It seems all because of the Objective-C
| runtime, as without it you'd end up needing something similar
| anyway.
|
| You can reach into built-in components and precisely modify just
| what you want while keeping everything else platform-native and
| without having to reimplement everything. I've never seen
| anything like this before, anywhere. Maybe OLE on Windows wanted
| to be this (I've seen similar capabilities in REALLY OLD software
| written around OLE!) but the entirety of Windows' interface and
| shell and user experience was never unified on OLE so its use was
| always limited to something akin to a plugin layer. (In WordPad,
| for example)
|
| The only thing that even seems reminiscent is _maybe_ Android
| Studio, and _maybe_ some "cross-platform" toolkits that are
| comparatively incredibly immature in other areas. But Android
| Studio is so largely intolerable that I was never able to dig
| very far into its debugging capabilities.
|
| I feel like I must be in some sort of honeymoon phase but I 100%
| completely understand now why many Mac-native apps are Mac-
| native. I tried to write a WinUI3 app a year or two ago and it
| was a terrible experience. I tried to get into Android app
| development some years ago and it was a terrible experience.
| Writing GUIs for the Linux desktop is also a terrible experience.
| But macOS? I feel like I want to sleep with it, and I weep for
| what they've done with liquid glass. I want the perfection that
| led to Cocoa and all its abstractions. Reading all the really,
| super old documentation that explains entire subsystems in
| amazingly technical depth makes me want to SCREAM at how
| undocumented, unpolished and buggy some of the newer features
| have gotten.
|
| I've never seen documentation anything like that before, except
| for Linux, on Raymond Chen's blog, and some reverse-engineering
| writeups. I do love Linux but its userspace ecosystem just is not
| for me.
|
| Maybe this is also why Smalltalk fiends are such fans. I should
| really get into that sometime. Maybe Lisp too.
| kmeisthax wrote:
| > 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.
| LoganDark wrote:
| > 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.
| Klonoar wrote:
| 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.
| anthk wrote:
| 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).
| tpmoney wrote:
| 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.
| sgt wrote:
| That's it, I'm pivoting my startup technically and rewriting
| everything in ObjC! /s
| Towaway69 wrote:
| I wonder how well AI generates Obj-C - it might well produce
| better quality code for your token/buck!
|
| In a previous life, one would select the programming language
| according how expensive developers were. Nowadays it's the
| quality that an AI can generate. What a wonderful future we've
| put together. /s
| GaryBluto wrote:
| I've been using Opus 4.6 to make myself a harness for old
| Macs that uses models offered by the Github Copilot
| subscription.
|
| From my experience, when it creates working Objective-C, it's
| great. When it slips up, it slips up majorly.
| mghackerlady wrote:
| I've always liked Objective-C. Despite me not really liking
| object-oriented programming, I appreciate that its one of a
| handful of languages to do actual smalltalk-esque oop
| danielvaughn wrote:
| I really enjoyed Obj-C when I did some iOS work back in
| 2015/2016. It was my first non-JS language, and it taught me so
| much that I didn't understand since I started out doing web dev.
| zarzavat wrote:
| Smalltalk is like pizza. Even when it's bad, it's still pretty
| good.
| flohofwoe wrote:
| IMHO the one great feature of Objective-C (compared to C++) is
| that it doesn't interfere with any C language features. In C++
| the C 'subset' is stuck in the mid-1990s, while Objective-C "just
| works" with any recent C standard.
| safercplusplus wrote:
| 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...
| j16sdiz wrote:
| I think C++ have caught up with C99 already. So it's late 90s,
| not mid-90s :)
| nly wrote:
| What C features can you not realistically use from C++?
| anthk wrote:
| People shoudld realize that since _long_ ago C and C++ are
| not sub /supersets, but interesecting sets.
| 201984 wrote:
| 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.
| plorkyeran wrote:
| 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.
| mikehall314 wrote:
| 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
| ihumanable wrote:
| Same. I remember when this first came up and I was like "this
| is so weirdly interesting."
|
| Sad that they got acquired because it was just fascinating what
| they were doing, even if I was never going to use it.
| zffr wrote:
| Holy shit, it's still being actively developed and maintained
| https://github.com/cappuccino/cappuccino
| Towaway69 wrote:
| More amazingly the guy doing the most recent maintaining[1]
| is a medical Professor at Freiburg Uni.
|
| [1]: https://github.com/daboe01
| vintagedave wrote:
| And wow, it's basically a web version of Cocoa! Check this
| out: https://ansb.uniklinik-freiburg.de/ThemeKitchenSinkA3/
| sgt wrote:
| Weren't they acquired by Motorola?
| mikehall314 wrote:
| 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!
| tumultco wrote:
| 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.
| samesimilar wrote:
| 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.
| mikestew wrote:
| 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.
| mikehall314 wrote:
| 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.
| 0x457 wrote:
| 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.
| millerm wrote:
| Wow, I haven't written any Objective-C since around 2012. I just
| went back and looked at some code I had written back then and
| that really brought back some memories. I was much happier then.
| I'm perpetually sad and unemployed now.
|
| That's all. Enjoy yourselves.
| gwbas1c wrote:
| One of the things I miss about Objective C is just how easy it is
| to call into a C API, or otherwise include a C function if that's
| the easiest way to call into a C API.
|
| I shipped a cross-platform C# project, and once I realized I
| could expose "ordinary C" from the Objective C part, it was very
| easy to integrate the two without using a framework. (It helped
| that the UI was 100% Objective C, so there wasn't much surface
| area between the C# and Objective C parts. We initially used
| MonobjC, but first I had to work around a shortcoming, and then
| we needed to remove MonobjC due to licensing and some of the
| newer C# integration layers were not available.)
| rixtox wrote:
| The most difficult part of Objective-C is its ARC rules, and
| mixing ARC and non-ARC code in the same project.
| zerr wrote:
| Any popular cross-platform GUI toolkits? How do you find GNUstep?
| JSR_FDED wrote:
| [objC retain]
| DerekL wrote:
| Hopefully, you're using ARC by now, so that's a no-op!
| kccqzy wrote:
| I do not get this argument at all. A long time ago I ported a
| simple sudoku solver to Objective-C by using the foundation
| classes, like NSMutableArray. It was terribly slow. All those
| messaging sending just to do what should have been a single
| instruction (or less!) That's when I realized that if you want
| speed in an Objective-C app, you really are going to reach for
| the C subset. The objective part is really good for building
| GUIs, but not for pure computation.
| kridsdale3 wrote:
| When I was writing apps at Apple for the low-integer-version-
| numbered iOSes, this is what we typically did (since we had a
| single-core CPU in the MHz and <1GB).
|
| UI shell in UIKit Obj-C, over a C++ or CoreFoundation (C)
| business layer, talking directly to sqlite.
|
| I haven't seen the source of Apple apps and frameworks in over
| 10 years now, but I hope for their sake a lot of it has moved
| to Swift by now.
|
| If I were CFed I'd mandate 2026 as the Year of Claude Code
| Radar Burndown. Their backlogs are insane and Apple actually
| addresses maybe 5% of what it knows to be wrong in a given
| year. Make it 2% when a UI Refresh is mandated.
| csb6 wrote:
| That is one advantage of C++ - you can use higher level
| features like generic data types/algorithms, member functions,
| constructors, destructors, and iterators and still have
| performant code. You can use object-orientation without having
| to heap allocate each object and pay the cost of "virtual"
| calls. (which many other object-oriented languages couple
| together)
| kccqzy wrote:
| Yes! The idea of zero cost abstractions became popular in the
| C++ world. It was never a thing for Objective-C.
| Klonoar wrote:
| 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.
| monster_truck wrote:
| Someone should vibe code Objective-C 3.0
___________________________________________________________________
(page generated 2026-03-02 23:01 UTC)