Whenever I create a new file in Xcode and choose Objective-C as the language, I laugh a little. Am I creating more technical debt or am I saving countless hours of time not dealing with the sharp edges of half-baked new tech? Zig when they zag.

@manton As a Mac developer since 1994.. I’d say that Swift has been out of the half-baked stage for a few years now.. and that even on the Mac 😎.

When I drop back into Obj-C these days, I’m struck by just how weird it is.. with all its semicolons, header files, etc.

I’ve still got 20 years of Obj-C code in my apps, but I’m much happier in Swift despite its over-enthusiastic correctness fetish.

It’s much easier to write clean code, which isn’t always quite the same as writing simple code.

@manton MFC FTW! 😄

@manton IMO, Swift is fully-baked if you avoid the very latest language gizmos, and I much prefer it to Obj-C.

SwiftUI either hasn’t gone in the oven yet, or they put it in before adding all the ingredients.

@manton

@bwebster @manton I like to think that either, but I think I’ve established myself as a foolish optimist.

@frankreiff I agree, Swift is mature and I like it. It’s more SwiftUI that I’m always hearing people run into problems with very basic things.

@jmwolf Yep, that sounds right. SwiftUI was such a different architecture, I’m honestly surprised it works as well as it does. Still avoiding it except where required.

@manton I avoided SwiftUI for a while, like I did for Swift for the first few years, but nowadays I prefer using SwiftUI. I have decades of legacy ObjC AppKit, but SwiftUI is the way of the future. But yes, when you hit a wall, it can be a big one. I can usually find a solution online, though.

@manton I’m a long-ish-in-the-tooth developer (pro since 1997), so I’m always curious about this kind of stance. How unproven was AppKit when you jumped in? Did it have analogous “rough edges” in the early days?

Honestly asking / curious.

@muncman It’s a good question. When I started with AppKit, it was already far along from the NeXT days, but it wasn’t as full-featured as it would become when integrate into the Mac. I mixed AppKit and Carbon for a while. Except for widgets, I don’t see much new with SwiftUI that is comparable.

@manton In any case, I think —as always— context wins for new-v-old stuff like this.

@manton Absolutely. Not really an option for macOS at all yet, but I also think it’s ultimately a blind alley even though Apple is fully invested in it. Declarative programming (just like visual prof.) always sounds like magic, until you realize that the internal workings of the engine is actually crucially important. Then the whole house of cards collapses and you add annotations, etc but it’s still a black box that makes debugging, scaling and performance tuning impossible.

@manton Worst of all is the fact that a minor change in your declarations can have huge performance impacts, so your code is now always fragile.

@frankreiff That is something I’ve wondered about… Declarative is so different. I’m not sure it’s actually better. I embrace it with React Native because the win is cross-platform mobile apps. Personally for me, iOS + macOS (and worse Mac apps) is a harder trade-off.

@manton CSS and SQL are the most universally used declarative languages.. and while they work, actually dealing with them is rarely as straightforward as “just express what you want”. For SQL there are literally jobs that consist of optimizing query performance despite the whole point of it being that “the engine can just figure out the details”. CSS is very powerful, but it’s also fiddly and fragile.