Hacker News new | ask | show | jobs
by mdhughes 3145 days ago
Objective-C code from 30 years ago still compiles and works; many of the NS* APIs still used were stable by then. The tech whims of Kids Today™ don't tell you anything about long-term survival, because they haven't been alive as long as some of those codebases.

In 5 years, everyone doing Swift is either going to be rewriting their app for the 5th time, or switching to something less like quicksand.

3 comments

>Objective-C code from 30 years ago still compiles and works; many of the NS* APIs still used were stable by then.

With the caveat of a huge pile of AppKit warnings and deprecations that will need to be fixed, and probably a number of Obj-C warnings stemming from llvm/clang being smarter than the gcc of 30 years ago.

This was my experience reviving an OS X 10.1-era project. It compiled and worked, but its warning+deprecation count was ridiculously high for the project size that the effort involved in fixing it all was scarcely (if at all) better than migrating to a major new version of Swift, and honestly it probably would've been better for a lot of those warnings to have been errors given how long the involved APIs had been deprecated.

I've also migrated a moderately complex app from Swift 3.2 to Swift 4. The transition was painless and amounted to little more than a couple dozen lines changed across the project. Most of it didn't change at all. There's no way that Swift users are going to be rewriting their apps once per year, especially if the UI and logic in these projects are reasonably well separated.

Objective C apps will still be plagued by wild pointer issues and crashes 5 years from now, Swift apps won’t.
Since they aren't now, they won't be in 5 years either.

Swift apps won't be maintainable because it makes writing clever code so easy, so nobody will understand them.

It's like, the opposite of what you wrote. Swift apps are much higher quality than Objective C apps today. I know because I write large commercial apps for a living and wrote in Objective C and object oriented C for 20 years.

There are too many ways to blow up your app from C. A disciplined developer who uses safe libraries/classes to shield themselves from dealing with naked pointers can succeed at making an Objective C app reasonably stable, but it's really hard.

Swift was designed to protect you from wild pointers. All you have to do is NEVER FORCE UNWRAP and 90% of the typical crashers can't happen. Our current app is 90,000 lines of Swift. It's been relatively easy to maintain and update with Swift versions, and it almost never crashes. Our crash rate is in the top 10% of Social Media apps.

You don't have to write clever code in Swift. Just use the strong typing and optionals, the language is succinct and powerful and you can be very productive (outside of compile times). Swift is the professional tool for building iOS apps, Objective C is fading away.

stability is also helped by stagnant functionnalities. Swift is only 4 yo and aims at "total domination" aka both server client and system dev. it's perfectly fine for it to keep evolving, as long as it hasn't stepped a solid foot in each domain it's aiming at.

objc otoh isn't good and will never be good for anything other than appleOS development. i don't think betting on that tech today makes any sense. it lived a revival thanks to iOS , and it'll probably die when that platform has completed moving to swift.

OS X, iOS, and all new APIs consumed by Swift on those platforms are written in Obj-C or C++, never in Swift. So what's "stagnant"?

It's true that few others have adopted Objective-C, GNU & MS occasional efforts aside. Which is why I keep a number of languages in practice.

But fragile, power-hungry, slow-compiling Swift isn't going to beat out stable Java, or easy JS or PHP on servers, and outside iOS/OS X, building desktop software needs UI toolkit support and stability.

Which is my point: Building in Swift is total technical debt.

i guess it all comes down to whether you believe swift is going to get better with time and solve its current issues ( the ones you mention),or if it's inherently a bad design. I'm betting on compilation speed and fragility improving a lot in the next two years. What matters to me is that the language type system is among the best ( enums and optionals) , and the general feeling when coding with the language is a real joy.

For objc, however I've never been able to say anything better than "i got used to it".

> Which is my point: Building in Swift is total technical debt.

That's the truth. Swift makes it easy to build clever, unmaintainable code.

The beauty of Objective-C is it is readable! And then easily maintainable.