NEW: Start my new Ultimate Portfolio App course with a free Hacking with Swift+ trial! >>

How important were Playgrounds and the reference guide?

Recorded – watch the full episode on YouTube.

You shipped Swift playgrounds as part of Xcode 7 and you shipped an epic Swift reference guide from Apple. How important were those other things to success of the language?

Chris Lattner: Incredibly. I mean I think that both those two things in particular both enabled the very rapid growth of Swift initially. Playgrounds could have been more stable and they could have been more useful that way, particularly in the 1.0 timeframe, but it really changed I think what people came to expect when they were learning. And so learning, experimenting with the new API, all these things that we take for granted with playgrounds now, just as valuable back then but in the labs at WWDC, this was the first time anybody had ever seen it.

Being able to sit down and say let's talk about three lines of code. Let me show you a new idea. Let me show you what enums were, something like that without the context of the entire application wrapped around them was a pretty profound shift for being able to teach people.

"When you don't have value-semantic arrays, it turns out the explanation is insanely long and complicated and you can just look at it and realize it's wrong. Whereas if it's right, it's easy to explain and it's clear and you can have simple examples and it makes sense to people."

I think that more than playgrounds though was the book. The Swift programming language book was profound. I think the folks working on the developer publication team at Apple did amazing work both in helping shape what Swift became because it turns out that when you need to explain something, you learn things, right? When you don't have value-semantic arrays, it turns out the explanation is insanely long and complicated and you can just look at it and realize it's wrong. Whereas if it's right, it's easy to explain and it's clear and you can have simple examples and it makes sense to people.

And so they helped shape and refine the language but also the book itself made it so that people could jump in. They could understand the idea of what Swift was about. The Swift tour remains one of the best introductions to what Swift feels like to a lot of people. And so I think that was huge, and still is honestly. I think that the team does an amazing job of keeping the content up to date. As you know, writing is a lot of work and it's really hard – it’s a design problem of it's own.

"The principles of how the type system works we thought were sound and I think they've stood well mostly, but we don't have a lot of that practical experience."

Paul Hudson: Certainly I remember reading about how Microsoft made the early Windows games like solitaire to demonstrate drag and drop so you'd learn drag and drop by playing solitaire. And you know some of the WWDC talks I think were designed to literally teach you concepts while teaching you techniques as well.

For example, the Dave Abrahams talk where he shows off memoization in WWDC 2014 – he returns a closure from the function, and it’s like… what? What just happened there? That would never have been possible before and it just gets you thinking in Swift. And that of course takes a lot of time to find idiomatic Swift, what Swift feels like naturally, because I was obviously writing in Objective-C in Swift code for quite a while at first and that changed. Now I've hopefully found a more natural Swift, I think – hopefully!

"A lot of people ask what is the right way to do this in Swift when it launched – do I use a struct? Do I use a class? And the answer is we don't know. We haven't written 10,000 apps with this."

Chris Lattner: Well, I mean you raised a couple of really important questions. So a lot of people ask what is the right way to do this in Swift when it launched – do I use a struct? Do I use as a class? And the answer is we don't know. We haven't written 10,000 apps with this.

The principles of how the type system works we thought were sound and I think they've stood well mostly, but we don't have a lot of that practical experience and so that's definitely one aspect. The other aspect of it that was really interesting for that Swift 1.0, that first WWDC, was how do you explain this? So the entire community was grounded on Objective-C – that's what everybody knew, that's what everybody expected. We want to grow beyond that but it makes sense to explain things in terms of Objective-C.

And so if you look back on what Swift 1 looked like, felt like, it was very intentionally close to Objective-C. This meant we could say, "Hey, well, if you know UIKit or AppKit, you could come right over and everything just feels normal, with the same API." The hardest thing about learning to program Apple platforms in general is the frameworks and how they work and you maintain all of that knowledge, right? The only thing changing is some syntactic things.

"It was about providing that ramp so people could start quickly but then transition, learn, grow, start to understand things in their own terms."

But then on the other hand, you want to make it so that people see the value and so memory safety like ARC is now implicit, which is great. Enums – look at how cool this is. This is a common pattern that's super awesome and look at all these nice things. It was about saying here are some things that you shouldn't use on every line of code necessarily, but this is what nice things modern languages bring into into the mix. You can feel productive because it's safe and familiar, and you can still make everything a class, and you don't even have to learn value semantics if you don't want to. But that day you do, they're nice because of this and this and this and this.

Then again it was about providing that ramp so people could start quickly but then transition, learn, grow, start to understand things in their own terms and different people have more or less tolerance for new technologies, right? Because new technologies often add bugs and things like that. But different people had more incentive to move than not and I thought that worked out well.

Paul Hudson: That transition was amazing and I remember telling folks in the early days, now's a great time to learn Swift because after Swift 3 it'll be so much harder because you've got to learn the language but also the APIs now look different. Before that, it was almost line for line some parts Objective-C to Swift. You could just pull it across very easily. Learn it now while you can!

This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.

Listen on Apple Podcasts

Hacking with Swift is sponsored by Stream

SPONSORED Check out Stream's cross-platform open source chat SDK on GitHub! Write once and deploy your app with fully featured chat UI on iOS and macOS.

Go to GitHub

Sponsor Hacking with Swift and reach the world's largest Swift community!

BUY OUR BOOKS
Buy Pro Swift Buy Swift Design Patterns Buy Testing Swift Buy Hacking with iOS Buy Swift Coding Challenges Buy Swift on Sundays Volume One Buy Server-Side Swift (Vapor Edition) Buy Advanced iOS Volume One Buy Advanced iOS Volume Two Buy Advanced iOS Volume Three Buy Hacking with watchOS Buy Hacking with tvOS Buy Hacking with macOS Buy Dive Into SpriteKit Buy Swift in Sixty Seconds Buy Objective-C for Swift Developers Buy Server-Side Swift (Kitura Edition) Buy Beyond Code

Was this page useful? Let us know!

 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.