The panelists discuss functional Swift with Michael Dippery.

 

Hey everybody and welcome to episode 67 of the iPhreaks Show. This week on our panel we have Alondo Brewington. 

 

ALONDO: Hello from North Carolina. 

 

CHUCK: Pete Hudson. 

 

PETE: Hello from Sutro Tower. 

 

CHUCK: I'm Charles Max Wood from DevChat.tv and this week we have a special guest, Michael Dippery. 

 

MICHAEL: Hi! Hello, from San Francisco. 

 

CHUCK: Do you want to introduce yourself really quickly? 

 

MICHAEL: Sure. I gave a talk at ThoughtWorks a couple of weeks ago about functional programming and Swift. It came about because I'm actually working on a book for Wiley Publishing about Swift, which came about because I had been writing a book for them on the Objective-C runtime, and unfortunately, that got cancelled back in June when Apple made a surprise announcement about a new programming language. [Chuckles] So we shifted focus and I'm both learning Swift and writing about it at the same time, so that's pretty exciting. I mean I've been doing Objective-C for about ten years now, mostly for some open source projects and things of that nature; mostly Mac development, but I've done iOS for a couple years now. 

 

CHUCK: Very cool. You mentioned functional programming in Swift, do you want to kind of give us an introduction or a place to start? 

 

PETE: I think maybe a good place to start is what do we mean by functional programming or what's our working definition of functional programming. 

 

MICHAEL: Sure, yeah, I think that's probably the best place to start. I think functional programming is one of those things where a lot of people have a different idea on what they mean. It's good to be on the same page for it. When I talk about functional programming, I'm talking about a paradigm on which you design or structure a program such that the function is the smallest unit of computation, similar to - maybe in contrast to object-oriented programming where an object is the smallest unit of computation. If you're really doing functional programming then you think at the level of the function and the program is basically modeled as the composition of functions and the data flows through that function composition. 

 

PETE: So pretending to be someone who doesn't know anything about functional programming, I don't know a lot but I know more than nothing, are there objects in this world? Like do you have - where does stuff live? 

 

MICHAEL: Well you know there are languages that will combine both object-oriented and functional programming. I would say, generally, data is represented usually as – well, not as objects. I guess I'm trying to find the best way of putting this. I'm trying to avoid using the word primitive types, but there'll be more primitive type like integers, or numbers, or things like records, or similar to structs that you'd see in C, like smaller collections, and there's not going to be methods directly associated with a class or a function. In a really good functional language you have things like type in [inaudible] and all sorts of very rich types of systems so that a function might essentially take a wide-range of different types to operate on. 

 

CHUCK: Can't you blend them so you have both objects and functions? 

 

MICHAEL: You can. There has been some languages that have taken that approach. Scala's a pretty good example. OCaml is probably the really classy example of blending object-oriented and functional programming. Swift, of course, blends it to a degree as well. You have classes and structs and objects in Swift as well as top-level functions. 

 

PETE: I think when Swift first came out, when it was first announced and led to you cancelling your book, one of the things I heard from a few folks was that the language that reminded them of the most was actually Scala, which was a little surprising to me because I just didn't see the folks at Apple being into that kind of language. Do you agree with that? Does that feel like there's a lot of Scala type things in Swift? 

 

MICHAEL: I think you can find some connections between the two. The thing about both Swift and Scala is that they're heavily influenced by preceding languages, so there are definitely some common influences there. I don't know if I'd say that I see tons of similarities. Partly if Swift is like Scala, I would say it's probably more of like a watered-down Scala. Scala's type of system is kind of crazy and even difficult to understand a lot of times. The language itself just has tons of features in it. I think Swift is - if there is a comparison to be made between it and Scala, I would say that Swift is a little more stripped down and focuses on some key features. Of course it still has tons of language features and more so than Objective-C, but I think the only similarities between it and Scala is that it has objects. It also has some functional elements and it's a statically-typed language. 

 

PETE: Yeah, I was going to say that that to me is where the similarity comes from is that kind of hybrid thing where, I guess I would probably say Swift is more of OO and Scala is more functional but they're both kind of sitting in the middle and you can use either style. Well, you can try and use either style of both and yeah, they're both - the static typing is definitely where a lot of the similarities come from as well. It's not like a Lisp or something like that where you can't do some of the impressive gymnastics that you can do with Swift and with Scala. 

 

MICHAEL: Right. Yeah. 

 

ALONDO: So would you say that one of the functional aspects of Swift is linked at solving different types of problems than we could solve previously, or are there just more things available to you and you can still work on a wide array of subjects? 

 

MICHAEL: I think it gives you more options. One thing I've noticed about Swift that's kind of cool is I think because of its versatility that it has objects and has OOP but also its functional programming features, I think it just offers different ways to approach a problem that might be better for that specific problem domain or better for the programmer writing the code. Over the years, I've gravitated much closer towards functional programming and I tend to think about solving problems in a more FP style. Of course, Objective-C was very, very strictly an object-oriented language and so when you're constructing programs and thinking about how to solve problems, you have to do it in an object-oriented way. I think Swift just offers an alternative. That said, there are some problems that I think will lend themselves better to functional programming and some that lend themselves better to object-oriented programming. 

 

CHUCK: One thing that I think is interesting about what you're saying though is that – I've done a little bit of functional programming in strictly functional programming languages like Clojure and Scheme in particular, and when you say you solve something in a functional way, the thing that jumps out at me is that whenever I encountered a problem in any kind of Lisp, Common Lisp, or Scheme or anything, it's like, "How am I going to solve this problem? Oh, I know, I'll take this list and I'll solve it with recursion," and then you know, the next problem, "Let's see. What other tools? Recursion!" And you know that's kind of the common thing and it kind of can grow out a little bit to where you get some kind of intelligent iterator so that you don't have to get the list so that it's, "Okay, operate on the first thing on the list. Now operate on the rest of the list." You know, you just iterate and you just get each thing in the list, which is essentially the same thing, but it's just kind of interesting. Is that the direction that you're talking about with functional programming in Swift? Is that kind of problem solving where you iterate over a collection or a list or are there other aspects of functional programming that you take advantage of when you write Swift? 

 

MICHAEL: Well, I think that's part of it. Certainly a lot of functional programming that I think is thinking very much in terms of lists and operations that apply to them and it turns out that that covers quite a few problems that we solve in programming. I think Swift offers some other styles for things. One example I used in my talk was about JSON parsing, which of course nowadays is, what program doesn't do JSON parsing? At some point, almost all of them. There are obviously plenty of libraries to do that for object-oriented languages. There are some interesting things that you can do though with using some of type systems features on Swift, particularly with its Enums to model a JSON document. That's interesting, but you also get into some other ways to design graphical programs. There's reactive programming, and particularly functional reactive programming, that offers a different way to model how UI works, how UI controls interact with each other. You could do that reactive programming style; in Objective-C there's a library called React Cocoa, I think. 

 

PETE: Reactive Cocoa. 

 

MICHAEL: Reactive Cocoa – to allow you to do that. I was actually at a talk the day after Swift was announced. I was at a mini-conference at GitHub about Reactive Cocoa, and of course the talk ended up much more about Swift and how Reactive Cocoa might be able to utilize some of the features of Swift. So there are some interesting ways in which you can use Swift to just completely change a lot of aspects of how you would design Mac or iOS apps. 

 

PETE: I think one of the big things, beyond just the recursion and everything, the Lisp type things that you get from Clojure, is not having shared a mutable state that really allows you to pare down how much of the program you have to hold in your head at one time. So if you've got these pure functions or something approaching a function where you give it some input and you get some output out, you just have to think about function in isolation; you don't have to also hold in your head, "Oh and then also interact with this other thing, which then does this thing over here, and then after that's happened, I have to think about the consequences because things aren't messing with the world," and it's just kind of a pipeline of changes flowing through a set of functions. You don't have to hold as much of the world in your head at once when you're trying to solve a problem. That's what I find really nice about that functional style is not having to - my brain is not very big so being able to not have to hold that much of the program in my brain at once means I can be more effective as a programmer. 

 

MICHAEL: Yeah, I think that's a really big aspect of it too. I mean when you're doing objectoriented programming, it's kind of the opposite. A lot of your program, a lot of your design, is towards managing state and controlling access to the internal state of an object. Especially anyone who's done Objective-C programming before properties came about knows that that was kind of a pain when you had to write accessors and mutators by hand, just controlling all of that stuff – access to the instance variables and that sort of thing was a lot of work, was also very error-prone. Properties made that a little bit nicer but it was still error-prone. Part of the reason I really like functional programming is for the reason just said that you try to avoid using mutable global state. In doing so, it occasionally makes something a little bit more difficult but I think it's easier to think about and reason about a program as a whole. I think it also lends to individual functions being more composable and reusable. I think it makes it easier to write test cases and things like that as well. That's why I'm a big fan of it. 

 

CHUCK: But can you get into situations or get into trouble where you are actually dealing - I mean, you're in the system that has objects in Swift, and so can you get into a situation where you actually do trigger some side effects within your function? 

 

MICHAEL: Oh, yeah! Definitely! I mean you know there's of course functional programming languages like Haskell for example, that make it much more difficult to do that sort of thing. Swift doesn't really make a lot of guarantees that - I mean you can still use global variables and global state and classes and all that kind of stuff. I think, Swift – it gives you the tools to, if you want to be disciplined and you want a more functional style to be an option, you can certainly go in that direction, but the language itself doesn't really afford a lot of guarantees that you're not monkey-ing around with a global state or mutable variables or anything like that. 

 

PETE: I guess that's kind of a trade-off between – the nice thing about having a hybrid language like Swift or like Scala is you can dip your toe in the water and you can kind of use functional style where you think it makes sense, or you can maybe fall back to an OO style if that's what you're more comfortable with, rather than, say, in Haskell, where you're all in. Haskell will actually close you for that matter, like you have to just embrace the functional style. With these hybrid things, you get to pick and choose, but the flipside is you lose some of those guarantees because you could be mutating stuff that's passed in for example. You lose that guarantee like, "Oh, I don't have to think about anything apart from this function." 

 

CHUCK: That's true but at the same time the crossover is nice because if you just treat your objects like values and you can avoid triggering the side effects, then in a lot of cases the functional approach really works nicely on lists and other values like that, where you can almost think of it as a mathematical formula or function that you put a value into and you get a value back out of. 

 

PETE: Yeah. Gary Bernhardt has this thing about Functional Core Imperative Shell, this idea of kind of having functions in the inside of a system or a module or whatever and then a kind of a more OO interface to the outside. And from doing Scala, that tends to be what happens with our code. The internals will certainly have objects on the large where it's an OO program, but in the small – inside of the implementation of each of those objects, it tends to be very, very functional, and those objects are almost always immutable. It's this weird kind of hybrid which we didn't plan on doing, but we've discovered that our most comfortable way of doing Scala is to have objects, but their kind of immutable objects that are return copies of themselves and the internals of how they do that is using functional styles internally and not really using private methods or anything like that. I suspect that given the similarities between Swift and Scala, I think a lot of Swift programmers will move towards that style where they'll have OO properties in the large, particularly when you're interfacing with obviously all of the UI kit. All the existing libraries that are out there are OO, so you kind of need to embrace OO at some point, but the business logic inside of the application I could certainly see it becoming a lot more functional. 

 

MICHAEL: I wouldn't be surprised if that's the style that gets adopted. I think it works a lot of cases because pretty much all the existing code out there is object-oriented in style. I mean, the only time you don't have OO code in Mac or iOS programming is if you're interfacing directly with the C stuff, which is kind of a rare case nowadays; it doesn't happen that much. I think that's probably the path that Swift will take, at least in the beginning. It's going to be a long time before you could go like strictly FP. 

 

PETE: I'm interested to see how things like Reactive Cocoa work with Swift because if you go down that road then you really could take a very, very functional style with your whole program. I think Reactive Cocoa plus Swift would let you be very functional from the UI down, but then I'm not sure whether there's anything out there today that would let you do things like Network Traffic or Persistence in like a functional style. Yeah, I'm not sure if there's anything that’s there today to do that. 

 

MICHAEL: Yeah, I don't know. There's a thing called PromiseKit; I think is written by Max Howell, who also did Homebrew. I think he's been experimenting with doing that in Swift – that's more of a promise library, of course, as its name suggests. I don't know how far along he's gone with that and I don't even know how widely-used that library is. But it is interesting to see the direction something like that might go to. 

 

CHUCK: Yup. Are there particular classes of problems that don't lend themselves well in Swift to be solved with a functional approach? 

 

MICHAEL: I think a lot of the UI stuff. It's very much geared towards an object-oriented style and Cocoa Touch and Cocoa right now. Things like table view sources and stuff like that is set to be still a very OOP style. 

 

CHUCK: Is that because of the design of the library, or is that due to something else that's inherent in the language? 

 

MICHAEL: I would say probably the design of the library. A lot of the elements of the UI code are still heavily rooted, not only in Objective-C, but in –. In the late ‘80s, early ‘90s when OOP was sort of really getting a lot of momentum and there were a lot of best practices and things like that only being established. The next engineers were definitely very good at designing their libraries but it was very geared towards Objective-C and of course, Apple continued that trend when they adopted those libraries and built on top of them, and extended them, and added different things. I don't think it's necessarily something that's a deficiency in other paradigms. It's just there's thirty years, twenty-five years of work behind a lot of that code so that's the prevailing style right now. 

 

PETE: If you think about it, a lot of UI is about shared mutual state, like a form that you fill out on a page is shared mutual state, so I think maybe that's why it lends itself more to a OO style is you have kind of like a blob of stuff with some state in the UI and then you represent it in code with a blob of objects with shared state. Maybe that's part of what's led everyone to do things more of in an OO style. 

 

MICHAEL: Yeah, I mean Smalltalk's firmly rooted in that. I mean Smalltalk really came about in an attempt to build a graphical interface to computers and so Objective-C of course builds on that, and I think UI programming does lend itself really well to an OOP style. I mean you can do other styles – functional reactive programming, as we mentioned, but I think most people doing UI are probably more comfortable with it in object-oriented style. 

 

PETE: So we talked about kind of some of the stuff about Swift and some stuff about functional programming in general. What specifically is there in Swift in terms of language features that allows us to do to kind of call it a functional language, or at least as a hybrid language? What makes it functional? 

 

MICHAEL: There are a lot of things that at least allow to move towards that style. For one thing, at least in comparison to Objective-C, it has static types and pretty decent type inferencing system. That is something that can figure out what types are variable without their programmer having to annotate all of them like you would in C or Java or similar languages. It's not necessary in a functional programming language, but a lot of them use that style. There are a lot of other things that have been added to it; they have option types now. Before, you had to deal with no pointers and all that stuff, which obviously led to a lot of problems. Swift designers pulled in optional types, which are heavily influenced by languages like Haskell and Scala and several other ones. 

 

PETE: Can we dive into that a little bit? Because I think folks who haven't used one of these languages before, it's a fairly weird concept I think – the idea of an option is a fairly weird concept. 

 

MICHAEL: It is a little bit weird. It's definitely kind of cool, though. The problem that it approaches is that sometimes you have a variable and it might not have a value. In a language like C, or Objective-C, Java, we can set those values to null, but of course this causes problems if you dereference the null pointer in C then your program will crash. Java, if you call a method on a variable that's actually null, you get a NullPointerException. Objective-C's really weird in that you can't call methods on null pointers and then just nothing happens. This causes a lot of problems, and I think there's been a quip about one of the guys that first implemented a null type and called it his billion-dollar mistake. So Swift gets away from [inaudible] is that if a variable can take no value then it's actually set to a type called non - is the terminology they use. You have what's called algebraic data type where a value can be something or nothing, but unlike a null pointer, the language actually forces you to deal with cases in which you have no value, in which you're dealing with non, so you can't call a method on a pointer that's actually non, for example. Well technically in Swift you can force that to happen, but you have to very explicit about it, but for the most part, you can't. If you have something that might be non, then you have to deal with a case in which it's non, unlike in Objective-C or C where you could have a null pointer and not have to actually do any check for the compiler doesn't force you to check if something's null or not. 

 

PETE: And the flipside of that is once you've got a non-optional type, something that you've kind of taken out of this box, you don't have to worry about whether it will be null, right? Like once you've done that check and now you can pass this thing around and say with certainty, “This is never going to be an empty value; this is never going to be null.” I know for a fact that at compile time, this code doesn't have to deal with that case so you can guard things on the outside of the program and then on the inside you don't have to keep worrying about whether something will be null or not. 

 

MICHAEL: Yeah and similarly if you want something to be able to be null, you have to explicitly specify that in Swift. In Objective-C, for example, any pointer can be null or nil. In Swift, you have to explicit if you want something to actually be null, and by default things can't be null. 

 

PETE: So optional types is one thing that Swift has. I'm going to get up on my high horse for a second and take a micro rant. It really annoys me that they built this into the language rather than just having it as a library. That boxing/un-boxing thing where you can say like, "I want this value. Take this value out of this optional box so that I can work with it." That could have just been done as kind of a library or as a function, but instead they've added syntax to the language, these question marks and bangs. That makes me sad because I think they could have done it - if they'd have done that just with methods or functions then A, it would be a smaller language which is easier to learn, and B, people would get used to the idea of monads, and yes I said the word monad. [Laughter] There you go. Micro rant over. 

 

MICHAEL: No, I'm inclined to agree a little bit. I've gotten some flak from some other Swift people for taking that same position, but I stand by it too for the reasons that you outlined. 

 

PETE: Yeah, it's a shame because if you start to see that there isn't really a difference between a

thing that might have a value or might not and a list of things, for example, then you can start using a lot of the same patterns that you used to transform things in a list, that you can then start using that same approach to transform maybe a string into maybe a person, into maybe a person's cash balance, or something like that, but anyway, I have a feeling I could go off on a terrible tangent if I keep talking. 

 

CHUCK: [Chuckling] 

 

PETE: So what other features in Swift as a language that make it fun or useful from a functional point of view? 

 

MICHAEL: I think their addition of Enums is pretty cool. They're not Enums like you would find in C; they're a little bit richer in what you can do. They're similar to the idea of algebraic data types from a lot of functional languages, which algebraic data types are composite data type, not in the same way though like classes or something like that or also composite data types. It's more like you have a single umbrella type that can actually be several different things. A good example would be, you might have a numbered type and that could actually be an integer or a float or a complex number even, but you might have functions that can work on an integer or a float so they take in this composite type called a number, for example. I'm speaking theoretically here; I don't think Swift actually necessarily does it this way. And then addition can be done on both floats or integers so you wouldn't necessarily need two distinct functions to do that, and that's kind of cool. A lot of times it will, without breaking data types you can do some things like pattern matching on them, which allows you to write some pretty concise bits of code to deal with what's actually a wide-range of types. The example I gave in my talk was dealing with JSON parsing. In JSON, you have numbers, strings, Booleans, arrays, dictionaries, and null values, and these are all conceptually similar. They're basically a JSON value, but you would interact with them in slightly different ways. I gave an example of how you could write a pretty concise function to provide a string representation of these values, so I think some features like that are pretty cool. And there's a bunch of other things in Swift. Functions are first class values now, so you can pass them around just like any other data type, which means you're going to have higher order functions which are functions that take functions as arguments and return functions. Similarly, you have closures now, which we sort of had in Objective-C with blocks, but blocks were incredibly ugly to use and had a terrible syntax, so now closures and things like that are a lot easier to use in Swift. 

 

PETE: Yeah, I think those two kind of properties, the first class functions and closures, are going to make iOS programming using Swift way more accessible to JavaScript programmers for example, who, for them, that transition from JavaScript to something static and kind of clunky like Objective-C, is a really painful transition. But through the right lens, I think Swift can look a little bit pretty similar to JavaScript even though they're actually quite different under the covers, right? Like one's dynamic, one's static; one's compiled, one's interpreted – all that kind of stuff. Actually if you kind of squint and look at some Swift code, it does look a little bit more like JavaScript. 

 

MICHAEL: Yeah, it definitely bears more of a resemblance than Objective-C did. It’s actually kind of funny to me -. 

 

PETE: That's a low bar, right? [Laughter] 

 

MICHAEL: Yeah, and there's not a lot of things that look like Objective-C. 

 

PETE: Right. 

 

MICHAEL: No, I'm actually kind of –. It's a little bit humorous to me that Objective-C caught on in such a big way. When I started doing it about ten years ago it was - there were a couple of books on it and some mailing lists and that's about all the help you got for it and then there was a period of time when I was in grad school and I was doing other things in life and didn't do a lot of Objective-C. And then when I

came out, it went from being a thing where no one even knew what Objective-C was to everyone was an Objective-C programmer. It's still kind of humorous that it caught on since it's so weird and so much different than a lot of other language. But Swift is a lot more like what I think a lot of modern, current programmers are going to be familiar with. 

 

PETE: I think one of my favorite things – the two favorite things for me about Swift in the context of functional type things is the option to declare a variable as not variable. So the let-syntax where you can say, “This is something that is this number is 12 and it will always be 12; I don't have to think about that anymore.” It's always going to be 12, so that immutability is built in to the language. I think, again, means you have to hold less stuff in your head so I'm really pleased they added that. The pattern matching, the immune stuff with the pattern matching, I think is super, super cool. It's just like one of my favorite features of languages like Erlang or like Scala – that ability to kind of really easily pull stuff out of the middle of an object. It's actually one of the reasons I really liked CoffeeScript as well. It means you can do that like super succinct, really terse programming that's not hard to understand. It's just very, very clear what you're doing but you don't have to spend so much boiler plate code typing to pull something out from something else. 

 

CHUCK: Yeah, the first time I saw pattern matching in Erlang, it totally blew my mind. I was like, "You can do that?!" 

 

PETE: Yeah, and I think it's interesting, actually, I never really thought about it until we were talking about it just now, but pattern matching, in a way, is how you do – and the abstract data type –. Sorry, I always call it abstract data type. Is there a difference between algebraic data types and abstract data types? I never really understood whether there's a difference or whether it's just me misremembering what they're called. 

 

MICHAEL: Yeah, I think abstract data type is more like if you're talking about queues or lists. 

 

PETE: Gotcha. 

 

MICHAEL: Like if you have a list, you're going to have a concrete implementation of it, like linked list or something like that, or array list, or whatever, but list would be like the more abstract way of talking about it. 

 

PETE: So yeah, I think, in a weird way the pattern matching and algebraic data types is how you get polymorphism when you don't have objects, right? Because you can say, "When it's this type of thing, do this. When it's type of thing, do this other thing," and you still get the ability to just pass something to a function and say, "Do stuff differently based on what I'm passing into you." 

 

CHUCK: Yup. 

 

MICHAEL: Yeah, it will let you do some pretty very OOP-like stuff and still within a functional programming paradigm. 

 

PETE: I definitely encourage folks who are listening to the podcast and not sitting in front of a computer, or even if you are, go and look at the slides from Michael's talk or go and find an example of how the JSON parsing stuff works, or the JSON serialization stuff works, because it is a really -. I think it's kind of like the "Hello World" of pattern matching in Swift, because I've seen it crop up in three or four different places now, but it is just a really elegant example of how you can take advantage of that language feature. It's amazing; you can basically do JSON serialization in 30 lines of code. 

 

CHUCK: Cool. Anything else we should talk about on this topic? 

 

MICHAEL: I think we covered a wide swath of material in the 50 minutes that we've been chatting. There's definitely like a lot of really cool stuff with Swift. I mean it's probably something I could probably go on and on for hours, but I guess I'm actually putting it in several hundred pages of a book, instead. It's definitely a cool language, although it made me have to start writing a book again from scratch, it was definitely cool announcement from Apple and I was pretty excited by it. 

 

CHUCK: So when does your book come out? 

 

MICHAEL: There's not a hard date. The original Objective-C one was going to be in January or early February, and now the date's a little fuzzy since we had to start working on it again. I'm guessing probably like late February or March of next year. It's kind of funny. I'm working on - there's two being worked on by Wiley. One's like a beginner's Swift guide and that will be out sooner. Mine's more of the intermediate to advanced which makes me chuckle a little bit because I don't know if there is anyone that's an advanced Swift programmer yet since the language is two months old. 

 

CHUCK: What are you talking about? I've been doing it for ten years! 

 

MICHAEL: Yeah, we're going to start getting those recruiter emails, right? Five-year Swift experience. 

 

CHUCK: That's right. 

 

MICHAEL: Hopefully by March there'll be some advanced Swift people that want to pick up a book on it though. I think that's probably when it will be coming out. 

 

CHUCK: Nice! All right, well let's go ahead and get to the picks. Pete, do you have some picks for us? 

 

PETE: I do! I have three picks today. My first pick is The Flux Architecture. So this is something that came out of Facebook recently announced this kind of UI framework called React which is more of 

JavaScript thing, but backing that, they also talked about a more general kind of architectural principle that they've been using apparently with great success on Facebook called Flux, or they're calling it Flux. And the reason I'm picking that today is because it talks a lot about how to model UI programming in a different way to the kind of classic MVC. Rather than two-way data bindings which feels more like a good fit with OO, they talk about you need uni-directional data flow, which actually lends itself quite nicely to a functional style attitude, and also to a kind of a functional

reactive style. Now they have a lot of really good documentation, and in the show notes I'll have a

link to their overview of Flux. They also have some really good presentations from some of the Facebook engineers talking about the problems they were having with the kind of traditional way they were approaching UI development and the way that they kind of discovered this architectural pattern and how it's been helping them so that was really interesting. I just read about that the other day and kind of got excited about stuff again, so that's my first pick. My second pick is Swift Code Golf. So we had another little meet up at the ThoughtWorks office in San Francisco the other day, and a guy called Tom Brown came by and introduced us to this game called Swift Golf and it's a really cool idea. It's golf - it's code golf, like you have a [inaudible] or whatever, so it's trying to solve a problem. In this case, get a unit test passing with the minimum amount of characters of production code, so it was really fun to do. It made me realize how bad I am at Swift and it's also

interesting because almost always the most succinct way to solve these problems is using a

functional style, so I'll add a link to the show notes with the GitHub repo and you can just clone that and follow the instructions and play along at home and see how low a score you can get or high score, whatever. And my third pick is a beer because I haven't picked a beer in a while. Last night I had the pleasure of drinking of a Free Wheel English-style IPA on cask at my local pita joint, and that was really good. It's kind of pretty close to a British style of IPA and when you get it on cask, nice and warm and flat like the English people like to drink, it's actually enjoyable. That's my picks. 

 

CHUCK: All right! Alondo, what are your picks? 

 

ALONDO: Okay, my first pick is the Elleven Amped Checkpoint-friendly Compu-backpack. I got a new back pack to make it a little bit easier to travel. I've got a lot of travel coming up in the fall and one of the frustrations is my current backpack. I'm always trying to pull out the laptop when I go through the checkpoint and now I have a new one that allows me to just fold it open and easily slide it through when I go through the TSA checkpoint. Second pick is along those lines. The fraying of the power cord has always bothered me, so one of my colleagues introduced me to the Quirky PowerCurl, which is a clip-on cord wrap that prevents the cord from fraying and will save me a lot of money from buying replacement power cords. This leads me to a final pick which is Amazon Smile. I'm late to Amazon Prime and I was introduced to it very recently when I started ordering all these things, and I discovered Amazon Smile which makes donations of half a percentage point to the charity of your choice. So I am using Amazon more as a way to also streamline delivery to my house but also to find a small way donate to charity more. Those are my picks. 

 

CHUCK: Awesome. I've got a couple of picks. I'm just going to pick a handful of books. I know that some of our listeners are freelancers. I think honestly that several of these books are books that everyone should read. Basically they're kind of - I hate to say self-help because you always get the kind of the stereotypical crap, but these books really were kind of inspiring and I really, really enjoyed them. I listened to them on Audible, but you can actually go and pick them up on Amazon or whatever, eBooks. They're all pretty short books. The first one is called Rhinoceros Success, and basically it talks about picking a goal and charging at it and achieving it – kind of like a rhinoceros. If you try and charge at too many things, you're not going to hit any of them, but if you go out there and you succeed –. And yes, the metaphor in it is kind of taken a little bit too far, but the overall principle is awesome and I really enjoyed it. The next one is called The Go-Getter, another really short one. It's actually shorter than Rhinoceros Success. Rhinoceros Success is the longest one and on Audible it's an hour and a half to listen to. The GoGetter is kind of a parable or story with a purpose or moral or whatever you want to call it. It just basically goes through, and you follow this character; he goes way out of his way to achieve something and really kind of defines what a go-getter is. Finally the last one is QBQ! The Question Behind the Question, and that one's about personal responsibility and I really found it inspiring as well. So I'm going to pick those three books. Michael, what are your picks? 

 

MICHAEL: I got a few. You know I've been doing a lot of writing for the past few months so I've become a big fan of a couple of information architecture products – Writer and Writer Pro, namely, which have pretty stripped down UI for writing that lets you get really into writing without worrying about formatting and all the other junk that comes with word processors, but still offers a pretty good number of tools for damage in writing and hopefully writing more efficiently, so I'm a big fan of both of those. I've been a big fan of the Reeder RSS client for several years. I've been using it on the iPhone for about four. It's a great client if you're really into or if you still subscribe to RSS feeds or Atom feeds, which I do. I use it with the Feedbin service since the demise of Google Reader last summer, and it really lets me keep up with all the blogs and stuff that I've subscribed to over the years. Finally, since we're on a podcast show, Marco Arment finally released Overcast a week or two ago and I just loved it. I got the day it came out and I think it's great for listening to podcasts. I think he did a

really great job with the UI and I definitely like it more than Apple's podcast app and even some of the other ones out there, so I'm a big fan. 

 

PETE: I think the super classy thing that he did as well is in the help or the settings or something, he said if you don't like Overcast that's fine. Here's some other one made by indie developers that you might want to try instead and he included links to all of his competitors, which is pretty classy. 

 

CHUCK: That's pretty cool. Awesome! Well, thanks for coming Michael. It was really interesting to talk about and hopefully we'll get a few more people trying out Swift and seeing what it's capable on the functional front. 

 

MICHAEL: Yeah, thanks for having me on the show. It's always exciting to talk about Swift. 

 

CHUCK: All right, if people want to get a hold of you, what's the best way to do that? 

 

MICHAEL: You can email me at michael@monkey-robot.com or you can try to get a hold of me on Twitter. I'm @michaeldippery.

I'm somewhat active on there. I don't use Twitter as much as other developers in San Francisco, but either one of those ways is pretty good for reaching me. 

 

CHUCK: Cool! Well, we’ll wrap up the show. Thanks again for coming, and we'll catch you all next week. [Work and learn from designers at Amazon and Quora, developers at SoundCloud and Heroku, and entrepreneurs like Patrick Ambron from BrandYourself. You can level up your design, dev and promotion skills at Level Up Con, taking place on October 8th and 9th in downtown Saratoga Springs, New York. Only two hours by train from New York City, this is the perfect place to enjoy early fall at Octoberfest, while you mingle with industry pioneers, in a resort town in upstate New York. Get your tickets today at levelupcon.com. The space is extremely limited for this premium conference experience. Don’t delay! Check out levelupcon.com now] [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net] [Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more] [Would you like to join the conversation with the iPhreaks and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at iphreaksshow.com/forum]