178

178 iPS Swift 3 and Swift Migrations with Paul Cantrell


1:00: Introduction

4:20: How the language is written

12:30: Synthetic Sugar

  • Swift 1.0
  • Double optionals

15:30: New API Guidelines

  • Strings
  • Fluency

21:15: Verbosity vs. Terseness

24:00: Successful Server Languages

28:30: Problems

  • Domain model
  • Limitations of control

32:40: Brand new startups

  • Limited users as a positive
  • Client development

Picks:

Swift (Paul)

BBS the Documentary (Jaim)

CleanCoders.com (Rod)

Swift from Two to Three (Paul)

Article on how we teach math (Paul)

Lockhart’s Lament (Paul)

If I Sleep for an Hour, 30 People Will Die (Paul)

Bust Out Solutions

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

Charles: Hey everybody and welcome to episode 178 of the iPhreaks Show. This week on our panel we have Jaim Zuber.

Jaim: Hello from Minneapolis.

Charles: Rod Schmidt.

Rod: Hello from Salt Lake.

Charles: I’m Charles Max Wood from devchat.tv. This week we have a special guest and that’s Paul Cantrell.

Paul: Hello also from Minneapolis. Cantrell, accent’s on the first syllable.

Charles: Gotcha. Do you want to give us a brief introduction? I’m pretty sure we’ve had you on the show before but we haven’t had you on for a while.

Paul: Sure. I see that my fame has not spread far and wide. I’m a freelance developer and software consultant here in the Twin Cities. I work mostly with Bust Out Solutions. I also teach part-time at Macalester College. I teach computer science and help students there build software projects and I’m also a quasi-professional PMS composer at times. I’m the author of the Siesta Library for Swift, some of you may have used and occasionally have dabbled in the Swift evolution list.

Rod: What does the Siesta Library do?

Paul: Siesta is a toolkit for writing primarily iOS and also Mac apps that use restful APIs. It is in very brief an observable in memory cache of the state of every restful endpoint that you might be interested in. Its purpose is to prevent redundant requests to clean up redundant network handling code and in particular to disentangle the sort of stateful messes that result from traditional call back based networking. Its effect is to give a sort of reactive flavor to your app without having to go all in reactive. There was in fact an entire previous iPhreaks about it. You could check that out if you’re interested in hearing more.

Rod: That would be episode 124. Siesta with Paul Cantrell.

Charles: Awesome. It’s been 54 episodes. Right around a year, right? Because we release every week.

Paul: Sounds right. I think it was last spring I want to say that I was on, maybe like seven months. Nobody would accuse you of not keeping busy.

Charles: Gotcha. What are you working on these days Paul?

Paul: As usual, I’m doing a lot of language hopping. I am maintaining Siesta, I’m working on some iOS stuff, I also usually have one or two Rails-based apps in the mix and end up often against my wishes working on things written in JavaScript these days. It’s sort of the C++ of our time, everyone loves to hate it but everyone needs it. I guess C++ is also the C++ of our time. Yeah, JavaScript. We can do a whole episode on what I hate about JavaScript.

Charles: I think we did a whole episode of that on JavaScript Jabber and we like JavaScript.

Paul: Yeah. Well, it’s a lovely language except for all of its problems.

Charles: Yeah.

Paul: Awfulness with the descent language screaming to be free which I guess is the whole script effort. God bless them and more power to them.

Charles: We did bring you on to talk about Swift. I’m not quite sure where to start. I think Jaim had some idea.

Jaim: Yeah, you would talk at MiniBar at local massive on conference that we have every year and he talks a little about the philosophy of Swift, how the creators of Swift had language to influence how we actually write the language, maybe you could talk a little bit about that.

Paul: Yeah, well it’s this language hopping that I constantly do, it exposes me to different developer subcultures centered around different libraries and languages. Something that I’ve noticed is that I think we greatly overestimate the universality of our own best practices. We do something that makes a lot of sense in Swift or Ruby or in JavaScript and feel like we found the one truth about writing good code when in fact what we found is something that is very well-optimized in the language which we’re writing in right now.

One example of that I think everyone could probably relate to is working with Ruby for the first time, for years I’ve been doing Java, C++, lots of very statically type languages. I was a little freaked out about how little help the compiler gave me but I found in Ruby and JavaScript projects, first of all, testing is a much stronger component of most projects. Second, especially with Ruby, there’s a much greater emphasis on minimalism and avoiding repetition and making code express very clearly only the things that are unique or relevant to the situation at hand. That is, issuing the kind of boilerplate that people complain about especially in Java a lot.

We often frame that as is it better to have a language that has less boiler plate or is it better to have a language that is clearer and more explicit. Moving back and forth between the worlds, what I see is that both models work, you just have to think very differently. If you have a language with less boilerplate, you need to make all of your tools and idioms much more concise and expressive and self-explanatory so that what they seem to imply is true to what the code actually does.

For example Rails, Rails is just a bunch of conventions that try to look like plain English when used correctly and that becomes much more important if you’re relying on convention instead of compiler tracking to make sure that what a human reader sees and what a compiler sees are actually the same thing.

I had all of that rattling around in my head and then Chris Platner made a really interesting post in the early days of Swift evolution where he seemed to be saying a lot of the same things and his term was programmer model. He said, “We’re very interested in the programmer model for Swift.” He said, “We’re not really interested in what’s the absolute right way or what the language can or can’t do. Whether it’s possible in the language is rarely the right question. We’re interested in what the language encourages and discourages. We’re also interested in what best practices and programming habits result from the language encouraging or discouraging particular things.”

Rod: That makes sense. I saw a Tweet once that says, “What do you want to complain about? A) two much boiling point or B) too much magic?”

Paul: Exactly.

Rod: Pick your poison. How do you think Swift encourages us in this way?

Paul: The example that Chris Platner gave in that discussion is really illuminating and much simpler. I think he said, “Why did we call it let and not const? It’s because if it took more keystrokes to make a variable immutable, then people would want to use the shorter form. They would probably come up with some rationale about how it’s better just to say var everywhere because that’s more consistent even though it makes them impart from it being also more verbose, thus the language would just very subtly discourage immutability.”

He’s worried about how many keystrokes the keyword takes. That shows up a lot in Swift code and I have to admit, if I had to type const, maybe I would be just slightly more reluctant to make things immutable first. But in fact, he’s right even before that comment in Swift code. I pinned all just start with let and see if I need to make it immutable and if I’m making it immutable, I think about why I’m doing that.

In that general pattern, I would say is very typical of Swift which is that I would start with something that is smaller or more obvious or more concise, more the language default than something that forces me to break out of that default and that moment of departing from the simplest thing corresponds to a moment of thinking deeply about the design of my problem, asking myself why do I have this problem, why am I trying to make this immutable, why am I trying to make this thing not the optional or the optional, why is the compiler asking me to stop and think here? That idiom of compiler message turns into a moment of big picture self reflection. That I would say is very typical of Swift and not necessarily of all even strongly type languages.

Rod: It makes a lot of sense, the thing in, probably you’re like, “Are you sure you want to do this?” Just make sense?

Paul: By contrast, Swift optionals look a lot like things that functional languages have been doing for a long time, Haskell has something like this. Haskell I think is a great thing for any programmer to learn about and read about most interesting language features you’re going to see somewhere else may have been tried in Haskell first. One of Haskell’s big downfalls is I think that designers really aren’t thinking in quite the same way. For example, in Swift 1.0, if anybody remembers working with Swift 1.0, optionals were super frustrating. When I dabbled, and I never develop a serious app in Swift 1.0, there were so many unwrapping conveniences that just doesn’t work there, so many things that I thought should have been implicit in versions where the compiler made me double unwrap something or explicitly state what seemed like it should have been an obvious type conversion. There were a lot of APIs where things were marked optional that really shouldn’t be. They forced me to deal with the nil case where the nil case didn’t mean anything.

At that moment, I thought all this optional business, yeah it’s nice in theory but it was annoying and functional language now it’s annoying here too. Lo and behold in Swift 2.0, the compiler team put a lot of work into unthemed implicit conversions where assigning to an optional variable from a non-optional variable always worked, maybe quite didn’t always work before.

APIs that had everything marked optional because they came from Objective-C got properly annotated and now all of a sudden the UI kit didn’t return optional everything everywhere and suddenly in Swift 2.0, the experience was that if the compiler was giving me trouble about optionals, it wasn’t forcing me to think about the language and how annoyed I was, it was forcing me to think about my code, why is this optional call, why could this be optional here? There’s something you haven’t thought of. There’s a state transition, a corner case, there’s a reason to stop and think. That reason to stop and think, it’s about your code, and your app, and your problem, it’s not just Swift being annoying.

The shift there, it’s profound from being asked to worry about language to being asked to worry about my own code. That shift hinged on some pretty sugary and minor things. Syntactic conveniences, better APIs, Yeah?

Rod: What are some examples of the synthetic sugar that helps the transition?

Paul: I was afraid you’d asked that. It’s been too long for me to remember minute details.

Rod: We had the Pyramid of Doom.

Paul: Yeah

Rod: Swift 1.0.

Paul: One thing that I definitely remember from Swift 1.0 is that I got double optionals all the time and it wasn’t clear why and so the sugar adjusted the compiler finding tastes where optional, optional didn’t make any sense in removing them, that was huge. Things like the guard clause where used. It’s utility was not obvious at first but what it does is it lets you peel off cases where things are optional at the top of the block rather than having a bunch of nesting. The ability to unwrap a bunch of optionals using a single if-let, let, let, separated by commas, that turned out to be huge. There’s maybe half a dozen language features like that that made it so that in good Swift 2 and now Swift 3 code, you just don’t see deeply nested pyramids of if-let, if-let, six levels down, that’s now a big bad code smell instead of the norm.

Rod: That makes sense. It was a little bit of a unfair question. That transition was a year ago, we’ve all forgotten what happened, we’re on Swift 3 now. What examples in Swift 3 influenced the developer’s defaults for how they write code. The big one, I would say is the grand renaming which if you haven’t encountered, you’re about to. There was a lot of back and forth on Swift evolution. I think one of the most hotly contested threads ever was about what the naming convention should be for the first parameters of methods and functions and the Swift 2 defaults is that most of the time, the first parameter just doesn’t have a name except in certain circumstances.

There was a lot of community pushback on that. I would say, this is a rare case where the Apple team was pulled away from their original direction to some extent by community input. Developers on the list seem to feel that no, the part of the method name that comes to the left of the parenthesis should really be focused more on what is this method or family or overloads and the things that come inside the parenthesis should be the things that are most focused on the parameters and we’ve ended up with this very convoluted set of API guidelines that actually make quite a lot of sense once you see them play out in practice. If you’re converting your code to Swift 3 and you’re using UI kit, you’ll notice that the migration assistant suggests renaming lots and lots of methods and these sort of this minor ways that end up reading a lot better instead of method names like wash dishes with sink full of forks and knives (wash dishes (with:sink, and etc.) the effect that this has had is first of all, I think it’s made the language more friendly to really using argument labels as a way of grouping similar things and expressing overloading relationships.

Second, it’s made the labeled arguments make a lot more sense at the actual poll sites and that second one, I think it took us a year and a half maybe of working with Swift and get out of the habit of seeing Objective-C. I am quite certain that the reason that Swift in its earlier versions first said, “Well, usually first arguments shouldn’t have a label it’s just because that look like Objective-C. That’s what we’re used to seeing. It was a lot of familiarity bias for us to train ourselves out of and it took some time to get unfamiliar with Objective-C before everyone could see how clearly its conventions didn’t actually make perfect sense.

Rod: That’s a good point because I definitely saw the Swift 2 conventions where you have the name as far as the method name as a hangover from Objective-C. In some place, it’s a good point. Now, it’s a good thing because one of the things that I really got to when I’ve got to Objective-C was how clear the name of the methods could be which my code never had when I was trying C++. It didn’t have it when I was writing C-Sharp or anything like that. Having the verbose names was something that was helpful but I definitely agree that I wanna see Swift 3 is like, “Yes, I have clear names and I have a clear intention of what I’m trying to do without loading all things that should be in the method name, that makes a lot of sense.

Paul: Yeah. Perhaps my favorite new point of the API guidelines for Swift 3 is it looks notice but it’s a biggy. It says argument labels should not contain words that are already present in the names of types but they should compensate for weak type information so there’s a mouthful. What does that mean? That means that if I’m calling a method that’s like delete file at path, that path argument is probably a string and if it’s a string, what is that string? The string can be a path, it could be a URL, it could be a name of your pet. Who knows?

In that case, string doesn’t completely say what the role of that argument is so it’s good to say delete file with path. If however, we had a path type, struck path can only contain things that are actually paths on the file system then you would just say, delete file with: and then value of the path. If the type of the variable tells you what it’s role is, then you don’t need to also say that in the argument. That one rule right there has cleaned up interacting with you just inconceivably. When you make the Swift 3 migration, it’s amazing how much nicer this labels look. It’s not an obvious thing but when you see it in practice, wow does it have a nice effect. I’m pausing here to just find a good example of that in zip code. I need half a moment to edit this out.

Rod: It also seems like you end up with a lot of propositions for your labels and it almost makes sense in English almost.

Paul: Yeah, the API guidelines say that you should, their phrase is strive for fluency and what they mean by fluency is make the method read like a sentence at least for the first argument or two. They actually explicitly say it’s okay not to make all of the arguments read like a sentence all the way to the end especially if some of them are defaulted but at least the method name and it’s first or second argument should read like a phrase. Pay attention. I’m going to flip through some codes because I’m blinking other really nice example. I wish I had the Delta from the migration handy.

A good example of how this migration helps us is look at the changes in the API for string instead of having things like name stringed by replacing t occurences of string with string blah blah blah, I can’t even remember how many times I said string in the old method name. Now, you just have string replacing occurrences of blah with blah. You don’t need to say string over and over and over and the non-repetition of that helpful word makes it so much easier to read. Something that I’ve learned from Ruby is that both [00:27:17] and verbosity are enemies of clarity. That is meaningless repetition of things that don’t convey information, things that lower the data ratio of code and tough terminologies things that make each character just  a little less valuable to read. They train your eyes to ignore things.

If there’s a lot of repetition to your code, a lot of boilerplate, a lot of of non-information bearing characters, you start skimming over stuff, you have to. That means that you miss bugs. Conversely, extreme terseness can be a source of confusion and bugs because there’s too much implied, too much magic and we’re still calibrating the balance between those things and Swift 3 has shifted that balance a lot just with these API conventions.

Jaim: How do you strike the right balance between verbosity and terseness, is it just the function of the language or do the developers have saying in that too?

Paul: I think we all do. I think one of the lessons of Swift evolution in every successful source language is that things work best when we have a little dialogue between theory and practice. We develop something that makes sense after the discussion we try it in the wild, we see how it plays out, we discover where it succeeded and failed and then we iterate. The design of everything and yes, language design is also a kind of design and the base of the same design principles like for example, the first job of any design and I mean graphic design, industrial design, programming language design.

The first job of design is empathy for the people who are going to be using and working with the thing that you’re designing and just as the size of the handle of the coffee mug matters and depends on the size of the hands of the people who are drinking coffee, the conventions of the language depend on the people who are using.

Ultimately with all the sign, the only way you can validate it is to let people try it out and see what’s comfortable and what’s uncomfortable. I think as users of Swift, now that it’s open sourced, the ownness is very much on us to discuss what’s working and not working and to send that feedback to Apple because there’s a really just amazing smart people and that you are listening very carefully to what’s going on and really interested in the conventions that emerge.

Rod: Yeah, that’s a good point because Swift is a client app language for OS 10 or Mac OS and iOS, that’ the first thing but that role definitely expanding. It may not be what people are writing in Swift five years from now.

Paul: Indeed. Platner explicitly said that he would like to expand the domain of Swift as far as possible down to embedded systems even if maybe having a lighter weight foundation is necessary all the way to lightweight scripting. Basically, I think the team wants to see how far they can push it and clearly I think server side Swift is the next frontier which I’m excited about as a young community but it’s an exciting one. I would love to be writing Swift on the server.

Rod: Yeah definitely. I think Swift is a great language and it’s definitely–I can see it developing a sweet spot server stuff.

Paul: It’s an interesting question  though. Since to dates successful server languages haven’t look like Swift. In fact, this is a big one, it’s hard for me to think. I cannot think of a successful lightly used  server language today that does not have garbage collection. Swift doesn’t and as far as I can tell isn’t going to. What that means is in a language like Java, Ruby, Python, JavaScript, any of these languages, if you have a bunch of objects that form a reference cycle, that means a references b references c references back to a again but that whole cycle is detached from your program as a whole nothing reference to cycle, it gets deallocated whereas the language like Swift, you only have reference counting to help you deallocate things and Ark is great it feels transparent most of the time but you do have to make sure that at least at the moment you intended to deallocate your object graph forms a tree and the only backreferences are weak or unknown references which requires a lot of knowledge about the relationship between objects and that sometimes can break encapsulation or at least make encapsulation more difficult. If you have reference counting then part of your API contract is promising what you will and won’t retain.

Rod: Okay. I was going to say I know Python has garbage collection but you do have to manage the retain cycles. I’m not sure what the difference is.

Charles: Yeah, I don’t know. Ruby and JavaScript are garbage collected.

Rod: I was going to say that to be an embedded language, garbage collections kind of frowned upon. For Swift to be an embedded languages is in its favor.

Jaim: Definitely.

Rod: Alright, sounds good.

Paul: When did you leave me? I was on some long ramble there.

Rod: Garbage collection and server languages.

Paul: I’ll just start from the top there.

Charles: Sure, we’ll stitch it together and make it sound good.

Paul: Okay. One thing worth considering with Swift sever is that right now as far as I can think, there’s no widely used server language that doesn’t have garbage collection and Swift comes close Ark reference counting feels a lot like garbage collection most of the time but it doesn’t have the cycle detection and just academically decide reference counting with cycle detection it’s equivalent to garbage collection they provide the same thing even with this implementation differences. It’s the case right now that in Swift, you do have to make sure that your object graph at the time that you expect something to be deallocated.

You have to make sure that your object graph is a tree and any back references are either weak or unknown in the language like Java, JavaScript, Ruby, Python, it is possible to have a bunch of things all referencing each other but when that entire glob of mutually referencing objects with all of its reference cycles when it’s no longer used, it goes away all at once.

There’s some compelling reasons why maybe garbage collection works pretty well on the server. You can allocate things really fast and then just kind of throw away a big unused object graph all at once after a response is already on its way to a client. The Swift team has stated quite explicitly, they are not interested in adding garbage collection to Swift, the reason is that a goal of Swift is deterministic performance. You don’t want a garbage collector jumping in and making your iPhone feel all lurgy, well Android-like, there’s a little animation glitches you often get on Android because of garbage collection as often as not. Android people have done amazing things to iron them out. They are now very hard to detect but they’re there.

So, can a language without garbage collection succeed on the server or is it going to be a problem? It might be because really in a reference counted language, what you retain and don’t retain is an important part of your API contract if you’re providing an API. It’s not something that we think about very often but it’s there, it matters a lot and because of that, reference counting can kind of break encapsulation or at least complicate encapsulation. How’s it going to play out on the server? Are obstructions that work in other languages going to become difficult because we don’t have cycle collection? I don’t know. Maybe I’m worrying over nothing but it concerns like that and one that nobody even thought of there just going to be cropping up over the next few server side Swift evolves and detours and I’m excited to see what comes out of it. I really don’t know.

Rod: That’s a good point. I think the problems that we’re handling, a lot of server side, server side are different than the client works. One example is the domain model. A lot of server apps I’ve done the domain model can get very complex because you’re aggregating data from all these different services, doing it together and seeing how they work together and build new things off them and they all reference each other and if you have to think about how this is going to be cleaned up with Ark, you might get in trouble whereas if you’re doing an iPhone app, you’ve got a couple of services, three or four maybe, and you’re not dealing with those type of things as much. It’s interesting to see–hold back from Swift like really large enterprise things possibly but it also might be a good thing for things that are being done by Gull right now so you have a compiler language that can move very fast and you don’t do huge, humongous stuff with it, enterprise stuff but smaller services you can handle well and also provide a really strong language outside of features.

Paul: I believe Go does really have or is building garbage collection, right?

Rod: Go has garbage collection.

Paul: Yeah.

Rod: I see Go and Swift tapping a lot of the same type of things. Go is garbage collected but that means you can’t really control when it gets collected.

Paul: Yeah.

Rod: Which is a problem for a lot of applications.

Paul: I mean, it’s kind of okay on some of the servers some of the time in a way when it’s not animation is a problem. In the world of smooth animation, apps, games, UI-based stuff, determination is even more important than that performance. It’s okay to be slightly slower if you’re always consistent. On a server at some levels of load at least, it can be acceptable to have maybe one node just has the garbage collect for a few milliseconds while other nodes take the load and that can be perfectly fine whereas say if it’s your phone and the UI is just a little bit twitchy and unresponsive then you’ll lose this illusion of physical interactivity, it can be a real problem.

Rod: That’s a good point. I’ve heard of Go limitations where garbage collection is a problem on the server because the reason Go is very fast is because you’re expecting a ton of requests and they didn’t have to think right or they do have some data type that seems like it was changed but brings out tons for memory it has to be cleaned up over and over again. In that case, something like Ark, you kind of know what you get into and you control and you know what’s happening.

Paul: Yeah, allocation and deallocation are not free but at least they’re consistent. I mean it’s true, right now Go, Swift, and Rust, this trifecta of languages sort of vying to replace C++, they all have this promise of thinking high level but getting C or C++ like performance and a. that’s wonderful and I’m really excited about it and b. it’s dangerous because we programmers, we can’t way too excited about performance. It’s such a shiny project, the promise of a better performance for free, the promise of faster even if we don’t need it. God, it makes us do stupid things. I mean, how long ago was it that [00:44:11] said that premature optimization is the root of all evil. That was decades ago and it’s still true. There’s something about fast, about that benchmark that says your code will just 20% faster. It makes developers jump at the latest shiny thing and often undeservingly.

Jaim: Yeah, that was true. Ruby would have never started.

Paul: Indeed. Working with–doing consulting, working with so many different companies, different faces, different sizes, so often the concerns that you have in a huge deployment, a high traffic deployment, they’re not just worth worrying about for us start-up that is trying to get its first 100 customers, that just want to validate an idea. The ability to rapidly iterate on a design and try things out and see what users respond to even with pairable performance, that can be so much more important than say quadrupling the response time of a server that already only takes a 100 milliseconds to get a response back. Different organizations have such different problems.

I was talking with a friend of mine who was at Google about the experience of some start-ups I worked with in a very early phase start-ups and we realized that so much of his thinking about web frameworks and web programming which is shaped by the fact that Google, if they sneeze publicly, they have 100,000 users. They can’t launch anything small. It has to be performant and just fully vetted for this onslaught from day one which makes it very difficult to do very good design because they can’t iterate on design. Performance tuning is the enemy of rapid iteration performance tune code is always more brutal, more complex, and having simple slow code that is easy to rework rapidly is a real asset. In that sense, having so many users for free can actually be a liability and I think is the reason why things like for example Google wave maybe struggled. I think Google wave could have taken off if it only had a few hundred and a few thousand users instead of having millions on day one.

Rod: That’s a good point. I sat with potential clients a month or so ago. I’m talking about what I do and they can sign their API and like all these questions about how do you make sure it scales, how do you make sure it does this? I asked them, “Well, what’s the application?” Well, we’re going to beta test with 25, 50 users and like–let’s just make sure this works first. Build something that works, see how people use it. The thing with scaling, you don’t know how it’s going to scale, you don’t know how users are going to use the system. You’re kind of guessing upfront. Like, “Is this going to be a scalable solution?” I don’t know until people will actually use it.

Paul: You can do some educated design about the ways in which I need to scale, is it going to have lots of data, lot of users, lots of traffic for a small number of users etc. but that doesn’t mean that you have to solve everything. It just means that you think right from the get go about whether you’re painting yourself into a corner and don’t solve all the performance problems right from the beginning. We often confuse thinking about performance and scalability. Switching from a slower language to a faster language doesn’t make an app more scalable, it just makes better use of the CPU that you already have but if your problem is for example that your app relies on having some shared state in server memory and making that shared state stick with the client through the length of some stateful session interaction. That’s a problem no matter how fast your language is because you can’t just freely load balance. There’s a difference between thinking about how your app is going to scale up to larger database, more nodes, more whatever, more of whatever you’re going to get more of. There’s a difference between thinking about how you’re going to scale up versus how fast it is in raw terms right now.

Rod: I’m trying to kind of take this back to client development.

Paul: Fair enough. Well, I probably shouldn’t go for too much longer both because I have to meet somebody before too long and because now I’m running up my cell phone bill probably.

Charles: I think we can go to picks.

Paul: Maybe we could just bring it back to Swift for a moment or something and then my first pick is about Swift so that be a nice leap closer.

Charles: Do we want to go back to Swift or just go to picks and loop it back that way?

Paul: Good question. Do I have anything more to say about Swift and its programmer model really? No, let’s just loop it back. Getting it done is good. If you feel that you’ve got enough material here.

Jaim: Yeah, it’s good stuff I think. I want to hear about the Swift 3 variation with your library but oh well. I think it’s a good episode.

Paul: Here’s a place to bring it back. It’s something I want to get my head in order. Even though Swift 3 now, a lot of things are just feeling really good, such a pleasure to work with, there are areas that are still rocky and in development just in the way that optionals were in Swift 1 to big ones that stick out for me first, the dispatch rules for protocol extensions which probably just made half the audience’s eyes cross the flood of blood but the question Swift uses static or dynamic dispatch, I think that question is not entirely settled and the compiler may need some more warnings and some more explicitness to help sort that out and make protocol oriented something that everybody can really grasp and work with on a day to day basis.

The second area of real pain still in Swift 3 is generics. Swift’s type system is not fully baked and much to my shagrin, a lot of really work put on it has been deferred until Swift 4 which was fair enough. I feel like already maybe they tried this stuff too many new features and not enough cooling down time in Swift 3 but you will find now, it’s very difficult. For example, it’s very difficult in Swift to have a list of different things, it’s difficult to have a function that gives you the number of items in a list without knowing what it’s a list of.

That’s possible but add one more wrinkle and it quickly becomes either impossible or you have to just sort of cast to any and work backwards. Go if you’re interested, look at the Swift evolution discussion around existentials and generic types. Lots of work going on around existentials and generic types, lots of interesting work going on right now and it’s going to have to go through a similar period of iterative, proposing, vetting, trying it out in practice and recalibrating and that’s the work in Swift right now that I’m most excited about.

Rod: Very cool. You mentioned the protocol dispatch versus dynamic or static in the last episode. I’m very glad that I read that because I ran through that problem three or four weeks later. “Wait a minute, that’s what this is. Oh my word, this is insane.”

Paul: It is and it makes a lot of sense. There’s a good rationale behind all of it but lack of compiler warnings plus the expectation that Swift sets up that if you’re doing things by default, that’s probably safe, this is something that kind of violates that expectation. The blogpost question is I believe it’s called The Ghost of Swift Bugs Future by Alexandros Salazar. Good read, every Swift programmer should at least skim it and know what that problem smells like.

Rod: You will read it eventually even before you encountered this problem.

Paul: Exactly.

Charles: Alright, let’s go ahead and push this to picks. Jaim, do you have some picks for us?

Jaim: Alright. I’m going to do one pick. It’s a documentary, it’s on Youtube, it’s 10 years old I think probably 2005, 2006 it’s on BBS. I realized this week what BBS is. I asked someone somewhat younger generation, “Do you know what BBS is?” He’s like, “Oh yeah.  “Oh no.”

Paul: No.

Charles: Broadcast all that British all over the place.

Rod: That’s what everyone was doing in the 80s, just downloading stuff from the BBS.

Jaim: Not quite. Bolts in boards system was the way people with computers talk to each other before there was an internet. There’s a BBS the documentary. It was just done. I think it was basically put up by one person or a small group and it’s got six episodes. It gets a little verbose at times but there are some of those that are good and if you’re out of time or curious about how people hunt for bears or us as younger or as a teenager communicated and shared data before there was Facebook, Snapchat and all that. We got a modem when we call some other guys some other persons have computer and we upload data. This kind of talks about the people that started it starting from the 70s people that brought up the first system to the 80s. There’s six episodes. You don’t need to watch all of them. The first one is really good. The second one is pretty good. That one with the hacking and freaking, that’s pretty good. The rest, you don’t watch it but I don’t really think that you need to spend 45 minutes listening to people talk about FT artists fighting amongst each other but you might. That’s my pick. BBS the documentary on YouTube.

Paul: Good stuff.

Charles: Awesome. Rob what are your picks? Rod. Let me back that up, Rod what are your picks? Maybe he didn’t hear me.

Jaim: Is he muted?

Charles: Maybe.

Rod: Can you hear me now?

Charles: Yup.

Rod: Alright, I have one pick and it’s from Uncle Bob himself, he has a site called cleancoders.com and on there he has lots of videos that teach programming concepts and design and what not and he just published a mobile app study which uses Swift with TD and dependency injection, and clean architecture and all the goodies. Check that out.

Charles: Alright sounds good. I’ve got a pick really quickly and that is I’ve been reading a book called The 12-Week Year and it’s a book basically outlines productivity from the standpoint of a lot of people set yearly goes for their business with their team or whatever and what winds up happening is that last quarter of the year they wind up kind of sprinting ahead to try and achieve whatever it was that was their goal and so what they basically point out is that if you have a 12-week year, then you can just do this every quarter of the year and make your goals happen and then what happens is all that work that happens that fourth quarter to get your goals done, you have that happen every quarter and you get basically a year’s worth of work done in 12 weeks.

Anyway, it’s really interesting and I love the way that they organize everything. A lot of strategies and stuff in there so if you’re running your own business or running a team and trying to figure out. Okay, how do we think about where we’re headed now we have a vision for what we’re going, how do we get there then this is a terrific book. Paul, what are your picks?

Paul: I’ve got a whole cornucopia here. First, I just want to recommend if you’re migrating or if you’re going to migrate to Swift 3, Erica Sadun has a book on Swift 3 migration I think it’s called Swift  From Two to Three. Full of just really useful arcane stuff that’s important. A good overview of everything you might encounter in the whole process. I think it’s good stuff. I had a chance to see some of the drafts since she was editing it and gave feedback on it as I was doing Swift migrations and even just reading her drafts as I was working myself, I found useful information in there. Go check it out it’s in e-book.

Second, I have a pair of links, if anybody is interested in Math, I found a really good article on how do we teach Math especially how do we teach Math in elementary school and how much Math is really about creativity, exploration, problem solving, and how you can bring that as a parent or as an educator into Math education. It’s a topic that is near and dear to my heart. This New York Times post about it just really laid out some good concrete stuff. If you’re interested in that topic I also highly recommend the classic essay called Lockhart’s Lament which is much grander, more poetic and thrill ra ra sort of treatment of the same thing and if you’re somebody who just has always sort of cringe at the idea of Math, read Lockhart’s Lament at least the first page. I think it’ll imagine how you imagine Math is. The truth is that a lot of us who got turned off Math in K-12 education have never even done Math. We’ve done rote computation which is not fun. Lockhart’s says in his essay, “Students say Math class is stupid and boring and very often they are correct.” That pair of things is the second pick and third.

There was a really beautiful documentary, this is much heavier stuff but worth checking out if you want to get your head out of some codes and into the world we live in. There was an amazing short, maybe 15-minute documentary called If I Sleep for an Hour Then 30 People Will Die about somebody who was forging identity papers in Nazi occupied France, really just a riveting thing and in the post there’s a news article that goes with it that it’s worth watching the video. If you’re interested in that topic and things happening today along the same lines, there was an article about somebody in France today helping smuggle people to Europe, whether that”s ethical, it’s clearly illegal, should he be arrested for it? Go check out that documentary. It certainly left an impression on me.

Charles: Alright, very cool. If people want to follow up with you, see what you’re doing or I think you mentioned you’re a freelancer, hire you, where should they go?

Paul: If you’re looking to hear me pontificate and rant, I’m on Twitter @inthehands which a name taken from my piano world but now has sort of become piano and code stuff. Twitter, @inthehands. If you’re looking to hire me, you should talk to Bust Out Solutions or tweet me directly though I refer most client work to Bust Out. If you have a particularly difficult, tricky Swift question and you just want me to do a sort of SWAT  team counsel, I’d be happy to talk to you and for that you should reach me on Twitter but if you’re looking to get a whole project built then the folks at Bust Out, really good people, great designers there, and just straight shooters who do nice job with everything they do. That’s why I choose to work with them. So, those two contact points.

Charles: Alright, well thank you for coming. We’ll go ahead and wrap the show up and we’ll catch everyone next week.

Paul: Thanks for having me on. It’s been a pleasure.

Jaim: Yeah, thanks Paul.

Charles: Thanks Paul.

x