Kent C. Dodds
TYLER: What's up?
KENT: And Lin Clark should be joining us shortly. Technical difficulties there. And then we actually, our guests today are also panelists but they our guests. So introducing them as guests, Brian Lonsdorf.
BRIAN: Hey. (laughs)
KENT: And Dan Abramov.
KENT: So, because you are our guests, let's go ahead and give you two a second to introduce yourselves and maybe talk about your background in functional programming. Why don't we start out with Brian?
BRIAN: Sure. Looks like Lin's here now too, if you wanna say hi.
LIN: Hey, sorry about that. My headphones weren't working, so I couldn't hear y'all, but glad to be on now.
BRIAN: You got the tool thing on there too, cool.
BRIAN: Yeah. (laughs) Welcome to (mumbles) or whatever. So, yeah, me, I am a normal dude, I guess, I did learn some functional programming from a normal-person perspective, I guess (laughs) and so people seem to talk to me about things in layman's terms, and it works out. I guess that's how I'm gonna describe myself. (laughs)
KENT: So by "normal dude," you mean you're not like a... you don't have a doctorate in computer science and you're not just like, not that they're not normal, but is that what you mean? (laughs)
BRIAN: I'm as normal as it gets, yeah. I don't know much, like, you know, I've been learning some linear logic and set theory and things throughout the years, so I could read the white papers. And it's fun to kinda share my adventures and talk to people about these things. And I also make little stop-motion videos, 'cause, why not? (laughs)
KENT: Yeah, I wanna talk to you about those later. (laughs) Cool. So Dan, let's get an intro from you.
BRIAN: Uh, sure. (laughs) It's like a trick question, right? Cause everybody's like, "Well, what's functional? It means you're using Monads and type, so that means you're able to use macros." There's all sorts of different definitions, but my favorite one is just being able to program with pure functions, so you know you can have a reliable output or input every time. And we say functional programming coming from the mathematical function perspective of a set of relations or just input to output, sets of pairs. So that's pretty much my definition. Anybody else want to throw stuff in?
TYLER: Can you define "pure functions" for us?
BRIAN: A pure function? Oh yeah, it's just a function with no side effects. For every input, it will always give you the same output so you could give it whatever input you want and you always get the same result without any observable effect.
KYLE: Just to chime in real quick, for any listeners that are kind of like lost or wondering about this stuff, actually, today there was a fantastic couple of blog posts going around (and it's gonna be in my pics later.) I don't know if we'll talk about this as well, but Chris Jenkins has a couple of really great blog posts that break that down very simply.
BRIAN: Yeah, that's great. And I read a little bit of it and just the examples of addition and multiplication or string to upper, things like that. You know, those functions, you don't have to be scared to run or test, or, you know, it gives you an intuition pretty quick.
KENT: So maybe you can talk about some of the benefits of programming in a functional way, the functional programming paradigm? Why would I really care to write pure functions and write my applications in a functional way?
DAN: So I think my favorite benefit is really a practical one, is that they are so easy to test. Like, if you write pure functions, it is safe to run them in the test code many times. You're not making some requests that you can't control. So, it's just calculations; you can give them the inputs, you can assert their outputs. And it's just amazing for cases when you have complicated logic and you need to really test this logic through.
So I remember the first time I actually went full functional programming, when the product that needed it was when I was working on a parallax-like animation on a complex landed page, that had a lot of different parts that depended on the scroll. And so the first attempt to write the code was imperative, like I watched the scroll event, I would move the DOM and up and down. And it didn't quite work correctly. And I would bump into weird edge cases where I would scroll too fast and some element would get in the wrong position and I don't know why this happens.
So I applied functional programming in a way that I extracted the calculation logic so that I have this function that achieved the current scroll position and returned the positions of all elements on the page. And this allowed me to test it without actually running it in the DOM. And I got the right logic. So for me, this is the main benefit of functional programming is that it's very easy to test.
LIN: I think that it being so easy to test is a side effect of it being easy to reason about. Which, even independent of tests, I think is a benefit in and of itself. But of course, once you can actually test it it's great to have those tests in place.
DAN: Yeah, yeah.
KENT: Yeah, that's great. So I forgot to mention at the beginning of the show, if you are watching live and you have a question, go to Twitter and with the hashtag #jsAirQuestion, go ahead and ask your question and we'll answer those at the end of the show. So, sorry to take us away from this for just a second.
BRIAN: it's good. (laughs) I did wanna throw in one thing in that last question about why. And for me, my ultimate goal in life is to get rid of Selenium. I never want to have to write a Selenium test ever again. (laughs) And using pure functions and functional programming to separate the concerns of side effects from calculation, it allows you to really write these elegant programs that you could reason about and you don't need to go launch a browser and click through things. And I think it's going to eventually unlock the key to a much better programming style where we can get around these long integration tests. I actually put a link in the show notes from a blog post that talks a little bit about that.
DAN: By the way, have you noticed that people started really rejecting this easy-to-reason-about thing as a buzz word? Because everybody keeps saying that and people are like, "I don't know what you mean." (laughs)
LIN: Yeah. (laughs) And I think that it's hard to explain it until you've actually gone through it and experienced, you know, what it means to not have to keep state in your head. And once you've actually gone through and had that experience, I think that the buzz word actually starts to make sense. I don't know, that might just be my experience. Do you feel that too, Dan?
DAN: Yeah, I think maybe one of the reasons it happens is also with this, there are different, you can take functional programming to different extremes, right?
DAN: You can just apply it a little bit or you can apply it fully. And there is this saying that functional programming, 80% of functional programming doesn't work, like you need to go 100%. Some people say that. And so they market the people who use it a little, saying that, "Hey, it's too hard to reason about." So there's fragmentation in the community about that.
KYLE: I would say I have been working on trying to understand the principles of functional programming for a really, really long time. I've read every blog posts and book and gone to every conference talk. And in all of that exposure, the terminology has never sunk in for me. I think the concepts have sunk in, but I have never been able to wrap my brain around those. So I think there are some, at least some people, for whom the terminology can be a blocker and I don't think we should propagate a culture that says, "If you don't understand the terminology, you're not part of the club." I think the concepts are the most important thing, which is why I like Brian's take on things because he basically tries to break it down to something that you could get the terminology around or you could leave the terminology aside and still benefit from it.
TYLER: I actually think that's the biggest benefit of what Dan and Brian has done is with Dan, with Redux, he's taken functional programming and kinda brought it to the masses. And with Brian, with all his YouTube videos and things like that, kinda like you mentioned, Kyle, it's refreshing to not have to worry about what a Monad is, but just worry about immutability and things that actually are practical to me.
BRIAN: Yeah, oh, there's a big problem in the, well, it's not really a problem, but divide. And you know, people talk about the names of like, "Oh, why don't we just call it a mappable? You know, you have a functor and what is a functor, and that scares people." And then there's, you know, "mappable makes instant sense; I have a map function...." Am I breaking up? It feels like everything stopped?
KENT: You're totally good.
BRIAN: I'm good? Okay. Well anyway, the only thing I think that's tricky about it is I wanna say mappable and say it has a map function, but any object with a map function is a functor or a mappable, right? But when you use the word "functor," you're talking about laws and properties that must hold an intuition about it. So I know just like, addition is associative, I can apply that to any monoid, or, you know, things like that. So it's like, when you throw the scary word out there, you're like, "What's a Monoid? Ahhh!" But when you say, "Oh, something with a concat method." You know, it becomes much more friendly and people are happier about it, but it also gets diluted a little bit to where people might be making instances that have a concat method, but aren't necessarily going to hold those properties and laws.
KENT: Yeah, you pretty much just freaked me out there for a second.
KENT: I think this is very true. And I wonder if maybe there's something that we can do, or something to be done about like the confusing terminology and just how things are so different from what we're used to as imperative programmers and non-functional programming style. So what are some things that somebody new to this space can do to kind of get in to functional programming in an easier way?
BRIAN: I was gonna say, "watch Dan's Redux videos." (laughs) Those are great. I don't really know what else. (laughs)
BRIAN: Kyle has a lot of, what he calls functional light stuff that really helps, it's in the same vein, like using that filter and immutability, from what I understand. Kyle probably knows more about this.
KYLE: Since you bring it up and since one of our show sponsors is Frontend Masters, I do have a programming course. It was taped earlier this fall and should be out, I think, in maybe February or something. But I have a course called Functional Light Programming. It tries to take the same perspective as you're hearing from our guests today, of building up the concepts and staying away too much from the terminology. So I cover all the things like pure functions and immutability from a very, very simple perspective. So it's like the 50,000 foot view of it. But that is my take, is that those concepts have improved my code even though I've never -- and probably never will -- have the justification to hold the functional programmers membership card, 'cause I don't really consider myself that. But I think my code can benefit from understanding why a pure function is useful or understanding why treating a value as immutable. Whether it's immutable or not, treating it as immutable improves the code. So I think that's true.
But that brings me to a point I wanted to kind of push back on a little bit, Brian, I'm curious. You said that there could be a problem if somebody takes one of the concepts and misses out on some of the other concepts. and you're trying to reason about something. Do you think that it is important for a piece of code to basically have a label on it that says, you know, like a big neon sign that says, "Hey, functional programmers, all of functional programming is alive and well in this program so you don't have to think about it. " Is that where the value comes? It's almost like a shared lexicon, if you will. Or is the value more in those base concepts?
BRIAN: Well, I think the reason people get so passionate about this is because there's a way to, if you're working within this small framework, we'll call it, like this mathematical framework, where you're saying, "I'm not gonna go outside and do unprincipled things. I'm gonna try my best to stay within these constraints," everything ends up being a LEGO, everything composes with each other. And otherwise, you might have some LEGOs here, some Silly Putty there, some Lincoln Logs there, and you need adapters, and, you know, everything was pure but then something kinda poisoned the well, right? And it kind of blows away the composability of it all. So when I know I'm not in a composable world, sprinkling in some stuff, and it doesn't really matter at that point, like I can program how I like and it can still have benefits. But when I am in a pure world, it's very much like anything will kind of taint the purity of it if you're not very careful about following these laws and properties, and saying like, "Oh hey look, if I have a map followed by a map, I can just fuse those into one map." And someone's like, "Oh, well, my map doesn't actually work like that." (laughs) You know what I mean? So it's hard to reason about. Really, it's all built on generic composable interfaces with properties that hold. And if those properties hold, you end up with your beautiful LEGO world, right?
KYLE: So it's like 100% is great, or like 20% is great, but anywhere in the middle is kind of dangerous because it pretends too much and trips you up, is that what you're getting at?
BRIAN: Um, yeah, I guess I'm getting at if you want the guarantee... for instance, if you have, if everything's returning a future, which is, it's like a promise that doesn't run until you kind of pull the trigger, so it'll build up the computation, you can map over it. Instead of calling "then," you call "map," it works exactly the same way. And you can just go ahead and work with futures all day long. And at the end, you call fork and it all runs. But if somebody cheated throughout here, and actually ran it in the middle of something, or, let's say, they mixed futures with a promise that's not actually going to be pure and hold its value, then all of a sudden, when you think things are going to happen, they're not. Or your properties of fusing these things into one computation or one action that doesn't actually hold. So like you said, it's 100% if you really want to get those benefits, and anything less is still great. But it's good to know, or else you're gonna be tripped up. (laughs)
KENT: I actually, I had a question on that terminology, since you brought it up. Is there a danger in ignoring the terms of functional programming? Or should we just kind of say, "Oh, the terms are for computer science experts, theoretical stuff. Let's talk about more practical things." Is there any danger in ignoring these terms?
DAN: I'm not really sure. I think it depends on how deep you want to go. Because many people who tweet and blog, they want to go deep because they care about building the stuff, building the abstractions, right? But there are also people who don't really care about building abstractions, they want to build products and they don't want to go deep into the terminology. And I think we ought to make it accessible to them too. It's not really a fault if you don't want to learn this world of functional programming. So of course, it's not going to be all the way, but if we can make at least part of this accessible, I think it's a good start. And, for people who want to dive, they can dive.
KYLE: He has a great quote on this topic, he says, "As soon as you learn functional programming, you stop being able to teach it." And I don't know whether that's entirely true or not, but at least for my own part that's one of the reasons why I have held back from getting too steeped in it. Because I don't wanna get to the point where I can't think in anything other than the terminology, because I think that will make it harder to bring people on board to it. So I do think there is almost a danger in getting too much into the terminology early on, is because we basically create almost an elitism; either you get it, because your brain is wired that way, or you don't and you pretty much should just go back to your kiddie framework and let the real programmers figure out the terminology.
BRIAN: It's so elitist in that regard. I think what I've tried to do with my examples throughout the last couple years was any time someone tried to teach something, I would hear crazy words and no examples and implementation detail -- and that was it. They were like, "Oh, here's a comonad, you can do this," but there's no actual use case and you're like, "What?" And so by providing use cases you can kinda see what this thing is, and, you know, of course there is the danger of, you know, diluting the meta information that comes along with the term. But I think I found myself, I tweeted it yesterday, that I found myself writing the sentence that the... it was like an interesting example of a contravariant monoidal functor is a transducer, (laughs), I was like, that's just...
But at the same time, somebody says, "Oh, it's contravariant. I can map over the inputand it's monoidal; I can concat it together and it's a transducer, so that's gonna be able to transform as it reduces." And all these things are so loaded and it's a terse statement, but I've expressed so much in so little, not to mention the properties that hold contravariant functors and monoids and things like that. As well as, you know, being able to say, "Oh, well if I have two monoids, I can put them together and form a ring and now we can get the X and Y axis to like, you know, do some crazy algorithm, that I don't know how to write. I can just provide two monoids." It's the same as, we're just talking about interfaces, but they're scary and it's elitist and it's kinda ridiculous. So how do you preserve the meta information and the properties without scaring everybody to death?
BRIAN: Um, do you want to go, Dan? (laughs)
DAN: Yeah, I just wanted to say that I really like the Flow approach, the gradual type. And it's up to you how much you want to opt into that, and you always have the escape hatches. And I think escape hatches is something that functional programming community doesn't like. And this is the elitist part, where you don't want to provide a way for beginners to opt out of that for a second, because then you're just not sure how to fit this small concern into the global string things, right? And so, yeah, I like that you can, with flow, you decide, you get to decide, where you want to opt into that and if you really want you can opt out for part of the code.
KENT: So we've talked about functional programming, but the show is also a little bit about immutability, and I think they're related. Can we talk a little bit about how immutability can help us in our programs?
...or it can't, evidently, so, yeah, forget about immutability. It's just, yeah, it's done (laughing) just kidding. No, I think if you've paid attention at all to blog posts and the things that are going on in the React community and even Angular 2 now, you've heard all this stuff like, "Oh, immutability's awesome because you can do like a strict equality check on the objects rather than a deep equality check to check that." And then there's always the question, "Oh, well, isn't it crazy memory terribleness to make copies of objects every single time?" I think there's enough content out there that covers most of those cases. So, is there anything in functional programming and immutability, or, sorry, if we don't program functionally or, sorry.... Let me start all over. If we don't program with immutability, do we still get all the benefits from functional programming, or is it just a whole lot better to combine the two? How are they really related?
BRIAN: I'm back, by the way.
KYLE: Before the guests actually give the right answer, I will just throw out, (laughs) I'm a fan of treating things as immutable even if they aren't immutable. And I think that would frame my particular perspective. I don't think we actually need to have something immutable to gain the value from the concept of immutability.
BRIAN: My computer restarted and I wanted to say something about programming, Kyle's last question, 'cause it's a really important one. But let me just let Dan talk about immutability 'cause he's better at that than I am. (laughs)
KYLE: On that topic, I am curious what you would say, because I've always seen one of the primary benefits of a library like Immutable.js is that it gives us the capability without the performance hit. And I think we shouldn't underestimate the potential problems of creating a chain of, you know, say 10 different map and filter, and reduce calls in one big chain, where at every single step, an entirely new array is created and the previous one is potentially garbage collected. There's value in things like transducers, where you try to combine those steps and not loop over them, but it's not just a CPU cost, it is a memory cost. And I've always seen that a library like Immutable.js, it's like growing up into functional programming when you realize, "Okay, I have the theory of FP is that I just make a new array whenever I do a map call." But in practice, that's terrible. I don't wanna create a whole new array. So what I actually need is to make a new thing that's only the delta, and "Oh, okay, that's gonna be really hard, so that's why I need a library to figure that part out for me." So I'm curious what your perspective is on that, do you think that the performance is something that we should think about as programmers?
DAN: Yeah, totally, but I think it really depends on the product and it really depends on the formats you want because if it's a product for native and if you're changing stuff very quickly, of course you want to minimize the memory usage and you want to minimize the (mumbles), but if it's a website that displays a feed that doesn't change all the time and you can hit "load more" and it displays 20 more items, like I'm not sure that there's a lot of data mutations going on right now. So that's really, are you willing to trade the need for developers on a team to understand the immutable APIs? So you need to learn another API, you need to be capable to use it, you need to take the heat of the tooling, the lack of proper tooling support. Are you willing to trade that for great performance and for constraints? And some people are, in big products, in complex products. But if you're just a beginner learning to create your first website, I don't think you need to think about that. So it's an optimization. And I think before choosing and jumping to conclusions, you need to build a simple stress test for the kind of usage you expect for a product, and measure, does it have a performance problem? And if it does, then it should be using mutable.
BRIAN: That's something, I was gonna jump in just really quick and say, yeah, there is purely functional data structures, there's ways to handle this, and it only needs to be written once, really. It's not, like you said, being built in the language, learning more adaption, especially where concurrency is concerned. And you know, I just read an article the other day about web workers being the new, in 2016 web workers. We'll see, you know, but as we get to the parallel future and we share things and we mutate things, we're gonna be able to, it's gonna be so much nicer to not have to worry about random mutation side effects, shared memory, all of these things that declarative functional programming immutability give you. If we all agree and we all move towards it, we don't have to worry so much about, nobody's written the most efficient tree yet, you know, somebody will. (laughs)
And I think the same is true in functional programming, and what I'm coming to is to say, I don't necessarily think that we need a library like Immutable.js to also be savvy of these things. So for example, if I have a chain that has four map calls in a row, I'm performing four separate transformations and four separate loops over the array, over the list every time, then there's another thing in functional programming, another concept, which I know has lots of terminology that I don't understand, but there's a concept of simply composing those transformation functions together and doing one map with that composed thing. And we don't need a library to do that, I don't think. I think we can just explain, or I think we should explain to people, that there is something to be said for not doing extra work just because it looks prettier in our code.
KENT: So, as awesome as this has been, I think we need to wrap up, 'cause we do have several questions on Twitter. So maybe we should turn this into a three hour show, but, I don't know. (laughs) So, I think it would be valuable to sum up our discussion a little bit. So for the immutability aspect, I think that we can probably mostly agree that for the most part, it's just simpler to think about your applications not enforcing immutability, just promising, like, I swear on my honor, I will not, you know, I will do immutability, but not actually enforce it with the library. But if you're really concerned about performance in your app, then bringing in something like Immutable.js or some of these other immutability libraries, could bring you a great, huge performance boost.
And then on the functional side of things, we've kind of determined that it's awesome to do 100% functional programming. And in the web, that's like, that's actually extremely difficult to do because you have to have something that's mutating the DOM, and that's, you know. We didn't even really get to talk about mutability at the edges of your program, but for the most part, trying to keep the logic of your application functional. And then if you can't quite do that for one reason or another, even having some of your application functional is good. But you don't want to give the impression that something is functional when it's actually not, 'cause that can be dangerous. So I think that kind of sums up lots of the things that we talked about. Is there anything else that anyone would like to add?
KENT: Cool, thanks. Okay, cool, so let's go ahead and get into our Twitter questions, we do have several here. So the first one is from Connor Elsey, I think, and it says, "Great talk so far, but what are some of these properties..." oh, shoot, I forgot, I was gonna ask for context on this question. Um, I don't know, do either...
BRIAN: I know what you're talking about. (laughs)
KENT: Thank you.
BRIAN: (laughs) I was talking about how using the term, whatever, if I say contravariant functor, someone's gonna say, like, "What are you talking about, get away from me," and bring out the mace, you know. But if you're open to hearing that word and knowing it's not such a scary word, you just need to, it's just a loaded word, it comes with a set of properties just like multiplication distributes over addition, you can have these little code snippets that you know hold true for everything. So, the best example would really just be look at the Fantasy Land spec on GitHub, and it'll just show you properties that hold for each interface like if you say the iterator protocol holds this property that it must hit every single element, that's all we were saying. Like, if you wrote an iterator that skips some elements, don't call it an iterator. (laughs) You know, so...
KENT: Okay, cool, thanks for having the context, you just pulled that out of Connor's brain. (laughs) So Ignacio Chavez, yeah, I just apologize if I say your name wrong. "What is the reality of SPAS with FP and Lisp. Since FP means no side effects, I don't see people doing web dev."
BRIAN: I made a cute video about like, FP and Lisp and Scala and Purity and this and that, at some point just like, you know, when you're talking about... it's hard to say FP and Lisp, for me, in the same sentence, 'cause I'm always coming from a Haskell-y perspective. But maybe somebody else can talk about this. Anybody know?
KENT: I know nothing about this stuff, so, good luck Ignacio. (laughs) Sorry. Okay, Vincent O. asks, "Have any of you guys managed to have a play with Cycle JS, a JS FPU framework built on top of RxJS?"
DAN: I think I ran the most basic example, although that was a long time ago. But I just had another look at the source examples in the releases, and wait for it to, like, wait for my eyes to get accustomed to the symmetry, actually being able to read this because I understand conceptually, it's not hard. I wrote some Rx code before, and Rx is pretty good but it's a bit more noisy on my eyes. So what I'm really hoping to happen is something AndrÇ Staltz actually, the author of Cycle.js he wrote about it in his latest blog post, is that the RxJS we write is going to have some kind of special API that can be used to build developer tools for Rx that can track all the observables, and how they relate to each other. And it's also possible to do this via static analysis, because you have variable declarations, you have guarantees that they are going to depend one on another, they all have some side effects in between, and so you can build a graph of all the observables in your app. And I think if these tools become mainstream, if we can see the relationships between observables begin to gain much bigger adaption, and Cycle is the more sensible framework I saw that uses Rx, so, yep.
KENT: Cool, yeah, I've seen the talks and I'm blown away, but it's still way over my head, I think, right now.
BRIAN: Can I interject? The last question about the side effects, it just kinda made sense to me. You can have side effects in functional programming, (laughs) very much so. In fact, Lisp doesn't enforce that, Scala doesn't enforce, you can just go and do whatever you want, whenever you want. But pure functional programming, different idea, you wanna push all your effects to the call leads, an inversion of control thing. So instead of actually running a function that does some kind of effects, you just basically propagate it all the way up to the controller or whatever you want to call it, the thing that's going to be the last possible line of code and everything else is purely in your model.
KYLE: My totally lay person non-FP perspective on this is, yes, non-pure operations are virtually required to have any kind of non-trivial application, but it seems like a functional programmer's answer to impurity is, you can write as many impure functions as you want as long as you wrap all those up in a pure function. So it's kind of like, it's not really turtles all the way down. It's not really Pure all the way down, it only has to be Pure at the highest level of abstraction that you expect people to interact with. And everything else inside, I think you're kind of free to do whatever you want. I don't know if that's true, but that's my outside perspective. (laughs)
BRIAN: Well, I mean, if you consider like a Promise or like we we're saying before, like you're treating a value as if it's there even though it's not. And as you map over it, that value gets passed into your function and you can actually work with it, right? And the IO abstraction, it's a similar idea. It's not asynchronous but you just, you have a value you're working with that's not actually there yet. And what that gives you is the ability to put it into data structures, it allows you to pass that IO all the way around your program, do all sorts of things, and then at the last possible second you can choose to run it or not.
But it also can do things like earlier, Kyle, you mentioned jQuery's chaining. You know, you can take an IO and another IO action and as you chain those, you can actually fuse into one object, you don't need to keep making copies because of certain laws and properties, we can automate this. Computers don't understand intuition or common sense; they understand very strict properties. So you could say, "I can chain 100 times and instead of returning a new copy, I'll just return this, because it doesn't really matter outside of this world." And by the time we get to the point where we actually want to run the side effects, we could have done optimizations, we could have gotten rid of things, we could have fused things. And you kind of do maybe one DOM reflow in the case of React instead of 30 throughout your application as you're changing things.
KENT: Wow, so much just made sense to me. Thank you. (laughs) Cool. Alright, so our next question is from Bradley Mick, and he asks, "Are the implicit/non-enforced FP contracts worth hidden tribal knowledge? My history is implicit contracts hurt maintenance." And that would be my history as well.
KYLE: I would invoke the comment, the maxim which is not unique to me, "You have to know the rules first before it's okay to break them." So I think once you know them it's okay to break them.
KENT: I need a T-shirt with that on there, as well as, "Separate your computations from your mutations," (laughs) I love that. Cool. So Charlie Koster asks, "If you allow devs to do stupid things, they will. That's one of the advantages of Elm in regards to FP." So that wasn't really a question, (laughs) but I'm gonna read these ahead of time. But does anybody have any comments about that?
BRIAN: That's another types versus no types, dynamic versus strong, whatever. You know, I like them both and so I can be like, "Hahaha, you're all silly." Like how Kyle says, "You gotta know the rules to break 'em." If you're in a dynamic language, you know there's types there, and you know you can cheat if you want. But if you're disciplined you can do it.
KENT: Cool, I think we have a couple more questions, but I don't think that we have the time. There was one other question that I thought most of our listeners and viewers would be interested in knowing about and that is, "Where does the community usually talk? IRC? Dischord? Where is a good place to discuss online?"
DAN: I just use Twitter, I don't use anything else.
KENT: Yeah, I think the danger or the worry is that you go to a hard-core functional programming community and you're just gonna get nailed for not knowing what a monad is, or whatever. And we kinda talked about that a little bit earlier. So, Twitter's pretty friendly, (laughs) sometimes. So, cool. Let's go ahead and jump into our tips and picks, unless there's anything else somebody wants to bring up that they thought of last minute. Okay, cool. So yeah, we'll go ahead and start with Getify. What do you have for us, Kyle?
My picks, I mentioned at the beginning of the show, there's the two-part blog post that literally came out today by Chris Jenkins. The first part is, "What is Functional Programming?" The second part is, "Which Programming Languages are Functional?" Really, actually, the first part of the blog post is absolutely essential. If you've listened to this and you're at all interested in this functional programming topic, go read that blog post. I thought it was great. Since we brought up asynchronous programming a bit, I do have a pick for an article I read a while back, maybe six months back. But it really tries to derive the functional, underlying principles of asynchronous programming from a functional perspective. From callback to future, functor, monad. It's a long article and there's a lot to read, but I found that to be really fantastic, especially since I spend a lot of time thinking about asynchronous programming, so it was cool to see the ties between those two.
And finally, I will bring up, it was mentioned in passing on the... I think Brian mentioned it, but I'll also pick the article, concurrency's future on the web, it's called, "2016 Will Be the Year of Concurrency on the Web." @cramforce on Twitter wrote that, it's an interesting article. I'm not sure I entirely agree with it. But I am a big fan of concurrency, so I'm absolutely cheering that that will in some way, shape, or form, end up being the future, so. Go check those out.
KENT: Thanks Kyle. Lin, can you give us yours?
LIN: Sure, so my tips this week are some Git tricks that I picked up years after starting with Git, and all the sudden I was using them all the time. So these are just two. And if any viewers or any other panelists have any that they want to share, I'd love to hear more, 'cause I love those little tricks that speed you up just that little bit. So one of them is if you do "git checkout - " it will flip you back to the branch that you were just on. So if you're switching between branches, that can be really handy. And another one, of course, there's Hub. If you're not familiar with Hub, check out Hub. That's a really good way to do things with GitHub, specifically. And another GitHub specific thing is you can actually set up your GitHub config to fetch any PRs that have, on a particular repo, whenever you do a fetch, each of those PRs will come down as a branch, too. So that's really good if you have to do reviews. On projects where I've been doing most of the reviews, that's been super helpful.
And my picks this week are, so we we're talking about functional programming and I mentioned about being easy to reason about. I found a really helpful talk that really helps you understand what people mean, or at least what some people mean when they talk about functional programming being easy to reason about, was Jessica Kerr's talk at React Rally, where she looked at the functional principles that you have in React. So this isn't getting into monads or anything like that. She uses some really interesting analogies, like the idea of tentacles coming in from side effects coming in to your brain as you're working on a particular part of the code. So if you want to get a really quick, easy introduction into that idea, it's kind of like what Dan's talking about, where you separate your computations from your mutations. You know, how that actually makes it easier to reason about code, check that out. And that's it for me.
KENT: Cool, thanks. Tyler?
TYLER: Alright, so I just have two picks. James Long, he works in Brazil, he probably works with the U.N.
LIN: Yes, he does.
TYLER: He wrote a really good blog post called, " Starters and Maintainers." It's basically him speaking from the heart. He has a lot of open source projects and they're really fun to start, and sometimes they get really hard to maintain, so he kinda just walks through his struggle with doing that. And I think it really highlights the emotional, I don't know the exact word, but sometimes it's tough being an open source author, and he really nails that argument really well, so check that out. And my last pick is, "Classroom Coding with Professor Frisbee," it's one of my favorite things on the internet, if you haven't seen it.
BRIAN: Thank you, thank you.
TYLER: It's fantastic. Just go watch it. I think there's three episodes right now, Brian, is that right?
BRIAN: Yeah, I gotta get making some for Egghead now, so, I might take a break. (laughs)
TYLER: Basically it is a very fun way to learn about functional programming topics, so definitely check that out.
KENT: Awesome. Okay, so for me, I just am about to start, well I guess I've technically started full time at PayPal, and I'm working from home. And my wife, for Christmas, got me, she made me a standing desk, and it's amazing. My wife is a boss. So try out a standing desk. Standing desks are awesome. You just feel like you have so much more energy. And I realize not everybody can do it, but it's really nice. And you can have a chair and whatever, and sit down every now and then, but it's really nice to be able to stand during the day.
And I just wanted to give one more tip: if you're trying to learn functional programming and you're past the beginner stage and you're in the intermediate stage and you see all these crazy words and you wanna read the White Papers, but you're seeing math syntax and Greek letters, and scary stuff like that, a really helpful book for me was the Haskell programming, or, it was like "The Haskell Road to Maths and Logics," or logics and maths, I don't even know how to say it. I'm just gonna look at the link. "The Haskell Road to Logic, Maths and Programming." And it's an incredible book that kinda goes through just linear logic, some set theory, and some category theory, and kinda shows you, from beginning to end, how all the stuff is related so you can kind grok this Curry-Howard isomorphism stuff, and really read these White Papers without being afraid. So I loved that book. From being someone who just sucked at math in high school and didn't get through it in so much college (laughs) and just like, so there's that.
And then finally my pick is ForwardJS, February 10th, we're gonna have a functional panel. So, you know, Evan Czaplicki from Elm is gonna be there, and Phil Freeman from PureScript is gonna be there. We're gonna have a full, and the author of Immutable.js, or an open-source maintainer at least. So we'll have some cool functional stuff there. Okay, that's it. (laughs)
KENT: Tons of resources, man. The tips and tricks on this show are stellar. Dan, what do you have?
DAN: Sorry, muted. So my first pick, it's a document that you can read, it's called, "A General Theory of Reactivity." It's a GitHub repo, but it's just a very long readme by Kris Kowal, who was the author the Q promise library, which is not as popular anymore, but it was one of the pioneering promise libraries before promise back emerged. So it compares different async functions like iterator, which is synchronous and observables, which are asynchronous and promises. And it really, if you were confused about these terms it's a really good way to just sit and read through all of it. He does a great job explaining these and how they relate to each other.
My third pick is a whole blog, it's called, "Programming in the 21st Century." And it's my favorite blog. So the link is through the archives. I read all of it, and I suggest you do the same. If you have a sleepless night or a lot of time, just go through all articles, because it's amazing. It talks a bit about functional programming and a lot of different things. The entries are fairly short and there's a lot of condensed code there. And there's a lot of empathy and friendliness, it's not elitist, so it's a great blog. I suggest you read it.
And finally, one project that caught my eye recently, if you use Redux, you might want to check it out, it's called, "Redux Saga," which is an alternative way to write side effects for Redux, like you want to fetch data, usually you do this with async middleware like Redux Thunk. But Redux Saga is alternative way to do that that promises to be more composable, promises to be easier to test because it's based on generators and it's declarative, so you can test things in isolation. And it seems really great for complex flows like when you have a registration flow, when you need to tell the user to do this, do this, so you have a script of actions that need to happen in a synchronous way, it's a great way to orchestrate those without jumping to use observables if you don't want to learn them yet. So these are my picks.
LIN: See ya!