I like Swift. We’re using it for new products like Linea, which was written from the ground up with the new syntax. In spite of this, I still consider the language harmful.
The best way to understand the issues is by imagining that you’re an iOS developer who wants to write their first macOS app.
You find this sample code and it has exactly what you need:
PhotoEditor: Crafting Modern Cocoa Apps
The sample demonstrates several Cocoa technologies and features, including:
- Storyboards
- Unified window titlebar
- Full-sized content view with behind-toolbar blurring
- NSAppearance (“dark mode”)
- Sandboxing
- Resume (state restoration)
- Modernized event tracking
- Modernized drag & drop
- UI validation
The best part is that these bits are fresh — it was published in October 2016 for Xcode 8 running on macOS Sierra. Perfect!
Build and Not Run
Everything is great until try to build and run that project. Xcode displays 12 issues that you’ll need to deal with before you can try out the sample.
A bunch of the errors are due to private protection levels on instance variables. Unfortunately, there’s no automatic fix for this issue. But even though you’re no expert in Swift, you find that changing the definitions to public seems to clear things up.
A harder problem is an error about a method not overriding its superclass:
override func observeValue(forKeyPath keyPath: String?, of object: AnyObject?, change: [NSKeyValueChangeKey : AnyObject]?, context: UnsafeMutablePointer?) { ... }
When you try to do the automatic fix for this issue, the code changes, but the error remains:
override func observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey : AnyObject]?, context: UnsafeMutableRawPointer) {
...
}
This is a problem you’ll have to solve with Google. After a few failed attempts, you finally land on a solution at Stack Overflow:
override func observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey : Any]?, context: UnsafeMutableRawPointer?) {
...
}
So what does fixing all this sample code tell us?
Learning with Swift is Hard
I can hear many of you saying, “just fix the auto migration tool!” But that’s not the issue here.
Swift is an easy language to learn and has some wonderfully innovative tools to help beginners. But as soon as you’re beyond the basics, the constant Swift syntax changes become an impediment to learning.
For public versus private issue above, I’m left wondering if this distinction is important in the design of macOS apps. Did I break something? And why do some of the instance variables work OK as private?
The problem with Key-Value Observation is an even bigger concern. As an iOS developer, it’s likely that you’ve not been exposed to this essential part of macOS app design. You’re forced to fix an issue where you have absolutely no experience. You don’t know what you don’t know.
And the part that’s broken is watching changes to contentLayoutRect: the mechanism that deals with everything from positioning vibrant content to supporting full-screen windows. It’s at the core of the window system modernization that started in Yosemite. For many developers, this is the reason they downloaded the sample code in the first place.
Take a look at the Stack Overflow page again. There’s some good information there, but it’s completely hidden by Swift code that’s no longer relevant.
Code Migration is a Crutch
It’s gotten to the point where every time I come across some information written in Swift, especially on Stack Overflow, I cringe. I know that I’m going to have to not only figure out the code, but also which version was used for the answer.
For many of us, sample code is the best documentation possible. It not only shows you an API, but also how it works in context. This sample code appears on a lot of places besides the web: it’s in WWDC videos, PDFs of presentations, books, and downloadable projects like the one used above.
And none of this code can be fixed easily with a migration tool.
It’s up to the author of the original information to make a revision when the next version of Swift rolls out and breaks things again. Some Stack Overflow answers will get this treatment, but most will not. Do you think Apple is going to edit the videos with non-functioning Swift code?
In my last book, all the sample code was done in Objective-C. I wanted to make the projects in Swift, but after seeing the language change significantly three times, I realized that any such examples would be outdated in a matter of months.
And that’s a shame.
It’s OK to Screw Up
Brian Kernighan has a bit of experience with programming languages. This comment from a recent talk on successful language design sums up the situation nicely:
If you design a language and other people use it, you very quickly learn that you screwed up. … this tension between changing something because you got it wrong, or because you have a better idea, versus trying to keep it stable, so that people who learn something don’t have to keep up with your language.
…
Swift keeps changing, and people have code that works, and “oops” it doesn’t work anymore with the next version. And that’s a problem. And how do you stop that?
I think the answer to this question is to realize that everything in our business has shortcomings. Perfect is the enemy of good.
With the recent announcement for Swift 4, it feels like folks are still searching for perfect, when what many of us want is just a great and stable language.
To that end, I invite you to duplicate this Radar.