When to Adopt Swift
Add up all of the time you’ve spent learning Swift from scratch, accommodating its strictness, fighting its buggy tools, migrating your code through language changes, and re-learning APIs and conventions as they’ve changed over the last 5 years.
I’ve spent zero time doing that.
I’ll jump in when it’s so old, boring, and slow-moving that nobody bothers to tell people to move to Swift because they’re all busy geeking out and fussing over a newer language.
[…]
I know the basics. I’ve written a few thousand lines of Swift, including an entire simple app. I just choose not to write it the vast majority of the time.
I think migration is no longer much of an issue. The tooling is still buggy but getting much better. However, there is absolutely a time cost, and you have to think about what you’re trying to do. Is it worth switching if you’re going to write Objective-C-style code in Swift? One could argue that’s the worst of both worlds. Learning to really take advantage of Swift is rewarding but takes time. And you’re limited in how Swifty you can be if you have an existing Objective-C codebase. For a new app or a major rewrite, I think most developers should bite the bullet. In other situations, it’s less clear. We don’t know yet whether Apple is going to redesign its APIs for Swift, although Mojave’s Network framework is an interesting example of functionality that’s available in both languages but second-class in Objective-C.
Another thing I’ve noticed: type safety slows down the prototyping stage where you just want it to work, not be perfect. Quick and dirty leads to great experiences.
(I’ve switched back to Obj-C, too.)
I think it really depends on the type of code. In some cases, particularly at the model and with algorithms, I feel like I’m going much faster with Swift. There’s less boilerplate, the standard library offers a lot that Foundation doesn’t, and the strong typing helps with both thinking and refactoring. But other times, particularly when interacting a lot with Cocoa, it can feel like it gets in the way. There are impedance mismatches and blind alleys. Some of this can be smoothed over with more code.
💯. I think the most underrated productivity metric in programming is the time it takes to make one iteration. I work hard to keep this cycle time short and cheap. More iterations produces better results.
I had high hopes that playgrounds would speed up iteration. That’s been a bust: either inexplicable errors or slower than just compiling some test code.
Unfortunately, this has been my experience as well.
Learning Swift didn’t teach me anything new about how to think about my programs. It didn’t expand my mind. What’s more, its type safety hinders some of the ad-hoc flexibility that helps when writing the kinds of UI programs I typically write.
Over other languages, Swift doesn’t help me with what’s actually hard about writing code: thinking through exactly what I want to happen. Once I know that, writing the code is mostly a matter of idioms, conventions, tooling, and richness and availability of good libraries.
I didn’t find Swift mind expanding in a theoretical sense, as it mostly brings together ideas that had already appeared in other languages. But it absolutely is in a practical sense because it makes these tools available for real-world code, written in a platform-blessed language. It also refines them in ways that make them more approachable.
It feels like a cult. Swifters can’t leave well enough alone. They’re morally repulsed if you’re not using Swift, and they have to knock on your door and convert you to the faith.
Marco’s reasons are perfectly valid for him, but they really only apply to indie developers or people who get to make the call about the language used for projects, being a Swift refusenik is career suicide otherwise.
Still confused by the amount of fuss over Marco’s tweet about Swift. No one is cancelling Swift just because Marco isn’t using it. Him holding off on adopting Swift doesn’t threaten anyone else. He’s just doing what he thinks is most responsible for his product.
[…]
Also:
“Swift is super easy to learn way easier than Obj-C so easy kids are learning it on their iPads”
“But if you don’t learn it now you’re going to be forever behind and never useful as a developer again”
It’s relatively easy to learn the basics, but it takes a long time to master. In a sense, everyone is always behind those who started learning any language before them. But learning is not linear, and also there are any number of other things to learn besides a particular language. No one is ahead at everything. The question is what it’s most important for you to learn now.
Swift:
(lldb) expr -l Swift -- import PowerPhotos (lldb) expr -l Swift -- let $view = unsafeBitCast(0x600003b132c0, PowerPhotos.IPPhotoSelectionView.self) (lldb) expr -l Swift -- print($view.description)ObjC:
(Lldb) po [0x600003b132c0 description]
Add this to your ~/.lldbinit:
command regex objc 's/^(.+)$/expr -O -l objc++ -- %1/'Now you can do:
(lldb) objc [0x600003b132c0 description]
Another option is overloading po to provide custom behavior for memory addresses:
command regex po s/(0x[[:xdigit:]]+)$/expr -lobjc -O -- %1/ s/(.+)/expr -O -- %1/This makes
po’ing 0x76543210 treat it as objc. Any other expression gets defaultpobehavior.
Previously: On My Misalignment With Apple’s Love Affair With Swift.
Update (2019-02-27): Vadim Shpakovski:
Open-source libraries written in Obj-C are slowly dying. They’re not maintained or authors rewrite them in Swift. This trend is probably unstoppable. And if your code uses third-party components, you literally have no choice.
11 Comments RSS · Twitter
“Swift is super easy to learn way easier than Obj-C so easy kids are learning it on their iPads"
“But if you don’t learn it now you’re going to be forever behind and never useful as a developer again”
Aren't these supposed to be 2 ironic tweets?
Swift is closing to 5 years old. And it has been an uneasy ride. Sometimes I keep thinking what if all those energy and time were invested in Objective-C, despite being 5 years old and few years in production for many, its advantage still isn't quite clear.
These are one of those things we thought were great in idea, in practice it isn't.
@Will Yes. My point is that a lot of people were tweeting stuff like that (seriously), and it’s easy to mock because it sounds like a contradiction, but there is actually some truth there.
"What’s more, its type safety hinders some of the ad-hoc flexibility that helps when writing the kinds of UI programs I typically write."
This common refrain sounds a lot like JavaScript devs resisting Typescript BEFORE they'd used Typescript for a while.
It also sounds like an excuse for hipster programming. $0.02
I remain happy to have avoided Swift. From the start I hated the language (mostly the syntax but that's what I write it). I'm sure it probably offers some benefits, but to me those benefits do not outweigh the cost. To me its the best and most beautiful coding language ever designed.
Its nice to see I'm not the only one. I'm fine being a minority sticking to Objective-C. But I will admit to being quite annoyed at all the people who switched to Swift so quickly and would not stop talking about it.
I switched some years ago from doing most of my work in less safe languages to working entirely in very strongly typed languages. Once you're used to it, everything is faster, because entire classes of bugs simply no longer exist and you don't have to spend mental energy thinking about them. Indeed, for the first time in my life, I routinely write substantial pieces of code and, as soon as they compile, they work correctly.
I recognize the complaints that type safety slows down prototyping. It sounds very much like the complaints we used to hear about how gotos were really an essential tool in getting code written fast, or about how writing tests along with your code would only slow you down (and that they were mostly unnecessary), and a dozen other claims I've seen over the last four decades. Such claims are ubiquitous, and they're wrong.
Take a little time, absorb the better way of doing things, and it's amazing how much more productive you can be when you do things well.
@Perry Are you referring to Objective-C/Cocoa or some other environment? My experience is that Cocoa development with Objective-C hit an unusual sweet spot where there was enough checking that, for an experienced programmer, code would usually work as soon as it would compile, yet the typing didn’t get in the way very much. Your comments about prototyping sound like they could be true on a different platform, but I would be surprised if anyone finds that to be the case with Cocoa development. The frameworks were not designed for Swift, so as soon as you start doing UI stuff you run into casting and optionals. Even something as simple as debug printing a property of a view will give you a compiler warning.
As someone who would like to get into mac/iOS development, which would you recommend learning?
I have a background in mostly C style languages, but have never used Obj-C or Swift for anything.
@Zach I would start with Swift, but you will probably need to learn some Objective-C at some point, too.
@Ruffin
> It also sounds like an excuse for hipster programming.
Just to be clear here, you're responding to someone with 25+ years of experience, who was a principal engineer on UIKit and watchOS.
He's also got a couple of excellent WWDC videos that should demonstrate he's definitely not a hipster.
Deja vu here! I remember these discussions, the general framework anyway, when Cocoa was overtaking Carbon. The Cocoa people were right, eventually everyone had to switch because Apple wasn't going to support Carbon forever. Is this the case with Swift vs Objective C? Five years down the line, what's the platform going to look like? Ten?
