057 JSJ Functional Programming with Zach Kessin

Use this link and code JAVAJAB to get 20% off your registration for FluentConf 2013!



00:55 – Zach Kessin Introduction

03:01 – Functional Programming

06:44 – Monad

11:33 – Functional Languages vs JavaScript

  • No side effects

18:09 – Why Functional Programming?

24:35 – Tail_call

32:54 – Programming Languages

33:38 – Functional Programming Libraries

36:13 – What do you miss in JavaScript?

  • Pattern Matching


Next Week

Building Accessible Websites on a Podcast with Brian Hogan

This episode is sponsored by

comments powered by Disqus


[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] CHUCKHey everybody, and welcome to Episode 57 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance. JAMISON:  Hello, friends. CHUCK:  Merrick Christensen. MERRICK:  Hi. CHUCK:  I’m Charles Max Wood from Devchat.tv and this week, we have a special guest and that’s Zach Kessin. ZACH:  Hey everybody. CHUCK:  Did I say your name right, Zach? ZACH:  Yep, you got it right. CHUCK:  Alright. This week, we’re going to be talking about functional programming in JavaScript. You want to give us a little bit of a background on you, so that you can kind of explain, I don’t know, who you are and your expertise here? ZACH:  Oh, okay. So yeah, I’m Zach Kessin. I’ve been a software developer for close to 20 years, on the web, close to 20 years now. My first web app in PHP version — oh, not PHP, in Perl version 4 with mSQL, because MySQL didn’t exist yet. That was, like, 1994. And let’s see, I’ve been doing web applications ever since. Worked in Boston area, in London and then in Israel for about 10 years now. I’m also the author of ‘Programming HTML5 Applications’ and ‘Building Web Applications with Erlang’, both published by O’Reilly. And my interests include functional programming, code generation and concurrency in Erlang. So, well, that’s a different show. That’s sort of my background. And I work at a small Tel Aviv startup called Product Structure that we build [inaudible] components and workflows that will be self-optimizing on your website. So, that’s what we’re doing. We’re launching it soon. CHUCK:  Cool. MERRICK:  Very cool. CHUCK:  You just launched your own podcast, didn’t you? ZACH:  Yeah. I just launched my own podcast called ‘Mostly Erlang’. It’s going to cover Erlang and occasionally other functional languages like Haskell and OCML. We had our first, we recorded our first episode last week. And the first episode is called ‘Building Skynet’. And the second episode will be on the Webmachine framework, which is an HTTP framework, backend framework though, to do semantically correct Webmachine. And it’s sort of similar in format to this podcast, The Ruby Rogues. So we sort of stole, borrowed your format, Chuck. We appreciate it. CHUCK:  [Laughs] That’s fine. ZACH:  We did ask, I should point that out. CHUCH:  Yeah, you did ask. Well, I actually stole the format from the TWiT.tv show. ZACH:  Okay. CHUCK:  Yeah. MERRICK:  Very cool. ZACH:  That’s the circle of life. MERRICK:  Zach, I know a huge portion of our users don’t actually know what functional programming is. Could you kind of give a high level overview of that to start us off? ZACH:  Okay, so functional programming is a paradigm of programming for which, sort of famously done in languages like Haskell and Lisp and Scheme and Erlang, in which basically you use composition of functions as your primary mechanism for building up programs. It works well in JavaScript. When Brendan Eich was designing JavaScript, he stole the function, concepts of how functions work, basically from Scheme which is one of the Lisp languages. So, you can do a lot of things with functions. It’s the thing in the language that, Douglas Crockford has said that and I think he’s right, that they got really right, is they got functions right. So basically, the way I tend to do functional programming in JavaScript and I was going to sum it today, is basically I write a lot of little one-line functions. I like one-line functions. They’re easy to test, easy to work with. And then, you just sort of string them together. I actually tend to use CoffeeScript and not JavaScript directly, when I can. MERRICK:  Is there attributes of CoffeeScript that make functional programming simpler or do you just prefer the taste? ZACH:  A little bit of both. I prefer the taste. I find the arrow and the fat arrow operators really nice, as well as the de-structuring arguments. MERRICK:  Okay. ZACH:  Really nice and just the ability to sort of have that sort of more concise syntax. I also use Underscore.js a lot for this to sort of wrap things up and just do that. You end up with, you end up a lot of times using the chain operator in Underscore. You end up with sort of like an algebra function, I like to think of it as. Or you start with a list and you know, you just perform a bunch of transformations on it and you end up with and output list that sort of more or less does what you want and you sort of have just a bunch of independent steps to get there. MERRICK:  Sure. ZACH:  So. MERRICK:  Sure. So, Underscore has chain. ZACH:  Yeah. MERRICK:  It seems like it also has things like compose, after, wrap. ZACH:  Yeah. MERRICK:  Do you recommend all those kinds of things for the functional programming approach? ZACH:  I do. I like the chain approach where you can just, you know, if you have a list of something, either on the frontend or the backend, it doesn’t matter. You know, you have a list. You might want to filter out some elements. You might want to transform some of the other, some of the elements, I was training somebody yesterday, she’s actually on the server-side, not in JavaScript, but well I was querying some data for data source and I needed to drop some records that didn’t reach some rules and then transform it in six different ways. So, I end up with six or eight little functions, each does one thing. And then just end up with a chaining operation that just sort of puts them all, they just will all run through. MERRICK:  Yeah. ZACH:  And then, build it up one step at a time. And it’s really easy to get it right. MERRICK:  Yeah, I particularly like about the chain operators, it usually reads very top-down. Whereas, one of the things that’s harder to grok for functional programming, for me, is that it’s kind of inside out. ZACH:  Yeah, it’s one thing that drives me nuts [inaudible] to it, especially when you start getting to, like, six and eight levels deep. MERRICK:  Yeah. ZACH:  You know, function1 of function2 of function3 of function4. What you really want to be able to do is decompose that into some sort of abstract out the flow control in some way. And of course, what you’re really getting to there in chain or with a promise like Q and you’re basically working with a monad. I’ve actually worked on a book on monads, but it kind of fell apart. MERRICK:  So, monad is always kind of one of those magic words to me. Minor saying in monads is it’s a function that takes in single arguments but people talk about it like it’s a lot more than that. ZACH:  So, it’s not really what at monad is. MERRICK:  Explain to me. ZACH:  A monad is a function that’s guaranteed to break your brain. [Laughter] JAMISON:  I thought monad was just invented to people who wrote Haskell could sound smarter than you. [Laughter] JAMISON:  I didn’t know it actually did anything. I thought they were just a thing you could drop in conversation. [Laughter] ZACH:  Yes, monads are one of the essential aspects of functional programming. They allow us to feel superior to everybody else. [Laughter] ZACH:  And by the way, if you look, there is a running debate online over whether jQuery is a monad, and really [inaudible] part of jQuery, not the plugins and the AJAX and all the other stuff. And I suppose you could do Google queries and say jQuery is a monad and jQuery is not a monad and see which gets more hits. That might be an interesting experiment to try, if you want to try that. But basically a monad, the best way I can think of to describe monad is it’s a programmable control flow. It’s really functionally what it comes down to. So, the chain value operator in Underscore is a monad as is the Q library. It all forms a monad. Basically, a monad has to have three operations. You have a thing to wrap a value in the monad, you need to unwrap it, and then sometimes you process it through. And if that’s a lousy explanation, I’m sorry, but that’s sort of the best I can do. [Chuckles] JAMISON:  I don’t know the theoretical explanation of it, but I’ve often seen it referred to as a way to wrap I/O or things that need to touch the outside world and do it in a functional way. ZACH:  Well, in Haskell’s case, and I do not know Haskell beyond the, you know, much beyond the Hello World. I’ve read a little bit about it, but I cannot claim that I know it. When you’re not in a monad, you can only write pure code that can’t touch any of the outside world, either reading or writing. So, you have to had to invent all this monadic stuff to be useful. That being said, it’s still useful. So like, one of the most basic monads, the most basic monad is the identity monad, which doesn’t really do anything useful. Or it’s not pretty cool [inaudible]. But beyond that, you can go to what’s called the Maybe monad, or just like having a keyword called maybe. That’s kind of cool. And a Maybe monad is basically, it takes a function that can return, basically an op. Think of it as an algebraic optional value. So, this gets you around the whole null pointer exception. So, whenever you have an operation that can return either a value or no value. So, you’re like, if you want to find out if a certain element is in the list, is it a list of elements, right? It’s either there and you return the element or it’s not and you return a null value, which in JavaScript would probably be undefined. JAMISON:  Sure. MERRICK:  So, it’s sort of like a functional if-else. ZACH:  Yeah. How nice is you chain it so you can have a chain of ten operations, any one of which can return either null or you can do sort of like your third level and have an error version, an error value, nothing or error. And it’ll just return, basically it’ll just iterate down the list until it gets either nothing or an error. In that case, it’ll just short-circuit the rest of the list. So that you end up with this wonderful thing that you don’t have to have the whole, alright, if I get the previous stage returns nothing, handle it, but it returns this, you have to [inaudible] the last. MERRICK:  Okay, yeah, that sounds a lot like promise chains. You kind of see the connection between them. ZACH:  You know what you can do, if you’re better at symbolic algebra than I am, you can come up with a general mathematical description of all this stuff, which the Haskell guys do. And if you imagine, JavaScript does not have a static type system like Haskell does, but you can sort of imagine a type system into it. Think about a type, and you could imagine that basically what a monad does is that it sort of modifies the type, where in the Maybe monad view, they have a value or nothing, so that you end up with something that looks like that. And then basically you have a control flow that just knows what to do with the right thing. Then you can extract out your control from your operations. So, jQuery has a similar API, whether or not it’s actually a monad, you can argue about and I’m not really up on that. MERRICK:  Sure. CHUCK:  I really… MERRICK:  Go ahead, Chuck. CHUCK:  I really want to back up here for a minute and just talk about, we hear about these purely functional languages like Lisp and Scheme and Haskell. MERRICK:  Haskell. CHUCK:  So, what’s the difference between these languages and something like JavaScript which, to my understanding, isn’t purely functional? ZACH:  Right, well neither is Lisp, actually. So, if you look at Haskell, and if you haven’t looked at Haskell, you should. It’s really cool stuff in it even if it does break my brain. Haskell has some things that JavaScript doesn’t. So first of all, in Haskell, as in Erlang, all variables are single assignments. Nothing can, values don’t change. Second of all, in Haskell, a pure function can have no side effects so you have a very strong static guarantee that for any function, if you give it the same input parameters, you’ll get the same output. JAMISON:  So, you can write purely functional code in JavaScript, it’s just not enforced by the language or the environment at all? ZACH:  The language, as you say, does not enforce it. You could probably write some tools that would do that, but the language itself. And in Haskell’s case, they could do things like, because everything is purely functional, they can evaluate a lot of stuff lazily, where the compiler can say, “Oh, okay you’ve just asked for an infinite list but only need the first three elements so I’m just going to only compute those.” You could again, do that in JavaScript, you just have to write some code. MERRICK:  So, you say that two of the big things are single assignments, which is kind of like immutability, right? Once it’s set, it’s set. ZACH:  Yeah. MERRICK:  And then the other thing is that it’s no side effects. And it seems like no side effects occur because of the immutability. Like, you couldn’t have side effects, right? ZACH:  Well, no, because Erlang is immutable. But you still have side effects. MERRICK:  Could you explain that? ZACH:  Okay, so in Erlang, any value, once you’ve assigned it, is fixed. You can’t say, if you try to say x = x + 1, the compiler would go, “No, it doesn’t,” and, you know, throw its hands at you. CHUCK:  Yeah, but can you do x = 1 and then later on do x = 2? ZACH:  No, not in the same function. But you could have a side effect. You could, I don’t know, print some output, or send a message to another process, or send output back to the — you know, interact with other things in the world. CHUCK:  Okay. ZACH:  So in JavaScript, you don’t have the immutability but you can still have the functional composition where you can use either chain or something, or promises, to have a very ordered code base. So that’s really where it shines in JavaScript, is when you start, especially when using Backbone. In Underscore, when you start to just say, “Okay, I’ve got a collection of data records here and I want some result from it, and I’m just going to chain a bunch of processes until I get the value of the information that I want out of it.” Which could be filtered then do a couple of maps, then another filter, then a couple more maps, then a reduce, then you have your final value. JAMISON:  So, I want to ask you about something that’s been my experience in trying to do functional programming in JavaScript, and I’m by no means an expert so I’m sure I was doing a lot of things wrong. But just inside some little system that’s pretty self-contained once I got all the data in, I tried to do everything in a functional style and I ended up having really complicated data structures. Because sometimes I needed to return multiple results, I have to return a big giant array and then pass that into the next thing, and it needed a hash of some stuff from the environment, and I don’t know. I just ended up, so since I didn’t have objects where I could store state and compute things based on that state, I had to pass everything in and return everything out. So, it’s like passing the world into my functions and then returning this modified world out of it. And I felt like I was doing it wrong, because it seemed pretty complex. I mean, I could see the benefits for testability where you have everything you need in the arguments and stuff, but it didn’t seem to make the code any better. ZACH:  Yeah. I’ve had that too, and there’s sort of a couple ways you could deal with that. First of all, you can just capture immediate results and branch them out and re-merge them later, that’s one approach. MERRICK:  You just warped my brain. Could you explain that, what you just said? ZACH:  [Chuckles] Oh, sure. So say, for example in jQuery, you could capture some DOM elements, do a couple operations on them, assign that result to a variable, do something else and then do a couple more operations. MERRICK:  Okay. Like a variable outside the scope, you mean? ZACH:  Yeah. MERRICK:  But then, don’t you throw away the testability at that point? ZACH:  No, it’s a compromise. JAMISON:  Well, not if you’re testing the function. It seems like you kind of encapsulate anything that is purely functional can do whatever it wants in the middle, as long as it’s deterministic with its inputs and outputs, right? ZACH:  Yeah. MERRICK:  But if your function is talking to some variable that, you know, it depends on some scope existing? ZACH:  Oh no, I mean, it’s not so much depending on some variables so much as just your chain simply returns a value at the end and you can use that value to simply restart another chain later. JAMISON:  So kind of split, instead of chaining everything together in a giant list of ten functions and maybe to do that, you need to have a more complicated data structure, you might split out the things that make the data structure complex into two chains and then combine them at the end, or something like that. ZACH:  Yeah. With Q, there’s some nice things. If you have three or  four promise chains going, there’s an operation in Q, I mean Q library, to interpret what it is, that lets you say, “Okay, when all of these complete, go on.” So if you’re waiting for four things to happen, you can say, “Okay, when all of promise1, promise2, promise3 and promise4 are done, create a joint promise,” basically. And you can do that in Q. I forgot the exact syntax, but you can do it. Honestly, I’ve been staying out of JavaScript for the last few weeks, as much as I could. The frontend of our company is being done by a different developer, and I’m mostly handling the API side. JAMISON:  Sure. So we kind of have touched on them a little bit, but I don’t know if we’ve actually enumerated the reasons why you’d want to do functional programming, especially in a language where you can do object-oriented or procedural, whatever programming you want like JavaScript. So did you want to just enumerate some of the benefits? Like, make the case for doing it? ZACH:  Okay, so first of all, you end up doing a fair bit of it anyway, because in JavaScript, you end up throwing around functions for callbacks and stuff. So you know, actually using something like the Q library, the promise library that you guys talked about some episodes back, by the way. I’ll find a link to it in a minute. You can end up avoiding the callback ladder of doom where you end up with six callback levels deep, which I know I’ve got. I’m sure everybody else here has done. JAMISON:  Oh, yeah. ZACH:  You kind of want to avoid that. And then also in, say when you’re trying to process using a list, process a list, you also can get that. The other thing is that it’s just a very powerful metaphor, a powerful mechanism. Interestingly, we’ve started going into and haven’t talked about higher-order functions, where you have things like map, or you can just start your own where you can abstract out some detail where you just say okay, we haven’t touched this part. Or you can create a function where the part of the operation of the function is another function where you can pass in abstractions to this. So map and reduce and those functions are very good examples. Where you can say, “Okay, I want to do something to every element of this list,” or, “I want to do something to every record in this data set,” where you just say, “Okay, I know how to handle one element, so now I just need to get that to handle any elements.” It’s kind of cool when you can spend a whole day writing code and never use either an ‘if’ or a ‘loop’ in any way. I’ve done that a couple of times. Sometimes without intending to, but it’s really, “Ooh, I haven’t used a loop in three days!” So the ability to use higher order functions is something that’s very convenient. And even in non-functional JavaScript, for example, I’ve been playing with Ext JS a lot, a bit rather than a lot, a little bit recently and in the Ext JS store, the filter, basically there’s a filterBy, you pass in a function then you say apply this to every element in every record in the store and filter out all those for which it returns false, which is again, very convenient. You’re trying to just say I want to show a subset of my data. You don’t have to scoop up a general rule for filtering, you just say I’m just going to pass you a function and it’s going to figure out what to show and what to hide. And that function can change as you put things in your interface and things like that. And of course, you don’t have to, in JavaScript you probably shouldn’t do functional programming exclusively. I mean, you can if you want to, I guess, but it’s [inaudible] languages like JavaScript is, it is a multi-paradigm language. You can use functional programming where it makes sense and then go use object-oriented programming in many of the same places. MERRICK:  Right. You then chain, like the _.chain that we’ve been using, that’s not purely functional because you’re kind of creating this object that stores the state internally and calling methods on it? ZACH:  Right. I mean, you’re creating — you know, the thing is, every iteration through the chain, you’re actually returning a new object. You’re returning a new wrapped object. CHUCK:  So, you’re not modifying the original values that were put into it. ZACH:  Right, you’re never modifying the initial values. You’re simply creating a new version of it. With jQuery… MERRICK:  Interesting. So these aren’t at all methods on chain that eventually return chain, it actually is passing down this Underscore wrapped… ZACH:  Yeah. MERRICK:  Oh, that’s kind of cool. CHUCK:  I kind of like the map reduce example again. You map, map, map, map, but you have the original values off in some variable somewhere else, and it’s returning a new set of values every time you call map. And then when you call reduce or filter or anything like that, again, you’re getting a different set of values. And it may be a reduced set of values, it may be a specific subset of the values you had before, or it may be some view on the values that you had in the original set. ZACH:  Right. CHUCK:  But it’s not changing the initial values, so you still have those off somewhere else that you can always call back to. ZACH:  Right. jQuery, it seems, when you first launch, when you capture something with $ operator in jQuery, and then you do $(“selector”).show().somethingElse().fadeOut(), whatever, each of those times it’s returning, you’re actually getting a new jQuery object that’s a transmutation of the prior one. So, you can actually capture that in a useful way. Basically, in the chain, you are actually transmuting, you’re actually not changing the initial values. You’re simply creating a new set. MERRICK:  So essentially, [Crosstalk] JAMISON:  [Inaudible] MERRICK:  Oh, sorry. So when you’re doing _.chain, it’s kind of the same thing as just wrapping something in the Underscore objects and then going from there, right? ZACH:  Exactly. MERRICK:  Interesting. So chain is just kind of long-hand for that wrapping approach. ZACH:  Yeah, I mean the great advantage of it is if you’re going to do seven operations or five operations or whatever, you could do value1 = _.map(initial value) and then just assign it to a new intermediate value every time. But this just means, it just saves you notation. MERRICK:  Got it. JAMISON:  So one thing I noticed in my experiment with doing stuff in a purely functional style is I was doing a lot of copying. Is that something that languages that are more designed for functional programming will take care for you? ZACH:  As in copying data? JAMISON:   Yeah, I was copying a ton of data around so that I wasn’t modifying stuff and then not returning anything, but just modifying the thing that gets passed in. And is that something that compilers or languages themselves will take care of for you, to do that more efficiently? ZACH:  Sometimes, usually. And you only just learned to pass in less stuff. JAMISON:  Yeah. ZACH:  And the other thing that JavaScript doesn’t have, unfortunately, that would be really nice for functional programming style is any sort of tail_call optimization. JAMISON:  Can you explain what that is? ZACH:  Okay, so if you have a function that ends by calling another function, the last thing is just a call to a second function, what a lot of languages like Lisp or Haskell or Erlang will do, is instead of adding a new stack frame, they simply replace the prior stack frame with new function. So in Erlang, for example, and Haskell’s the same, there’s no loop up, there’s no for loop. You can’t reach your variables. So you loop by doing recursion, by using a tail_call optimization, you can recurse effectively infinitely. JAMISON:  Without blowing up your stack. ZACH:  And the stack doesn’t grow. CHUCK:  I’m just trying to wrap my head around this. So when you recurse — okay, so let me back up. The way I understand Lisp and some of these other languages work, you have the cdr and the car. ZACH:  Yeah, Lisp is famous for giving things functional names. CHUCK:  So, it’s the first element and then everything else. ZACH:  Right. So you have a Lisp list. You have two operations: car, which is the first element of the list; and cdr, which is basically the tail of the list, everything but the first element. And those names relate to the architecture of an IBM [inaudible] that was current in 1958. JAMISON:  Yeah, the names are all pretty funny. CHUCK:  So anyway, so when you’re talking about recursion, what you’re saying is you have an operation that operates on the car and then calls itself on the cdr, because the car of the cdr is the next element. ZACH:  Exactly. And of course, you could do this in JavaScript quite nicely. It doesn’t have to be — I mean you could also, say, use recursion to do binary search, searching through a binary tree or lots of other things. One place I ended up using this sort of operational, though not strictly speaking recursive in terms of the code, it is logically, in JavaScript is if you have a list of things you need to send to the server. If you have 20 elements you need to send to the server and for some reason you don’t want to put them all into one AJAX call, because I don’t know, it’ll blow up your server or something, basically you could use that type of operation where basically you treat it as an array. You send the first one element to the server, when the AJAX call returns, you then just take the remaining list, which is all of the list minus the first element, and apply it again and just keep repeating until you run out of elements. I’ve done that in JavaScript once or twice for reasons that I don’t remember. Normally obviously, you’d just rather send the whole thing in one go, if you could. CHUCK:  Right. ZACH:  But this doesn’t have to be that. You can do recursion for any number of things. If you want to compute the Mandelbrot set, the algorithm is basically recursive. In Haskell or Erlang. You can do a quick sort in one line of code, through recursion. It’s not necessarily the most efficient implementation of quick sort, mind you, but it’s one line, two lines of code. It’s really impressive. CHUCK:  So can you explain now, in terms of the first element and everything else, how the tail_call optimization works? ZACH:  Okay. So normally, when you’re in a function and you call another function, you add a frame onto your stack. So, given that your computer is fine, your memory is fine. At some point, you run out of space in your stack. In JavaScript, if you recurse infinitely, at some point, your stack explodes and your program, your code crashes. CHUCK:  Right. ZACH:  Now in languages that use recursion very heavily, of which Lisp, most functional languages that don’t run on the JVM falls in this category. What they do is basically, in cases where they can, in some cases you can’t, when you make that call, that next function in line, instead of pushing another frame onto your stack, you simply pop the current frame off and put the new frame in as a replacement. So, you can recurse infinitely with a constant stack. CHUCK:  That makes sense. ZACH:  This doesn’t work if you need to operate on the return value of the call function. So if you say, if you were — this would be a stupid implementation. But you’re using recursion to add a list of numbers and you said okay, the sum will be 1 + the sum of the rest of the list, then you can’t do that because you got to return the rest of the list then add 1 to it so you still need that stack frame. That’s probably not the best way to add a list of numbers, but it was just for a simple example. So, that’s how you do that. I think I read that they’re talking about adding tail_call optimization into whatever the next version of JavaScript will be. But I have no idea when they’re going to do that or if they’re going to do that or what kind of [inaudible]. MERRICK:  So, we had the opportunity to talk about Dave Herman about this exact thing two episodes ago and he mentioned they absolutely are. And he explained it as well. So, if anyone didn’t grok your explanation, we also have David Herman’s explanation. ZACH:  Which episode? I don’t know if I caught that one. I’ll just go check. CHUCK:  I have to say that this is one of those things to that you kind of have to hit your head against a couple of times before you really get it. So, I highly recommend, if you’re trying to understand the approach and tail_call and all this stuff, that you listen to both episodes. Listen to both explanations because they explain it a little bit differently and hopefully then, you can get hour head around the concept that we’re addressing here. ZACH:  It might also be useful, if you really want to get your head around the concept, to step away from JavaScript a little bit and go play with Haskell or Lisp or Erlang, or one of the languages that really emphasizes this stuff, probably Haskell or Lisp. And play with it for a while and really get your head around it in a different language where you could sort of have a blank slate. Because the thing is, if you can figure out how to do something cool in Lisp or Scheme, you probably could take that solution back to JavaScript with you in a way that if you just stay in JavaScript, you might not. So, it’s one of those reasons why learning a new programming language every so often is just a useful skill. It’s a useful thing because if you learn a new language, you’ll discover it does something really awesome. If you haven’t read the book ‘Seven Languages in Seven Weeks’ from The Pragmatic Programmers, you should do. If one of those languages doesn’t make you, one of the seven doesn’t make sit up and go, “Oh, my God! That’s the coolest thing I’ve ever seen,” then you’re in the wrong line of work. CHUCK:  [Laughs] ZACH:  I don’t know which of the seven it’ll be. For me, it was Prolog, which I’ve never actually used. They present a Sudoku puzzle solver and it’s 20 lines of code. And it’s like, you’re looking at it like, “Where’s the program? That can’t…” MERRICK:  [Laughs] That’s awesome. ZACH:  I mean, it’s like, “Oh, my God! This is the coolest…” Maybe for somebody else, Scala or Erlang or whatever, I fundamentally feel that learning seven programming languages, if one of them doesn’t make you sit up and go, “Oh, that’s just cool,” you shouldn’t be a programmer. [Laughter] ZACH:  I don’t care which of the seven it is, it just better be one of them, at least. CHUCK:  Yeah. MERRICK:  Are there any, I know there’s some heavy functional programming libraries, like libraries that focus explicitly on this kind of stuff. Like there’s Valentine. Jamison, what was the name of that library that JavaScript Allongé is working on, that book, do you remember? JAMISON:  Oh, no, but I have Google. [Laughter] MERRICK:  Well, I’m wondering if you know of any functional libraries in specific, I mean aside from Underscore, that you recommend for learning this kind of stuff. Stuff that maybe has things like Maybe. ZACH:  I actually have an implementation of the Maybe monad somewhere on, I need to just [inaudible] I can find it. So here is an implementation of the Maybe monad in CoffeeScript. Now, you can test it. MERRICK:  Very cool. Yeah, we’ll post that to the show notes. CHUCK:  Yup. ZACH:  The Q promise library is one I like a lot, because it solves a problem that, if you’re doing any sort of JavaScript development, frontend or backend, you have, which is the Callback Hell. MERRICK:  It’s so interesting that you reference Q, because I’ve been using Q for a long time and I’ve loved it but I never considered it a functional programming approach. ZACH:  Well the truth is, I found out about it through this show, you guys. [Laughter] MERRICK:  Woohoo! ZACH:  I found out about it and was like, “Hold on,” started reading about it and was like, “Hold on, I think that’s a monad.” And I sat down and worked out the map and like, “Yup, it is.” JAMISON:  So, Q seems cool because it seems like a way that you can make things that aren’t functional into a functional style, because you take things that have callbacks and asynchronicity. MERRICK:  I just love Q. JAMISON:  And you can turn them into things that just take an input and return an output. ZACH:  Yeah. MERRICK:  Absolutely, Q is just wonderful. ZACH:  It’s the idea that you can take the sequencing aspect and separate it out from the functional aspect, smaller functional. Take the sequencing and separate it from ‘this is the problem I am trying to solve’ aspect. Okay, this is going to happen and then this has to happen when it’s done. Okay, I don’t need to know the mechanics of how that works. I just want it to work. I’m a big fan of the whole higher abstraction. You know, I spend a lot of time in Erlang where error handling is inherently handled somewhere else. The motto of the Erlang community is ‘Don’t write defensive code, ever’. Well, almost ever. CHUCK:  So, I have one more question and then we’re going to get into the picks and that is, what do you find that you miss the most when you’re working in something like JavaScript where it’s not totally functional? And what do you find that you miss when you’re working somewhere where it is totally functional? ZACH:  So, the thing that I miss the most when I’m in JavaScript versus Erlang isn’t necessarily purely functional, it’s a syntax thing, but it’s pattern-matching. In Erlang, you can say, “Okay, I have four clauses and a function.” And depending on what the input is, it’ll run the right one. And it’s just very concise. And also, the concurrency model in Erlang, it’s just really nice. In terms of the other way around, what I really like about JavaScript, CoffeeScript for that matter, is it just has wonderful syntactic sugar. You can make the language do almost anything. It may come around and bite you later, but it’s a wonderful syntactic sugar where you can say, “Oh yeah, I can just make it to that.” We’ve taken this language, which is in some way syntactically not so wonderful, and then we just added things like Q and Underscore and jQuery. If you actually try to do raw JavaScript interfacing with just the DOM, if you told me I had to do that, I think I’d go shoot myself or something. CHUCK:  [Chuckles] ZACH:  Really, I don’t want to do that. I’ve done that, it’s not fun. It’s really not. But you start adding Q and jQuery and Underscore and all these other things and suddenly it’s like, “Oh, this is actually really nice.” So that syntactic sugar, where you can just say, “Oh yeah, and you’ll take a bunch of functions over here and stick them over there.” MERRICK:  Yeah. ZACH:  That’s really awesome. CHUCK:  Alright, cool. Well, we’re right about at our time limit, so I hate to cut you off, but I’m going to. ZACH:  We’ll just do part 2 some other day, if you want. CHUCK:  Yeah, that’s true. Alright, well let’s go ahead and do the picks. Jamison, why don’t you start us off with the picks? JAMISON:  Alright, I’m going to go with two. One of them is this video by someone called Vi Hart. I’ve never heard of her before, but I was exposed to this on Twitter a couple of weeks ago, and she’s talking about the Normalcy of Pi. And she has a bunch of videos like this where they’re about deep mathematical things but they’re explained in a really clever and easy to follow way. It’s one of those YouTube things where she makes like a bunch of drawings and records herself talking over the drawing that kind of explains what she’s talking about. So, it’s really well done. And then my next one is, continuing my series of goofy tumblrs. It’s ‘Sport Balls Replaced with Cats’ by Tumblr.com. And it’s what it sounds like. They take pictures of athletes slam-dunking a ball and then they Photoshop a cat in place of the ball. So, it looks like they’re slam-dunking a cat. [Laughter] JAMISON:  It’s pretty great. Very mentally stimulating. [Chuckles] Those are my picks. CHUCK:  Awesome. Merrick, what are your picks? MERRICK:  So, my picks, since we’re talking about functional programming with JavaScript, I’m going to pick this book. JavaScript Allongé. I think it’s a-lonj, it might be a-long-ay, I don’t know. But it’s a book on functional programming and it also has kind of a library. And it talks a lot about the things we discussed today. And secondly, I’ve been using this library called BonsaiJS and it is awesome. It’s kind of like the good abstractions of Flash in the browser. It’s awesome for really rich animation kind of projects. CHUCK:  Awesome. ZACH:  I’ll check that out. JAMISON:  Cool. MERRICK:  Thanks. CHUCK:  Alright, my picks this week. My first pick is there’s a video from the International Space Station of an astronaut wringing out a rag, a soaking wet rag of water. ZACH:  I saw that, that was awesome! CHUCK:  It was really, really cool. So, I’ll put a link to that in the show notes. Just, well, it was awesome. So anyway, I really, really liked that. The other pick I have is something that we’ve talked about. We actually had an episode on it. But I’ve picked up a contract that wasn’t Ruby, it’s JavaScript, and we’ve been using RequireJS and AMD as part of the project, and I have to say that there’s some pretty awesome stuff in there. It’s one thing to talk about it, but it’s another thing to actually use it. MERRICK:  It’s wonderful. Yeah, it’s awesome. CHUCK:  Yeah. CHUCK:  I’m still getting used to some of the patterns for use that it has. But yeah, in some of the areas, it just makes things a whole lot simpler. Anyway, Zach, what are your picks? ZACH:  So, I’ve got a couple. Tech pick, first of all I’m going to pick my own podcast, Mostly Erlang, we mentioned it earlier. But people who’d go and subscribe would be very much appreciated. It’s just getting off the ground. We’ve got one episode recorded so far, and hopefully a second by the time this comes out. As I may have mentioned earlier, I live in Israel but I’m originally from Boston. So, I just want to pick and sort of honor all the first responders in the Greater Boston area from the last couple of weeks’ work. It’s almost kind of a frightening time for all of us Bostonians, even though it’s real far away. So, it’s nice to know that we’ve got good people. And the third thing is a piece of Israeli tech that I’m really impressed by. It’s call the Iron Dome. So it’s an anti-missile system that basically is designed to take out short-ranged rockets. It can basically sport a rocket launch in within about the 15 seconds of flight the rocket would have where it hits, determine whether or not it would hit populated civilian areas and if so, fire an interceptor and take it out with about 90% reliability. During out last round of conflict, it reduced casualties all around. CHUCK:  I don’t care which side of the conflict you’re on that, it’s cool technology. [Chuckles] MERRICK:  That is awesome. ZACH:  I’ll send you a video. This was from, here let me send you a link. It’s purely defensive tech. All it can shoot down is incoming rockets. So the video, it’s from a wedding that was in Beersheba, which is in south of Israel. And they’re at this wedding and the air raid sirens go off, everybody runs for cover. Because when the air raid sirens go off, you run for cover because you have about, depending on where you are, between 15 and 90 seconds to run for cover. And you just see these rockets come out and fire and then the all clear sounds. It was truly astounding. Thankfully where I live is part of the [inaudible] into the boonies outside Tel Aviv that we didn’t, I didn’t actually hear. The only air raid siren I heard was a drill from school around my house. But it’s a very scary time, really. But yeah, it’s truly amazing technology. They did a huge job on it and I just have to thank the people involved in it, Israel and the United States, because the US government paid for a chunk of it. Yeah, really good technology. CHUCK:  Cool! Alright, that’s the show. Thanks for coming Zach. It was a really interesting conversation. JAMISON:  Yeah. Thank you. ZACH:  Yeah. Thank you so much. As I’ve been saying, I’ve been a fan of the show for a while. MERRICK:  Yeah. Thank you, man.