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.
