Interview: Erica Sadun
We chat about Swift Evolution, the community, and Clarus the dogcow
No matter which of Apple’s platforms you’ve developed for, you’ve almost certainly come across the name Erica Sadun before. If you haven’t, it’s my pleasure to introduce you to her: she’s authored or coauthored more Swift Evolution proposals than anyone else, she’s written more books than I can count on building great apps using Swift and Objective-C, and she’s also a leading blogger in our community.
Erica was kind enough to take a break from her busy schedule to chat with me about her books, her work in the Swift Evolution community, and, er, dogcows.
Hacking with Swift: Perhaps excluding a few Apple folks, you’re probably the most well-known member of the Swift community. You’re also one of the (comparatively) few folks who were interested in Apple development before the SDK shipped. For the handful of folks in remote parts of the world that haven’t heard of you before, where did your Apple coding interests start?
Erica Sadun: What a kind introduction! Yes, I've done lots of development in the Apple world and had the pleasure of developing for the iPhone before an official SDK released. It was an especially exciting time in my life. I'm getting to relive that excitement a little due to the introduction of Swift.
While the Swift Programming Language is synonymous with Chris Lattner, who is surely the most well-known member of this community, I'm very pleased with the books I've written about Swift. My "Swift Style" book surveys standards used throughout our community and helps you work on establishing a "house style" of your own. "Swift Documentation Markup" book dives into code-level documentation and shows you how to structure and annotate to match your code to Apple's standards.
If you count NeXT development, I've been doing Mac in some form or another since oh say the 80's.
As for Apple Interests, I've been working on Mac development since approximately the time that dinosaurs roamed the earth. I started back in the old days with Pascal and Prototyper, then on towards Code Warrior, long before MacOS became a reality. If you count NeXT development, I've been doing Mac in some form or another since oh say the 80's. I know what ResEdit is and why Clarus moofs. Hopefully some of your readers will get those references.
HWS: I think it might just be you, Daniel Steinberg, and Chris Espinosa!
ES: Interestingly enough, Chris Lattner made a decree at some point that any Swift Language modification proposal that broke dogcows would not be accepted into the language.
HWS: Obviously Apple’s development tools have come on a long way since the eighties, although things like Interface Builder still manage to stick around. Do you think such a long legacy of software has helped Apple create a strong foundation (no pun intended!) for its developers, or are there some places where we’ll still fighting with choices made 10 or even 20 years ago?
ES: I think that it is, of course, a balance of the two. Take Xcode for example. It is an amazingly powerful design environment and amazingly frustrating flaws. The software legacy both supports you and traps you.
Getting up to speed and getting work done is often far easier with Xcode because of its age, its experience, and its extent. I don't think you can point to anything in Xcode (or Swift) that is completely novel and innovative but it's easy to find features that you love and that you'd hate to lose.
Swift is designed to break out of the mindset of 1980s programming when Brad Cox developed Objective C. It lets Apple enter the modern programming language space, both adopting the best features of many programming languages and introducing a new and opinionated layer that sits on top of those features.
An IDE has to be good enough to create amazing and wonderful software. It cannot be good enough that too many resources go into the dev tools and the company loses sight of its core mission.
No IDE is ever going to be a perfect solution because they tend to be built as dogfooding platforms, which is to say, they first serve the company that makes it in terms of building its own tools, then serves developer outreach. Developer tools do not in and of themselves make money. It's the secondary market that brings in cash, specifically what developers build with those tools.
An IDE has to be good enough to create amazing and wonderful software. It cannot be good enough that too many resources go into the dev tools and the company loses sight of its core mission.
So you're stuck with a quandary: how good is good enough. I think most people will agree that Xcode is "good enough" but that it has deep systemic flaws that are fundamental to its suite.
HWS: I’ve written a heck of a lot of Objective-C in my time, but you’ve probably written an order of magnitude more. And you wrote a lot about it – some of the code snippets from your iOS Cookbooks must have appeared in tens of thousands of apps. Now that we’ve had Swift for a few years, is there anything about Objective-C that you look back on and miss?
Objective-C is a happy farmer with a large and pleasant family, surrounded by a few dogs and cows. It compiles quickly. It runs nicely. It is open, friendly, and agreeable.
ES: There is a sweetness to Objective-C. It is a pleasingly structured language. It does not aim for terseness or clever applications of specialty programming, such as you find with Swift's protocols and generics and functional application.
Objective-C is a happy farmer with a large and pleasant family, surrounded by a few dogs and cows. It compiles quickly. It runs nicely. It is open, friendly, and agreeable. Most developers will not regret the square brackets they had tattooed into their arms or other body mods centered around Objective-C.
Objective-C is stable, it's reliable, it's business-ready, and it's had years to mellow and age well. Yes, going back to it makes me miss many language features that would otherwise be immediately available in Swift, but it's an excellent and happy language to work in.
In Swift, we're still engaging in some of the same Objective-C dances. We still have to worry about retain cycles and the weak-strong waltz, even with ARC and better typing. Swift is not a complete break with its past. Also, the interface between the two languages remains turbulent. It may never be completely easy to sail the waters between Swift-sourced and Objective-C-sourced code.
Don't forget that Objective-C hasn't "stopped". It continues to grow and evolve. Yes, admittedly, a lot of Objective-C improvements are aimed at better annotation for Swift integration but the language continues to live and develop.
HWS: I think it’s interesting that there has been such a mixed response to newer features like lightweight generics and nullability – some folks see these things as Swift polluting their language and refuse to use them, whereas others embrace them. From what I understand, even ARC came about because of Swift.
Generics and nullability are specifically part of that "pouring oil upon the waters" effort. There is and will be for some time to come a big investment in Objective-C libraries via Cocoa and Cocoa Touch. Swift cannot just go off on its own. Just as we're seeing Swift reach out to Linux, Windows, Raspberry Pi, BSD, and more, you must recognize that this is primarily a "house language" for Apple and it must serve Cocoa and Cocoa Touch first.
I can't really speak to the automatic reference counting decision as I don't have sufficient insight into how that evolved and was adopted. I think on the whole it was a great thing and a great step forward. In Swift, all the C-based Core Foundation object-based CFType/CFTypeRef classes have taken on an entire new presence. They are automatically renamed (no more "Ref") and memory managed (no more CFRelease) for you. And yes, you can still do direct memory allocation for C-style work, but if you're using Core Foundation objects, Swift is there and ready.
I have had more Swift Language proposals outright rejected than any other person in the Swift Evolution community.
HWS: Then let’s talk about Swift. You have – by a huge margin – authored or co-authored more Swift Evolution proposals than anyone else, including anyone from Apple, and I don’t think it would be too much to say that you have been a fundamental part of shaping how we write Swift code today. It started early, too: Erica “Slayer of C loops” Sadun, right?
ES: I generally phrase it like this: I have had more Swift Language proposals outright rejected than any other person in the Swift Evolution community.
I'm quite proud of that and I still wish some of them had been accepted, such as the dangling comma one. That one allowed you to comment out parameters and use defaults. You didn't have to edit the final comma, so the git diffs remained clean. Swift uses complex declarations and I think that dangling commas would have made a significant and positive impact.
With other proposals, I am happy that the subject was aired and voted on and put away. Sometimes you have to champion an idea that won't die so it will be properly debated and gently laid to rest.
I'd say that many of my proposals are utility ones, that simply formalized where the language was already going. The C-Loop one was one of those.
HWS: I know many people find Swift Evolution intimidating, but with so many rejections clearly you don’t – or at least don’t appear to.
ES: I found Swift Evolution incredibly intimidating and that has been valuable for me. Just like when you write books, where you must open yourself to criticism to make yourself a better writer, putting your design ideas out for critique and improvement strengthens you as an engineer.
If you believe in an enhancement, you have to be willing to stand up for and argue for it. You must provide a detailed and logical reason why this idea should be adopted and honestly evaluate its associated drawbacks.
Swift must wear its scars and warts and poor decisions and soldier forth the best it can.
There is a proposal I have going into review very soon. And one of the points I make there is that the language has gone past the point where things can be removed just because they're not used very much. With ABI stability on the horizon, the only sufficient cause for removal is "active harm".
Absent that, Swift must wear its scars and warts and poor decisions and soldier forth the best it can. It is no longer acceptable for Swift to break code just because it makes the language more beautiful or endearing. Swift has to get to work and ship apps. Anything that stands in the way of that objective is no longer acceptable.
HWS: I think many folks have concerns that being “willing to stand up and argue” with people is itself a deterrent. Chris Eidhof’s toggle() proposal, for example, was particularly fractious, and could easily have caused problems for someone with less experience or confidence than Chris.
ES: I voted against it. I felt it was of minimal utility and easily duplicated by anyone who used it. I am glad it was accepted, though. I think on the whole it's a lovely tweak. The core team's feedback was clear: they wanted more lovely tweaks in the language, things that make programming flow better and reduce turbulence.
HWS: But as for the tone of discussion around Swift Evolution topics – you think the current situation is about right?
Review is the one time where you can have the greatest impact on the language for the least investment of time.
ES: I do. Even so, I wish the reach of Swift Evolution was larger and more voices participated in review. I worry that Swift Evolution can sometimes feel like an echo chamber with too many of the same voices and same ideas. Review is the one time where you can have the greatest impact on the language for the least investment of time.
Many developers outside of Swift Evolution have expressed they feel they have no voice and great frustration. The problem there is then to figure out how to realistically provide outreach in a way that solicits their needs and cares in a measurable way that doesn’t place undue requirements on the language developers and the core team.
Right now, participating in reviews is the only solution for that. You can express why you are voting for or against a proposal and provide concrete use-cases to support your argument, especially in terms of your day to day development work
You can say: "Here is how this change will affect me: personally, as a company, and as a member of the community as a whole." Do that and you will be heard. Do that and your voice will count.
There is overhead but I don’t think the overhead is extreme. More and wider participation can counter the feeling that it is burdensome to participate in Swift Evolution, that Swift Evolution is elitist, and that a developer’s primary concern and responsibility is their paid work.
HWS: Do you have any simple suggestions for folks who are thinking of joining in – is it perhaps a matter of just picking and choosing the proposals that interest you most? I don’t even know how most folks are made aware of proposals for discussion.
Just filing a bug report is joining in, whether it is for a feature you want in the language or a performance issue or whatever.
ES: I know many developers, for example, who refuse to file bug reports into Apple's "radar" system. Swift is open source and so is its bug reporting system at https://bugs.swift.org. You can see a bug's progress, comment on it, discuss it with the language maintainers. Just filing a bug report is joining in, whether it is for a feature you want in the language or a performance issue or whatever.
As for following the proposals, there is a public list of items currently in review that is updated every time a new review period starts: https://apple.github.io/swift-evolution. Yes, just pick and choose the proposals that interest you the most. You can also join the forums at https://forums.swift.org, and just subscribe to the announcement list and have it email you. It's low volume and lets you know about review periods, acceptances, rejections, and returns for revisions.
HWS: Looking at the list of changes for 4.1 and 4.2 – “minor releases”, technically – Swift’s evolution doesn’t appear to be slowing down. What are the major areas where you think the language is still lacking?
ES: You can find the change log here: https://github.com/apple/swift/blob/master/CHANGELOG.md. And I know that the Swift Evolution community is trying to get as much work done before declaring ABI stability. So yes, there's quite the rush going on.
From here out, what you'll see is more additions to other libraries like Foundation instead of the standard library. And there will be a lot of work under the hood to make the language more stable, faster to compile, and so forth.
New proposals cannot break code. And those changes must fix real problems, not theoretical ones.
Swift Evolution is entirely a user-facing process. Anything that affects the way that users interact with the language must go through the Swift Evolution process. Currently, any language changes must be highly focused with limited impact. Their benefits, if accepted, must be measurable and real.
New proposals cannot break code. Changes must fix real problems, not theoretical ones. So you can't add many 'good ideas' to the language. This is, of course, where I worried about toggle(). The problem it fixes is real (a mutating, functional way to toggle a boolean value in place) but I wasn't sure at first that its impact was sufficient.
Finally, changes to the language must directly improve safety, speed, and expression. The toggle proposal fell into the last of these.
HWS: There’s also the need for proposals to come with implementations, which has presumably limited who can contribute.
ES: It certainly changed the way Swift Evolution did business, and it was pretty much down to me why they did this. If you look up one of my old accepted proposals, SE-0068, you'll notice that it's not implemented: https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md.
The proposal extend Self to classes the way it works in Objective-C, where Self is the type and self is the current instance. As of right now, no one has been able to make that work. The rule that was introduced ensures that proposal are not just real problems, they are ones that are solvable. You need an implementation, which allows designs to be tweaked and road-tested,
I know a lot of people felt disenfranchised by that move, as their background is in Swift and Objective-C, not in C++ and Python.
HWS: It’s something you’ve personally blogged about – skilling up in C++ and Python in order to contribute.
ES: It is. And I am slowly learning both. I feel it is important to be able to contribute at a code level not just ideas and write-ups
HWS: I can imagine this adds a lot of extra worry for folks – not only can folks pick at your proposal, but they can now pick apart your C++!
ES: That is actually not a problem at all. The people on the swift-dev side of the house are amazingly supportive, especially of beginners. They even publish "starter bugs" for people who want to become more active in language development. It's also an extremely good way to get a job at Apple, should you follow that path.
HWS: It’s true; I had the pleasure of meeting Harlan Haskins and Robert Widmann recently – they have repeatedly offered to mentor people who want to get into Swift compiler development, and they don’t even work for Apple!
ES: I mean this seriously when I say the entire Swift-Dev community is filled with love, unicorns, happiness, and lollipops. Swift Evolution tends to be a little bit more thorny but also full of wonderful people. They're just crankier unicorns and pickier lollipops.
HWS: Putting Swift Evolution to one side, it’s clear that Swift adopts quite a different approach to Objective-C – there’s much more of a functional influence, plus protocol-oriented programming has taken a strong hold. What do you think truly idiomatic Swift looks like, if such a thing can even really exist this early in a language?
ES: I honestly think that Swift looks a lot like nearly every other modern language. They're all kind of converging right now. Feature by feature, you talk to people, and they'll point out correspondences in 2, 3, or even more languages. Swift benefits by trailing slightly and learning important lessons.
I honestly think that Swift looks a lot like nearly every other modern language.
Issues with protocol extensions may have already been hashed out in C#. Or you might have already seen raw strings in Python. Following on makes it easier to accommodate already road-tested ideas and enhance development.
I know that I personally want method cascades like you get in Dart. When you work in Cocoa / Cocoa Touch and need to set up an object after instantiation, method cascades bring that setup process together visually and logically. For example, consider what you do to create an NSTask or an NSPipe. A method cascade avoids those blocky setup columns of doom, making it clear that you're establishing a single object's properties outside of initializers.
HWS: Would you say you ever catch yourself writing Swift as if it were Objective-C, or are you “Swift native” at this point?
ES: It really depends on how recently I've been in that or another language. I tend to "leak" features. Most recently, it's going between Swift and C++ more than Swift and Objective-C. Semicolons, sigh. At least semicolons are legal (if somewhat unwanted) features in Swift. When I come from Python, rote indentation is a really horrible thing to inflict on innocent Swift code.
HWS: Working on so many Swift Evolution proposals, and now contributing to Swift directly, it’s amazing you still have time to post on your blog. You must have posted hundreds of articles there over the years, tackling a great many topics. Are your posts there offshoots of whatever you’re working on right now, or is it more a test bed for future ideas?
ES: My blog is almost always a place where I can dump ideas out of my head that I want to keep around for my own reference. Forcing myself to write them up ensures that I get the most from those lessons and can share them with others who would appreciate the content.
My blog is almost always a place where I can dump ideas out of my head that I want to keep around for my own reference.
It's a bit like doing homework – you learn once by experiencing, twice by repeating, and three times by the process of refinement and teaching.
HWS: Does that then start to give you ideas of directions for future books? Ultimately your books are what most folks know you for – you’ve written some of the landmark books about iOS.
ES: I am already knee deep in future books and I always have a list of projects and ideas that is far far longer than I could ever get to in a dozen lifetimes. I am blessed and cursed by more ideas than capacity.
HWS: That’s something I enjoy about working in the Apple community – every year things get shaken up with incredible new features or refinements. You can’t rest on your laurels, because Apple certainly aren’t.
ES: As you know yourself as a writer, it's also the biggest headache about being in the Apple ecosystem. You cannot write much that has a shelf life.
I basically burned out. I chose to write about Swift Style knowing that it the advice would be long lived. Even so, I'm refreshing the book for Swift 5 so the examples won't look "quaint" or outdated. I'm also working on updating my iOS Drawing book for Swift.
I'd like to give my Swift Documentation Markup and Playground Secrets a quick refresh as well. If I get the chance, I'll probably also bring Auto Layout into Swift as that information never really goes out of date, even if a few utility APIs have been introduced.
Unfortunately, my Swift Developer's Cookbook never got the update I was promised because Addison Wesley laid off nearly their entire developer library staff. I feel terrible about that because I had refused to sign up for a Swift title unless I had some way to keep the content current. Even so, people still write me and say they got a lot of great insight out of the book, despite it being completely outdated. It was written for Swift 2 and the Content Update Program was killed before Swift 3 debuted.
HWS: You’ve also self-published some great books on the iBooks store – Playground Secrets and Swift Documentation Markup, for example. Are these a new direction for you?
ES: Again, it’s finding a topic that I love and am passionate about and one that has a decent chance of still being helpful in a year or two. Both Playgrounds and Swift Documentation Markup are still relevant even though they're both a few years old now. I love being able to take a small topic and dive into it with more depth and organization than I could do in blog posts.
Thank goodness for niche topics!
HWS: You’ve already been more than generous with your time, but just to wrap up: WWDC is around the corner. This time last year we already a clear Swift 4.0 release plan announced on swift.org, but this year things are different. What are you expecting to see from Apple?
WWDC is always Christmas morning with lots of presents to unwrap… I can't wait to discover what we get this year.
ES: I never know but I am always excited to find out. WWDC is always Christmas morning with lots of presents to unwrap. Some of the best never even make it to the keynote. There are all these tiny wonderful things that make your life better that show up in technical sessions. Just a couple of years ago we got the new image APIs. I can't wait to discover what we get this year.
BUILD THE ULTIMATE PORTFOLIO APP Most Swift tutorials help you solve one specific problem, but in my Ultimate Portfolio App series I show you how to get all the best practices into a single app: architecture, testing, performance, accessibility, localization, project organization, and so much more, all while building a SwiftUI app that works on iOS, macOS and watchOS.
Sponsor Hacking with Swift and reach the world's largest Swift community!
