It’s Not (All) About the Speed

Swift is a young language. We still don’t really know what it’s all about. And while the reception has generally been pretty good, many devs have been hesitant to use it. A lot of the time it’s for mundane reasons: too much Objective-C to convert (right now), current release not stable enough, not widely available for other platforms. Other times, though, the language itself will be criticised. Some of these criticisms are aimed at the implementation: bugs in Xcode, gaps in the standard library, that sort of thing. But what I’m interested in are the criticisms of the design of Swift.

I’m not interested in whether they’re right or wrong: I’m not well versed in the alternatives (especially the elephant in the room: dynamic languages like Objective-C or Smalltalk), so it’s not my place to say.

Swift’s design introduces a lot of ideas to people that were maybe not familiar with them before. This kind of thing is generally difficult, and you’d want very good reasons for doing it. I’m interested in those reasons. I’m interested in what motivated the Swift team to make the language they did.

Talking about a programming language in this context is a little strange. If you look at other languages in the top 20, it’s very difficult to find consistent motivations behind each language, or even consistent motivations behind each design choice. Languages designed by committee pull in different directions. Other languages like Javascript were designed for things completely different to what they ended up being used for.

Swift is different. It has all the cohesiveness and clear philosophy of an academic language designed by a tiny team – but it’s being used by thousands. It’s young, willing to change fast and break old code. Its domain (for now) is pretty much known, and its popularity is (to a certain extent) guaranteed. (I mean, if Apple decided to push COBOL as the next programming language, I’m sure there would be complaints. But you know what else? There’d be an awful lot of COBOL written)

We all know the disadvantages of a closed-off, proprietary language. What you’ve got to realise is that the nature of Swift’s creation means that the language we see and use is pretty close to the language that the Swift team wanted to make.

This is, of course, classically Apple. Secretive, one message, one voice. But Apple is in transition. The channels of communication are opening a little. If you have a question about why something was done in Swift, you can tweet one of the designers. And they’ll tweet back!

This means that it makes sense to talk about the philosophy of Swift. We can wonder about why things are the way they are, and we can make pretty good guesses as to the answer.

Buddy, the clue’s in the name. This language is all about speed.

Maybe. Let’s be clear: this language is mainly used on small, power-hungry devices. Performance matters. But it’s not the only game in town.

I mean, think about what Swift is taking over from: Objective-C. This isn’t because Objective-C was too slow: arguably, Objective-C was able to hang on for so long because it was so low-level and fast. When the clamouring began for a modern, easy, high-level language for Apple development, the demands weren’t stalled because modern languages “weren’t dynamic enough”; they were stalled by the iPhone. Performance became really important, really fast, and Objective-C knew performance.

Still, the demands were only stalled. Something new was needed.

So where are the answers?

If you go to the Swift homepage, you’ll see the tagline:

A modern programming language that is safe, fast, and interactive.

I think this gives a pretty decent overview of three of the key aims of the language. It does say “fast”, but everyone knows performance is important. The other two words there are what interest me.


This is a biggie. Swift is a safe language. Objective-C isn’t being replaced by a faster alternative, it’s being replaced by a safer alternative. (Or, an alternative which is intended to be safer) Immutability, error handling, optionals, the string handling: it’s all very constrained. There are some clear performance gains to some of those constraints, but far more clear is how safety-oriented they are. In particular, I think this stands out with the type system.


As a beginner programmer, types and type systems are one of the first things explained to you. You are told a little bit about duck typing, dynamic typing, static typing, and so on. Sometimes, though, the explanation for why you would prefer one type system over another is a little misleading.

The most frustrating common explanation is “performance vs ease”: dynamic typing trades performance for the hassle of static types. This is a strange straw man. Stray away from Swift for a minute, and look at Haskell: a language that takes static typing to the extreme. Ask any Haskellite about the type system and they’ll rarely emphasise performance. In fact, if you delve into the world of even more academic, functional, and experimental languages, into a domain where performance is even less of a concern, you’ll see the type system take centre stage. So, in some languages at least, types are not static for the sake of speed.

Obviously not everyone thinks static typing is just a performance issue. But I get a little worried when I see people get close to calling it a “premature optimisation” – especially with beginners, this kind of mischaracterisation can stick.

I don’t want to build the same straw man for dynamic typing that I’ve been trying to defend against for static (Oh, they only want duck typing because they think it’s less of a hassle). I’m not saying that one type system is better than the other: those arguments should be had by people better read than me. Here’s what I’m concerned about: if you think performance is the main motivator for static typing, you begin to think of design patterns, compile-time woes, signatures, and complex types as disadvantages. You think that those things are the hassles that you have to deal with if you want static types.

But that’s not what the language designers think. Go back to your Haskellite friend. Don’t worry, they’re right where you left them: they’ve not stopped talking since you asked them about the type system. Why? Because they love it. All those hassles you have to deal with are joyful treats to the Haskell programmer. You say “ugh, this won’t compile because of some type error”, the Haskellite says “Yes! This caught my error at compile time rather than runtime!”. You say “yuck, all of my functions need signatures”, the Haskellite perks up “I love signatures! They tell me a lot about unfamiliar functions – how they work, what they’re supposed to do. When I’m writing my own functions, I can start with a signature, and that’ll tell me a lot about how my function should work!”

Obviously that’s a caricature. Static types can get in the way: no-one knows this better than a Haskell programmer. But don’t go thinking that something like Protocol-Oriented-Programming is a solution to a problem that duck-typed languages don’t have. Protocol-Oriented-Programming, along with a whole load of other things that static typing opens the door to, is the goal. If you make it seem like a disadvantage, people – beginners especially – may use it like one, and avoid it when it should be utilised.


One of the major tools you’ll find yourself using while learning Swift is playgrounds. They seem a little gimmicky in the beginning, but their usefulness quickly becomes obvious. I’ve become surprisingly reliant on them: I’m trying to learn Haskell and C at the moment, and the code at runtime is a little opaque. Setting up a debugger with breakpoints to examine variables is a hassle, and using the REPL allows only very short snippets of code. In Swift, the time it takes to go from “Hey, I wonder if I could…” to “Yeah, I can!” is the time it takes to open up the empty playground I always have on my desktop, plus the time it takes to write the code. Haskell/C? Hmm… I’ll try the REPL, first. Well, actually, this’ll take 30-40 lines, I’ll open up a file. Right, that didn’t compile. What’s the problem? Line 23… Ok, right, lemme change line 23. Still doesn’t run…

But playgrounds aren’t a design choice like static typing is – pretty much every language out there would benefit from them. So why don’t those others have them? Well, playgrounds are expensive: it takes a lot of engineering time and money to get something like that together. The better question is: why did Apple decide they were worth doing?

One group in particular benefits from playgrounds: people learning Swift. Coders with more experience will more easily be able to navigate complex debuggers, or mix-and-match various tools to get the iteration times they need. But beginners may not be able for that. For them, playgrounds may be the only avenue to the kind of debugging others take for granted.

And Swift is young: for now, pretty much everyone is a beginner. So maybe it’s a simple as that: Apple needed to make it easy to learn Swift, because Apple needed people to learn Swift. It’s in their own interest.

However, I think that there’s some (Shock! Horror!) altruism involved. Here’s a quote from Chris Lattner:

The Xcode Playgrounds feature and REPL were a personal passion of mine, to make programming more interactive and approachable … I hope that by making programming more approachable and fun, we’ll appeal to the next generation of programmers and to help redefine how Computer Science is taught.

Now, it’s tempting to take him at his word – and it would make sense. Swift is a language that is easily taught. Not to mention it’s a nice quote.

Regardless of whether the high-minded sentiment is to be believed (and I would tend to believe it), the result is a language and set of tools that is very well suited to education. This talk fantastically describes the importance and usefulness of those tools – I think it’s also worth mentioning the importance of Swift. It’s a language that’s being incredibly widely taught, a language that may become the dominant language on one of the most important platforms in the coming years, and (hopefully) a language that will have a scope and application beyond one company. Of course education in Swift is important. We shouldn’t expect anything less.

One comment

  1. Pingback: Stasis | Big O Note-Taking

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s