052 iPhreaks Show - Book Club: Functional Reactive Programming with Ash Furrow
This Book Club Episode features Ash Furrow, who wrote the book, Functional Reactive Programming.
CHUCK: We are here to talk about a book. Did somebody write a book? ASH: I've written a book. [Laughter] BEN: I believe we’ve read the book, so I think we’re in good shape. CHUCK: Hey everybody and welcome to episode 52 of the iPhreaks Show. This week on our panel we have Ben Scheirman. BEN: Hello, from Houston. CHUCK: Jaim Zuber. JAIM: Hello, from Minneapolis. CHUCK: Andrew Madsen. ANDREW: Hello, from Salt Lake City CHUCK: I'm Charles Max Wood from DevChat.tv and we have a special guest this week, Ash Furrow. ASH: Hello, from Amsterdam. CHUCK: Do you wanna introduce yourself really quickly? ASH: Sure, yeah. I'm a Canadian iOS developer who previously lived in Toronto. I've worked for a couple of startups including 500px and now I'm working for Artsy in New York. CHUCK: In Amsterdam. ASH: Yeah, from Amsterdam, in New York. I'm going to be moving there in 11 months, so. CHUCK: To New York? ASH: Yup. CHUCK: That’s kind of interesting. Did you just move to Amsterdam just for the heck of it or –? ASH: Yeah, that’s pretty much it. I met Mike Lee at a conference over the summer and he said it was a great place to be and I should come and stay for a little while and that’s what I decided to do. CHUCK: Cool. ASH: Yeah, yeah. It’s nice here; there's a fantastic developer community. I'd highly recommend it if you can come. ANDREW: I have a co-worker that’s about 30 minutes outside of Amsterdam. We talked a little about what goes on there, but I haven't visited yet. CHUCK: Yeah, it seems like an interesting place to be. JAIM: People in Amsterdam call it Absterdam? BEN: Some of them do. ASH: Yeah, some of them do. I just bought a bike from a fellow Absterdamer, and he’s got Absterdam stickers all over it, so I [inaudible] it’s mine. BEN: Nice. [Crosstalk] BEN: I like the bikes there that have the little kid buckets in the front? I thought that was pretty awesome. Just seeing the bikes there is pretty – like it’s an amazing sight. ASH: Mm-hm. Oh, there are so many of them. CHUCK: So, we brought you on today because you wrote this book Functional Reactive Programming. I'm really curious to just get a little bit of background on it, like what made you decide to write it? ASH: Well, there's this new framework which the book talks about in the later chapters called Reactive Cocoa, and there weren’t really a lot of good introductions to Reactive Cocoa out there and I feel like it’s a really powerful and useful framework and I wanted to learn more about it. The best way for me to learn is to write and teach, and instead of doing a series of blog posts about Reactive Cocoa introducing readers to it, I thought I’d write a book instead. CHUCK: Oh, cool. ASH: Yeah. BEN: And you self-published this, correct? ASH: Yes. This is the second book that I've published. I've worked with publishers before, but it’s a messy process. They make you use Microsoft word – it’s just terrible. I used a service called LeanPub and they let you write Markdown; it’s all distributed to a Dropbox folder so it’s super easy to do. CHUCK: So what's your other must-have book that you’ve written? ASH: I wrote one called Your First iOS App and that one was a little bit longer than this one and it actually takes readers through the first episode of opening up Xcode for the first time, creating your first project, all the way through to how to integrate with the basics of core data, so it’s actually a pretty comprehensive book for a first timer. I actually did a kickstarter campaign for that and it got pretty popular and I'm pretty proud of that one, too. CHUCK: Very nice. JAIM: So did you have an editor, or anybody else helping you out, sort of proofreading or something like that? Because I wrote a couple of books back in the day for Manning, and I really kinda hated that whole, entire process, but having somebody book-technical and just somebody who knows English better than I do, checking them over – it can sometimes be helpful. Did you have any of that during this book writing process? ASH: For this book, I haven't got a technical editor for it. For the other self-published book like the Your First iOS App book, I have someone who volunteered, actually, and he said, “Would you mind if I’d technically review your book?” and I said, “Not at all. This is amazing. Yeah, great.” For this one, I just did it myself, and LeanPub has this concept of “Publish early, publish often” so you can release updates to your book as you go. So I just prefer it myself and then I would just – this sounds terrible, but people would email me bug reports, almost, and I would just fix them in the books. People were really generous about their time in that way and I really appreciated hearing from listeners too. JAIM: I kinda like that approach just so that you can get books faster, and I think that the ebook movement has moved people to write somewhat shorter, more focused books, which I think is good. I find most of my books on PragPress, primarily because the bar is set so high, but they also have the Dropbox integration, so if you buy the book it just shows up in that Dropbox folder and then I can open that on my iPad and open it in iBooks and that’s, to me, the best experience I have when I get four or five LeanPub books I've purchased. And I get the updates two or three in a month, and then I have to go copy that to my Dropbox folder, overwrite the old one and then go back into my iPad and reopen it in iBooks. That process, I wish it was a little bit more streamlined, but yeah, I do appreciate fast updates because when you print a book and you have a typo in there that makes you look like an idiot –. ASH: Oh my goodness, yes [crosstalk]. JAIM: You can’t exactly just go back and fix that. ASH: Yeah, the first book I ever wrote, actually, it had a typo on the cover and [crosstalk]. They spelled ‘language’ wrong, and it just – till today, my name is on this book with a cover with a typo on it and it kills me just because they were supposed to be in charge of the cover; that was in the contract and they messed it up. JAIM: Stop the presses! ASH: Yeah. BEN: So maybe we could get into the meat of the book. One of the things that I guess you mentioned is that there weren’t a lot of resources out there for learning Reactive Cocoa, and I found the same thing, and everybody we ask is like, “Oh, you need to read this book; it’s good.” First off, we would like to thank you for just filling a void in the community and second, how did you learn all of this stuff? Did you use it on a client project, or were you just sort of researching and thinking that this is the right way to go? ASH: Well, I kinda came across it organically just through browsing and things like that. I think NSHipster had an article on it that I found and I just started reading and it really confused me, which is to me is sort of a heads up that maybe I should look in this direction. So I took a look, and the more I read about it, the more it confused me, actually, because all I was reading were documentation on hetero files, basically. So I decided to really connect to it and learn in my spare time. And then later on, I worked for a company called Teehan+Lax and they do some open source stuff. I worked on an application there called Upcoming, and there was a counter-application and I wrote it using Reactive Cocoa with another developer there named Brandon. We learned a lot in the process of doing that, and so I just kinda kept up with it and then I may have submitted a few poll requests for minor issues and things like that and I really enjoyed the community. But what really drew me in towards it were there were a lot of people with questions about it and I could go on the issues page or the Stack Overflow page for the tag, and I could answer those questions. And the more I answer the questions, the more I learned about it. JAIM: So maybe we can back up a bit. Can you describe exactly what we’re talking about – we’re talking about3 functional reactive programming? ASH: Yeah, it’s a big term. So there's programming, which I assume we’re all familiar with, and then there's ‘functional reactive’ in front of that. The way I like to describe it is functional programming – it has a lot of different definitions depending on who you talk to, but the most agreed upon one is that you have functions without side effects and you just use data manipulation like maps and things like that in order to chain data from one thing into another, but there are no side effects, so you can have a variable x equals something, and then x is equal to something else later on. It’s just x is always equal to that initial thing, and that’s really cumbersome because in the real world, things have side effects, like input is a side effect. And then there's ‘reactive.’ Reactive programming is just basically a spreadsheet – if you have a cell that’s A, and you say A=B+C, then whenever B or C changes, then A changes automatically, and those changes propagate automatically throughout your spreadsheet. So I like to describe functional reactive programming as the peanut butter and chocolate of programming paradigms. It’s that sweet spot between functional programming and reactive programming, who, individually, on their own, they're not really that useful, but together they become this really cool sweet spot. What you do is you have these things called signals, and signals are really core to Reactive Cocoa and functional reactive programming, in general. What a signal does is it emits values over time; it doesn’t have a concept of any previous values; it doesn’t have a concept of current value; it just sends values as it receives them. A really simple illustration for this for iOS Mac devs is KVO. You can very easily create a signal out of a property that is key value compliant, so whenever that property changes, you have a signal that emits a new value, and then you can do something with that. That’s the core of it. What you do with that, we can get into some really complex examples, but the most basic example is just logging a new value would be really easy to do. JAIM: Yeah, I think one of the sort of quick wins in my mind, just not knowing a lot about it and a whole bunch of people I respect have at least been looking into it, right. So, this looks kinda something that I can’t ignore, and so then you go look at it and you kinda – at first you get scared because the code looks totally different than what you're used to, but the KVO story, I think, is probably the most compelling sales pitch just because traditional KVO is really clunky. It works, but the method you have to implement – and if you wanna watch more than one property and things like that – I think the Reactive Cocoa with KVO story definitely looks favorable to the alternative. ASH: Yeah. And I've had a lot of people, when I tell them that they're like, “Oh, there are BlocksKit or something similar to that that will wrap KVO for you, why don’t you just use that?” and that’s fine if that’s all you're going to use it for, but KVO is a really good introduction to Reactive Cocoa and functional reactive programming. It lets you graduate into using Reactive Cocoa for other things. An example I like to show beginners is one with the gesture recognizer. I just have a pan recognizer attached to a view, and I have a subView, and I want that subView centered to be whatever the touch moves to. So the gesture recognizer has an extension – this is a signal that emits values as the recognizer changes – and then I can map those values into screen coordinates, and then I can assign that to a binding to the view’s center property. So it’s like one line of code to do all that. BEN: That sounds pretty interesting, huh? Do you have a link to that that you can put in the show notes? ASH: Yeah, I got one up one on GitHub I can send you. ANDREW: Ash, you should know, I'm mostly a Mac programmer, and when I first started reading your book – well, when I first looked at Reactive Cocoa in general – I sort of thought, “Well, a lot of this is stuff I can already do with Cocoa bindings on the Mac.” And I actually still think that, but maybe – you’ve touched on it a little, but I do think it’s interesting to talk about some of the stuff that Reactive Cocoa does that’s above and beyond what you could do with something like bindings, which is fundamentally sort of similar to the simple examples you find, if you just read the basic tutorials on Reactive Cocoa. ASH: Yeah, that’s a really good question. So you’ve got bindings on Mac, and then you’ve got value transformations – sorry, NSValueTransformer, I believe? And it just maps one data type, and do another, and then your bindings are bound to the things that are [inaudible] of that. So you’ve got that, and that’s really easy and great, but we don’t have those in iOS, so it seems like Reactive Cocoa is a little bit more valuable in iOS than OSX I would say, but it’s still valuable in OSX because you can do things like features and promises and some really cook things like if you have a signal that represents a unit of work that hasn’t been done yet because maybe it’s expensive for – it’s a network operation that you don’t want done more than a month, then you can return that signal, and then only when that signal is subscribed to will that unit of work actually be executed. So you can use it to defer execution and structure code in such a way that you’ve got signals that are just processed through maps and filters and different operations on signals like that. ANDREW: I found that stuff the most interesting, because I'm coming from a place where I use bindings every day and so the stuff that’s just as simple as having a view update when some model property changes is not that new or novel, but the stuff that you show in your book where you can do what you just described and have network requests, for example, be part of Reactive Cocoa seems really powerful to me. ASH: Yeah, it’s [inaudible]. BEN: I did appreciate how you structured that where you didn’t just say, “Okay, let’s rewrite the entire application as if we already knew Reactive Cocoa because all the concepts would change at once and it’d be really hard to grock what's going on.” So you took some baby steps, which I think was a good approach. However, I didn’t fully understand – at what level do you stop converting everything to Reactive Cocoa? Because if you just used the simple things, you can get some quick wins and some pretty easy to understand code, but if you wanna chain everything together, then it changes basically your entire API – like, all of your networking code has an immediate return value, which is a signal, instead of taking a block, right? How do you balance that to change the entire app to be really, really Reactive Cocoa-dependent versus trying to isolate yourself from that so that it’s not such an opinionated, sort of invasive thing in your code base? ASH: Mm-hm. I would say that it’s important to sort of a check in balance there to make sure that you're not going too far because, certainly, I've pushed for this strongly in the client applications that I've written and the other developers on the team have had to get up to speed with functional reactive programming in order to work in the same code base as me and that was a little bit premature, I think, in hindsight. But if you can get a group of developers who are willing and able to commit to learning something new even just for a couple of days, and try it out, you can get some real wins, I think, in terms of testability and having a structure of code. I mean, what we’re really trying to do to go a level up in the chain here is we’re trying to reduce state. Because if you have state, a mutable state, in your application, then you have different test cases you need to be aware of; you’ve got invalid state that your application could get in – and that’s really hard to test for because all of your code managing that state is specifically designed so that it doesn’t get into an invalid state. So trying to put it there through testing is really kinda difficult to do manual testing. So there are a couple of wins that you can get through using functional reactive programming using Reactive Cocoa – how much you want to actually do it is something that I'm still learing myself. I just started at this new company, Artsy, about a week ago. I've gotten [inaudible] Reactive Cocoa in the pod files so it’s installing now and that’s really awesome. But I'm being cautious about how much I rely on it because I don’t want to intimidate the other developers on the team and introduce a large cognitive dependency for it. JAIM: So what things do you start with? ASH: KVO, just like we discussed; that’s the easiest way to do it. There was one example where we’ve had a custom navigation stack thing with a back button, and I wanted that back button to disappear whenever we’re showing the offline view to show that the user wasn’t online. So I just used Reactive Cocoa to subscribe to the show’s offline view property and then whenever it shows the offline view, it switches on the value that’s sent on along that signal and just either hides or shows the back button. JAIM: So if you're doing a KVO we’d have some object that has a property, whether online or not, and you have to wire up the KVO with whatever those clunky things are. But with Reactive Cocoa, you just create a signal with that, and you subscribe to the signal. Did I get that right? ASH: Exactly. JAIM: Okay. ASH: Yeah, and that was really useful in this viewcontroller because it was already subscribing to a single other KVO property and it wasn’t used in the front end at that time, so I would have had to add a context and then added a second context in order to switch on that depending on with which property was emitting a new value and it just would have been a lot more work considering it was a one-liner. BEN: So when you're working on a team – and I think you could probably say with good certainty that if you work on a team size of say, more than two or three, there's probably a strong likelihood that somebody on the team probably either hates or maybe dislikes strongly this style of programming. So at that point you just sit down and say, “Okay, we’re only going to make this a dependency if everybody on the team is on board with this style.” Because one of the things I think can be problematic is when you have sort of a schizophrenic application architecture, or some of it uses KVO and more reactive style, less state, functional chaining together of operations and other styles are more imperative. I think that’s really bad for a software architecture to mix those two everywhere. How would you approach putting this into a project? Are you willing to remove it from the project you're working on if your teammates are uncomfortable with it? ASH: That’s a really good question. I don’t know if I would be willing to remove it; I mean, I typically work on smaller teams, so I haven't ran into this problem before but I can see it being an issue. I think that probably the most important thing would be to communicate to your team and let them know why you think it’s valuable and maybe you don’t have a [inaudible] or something like that to teach them the benefits of using a more functional paradigm. Because even if you don’t go in a whole hog on FRP, you can still learn some valuable lessons just through programming functionally and having less dependence on mutable state – I think that’s the real issue here. BEN: So, one thing that sort of going hand in hand with that with this being sort of a new style – not sort of, it is a new, a different style of programming than what we’re used to and what Apple recommends – and a whole bunch of people that I would consider competent developers are somewhat confused by it at first and that’s totally understandable, thus the need for your book. And the competent developers, you sell them on the benefits and you do the launch and learn like you're talking about, but what about beginners? If you hire somebody who’s pretty new to this stuff, do you think it’s appropriate to teach them Reactive Cocoa, or do you think they need to understand the old way first, and then sell them on the benefits? ASH: Yeah, I would lean towards the latter where you would sort of graduate them slowly up to the chain. I mean, you shouldn’t really be doing something like an advanced FRP before you have the basic Cocoa core competencies down. So understanding what KVO is and how it works before you're using the signals to wrap properties and turn them into KVO signals, it’s probably very important I’d say. So if you have a beginner in the project who’s getting into iOS development for the first time, then I think keeping them a little far away with the Reactive Cocoa stuff might be a good idea. On the other hand, I know there are some studies that show that teaching beginners functional programming is actually a little bit easier than imperative programming, because they don’t have to construct this mental model of what –. BEN: What state it is. ASH: Yeah, that’s it. ANDREW: Exactly what I was about to say. BEN : That’s in university – my intro to C course. I had this excellent professor and he had this cartoony voice, and literally he would write on the chalkboard every step of the program and the state of all the variables and it was a really effective way, I think, to learn how that stuff works but it requires a good teacher, I think. Let’s say, I have to agree with you with the concept of just sort of starting from x and then moving to y. Even today, I think it’s important that people understand what life was like before Arc – you gotta understand what Arc is doing for you, so I think that’s a smaller but relevant example. The only other thing that sort of bugs me about this is this is like a radical approach to software development. It’s a conscious decision; say, I gotta do what I think is best for this project given my skill set or the skill set of my team. But a lot of us do client work and some of that client work is, we write it, we ship it to the App Store, and then at some point, they are going to hire a team to bring it forward. In the past, I've had push back on non-standard frameworks and things like that and it drives me a little bonkers, but I think that’s something to be concerned with if you're writing apps for other people that you may not maintain forever, right? Are they going to be able to find somebody to work on this? There's a lot of iOS developers, but the pool of iOS developers who are experts in Reactive Cocoa is pretty tiny. ASH: Mm-hm. Yeah, I think there's almost a couple of different problems there because as you pointed out that you can have another team or more members of your team take over and maybe you're not involved in the project anymore to kinda hold their hand to the learning process, and that can definitely be worrisome. And the other idea is that if, say, we wake up tomorrow and realize that this whole Reactive Cocoa thing is a huge mistake and we go back to imperative programming – I mean, that’s also a danger to the framework. I don’t think it’s likely to go away because GitHub’s behind it and they're the reason [inaudible], like they're dogfooting on all of their OSX projects, so I don’t think that’s likely, but it’s still something to be concerned with if you're introducing any third party dependency. And that’s a broader discussion to have, like how willing are these developers who are working on client applications? How willing are we to introduce dependencies on behalf of our clients? Even something like Cocoa pods – something that’s pretty contentious right now because we’ve got developers out there who don’t want to introduce third party dependency into their application. They'd rather just use sub modules or some other non-dependency manager style solution to the open source problem. I've been a developer who just wouldn’t – he wouldn’t use Cocoa pods because he wanted to be able to just hand a directory over to the clients and say, “This is the source code; it works out of the box.” JAIM: Yeah, you can’t do that with Cocoa pods. [Crosstalk] BEN: Honestly, I kinda wanna have one of those duke it out sessions respectfully, because I find that argument ridiculous, honestly. ASH: Yeah. [Crosstalk] BEN: Everybody could choose what you wanna do as a professional, and I respect that. And if you choose - [inaudible] “It’s not for me,” that’s totally cool. What I don’t like is when somebody says, “Nobody should use it because of these problems.” I think their concerns are legitimate, right? You could pull in third party code that uses some private method or fails the private framework check because they use some selector in a weird way. Or the code is just terrible and it will break in the future. And so you know what you're pulling in, right? Do your research and don’t pull in stuff, libraries, that are bloated and not maintained, and written by people who aren’t really qualified to ship code like that. But there's nothing stopping you from taking your own private code and distributing it yourself via private GitHub repository as a Cocoa pod and never touch static libraries again. ASH: Exactly. I had the opportunity to do some contracting for a company [inaudible], and that’s how that they actually structured their code, is through different private pods, and it worked really well for them. BEN: Yeah. I guess I’ll get off my soap box, but sometimes I just get a little bit [inaudible] with utter hatred of new things. ASH: Yeah. JAIM: So we talked about the kind of new things – we talked about convincing developers that this is the right way to do it. What's the selling point for your manager, the product owners – people that are actually clients, people that are paying the bills? How do we kinda sell Reactive Cocoa, that this is the right thing to do? What are the main benefits and what type of applications? ASH: Well, that’s a good question for the non-technical people who are involved in the decision-making process. What are the implications and then pros and cons for using Reactive Cocoa? And I think we’ve discussed the cons pretty thoroughly, but what are the pros? From the developer’s perspective, it’s pretty easy to say that I find it more enjoyable to write functional reactive code than imperative code, but that’s not an easy sell for a manager. I think that the biggest win is that you’ve got more testable code if you write in a more functional manner. In general, you can test your code easier or more easily. If you're using FRP then you can really use some cool things and if you're comfortable stepping inside of the sort of the anointed design patterns that Apple specifies, you can use something called ModelView ViewModel, which is something I've discussed in the book. It’s not really a radical departure, it’s sort of within the ModelViewController paradigm, but what it does is it lets you test your presentation logic a lot easier, and that can be a big win for managers as they're looking at things like test code coverage or the number of unit tests, or whatever the metric that you're using. I'm not going to say that it’ll give you a more performant to that because it probably won’t. There are ways in which – I mean, Reactive Cocoa itself is going to add quite a few layers to your stack trace if you're debugging it, say. But it shouldn’t negatively affect the performance of your application; it won’t speed it up, but it won’t slow down unless you're running that debug build and then it does a lot of stuff for you like logging and tracing and stuff like that. So I've had people comment to Stack Overflow with like, “I wrote the exact, same code imperatively and using Reactive Cocoa, and the Reactive Cocoa one is a hundred times slower. What's going on?” I just pointed out that you're running in debug mode, so every signal is given a unique identifier using a string with format, which slows down things quite a bit, actually, so that’s the cause of that. But back to your original question, “How to sell a manager pon this?” That’s a really good question. I mean, how do you sell a manager –? BEN: Can I jump in? ASH: Yes, please do. BEN: I spent a long time in my early career in .NET trying to justify architectural decisions and dependencies, and even should I unit test to management. And eventually, I've realized that the engineer’s job is to ship the best software considering all of the constraints and dependencies that you have in your workplace. One of those things, being unit testing, is something that is just non-negotiable for me. I'm a professional developer and I'm going to write code that doesn’t have bugs to the best of my ability and that means, for me, that I'm going to unit test as much code as I can confidently do so without going off the deep end, right? Just enough. In places where it’s much easier to test like Ruby Code, I will test a whole, whole bunch more. And places where it’s little bit harder to test and more cumbersome, like in iOS projects, I will test less, and I think the tooling and stuff like that can make that a little bit balanced out. But what I don’t think is right is to, say, “Well, I've read that unit testing is good, so can I please have permission to do it?” and they're going to look at it and say, “Well, you're going to be writing code, therefore you're going to be taking more hours to deliver features” and if it’s a line item on an invoice, people can just say, “I don’t want that.” Right? Whereas if you instead say, “The cost of this feature is x” and I'm a professional developer – it’s not done until it’s done. And so that includes things like unit testing. So I think that can extend to architectural decisions as well, like, trust me to do the best job that I can and that means that I don’t ask the manager whether or not I can include Reactive Cocoa. I think Reactive Cocoa is an interesting one because it’s kind of a heavyweight dependency and if there are existing developers on the team, you still have to consider all that stuff but asking a manager seems like the wrong questions ask. JAIM: There's managers, there's also clients – those people that are writing the checks, and at a certain point it comes down to money. If we can remove state from our program, we can make the case that that’s less bugs, that’s less time fixing bugs, that’s more features. Are you seeing that with more complex applications if you're doing a reactive style? I mean, you have less state, easier to test, less bugs? That could be more money. Is that something that you're seeing? ASH: Yeah. I've used it [inaudible] in my personal projects and I've actually open sourced a couple of them on GitHub and just having – me, personally I also unit test because it’s a matter of professionalism, from my perspective, so I have seen a dramatic increase in the amount of test coverage that I've been able to attain using Reactive Cocoa. I built this application for myself – it’s called C-41 and it helps you develop film because there are actually still people out there who develop film. I wrote it completely using MVVM and Reactive Cocoa and I installed crash [inaudible] in it and I haven't got a single crash report since I launched it at Christmas time. I'm pretty proud of that, and again, it’s open source; it’s on my GitHub page. CHUCK: I mean [inaudible] if we’re talking about convincing managers or whoever, stakeholders – if it’s a long-running project, a lot of times that I've had [inaudible] actually saying, “Look, I've listened to this podcast. The fellow they had on there, he just explained really well that it reduced the number of bugs and it sped up the amount of work that he was able to get done. I'd really like to try it for a couple of weeks or a month on this maybe tangential or side-ish project and see if that works.” And a lot of times, they’ll give you some leeway if you're an employee in a company and it’s a long-running thing; sometimes they won’t, but at least that way you're offering them some value proposition and at the same time you're also not making it a permanent change without proving it out first. BEN: I would probably insert a little bit of self-study just so [crosstalk]. Yeah, I totally agree with what you're saying, but when you come to somebody and be like, “You know what? I was really interested in this idea because I heard it in this podcast. I decided to try it out on a little side project and it worked out well there.” I think that's a good approach to sort of introduce things like that, but I do a whole bunch of stuff on the side just because I don’t feel comfortable spending my client’s money on experimentation things that may not work out. On some level it is like professional development and it’s good for the project to be always learning new things, but maybe not always use their app as your playground, right? CHUCK: Yeah, fair enough. ANDREW: Yeah, I feel the same way and I think most of the new technologies that I learned I try to learn them on my own time because it makes me feel a lot more comfortable using them in a production setting too, and so I'm not writing my novice, terrible code. It’s a real app, you know. BEN: Yeah. JAIM: And you talked a little bit about the MVVM pattern. When I've been starting to hear about the functional reactive style in iOS, I was kinda surprised to hear MVVM in Reactive Cocoa mentioned side by side. It seemed kinda orthogonal to me, but they seemed to be mentioned in the same thing – not just by your book but by other people I've been hearing too. Are they somehow related? ASH: Yeah. Functional reactive programming as a concept has been around since the ‘90s, I think, so it’s not too young but Reactive Cocoa as a framework is actually based on the Arc’s extensions in .NET which are, I believe, an open source project that you can go and explore if you want to. So when they imported a lot of the same concepts that that framework had, they also took a look at MVVM because that’s very popular in .NET as well. So they're related in sort of a historical context; I just think, personally, that MVVM has a more – I shouldn’t say ‘better framework’ for MVVM because better is not really the right term. I think it’s a more appropriate framework for building iOS applications and then Model View Controller just out of the box. And MVVM isn’t really that different form Model View Controller, so I’ll do my best to sort of explain over the air what MVVM is. You still have your model, and you still have your view, but your view is formally coupled to your controller so you only have one view, one controller – you treat them pretty much as the same object. And then instead, in between the view and the controller and the model, instead of having another controller you have the viewmodel which encapsulates all of the presentation logic that you might have, so if you have a date in your model and you wanna expose that as the string in your user interface or your view, then your viewmodel will be responsible for transforming that from an NSState into an NSString. And you can test that, so it’s really encapsulating the logic – not having any references to your UIViews directly, because you can use things like bindings in order to observe your viewmodel, but having it as a standalone piece of logic that you can test – you’ve got inputs, you get outputs – you can test those. JAIM: Okay, so if I had a date and I wanted to change it into a string like yesterday or something like that, I will put that in a viewmodel instead of in a controller where it doesn’t quite fit, or in a model? ASH: Exactly. So if you had it in a controller, which is probably the more traditional MVC way of doing it, then what you’ve got is a controller with a bunch of other external state that you’ve got to introduce into your unit test that you are writing. But if you have it in viewmodel, the viewmodel doesn’t actually reference anything in the UI Kit, it just has foundations. So you can test that a lot easier, because you don’t have to rely on UI Kit stuff. It’s a headache you don’t have to worry about. ANDREW: I think you can also help with quotability between iOS and OSX – kind of help [inaudible] parts of your code based on what’ll worn on both out better. ASH: Absolutely. If you have a multi-platform application, even between – if you have a universal application with iPhone and iPad support, or even like an iOS and OSX application, then you can write your viewmodels and share those between the different applications, which is really handy. Now the really cool thing is if you're using another framework, another tool like Xamarin where you're actually writing things in C#, then you can use the same viewmodels for iOS, OSX, Android and Windows phone. So you can write all of that presentation logic once and repeat that throughout your different applications. JAIM: You mentioned observing things in the viewmodel in order to update UI Kit elements – so that stuff goes in the controller? ASH: That’s right, yup. BEN: Okay. So if I understand the big picture correctly, to build a sufficiently complex application using Reactive Cocoa you're modeling all of the behaviors ahead of time and then you sort of say go, and at that point it’s the machine that runs itself. So it’s responding to events and other things happen, and it chains and transforms data in order to update other things, but at some level, most of your code is just registered in viewDidLoad. Is that more or less correct? ASH: That’s correct, yeah. BEN: So I wonder, in .NET, like in the early days of web forms in .NET, you'd run into the pageLoad method in a webpage that would basically contain all of the code for the webpage, and it would be like switching on params that are accessible and it became like –. The first Litmus test on is somebody a bad programmer not just because they put all of their code in this one method, right? It kinda seems to me like you’d be doing so much in viewDidLoad – is it easy to understand the big picture? Can you see the forest for the trees when you're sort of registering everything just right there at once? ASH: Yeah, so the really cool thing with this approach using MVVM in just Reactive Cocoa without MVVM, you definitely have ran into that issue were you’ve got just reactive spaghetti that’s just bindings and state transformations everywhere, but if you separate that presentation logic out to a viewmodel, then all you do in viewDidLoad is bind your view properties to your viewmodel properties – and that’s it. All the logic for transforming that data, it’s all inside the viewmodel. BEN: Okay, so I definitely need to look into that more just because what I have in my head, it seems not great. So having a good example splitting that all out – is C-41 probably the best example I could go look at at something real? ASH: Yeah, definitely. I mean, I don’t wanna say it’s the best because I wrote it, but it’s an example and it’s got test coverage and everything, so you can take a look at that, see how I did it. BEN: Cool. I wanted to ask about a couple of other things: one thing I didn’t quite get in the book is the difference between cold signals and – I don’t know if hot signals is the right word – I noticed that mentioned in a couple of tutorials. Can you go into a little bit of detail on those? ASH: Sure. The difference between a cold and a hot signal is really esoteric and 99% of the signals that you'll encounter are all cold signals. But then there's also this weird concept of a warm signal, which I still don’t totally understand. Justin Spahr-Summers has tried to explain it to me and I don’t completely understand it, but the nice thing is with Reactive Cocoa 3.0 is that this is all just going away. Everything’s going to be a cold signal. I'm trying to refresh my memory here because I haven't used a hot signal in forever. I believe the hot signal does work when it’s created and not when it’s subscribed to, which is kind of weird from a Reactive Cocoa perspective, because you wanna make sure that you just have stuff that’s done when you are subscribing something, like an on-demand kind of thing. It’s not something that I completely understand, I guess. JAIM: Well, that’s comforting then that I didn’t get it at first glance. ASH: Yeah, I know, definitely. There's a couple of concepts in Reactive Cocoa that are super confusing and they're being removed in Reactive Cocoa 3.0. JAIM: I wanted to ask if there are any hidden gems that you’ve seen, maybe unrelated to Reactive Cocoa. One of the things that comes to mind for me was the strongify/weakify, and that comes from libextobjc, I think. ASH: That’s right, yeah. JAIM: Do you wanna talk about that and maybe any other things that come along with Reactive Cocoa that are cool ideas? ASH: Yeah, sure. Reactive Cocoa itself has a dependency on, as you said, libextobjc, which is written by one of the creators of Reactive Cocoa himself. It’s got this really cool thing that you mentioned, the strongify/weakify, which lets you simplify the code you're writing for using blocks that are going to be stored somewhere, so you don’t have to have __weakSelf=self – that kind of stuff. It just does that for you using a [inaudible] of variables, which are super cool. Probably one of the gems I like the most is there's a class you can have – I can’t remember the name of it at the moment – but it'll actually conform to a protocol for you, and you just tell the class what you want it to do when it encounters certain signals like there's four signals, and they have to return void, unfortunately, but it’s really cool if you have a delegate protocol that just responds to events, then you can encapsulate that logic inside anonymous blocks that you're just defining viewDidLoad if you want to, so you don’t have to conform to the protocol yourself and then you risk introducing state into your application viewcontroller. JAIM: It’s kind of a cool, handy thing to have in your back pocket. ASH: Yeah. JAIM: Because sometimes you're like, “Oh God, I gotta declare my protocol or create a new object or whatever.” ASH: Yeah, if you're just like presenting that UIAlertView or something like that, it can be pretty handy. Yeah, I don’t know if I know any other gems or anything that’s –. There are a lot of different operators that you can do on signals themselves, so I like looking at the hetero files for RACSignal+ operators, and just reading through that and learning you can do something like samples. I can create a signal that will emit whenever this other signal emits, and you're just like, “When would I ever use that?” But then, if you know about it, you'll come into a situation where it'll come in handy, so definitely look through the operators [inaudible] for that. BEN: So, objective-C as a language – at first glance a lot of people hate it, and I didn’t love it at first. In fact, my entire intention was to learn – just like what we’re talking about with Arc – I just wanted to learn the right way first, and then I was going to go to, at that time, was called, Monotouch. And now, Xamarin, because I was a C# developer. Turned out, I actually started to like the language. Go figure. And I hear that a lot, like other people, once they get over the square brackets and the wordy method names and stuff like that, some of the aspects of it start to appeal to you. Call it Stockholm Syndrome, I don’t care, but I like it. But when you do things like chaining method calls with blocks, that really starts to get ugly. And it was a [inaudible] just when I'm looking at your book on an iPad mini where – I don’t think a single line of code could display without breaking, so it was kinda hard to read, just on this device. That’s part of the reason why I think it’s – what I'm getting at is objective-C, the language, is kind of ill-suited to these fluent interfaces and chaining things together. I know there's another project called – I think it’s called Underscore.m or something like that. I’ll see if I can find the project – yeah, Underscore.m.org, and it looks a lot like Underscore.js, where you can sort of chain together things and it’s got map and filter operations, but it changes this style of objective-C to more of a C-based language where you use parenthesis and dot syntax, where it’s basically properties and blocks instead of objective-C methods. It seems like this is kind of frustrating to look at because it’s not objective-C style, but it supports this sort of [inaudible] interface style a little bit better than objective-C does. Do you have comments on that? That you find that, at some point, are we reaching a limit on what is tolerable in objective-C to do from an API design perspective? ASH: That’s a really interesting question. I think that what's important as developers is to not become too insular as a community. I'm a huge fan of the idea of taking the best ideas from other developer communities and incorporating them into our own language and our own environment, whether that’s Reactive Cocoa, or they're Underscore.m. There's also ObjectiveSugar, which is kinda cool; it has some convenience methods. It follows more of the objective-C pattern than the C pattern, but it’s still using your ability to do maps and stuff like that. I think it’s important to take a periodic look-around and see what other developers are doing out there who aren’t iOS developers and see if there are any cool ideas that we can steal from them to make our lives easier. And there's going to be some experimentation, and there's going to be some things that don’t work out, but it’s still important to try, I think. BEN: Well said. ASH: Thanks. CHUCK: Are there other ways of doing reactive programming that makes sense besides Reactive Cocoa? ASH: On iOS and OSX? CHUCK: Yeah. ASH: I'm not aware of any. I think, and this is something that I talked about in the book too, sort of graduating developers up from just imperative programming to functional programming, to functional reactive programming, I think that if you're going to use even something like map and filter and that kinds of stuff and left folds and things – those functional methods and Arc’s collections are super useful. So even if you don’t wanna go whole hog on FRP then you can still get some value out of the functional way of doing things. CHUCK: Cool. Alright, well thanks for sharing with us; thanks for writing the book. Hopefully, this helps a few people go explore a new way of writing programs or if people are already old hats at Reactive Cocoa – it maybe gives them some tips or tricks they can use to move ahead with things. We’ll go ahead and get into the picks then. Jaim, do you wanna start us with picks? JAIM: Sure, I've got one pick today. So about a month ago, I was sitting around thinking about a game I used to play when I was a kid – an old Apple 2e game called Taipan!, where you kinda sail around the far East and trade stuff. I'm like, “Oh that was a fun game! I wonder if that exists.” And I didn’t think about it again for a few weeks, and then I was digging around the internet on something totally different and I actually stumbled upon a link for someone who had done it for iOS. So Taipan! has been imported to iOS. I've been playing it; it’s fun. It’s free download, like a $3 upgrade if you wanna keep playing, but it’s a fun game – one of the Apple 2e games that have been imported over, so I've been playing it. If you know me, I don’t play a whole lot of games. I've played Angry Birds, and then I played Flappy Bird, and that’s about my iOS game experience. But Taipan!, fun! BEN: No wonder you're not playing lots of games, those games are terrible. CHUCK: [Laughs] JAIM: I loved Flappy Bird! BEN: Alright, I have one in my picks, too. CHUCK: Alright, Ben. Go ahead. BEN: Alright. I'm really annoyed with the state of iOS gaming and every time I see a game that’s free, I'm just like, “Nope, not going to do it.” And Angry Birds is like – the first one was really awesome because I think I paid 99 cents or maybe $2 for it and it was a great, innovative game and fun to play. Nowadays, it’s free and there's full of all these buttons that my son doesn’t know not to click on, including the – I don’t know what it’s called – Angry Birds Go? It’s like a cart racing game with their Angry Birds characters. But there’s 12 buttons on every menu screen and one of them is like ‘Race Again’ and all of the others lead to liking this crap on Facebook and buying turbo boosters and stuff, and I'm giving my iPad to a four-year-old to play this game – he loves it. Anyway, I wish I could just pay them $5 or $10 and just get rid of all that crap. I've been on this sort of quest to find games that don’t do that and charge a reasonable price for the game. This one, it’s called Monument Valley and it’s really, really nice. It’s well done; it’s kind of like an MC Escher meets a little platformer game. It’s not difficult, but it’s more immersive, and the art style and music and stuff like that – it’s just really well done. So support these people who are making games that don’t spam you with all kinds of stuff and try to get in-app purchases for juju berries or whatever. So monumentvalleygame.com for that. Another pick is Sketch3 just came out, and I've been a big fan of Sketch. I'm using it more and more for iOS design stuff and Sketch3 is just a solid upgrade all the way around. One of my favorite features is just the ability to create slices of things at an interface you're creating, and then you go to the export button, and you can just export all of it in Retina in 1x sizes with basically a single button click. You name all the layers the way the image file names to be created, and it does it all for you – it’s pretty awesome. And I'm working on an update through GiggleTouch – an old game that I created back in 2010, and I used Sketch for all the artwork for that game. So, go download Sketch3 from the App Store, and those are my picks. CHUCK: Very nice. Andrew, what are your picks? ANDREW: I got a couple of picks today. I was in Los Angeles again last week and I found a couple new record stores, and so I'm going to pick one of those, because it’s one of those shabby, little, small mom and pop record stores that been there forever, and a lot of times they're just kinda all the same. They’ve got a lot of used records that you don’t actually wanna buy or not in good shape but his place was a little different. They had a ton of soundtrack music and classical music and just interesting stuff that I hadn’t seen before, and I found some cool stuff that I bought. It’s called Poobah Records. They're also a record label, but the music they release on their label doesn’t seem to have much to do with them and the store. Anyway, I really enjoyed it. And I've picked this before but I'm going to pick it again because it’s been a while and it’s CocoaHeads. I met Chuck at CocoaHeads, and CocoaHeads has just been a big part of my Mac and iOS developer life for the last few years and I think it’s a great way to know people, and it’s a great way to network, and I've learned a lot there. We actually had a presentation on Reactive Cocoa this month at Salt Lake CocoaHeads and it was just good to get to discuss it with people who know more about it than me in preparation for this episode, and there's a lot to learn and a lot of people to meet there. Those are my picks. JAIM: Plus one, CocoaHeads. We’ve got a local one here, yeah, great group. CHUCK: Yeah, I have Scouts every Tuesdays so I can’t make it but when that changes, I will be making it again. But yeah, anyway, I've got a couple of picks here. My first pick is Hatching Twitter by Nick Bilton, and it’s basically the story of how Twitter started, and so that goes through the different people who were involved and –. It’s really interesting how it evolved and where all of these different people came from, and it’s kind of told as a narrative, so most of this stuff happened, but some of the dialogue may not have happened exactly the way that it tells it, but anyway, it’s been really, really interesting. I've been listening to it on Audible.com and I really, really like it, so that’s one pick. Another pick is Discourse, which is an open source forum software. I would say it’s sort of the bulletin, but it’s not – it’s better. It works, it doesn’t suck, and has a lot of features that make me actually wanna use a forum. And the other thing is it has a setting in there that you can set so that it will actually email you all of the posts, so you can kinda treat it like a mailing list instead. So yeah, I'm really excited about that, and we’re actually going to be opening up a forum for our listeners – and this is just a way for you to support the show. The lowest cost option is $10 a year, and that’s really just to keep the trolls out, so it’s really inexpensive. Anyway, it’s really a nice way for us to be able to interact with you, and for you to be able to discuss things like Reactive Cocoa or functional reactive programming, and we invite all of our past guests into our forums so you can talk to them as well. So anyway, I'm just going to plug that. There’ll probably be a little segment at the end of the show, so you go sign up. But yeah, we’re going to watch that and it should be available when this episode goes out. Anyway, those are my picks. Ash, what are your picks? ASH: I've got one. It’s from corker – well, two corkers actually, so I just wanna put a full disclosure on that. It’s a new podcast, actually, that Orta and DB launched last week called Pod5–. BEN: Wait, wait, wait, wait. ASH: I know, I know. BEN: I'm just kidding. [Chuckling] ASH: Don’t worry, it’s very different from this podcast, but it’s very cool. They have this kind of schtick – if you're a fan of Russian humor, you'll love it. It’s called pod5.io, and it’s just talking about new Cocoa pods that have been released over the week. JAIM: Oh, that’s Orta’s new podcast, right? ASH: Yeah, exactly. JAIM: Oh, I forgot you guys are working together. That’s awesome. BEN: He’s good people. ASH: Mm-hm. And that’s it. CHUCK: Very cool. I always like having new podcast to add to the list of ones that I'm way behind on, so. BEN: Chuck, I don’t know how you can do this without a commute. Like, that’s my only time to listen to podcasts, is my commute. If I worked at home, I would have to cut my podcast in half. CHUCK: So, a lot of them are NPR, so I can just play those in the background and ignore them. But yeah, I just play podcasts while I work and kind of half-listen to them and then the ones I'm really keen on, then I’ll listen to those when I'm driving kids to school and stuff. You asked, there you have it. Anyway, thanks for coming, Ash. ASH: Thanks for having me. JAIM: Good discussion. BEN: Good discussion, yeah. CHUCK: If people wanna get a hold of you or know more about this stuff, what's the best way to do that? ASH: The best way to get in touch with me is through Twitter and I'm @ashfurrow there, and if you have any questions about Reactive Cocoa at all, feel free to create a Stack Overflow post and send it my way and I’ll take a look at them. CHUCK: Cool. Alright, well we’ll go ahead and wrap up then. We’ll catch you all next week. [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 form that allows you to join the conversations and support the show at the same time. You can sign up at iphreaksshow.com/form]