Swift is like Frasier
Swift is like Frasier.
…
Still reading? Okay, let me make my case:
When I was a kid, I spent more than a few hours at my grandparents’ house watching Frasier – I was never particularly interested in the characters or the plot, but I liked the dog and the tendency for the characters to make uproarious fools of themselves.
Over the past few months, I’ve been steadily binging through it on Netflix 1, and I’m surprised at how simultaneously familiar and unfamiliar it seems. I remember the broad strokes and characterizations – Frasier is pompous but kind-hearted, Martin is cranky but proud, farce is omnipresent – but there are so many pleasant surprises that I’ve picked up on now that I have a pop culture foundation surpassing that of a sheltered fifth-grader: things as basic as an extended homage to My Dinner With Andre 2 and throwaway references to Seattle intersection to the serious undercurrents of ennui and loneliness that manage to thrive amidst the world’s most obnoxious soundtrack.
Watching an episode (or five) feels vaguely familiar – the plots, even as unremarkable as they are (Frasier fixes the toilet! Niles needs new shoes!), are nothing new, but there’s another aspect to it that makes me enjoy the whole thing a little bit more, if only to appreciate the fact that a dozen or so talented writers had the brains and guts to throw references to Jung and Vivaldi at the sitcom-shaped wall and see what stuck.
This, of course, is the exact same experience I had working with Swift.
Swift’s launch wasn’t just met with fanfare, it was met with unbridled enthusiasm. Objective-C, to many 3, is less of a language and more of the wall you have to climb to do fun things. I maintain that anyone rising to the defense of its Smalltalk-esque syntax is a victim of Stockholm Syndrome; the prospect of ditching the baggage of Objective C and progressing to a language with vastly better development and execution time (as claimed in the keynote) is incredibly enticing.
I’ve spent the past two or so weeks porting Barback to Swift. This was done both for pragmatic and educational reasons: I was already itching for a reason to replace v1.01 with something that looked less like spaghetti code, and I wanted a chance to tinker with this awesome new language before it became passé.
The port is done, and while I must wait until autumn to actually push it out to the App Store, you can take a look at the code on GitHub.
The reality is twofold:
First, writing in Swift is incredibly pleasant. Swift code is aesthetically pleasing; it promotes clarity and pragmatism. While I haven’t played around with two of the most highly touted aspects of the language – case matching and robust enums, I’m in love with mobile programming that looks like this:
func matchesTerms(searchTerms: NSString[]) -> Bool {
for term: NSString in searchTerms {
// If the term is nil (e.g. the second item in "orange,", match errything.
if term == "" {
continue
}
// If the term matches the name of the recipe..
if self.lowercaseName.rangeOfString(term) {
continue
}
// Or at least one ingredient in it.
let matchedIngredients = ingredients.filter({
(ingredient: Ingredient) -> Bool in
return ingredient.matchesTerm(term)
})
if matchedIngredients.count > 0 {
continue
}
// Otherwise, no luck.
return false
}
return true
}
As far as I’m concerned, the closer it feels like to writing Python the happier I am, and Swift succeeds remarkably in that regard. As dumb as it sounds, there are times where I want to hide my code and there are times I want to keep refining it and making it even better: my experience with Swift falls solely in the latter, and I’m enjoying actively refining and refactoring my code for no other reason than that I can. It’s the first hit of a new designer drug: everything is new and wonderful and unexplored
Second, you’re still writing an iOS app that looks structurally identical to one you’d write in Objective-C. Which means you’re still dealing with Cocoa Touch bindings 95% of the time; which means you still have to struggle with Core Data et al, in all of its flawed glory; which means you still get to spend a few hours debugging why your UITableView refuses to adopt its new constraints before realizing you called willLayoutSubviews() after self.view.layoutIfNeeded().
Swift is still a very opinionated alpha of a language, which can be frustrating. Protocols and extensions are nice but they’re no absolute solution to a lot of problems; the singleton pattern gets to be implemented with this abomination of a struct:
class MySingleton {
class var sharedInstance: MySingleton {
struct Singleton {
static let instance = MySingleton()
}
return Singleton.instance
}
}
And, while dealing with segfaults and random SourceKit crashes is hardly symptomatic of Swift’s long-term prospects, it points to the larger issue of how early adoption of a (for now) closed-source language is tenable. A few thousand open Radars is no substitute for a robust community.
Syntactic sugar is great to use, but Swift development encourages overdosing on the carbs: you’re usually stuck using suboptimal builtins (String.lowercaseString is O(n), and was the legitimate chokepoint of one of my methods to the extent that pre-calculating it and storing it as a parameter sped up viewDidLoad() by 95%) and bridging to the NSEquivalent (this is something that will hopefully get better in time, but good luck for now judging what should and shouldn’t be an Optional!)
What I’m getting at is that there are all of these quirks that don’t really go away just because you’re using Swift 4 – if anything, Swift exposes them.
With Objective-C, it was vaguely hellish the whole way through.
With Swift, the contrast is painfully apparent: you use an elegant language to do inelegant things.
Put another way: Objective-C was a pain point, but it wasn’t the pain point. The difficulties and imperfections in working with Apple’s development stack are still there, they’re just smoothed over by a much nicer programming language and the promise that things will keep getting better.
Ultimately, Swift didn’t really solve most of my problems with iOS development. But it certainly made me more excited to run headfirst into them – and appreciate the work put into so many things in a new light, like watching a six minute silent comedy and only now realizing the brilliance.