Functional Programming

In this episode we discussed functional programming, and how it relates to JavaScript programming and its benefits to programming in general.

React Native Radio Episode 068

Transcript

[00:00] [music]

**Nader Dabit**: [00:13] Hello, welcome to Episode 68 of React Native Radio. I'm your host, Nader Dabit.

[00:16] Today on our panel we have Peter Piekarczyk from Preposterous.

**Peter Piekarczyk**: [00:20] Hey everybody.

**Nader**: [00:21] Gant LaBorde from Infinite Red.

**Gant LaBorde**: [00:23] Welcome!

**Nader**: [00:24] And our special guest today is Eric Normand. Eric, welcome to the show.

**Eric Normand**: [00:29] Hello. How are you going? I'm so happy to be here.

**Nader**: [00:32] Glad to have you all.

[00:34] Eric, we're going to be talking about a lot of different things, I guess we would say that are typical React Native specific stuff. We might dive into a little bit of Clojure, maybe talking about compile to JavaScript stuff and kind of everything going on in that ecosystem right now.

[00:50] Before we jump into our topic in general, can you give us a quick overview of maybe how you got into programming, what you're doing now and kind of what all you're working on?

**Eric**: [01:00] Wow. How I got into programming. That was a long time ago. I had very supportive parents. I remember when I was — I must have been six or seven — I was in school and I was in a meeting with my mum and my teacher. My teacher asked me what I would like to like do research, explore. For some reason, I said computer programming.

[01:29] I had no idea what that was at that time. My mum looked at me, was like, "Really? That's what you want to do?" She helped me the whole way. We spent a lot of time on the computer, and I got my own computer at some point and I just really like programming. What I like most about it is that just like an artist, or a poet, you spend a lot of time in the world of ideas.

[01:54] You're constructing ideas, and I really like that. It's like world-building. Like building a middle earth or something. How things are supposed to work. That's one of the reasons I like functional programming because I feel like it operates a lot in that world of ideas. I got into functional programming about 15 years ago while I was still in college and I just really like it.

[02:26] I'm glad to see that functional programming is now getting a lot of...people are talking about it. It's getting a lot of attention. It's now more possible than ever to be a gainfully employed functional programmer.

**Nader**: [02:41] What was Functional Programming 15 years ago? What was going on, on that space?

**Eric**: [02:47] The big one was Common Lisp. Common Lisp was written in the late '80s and really hadn't developed much since then. It has been modernized and ported to the operating systems at that time, but a lot of the Web happened in the '90s and so there were Web frameworks and stuff like that.

[03:11] That was were most of my time was spent, in Common Lisp. And it's actually a really nice system.

**Nader**: [03:17] Common Lisp, is that programming language millennials put on their Twitter profile and say they know?

[03:24] [laughter]

**Eric**: [03:24] I guess so. I'm getting kind of old as long in the tooth. I don't really track what millennials are doing at these days.

**Nader**: [03:32] I'm a millennial and I see it all the time. "Lisp programmer." "sure you are, you probably just doing Functional JavaScript."

[03:41] [crosstalk]

**Eric**: [03:41] Right. You know, Lispers have always been sort of relegated to the shadows. They haven't been able to get paid to do it. Someone who is doing Functional JavaScript might very well go home and type a bunch of parentheses and play with it at home.

[04:05] Nowadays, like with Clojure and other options, it's much more possible to be doing that and get paid to do it, which I think it's great. It's kind of what I'm trying to do with my business. It's called PurelyFunctional.tv. I make Clojure video tutorials.

[04:27] More broadly, I try to help people transition their career from the language that they might not be that interested in, that they're working in to a career in Functional Programming. And Clojure is kind of like the gateway drug for that. If you know Java for instance, it's an easier transition that learning something completely new.

[04:57] A lot of people who are trying to transition their careers, they got stuck in a language because there wasn't much opportunity in other languages back in the day. Now, they're older. They have a mortgage and kids and they're afraid that they won't find jobs and they'll have to take a pay cut, which is totally untrue.

[05:19] There's lot of jobs. The Clojure jobs are well paid. I try to help them transition over. Find the job, work on their resumè, get some side projects going. Learn the basics that they need. Really help them get going.

**Nader**: [05:37] That's amazing. Do you think that you would ever consider doing a JavaScript to Clojure lesson, or you think that's just too simply, and it would just not benefit anybody? Or do you think that perhaps, "Here it is in JavaScript functional. All right, let's go ahead and see what happens here."

**Eric**: [05:57] You mean like a ClojureScript for JavaScript programmer, that kind of thing?

**Nader**: [06:01] Yeah. Since ClojureScript, you see it as a gateway drug, I agree with you. I think that a lot of people are looking towards taking this language, this compiled, or this checking that happens. This transpiling stuff.

[06:21] We're all still stuck in JavaScript. I didn't know if you were looking at, perhaps, even extending that gateway drug a little further.

**Eric**: [06:28] It's an interesting question. One thing that I have really thought about is, whether people, enough people to make it a profitable business, are actually going to be transitioning over to a new language.

[06:47] Maybe they would be much better to just focus on functional JavaScript. There are some attempts. Some good books about functional JavaScript, a lot of good blog posts, but they're not that practical. They're usually just talking like Lamba calculus gymnastics, is what I like to call it.

**Nader**: [07:16] [laughs]

**Eric**: [07:16] They're just like, "Look, I can take this function and do this other thing. And I can represent numbers as functions." That's very fun and very useful. In fact, people who advance in functional programming, the better ones usually get into that stuff, because it is neat.

[07:35] In some way it rewires your brain to think of problems differently. As an introduction I don't think it's that useful. I would rather be able to teach someone how to use map, filter and reduce very effectively. In a way that you could show this has value to your code right now.

[08:01] You take your for loops and just replace them with map, filter and reduce, and your code is better. It's shorter, it's clearer, the intent is clearer. You have fewer bugs because there's less initialization to do at each point.

[08:19] Start there. Start with like the very basics. The stuff that you can guarantee is going to have a benefit.

**Nader**: [08:27] That's interesting that you've mentioned map, filter, reduce. I have a blog post that I'm almost finished with that's called "The 80/20 Rule of Functional JavaScript." I'm talking about how you can take a small amount of array methods and get 90 percent of your work done.

[08:42] Those are the three methods that I'm going over. What does functional JavaScript mean to you, right now, in the sense of you just talked about? Is it just using these methods, or is it also about currying and other things?

[08:57] What do you say, if someone is like, "I want to get into functional JavaScript programming, and I want it to be applicable to my day-to-day work"?

**Eric**: [09:07] That's a good question. I think the main reason I haven't jumped in and made this course is, I feel like I don't really know what it means. As a long-term functional programmer, that's what I do. To step back and see what JavaScript programmers, what do they need?

[09:30] How can it be something where they don't have to spend 15 years to get there? Map, filter and reduce is a big thing. I see it even with Clojure programmers. People learning Clojure, they miss that things could be a map, things could be a filter, things could be a reduce.

[09:49] When I help them, I pair with them. I'm like, "This is obviously a map." I need to be able to explain, how do you see that? How do you see that this could be a map? It would be a lot of that. Map, filter and reduce, I would say, Lodash.

[10:07] Just teach Lodash and show how these things can be chained together and put together in new ways. I would love to get into higher order thinking, but I feel like it's a first course. Start using map filter and reduce and just see how much better your code is because of that.

**Nader**: [10:31] You're absolutely right. I've been mentoring this fresh kid right out of school. He's not bad at JavaScript, but obviously, he's got a lot to learn. Some things, I'm just like, "Man." I could totally see it. Just filter it or use map.

[10:55] I almost forgot how to do it otherwise. It's almost enlightening to see him go through the process. It makes me understand, "OK, I have to figure out a path for you to get from what you're doing now, to being able to use map, filter and reduce."

[11:14] That's been super, super helpful for me as a mentor and a teacher. You forget about it.

**Eric**: [11:24] For sure. Especially teaching a language like Clojure, where you don't have for loops. People coming in, they're like, "So, how do I do a for loop?" I'm like, "Well, you can't actually do that. Tell me what you want to do."

[11:43] You have to guide them into thinking, is it something where you're taking an existing sequence and tracking all the elements? That's a map. Or are you removing some of the elements? That's a filter. Or are you building up another value? That's a reduce.

[12:05] Those ways of thinking are not really what people think. They think, "I have an array. It's got a bunch of elements. I'm going to make something new out of it." They just jump into a for loop and start iterating through stuff.

[12:19] It's just the way we're usually taught, and then we have for loops in most languages. They're used to translating their language from one to the other. It's more like, "What is the syntax for loops in this language?" Not, "What am I really trying to do here, and what's the best tool for that?"

**Nader**: [12:42] Essentially, the concept has to translate over as well, of staying away from mutating some state. What's funny is, when you look at it, you hit the nail on the head.

[12:58] Whenever someone comes from a different language and then they start looking at functional programming, it's like a 10-second countdown till someone mentions Monads to be all intelligent.

[13:11] [laughter]

**Nader**: [13:12] Then the person just walks away pretty upset.

[13:17] That's going away now, fortunately. [laughs] People are being a bit less academic with functional programming. That's helping out people a lot.

[13:27] Another thing that helps, and I want to [inaudible] , would you say that functional programming has grown in JavaScript because JavaScript's been notoriously terrible at object-oriented programming?

**Eric**: [13:45] JavaScript is one of the best things to happen to functional programming. It has taught people about first class functions, it's taught people about higher order functions. You're passing callbacks all over the place.

[14:08] If you take a computer science course on compilers, you might learn something called continuation passing style, which is exactly what you do with callbacks in JavaScript all the time.

[14:21] It's one of these courses where you're scratching your head, trying to convert code from one style into another, and it's so hard. In JavaScript, we just write it naturally. That's what we have to do in JavaScript.

[14:36] JavaScript has introduced people to a lot of these concepts, in a way that maybe a theorist would cringe at, because they're using the wrong word or something like that. It's there. The ideas are there. In real programmers' heads, they're actually being used practically.

[14:59] There's a great opportunity there. I'm not trying to beat down on JavaScript. Unfortunately, people in JavaScript do tend more toward the object-oriented and procedural sides. That really doesn't help the functional stuff.

[15:23] When the going gets tough, you don't call map, you just use a for loop.

**Nader**: [15:30] That's because all the tutorials online are doing that. I'm going to be pretty mature about my pick. I just want to stress how awesome it was for me. I was lucky a few years ago and read "JavaScript Allongè" by Reginald Braithwaite.

[15:51] This was before I knew functional programming was a thing. I was applying at Trunk Club, and being like, "Hey, check out this Compose functioning. This is my function cook and this is my function eat. And then I can just wrap it in a cook and eat function, and just works out really nicely."

[16:14] Everybody was like, "That's cool, but we don't do that. We do object-oriented." Literally, a year later, we're looking at React and then Redux, and boom, Compose is right there. It's like, "Oh, wow. We could do this with that?"

[16:34] I didn't get it at the time. I just got lucky that I read this book and learned about partial application and started naming things like pluckWith and getWith. Thinking about it in that regard. Reading a good book on a topic, I don't know if there's many JavaScript allongès. I'm sure there is.

[17:01] Reading a book on that topic, where it shows you real world examples of how you can apply this to your work, has made a huge impact on my understanding of functional programming and JavaScript.

**Eric**: [17:13] I have a lot to say about that. That's actually a really cool story. Another book that I like is "JavaScript: The Good Parts." It's a functional programming book in disguise.

[17:29] One of the things that is really appreciate is, he really breaks down — in the parts that he says are good, which are usually the functional parts — he really breaks down stuff into their component parts.

[17:48] In object-oriented programming, we tend to want to build something big, like a big class that does all this stuff for us. The problem is, when you have something big, it's much less likely to be A, correct, and B, reusable. It probably does something you don't want it to do in every case.

[18:14] Sure, it feels good when you do find a reuse for that, because it's big and you're saving all this code, but usually, you want something smaller. Smaller things tend to be more correct and more "timeless," I'm doing air quotes.

[18:30] You can see, "Oh, this is just like adding a thing to an object. I made a function that just does that." It's something I do that all the time. It's easier to see that it could be something reused. In "JavaScript - The Good Parts," he talks a lot how you're using a function to create a scope.

[18:55] Now you can do information hiding because you can return a function that will modify that thing, but nothing else can modify it. These are the things that functional programmers think about.

[19:09] This is functional programming, it's like using all these little pieces and composing them together into a solution that you want. As opposed to having a ready-made for you in this object that does all sorts of stuff.

[19:24] It holds state, has an interface, it hides the implementation details. It's like a unit of meaning. It does all sorts of stuff. It's like a namespace. If you read that book you start to see that these things are better when they are broken apart.

[19:43] That they're smaller, they're easier to understand, and now you can build the solution you want. I think that JavaScript LMJ does the same thing. It starts to show you that, "Look, these functions, not a class, but a function, is so useful."

[19:59] You can build other functions out of it. In JavaScript, it has the function scope, you can build a new scope out of it. It's all these cool stuff.

**Gant**: [20:12] You mentioned higher order functions. In React and React Native we have high older components, and higher order functions, and higher order functional components. Is that a functional programming principle?

**Eric**: [20:24] Yeah. It's very similar to what in object-oriented land is called dependency injection.

**Gant**: [20:34] Really?

**Eric**: [20:35] Yeah. The difference is, it doesn't require so much elaboration. Really, you're passing in a function that something else is going to call, just like a callback. That thing is going to call it but you don't know exactly how it's going to be called. It's part of the semantics of the thing you're calling.

[21:00] It just lets you start thinking in higher order terms. Meaning, you're not thinking like, "Oh, I have to construct this for loop." You're thinking, "Oh, this is a map, so I'm going to call map and pass it the function that I want done to all the elements."

[21:19] The same goes with higher order components. You can take a component as a...and the idea is that as much as possible, it's a function, it's just like a render function, and you pass that to something else, and that will transform it into a new component.

[21:39] Maybe it's a component that keeps track of its state. It has an undo or something like that.

**Gant**: [21:45] I have another question about React in general. I know with Redux, and with a lot of the modules and things that we're using in the React ecosystem, we see these curried functions.

[21:59] I'm curious, is currying a functional programming principle as well? I believe I may have read that somewhere. If so, how does that all work? I understand how currying works, but is it used in other languages as well?

**Eric**: [22:16] Yeah. Just a bit of history, currying comes from a person named Haskell Curry. Haskell is also...the language Haskell, the functional language, comes from his first name. Currying is from his last name, Haskell is his first name.

[22:39] It's a functional Programming concept. I, for one, am really glad that people in JavaScript are learning this stuff. Like I said before, it's amazing that you hear of JavaScript programmers saying the word curry, and they know what it means. It's just great.

[22:57] Redux itself is very functional. It was inspired by other functional languages, like ClojureScript and Elm. I think Redux is another example of where...and React in general, of how much functional programming is actually being done in JavaScript right now.

**Gant**: [23:17] That's interesting.

**Nader**: [23:21] What's really funny is, addition of that, "ACM Magazine" usually could care less about JavaScript, if you've ever try to read it. It's usually about image perturbation with functional deep down to the core.

[23:39] They had an article, I want to say earlier this year, reacting Facebook's functional turn on writing JavaScript. Of course, the article is available for everybody. Combining with that Redux, and then additionally, I think Peter may be a fan as well.

[23:58] I'm definitely a big fan of Ramda, which is a functional JavaScript library, which automatically curries all of your functions for you. It's just amazing to me. This is my gateway drug. [laughs] It's slowly making more and more functional programming.

[24:18] Speaking of Haskell, that's what used to scare some people away. Somebody gets thrown into Haskell, where it is strict, it is insanely philosophical upfront. You say, not having a for loop. How about not being able to maintain any mutable variables at all? [laughs]

[24:44] You start to lose your mind when you're thrown into something like that from a different programming language. To me, it's really cool coming back to those same concepts, and seeing languages in entire libraries like Ramda where you can do these things.

[24:58] These are the real friendly ways to bring people into a functional set of programmers, those millennium goals with Lisp and such.

**Peter**: [25:08] Gant and I were just talking about Ramda before we jumped on this call. I've never used Ramda before, maybe once or twice when I was using the Infinite Red starter kit. I've always been like Lodash and Lodash FP, or just hand-rolling functions that I've learned from Allongè.

[25:28] I'm like, there's got to be better ways for me to do this than just have a bunch of hand-rolled functions. Exploring different libraries and seeing what works and what doesn't.

**Eric**: [25:41] I'm all for the exploration. I have recently read an article that is critical of JavaScript as a functional language and has a good point. Like I said, I'm all for people learning all this functional stuff.

[26:00] It's good stuff. It complements the object-oriented stuff really well, and the procedural stuff. The problem they were running into was, when you start trying to use multiple libraries, you're using Lodash and you're using Immutable.JS.

[26:23] You have to know, am I using an immutable list, or do I have a JavaScript Array? It starts to get a little cumbersome. I'm sure there's a solution to this, like another wrapper around them, another level of indirection that will just solve the problem.

[26:42] I think it's still a problem. you want to do things right. You want to do things as functional as possible, so you import all these libraries, they give you all these tools, and they don't quite work well together.

**Gant**: [26:54] Also, the fact is, a lot of the stuff is not baked into the language itself. We're importing and using all these libraries. Those things, they change, the APRs change. They add extra block freezing, if you're doing Web programming.

[27:11] One of the main things that I use Lodash for is to do map, filter and reduce on objects. I wonder why that isn't added into the language itself. Also, is that something you can do on other data structures, other than arrays?

**Eric**: [27:30] Yeah, for sure. In ClojureScript, you can do a reduce on a map, and it will give you each pair, meaning the key-value pair. Map is interesting, because map, you could actually just do something like map values and get the same structure.

[28:00] Meaning the same keys, but now all your values are changed. Or you could do something where you get both the key and the value, and you can transform them in some other way. The key set might be different when it comes out.

[28:14] There's different ways to do it. It's totally possible.

**Gant**: [28:19] I wonder, is there any discussion of adding that functionality to JavaScript that anyone knows about? I haven't heard. I don't know if there's a reason behind it or if it's just something that they haven't thought about.

[28:30] I'm sure they thought about it but, I'm assuming there's a reason that it's not there. So many people use Lodash just for that reason.

**Nader**: [28:39] JavaScript hasn't evolved for a long time, and just began evolving again. For the longest time, the language just sat stagnant.

**Eric**: [28:48] For the longest time, we didn't even have object.keys.

**Nader**: [28:51] Yeah. It didn't have .includes. That caused the fragmentation in JavaScript. All these different libraries claiming all these different micro-benchmarking speeds. Everybody is, "Oh, I know this one."

[29:07] [crosstalk]

**Nader**: [29:08] Exactly. It was just very poisonous for JavaScript. It's definitely turning towards a light. [laughs] JavaScript in its innate place basically became stagnant and toxic for a good while. That's when everybody was on client languages.

[29:32] That was the future. Now, here we are back. The longer things change, the more they stay the same.

**Gant**: [29:38] Let's not forget that this was just three, maybe four years ago. Not that long ago.

[29:44] [laughter]

**Gant**: [29:49] Go ahead.

**Eric**: [29:49] I comment on this all the time because I do give a presentation about JavaScript versus ClojureScript, just to help people understand what ClojureScript is about. I keep saying, the last time I really used JavaScript long-term at a job was before ES6.

[30:11] It was like old school JavaScript. This was before and NPM, before...I don't even know, the Web...all that stuff. We would concatenate, we would use the Unix cat command to put our JavaScript files together into one bundle.

**Gant**: [30:28] [laughs]

**Eric**: [30:29] It worked. It worked perfectly. It just had no problems. We never had to upgrade. We never had to deal with any new features of the packer. It was just CAT.

**Nader**: [30:46] That's OG JavaScript.

**Eric**: [30:47] Yeah, that's what I remember. When people talk about, "Oh, I'm trying to configure my bower," I'm like, "I have no idea what you're doing. I just run CAT."

[30:59] [laughter]

**Gant**: [30:59] I wonder if it would be possible to create a Babel plugin that allowed you to do these things and add these things to the language. Is that something that you can do with Babel? I mean, from what I understand it is, but do you think it would be something...?

**Eric**: [31:17] I would really love to see that because when people started transpiling, like everybody's transpiling now, and importing all these modules from the future like Level Zero. I thought we would start seeing more home-grown modules that did this kind of stuff.

[31:42] For instance, replacing all the literals that JavaScript object and array literals with Immutable.js. You could do that with a module that just changed the syntax. I just wonder why we haven't seen more stuff like that, at least even experiments.

**Nader**: [32:03] That may be an experiment. I may try to create a module, or a Babel plugin that does object.reduce, and object.mac, and object.filter.

**Peter**: [32:14] It's fair to say at this point, as React Native developers, we've always been benefiting from Babel. Now, take this with a grain of salt, there are quite a few people who know quite a lot [laughs] more about this than I do.

[32:29] With React Native packager, and I'm sure — Eric, I don't mean to step on your toes on this one, but it definitely...I think he was going to talk about it for a second — but moving off into its own library and the ability to tie in at the Babel level with our own CLI config.

[32:52] Even though we've been writing ES7 and all the fancy stuff that's getting transpiled for React Native development, recently it's really opened up the transpiling initiative so you can do just about any language that transpiles and start getting things moving real fast.

**Eric**: [33:16] Yeah. Wow. I have a lot to say about that. First thing I want to say is, "Yes, it is awesome that it opens up everything," because it puts all languages on an even playing field. I mean, basically, if you're transpiling anyway, why not choose the language you want.

[33:36] That means you could do PureScript, or TypeScript, or ClojureScript. Why be stuck with ES7, and especially when it's still being modified so you do it in upstate and your level zero stuff starts breaking?

[33:54] Anyway, you have this opportunity because everything's getting put — everything's transpiled now, just transpiled from what you want. The other thing I have to say is that I don't know how that's going to affect ClojureScript, because we've had our own tooling to build React Native stuff for a long time.

[34:18] We built on top of what was there, instead of — not to be derogatory or anything — waiting for React to support this...

**Peter**: [34:28] Good call.

**Eric**: [34:29] We've just built on top. We have had live code reloading. Basically, you're running your program in your iPhone simulator or on your phone, and you type some code, you save it. It gets compiled automatically by the Clojures group compiler.

[34:56] Not really even touching React at all, not talking to it. Through a WebSocket, it sends the phone a command that says, "Hey, this file is updated," download it again and it just reloads it and you see the change right there. You don't have to shake your phone. You don't have to lose where you were, so you can do...

[35:26] I don't know if I can do it just by describing it but you can literally do styling changes and save it as you go and just watch your style change and a deep screen. You're like three things in, you've got stuff, you've typed stuff in, you've selected stuff, and you can watch it change right before your eyes. I don't know if JavaScript has gotten there yet where you can do stuff like that.

**Peter**: [35:52] Yeah, I mean it's amazing that ClojureScript went that far before these toolings have been opened up. I mean, it's amazing to me. It speaks to the mettle of the people just to say, "Oh, yeah, well, this is available? "No." "OK, well, we're going to do it anyway." [laughs]

**Eric**: [36:13] Yeah, I think we were lucky that a lot of the stuff already existed because that's the way we would program the web too. When React Native came out, someone had also been experimenting with how do you do live coding on an iPhone in ClojureScript, and so they just hoarded all these pieces and made this system that works well.

**Peter**: [36:41] Yeah, it definitely seems to have caught up pretty nicely and very open to what languages are being transpiled from, especially in the most recent edition. I guess, it almost is a little scary because now that we have the options, which ones...are we going to have that same fragmentation problem that we saw before with all the different JavaScript libraries?

[37:13] Is it going to be every company that you work with is going to say, "Hey, we wrote it in this language, we need you to go ahead and continue working with this language now," and then you switch over and you have to relearn everything again, almost wish there was...which ones are doing the best?

[37:33] We were doing our bets on what we think is going to succeed but there's no guarantees right now with JavaScript.

**Nader**: [37:42] Yeah, it could be a thing like how we did see the fragmentation languages were in the frameworks where there was a lot of fragmentation for a couple of years, but now we're seeing a little less fragmentation that people settle on a couple of things.

[37:54] Maybe there will be an explosion of language of compile to JS languages and then maybe we will see fragmentation and then possibly people moving down into just a handful of languages, or maybe JavaScript will improve to the point where we won't need to do this stuff. I don't know.

[38:12] I know there's other issues other than the syntax that some of these other languages bring to the table, such as types and things like that. I have a question though. This is about functional programming in general.

[38:27] I see this ML syntax, it's ML tacked on to different languages like ReasonML and OCaml. What does it ML actually mean? Is it something that people add to a language name to represent that it is a functional language? Where did that come from?

**Eric**: [38:46] ML is one of the original-typed functional languages. It's actually standard ML.

**Nader**: [39:02] ML is an actual language in of itself.

**Eric**: [39:06] Yeah. It is the pre-runner for OCaml, for Haskell, and then all the ones derived similar to Haskell, like Elm and PureScript. It's just an old language that was functional and had the stuff that you're used to, currying, pattern matching, type inference, that kind of thing.

**Peter**: [39:37] Nader, going back to what you were saying with JavaScripts and the community, I feel like JavaScript being this cross-browser language, it has a lot of different targets. All of these new developers coming into every single day, I think at this point, there are so many people with so many opinions.

[40:01] I don't know if we'll ever be able to come together and agree like, "This is the way we're going to do things," because think about even Lodash being the standard library of JavaScript. You could argue, has so many different competitors, or even just like Lodash, Ramda...I've even heard people on Reddit say that they've replaced Lodash with Immutable completely.

[40:32] I've always considered Lodash the standard, the library I'm always going to use. I even have several flavors of that library to use. I'm sure there's many more.

**Eric**: [40:44] One of the things about talking about fragmentation, I think that JavaScript has a healthy user base. [laughs] I don't think it's going to go anywhere. What you are going to see is...and it's not going to go anywhere. It's not going to move like people aren't going to move to scatter across thousands of languages and will never be able to communicate.

[41:12] It's always going to be there and it's always going to be influenced by these other languages. You could see that JavaScript already was influenced by Scheme and Shelf when it was created. Now a lot of the influence is from CoffeeScript with the syntax changes that have happened recently.

[41:41] I'm sure that at some point, the more functional languages are going to influence it again in terms of what features get added officially to the language. I think that you're going to see a few splinter groups for people who, I don't know, feel like, for some reason, there's an advantage there.

[42:08] That's going to feed back into the main group slowly. This is 20 years we're talking about. That's my prediction of what's going to happen.

**Nader**: [42:18] I have a question. Have you looked into Reason at all? If so, what do you think about the language, or the tool, whatever they call it?

**Eric**: [42:26] I haven't looked at it. I feel like things are moving so fast that often, I'll look at it and be like, "That's interesting." I put in a folder to read later and I realize that there's like 300 things in that folder. [laughs] What is Reason? Tell me. Give me the one sentence.

**Nader**: [42:49] I haven't looked at it a ton. I don't know, Peter. We had a guest on last week that specializes in reason and that episode will be out probably next Monday. I'm looking forward to listening to that. From what I understand, it's basically a tool-chain built on top of a Caml.

[43:03] They're using it at Facebook. They're replacing a lot of their code at Facebook with Reason, to the best of my understanding.

**Eric**: [43:10] This is to replace Babel and web pack and stuff like that?

**Nader**: [43:14] Well, it's also compiled to JS language. I want Peter to take over.

**Peter**: [43:19] ReasonML stands for reason markup language. It uses the OCaml AST behind the scenes. OCaml by default comes with types. It comes with Immutable and all these other features that we could really take advantage of in JavaScript.

[43:38] We've done the best we could to make up for that with Flowtype, with TypeScript, with Immutable.js. We can do better than that. Jordan Walk from Facebook, a bunch of other folks came together and started working on ReasonML. All it's doing is it's taking OCaml and giving you a new syntax that's much more familiar to JavaScript so you don't have to worry about learning OCaml.

[44:09] You can learn Reason and get the same benefits of OCaml, Immutable, the performance that comes with it but not having to relearn all that syntax all over again.

[44:24] Nader, you're right. Facebook's Messenger is using like 25 percent Reason right now. Writing Reason generally is more performance than fine-tuning your JavaScript. The code, the compiled JavaScript code that you get from Reason, it's pretty legible too.

[44:43] It's not like opening up something that you've transformed with Babel, for example. It's looking better and better and it's a lot more legible and they actually encourage you to check in your compiled JavaScript code.

**Eric**: [45:02] That's interesting.

**Gant**: [45:02] That's really interesting. I just want to say for a second there just to tie up a few things. There's definitely a jump across a bridge to switch languages. I see that there's definitely things missing. I want to take a moment and say I think it's awesome that Facebook's going that direction. I think they needed to pick a direction and go towards.

[45:29] Seeing as the fragmentation is going to happen [laughs] with all the things, I want to put my two cents into two things. One, I just want to say real quick, if you're familiar with JavaScript, jumping over to TypeScript is nothing. It's magical. It's weird for me to say anything that backs Microsoft, but I find myself doing it more and more every day.

[45:53] Now, if you're willing to switch languages and you're willing to go the full length, I honestly would say, "Go ahead and take a moment, maybe look at PurelyFunctional.tv, take a look at the other languages."

[46:07] I wouldn't just jump in because Facebook says, "This is what you should use." I say like, "Take a look at ClojureScript, take a look at all the other ones. If you're looking to switch languages completely, take a step back and spend some time on it."

[46:21] I think that you'd probably be a lot happier looking at it as a higher order language that's built around that stuff. Are you looking to stay with the JavaScript? TypeScript gives you so many of that magic without feeling like you've changed languages.

[46:37] I am happy Facebook's doing this but I can't barrel down after the OCaml train and say, "Yes," because I remember I was at the talk when they announced this. I was like, "What are they talking about?" [laughs]

[46:53] I don't know if the clarity is continuing to grow but I would do some home investigation with that stuff. It sounds like you've done a lot, Peter. Honestly, Eric's got the most experience with these functional programming languages, so I'd probably ask him.

**Nader**: [47:11] Eric, I'm curious what your opinion is about what the most applicable functional languages for JavaScript developer if they want to expand their toolset and learn something that's not only fun but maybe they can actually give a job doing it or contract working with it.

**Eric**: [47:32] Yeah. This is a really hard question because I think everybody's different and they're looking for different things. I think TypeScript and Flow are really interesting because if you're looking to learn the typed functional languages, those two...

[47:55] I think Flow might be a little bit better for this, but if you're looking to get into typed functional programming without really changing languages, that's really awesome. If you want to jump right in to a language that has a really good beginner focus, and I think it's only for the web right now, but there's Elm.

[48:23] Elm has amazing beginner experience. Type errors in functional languages are really bad in general and really hard to decipher, and you'll spend so much time just trying to get your thing to compile.

[48:43] Elm has such good error messages and it's kept a very simple type system, very powerful but simple. It's simple enough that they can cover all of the error message types and give you really nice messages from them.

[49:06] If you want to go all the way in the deep-end, there's PureScript. PureScript is like Haskell but targeted at the JavaScript ecosystem. It's got very advanced types. People talk about monads there. If that's what you're into, that's there.

[49:30] Now, ClojureScript is separate from those because it's Type. It's not strongly typed. If you are into more of the...you want Immutable data structures, you want higher order functions, you want a good standard library, and you want good interop, but you don't want to have to learn Types, you can learn all that stuff in ClojureScript.

[50:00] I would say, ClojureScript for React Native and for React development is really a nice experience. Like I said, you have the live reloading, there is decent error messages. There's source maps so you can debug right in your original source code. The set-up is a couple of commands, install a few things and then you type go and you can start editing code. That's my recommendations.

**Nader**: [50:39] Eric, we got off track at the beginning of the show but I'm curious as to what you do right now and what you're working on and your day-to-day career and your day-to-day work.

**Eric**: [50:51] Right now, I am full-time working on a company that I started called PurelyFunctional.tv. I'm mostly making video tutorials for Clojure and ClojureScript.

[51:09] That is a lot of work, running your own your own business. Right now, it's mostly subscription-based. What I mean by that is there's an all-you-can-eat subscription. You become a member. There's a monthly fee or a yearly fee. You get access to everything, old and new, new stuff as it comes out. You can also buy the courses individually.

[51:36] It's a much better deal to just go all in and get everything. I try to keep everything super practical, that means making sure that this is going to be something that people actually want to use. I do like to go a little bit into theory and philosophy. Mostly, it's like, "Let's get something done. Let's get something working."

[51:59] Not to limit anybody, but my main audience is people who want to learn functional programming to use at work. Either their current job or future job that they'll transition to.

**Peter**: [52:16] I see you have a ton of videos here. Have you become a master of creating video tutorials during this experience of creating your own business? Because I'm getting into that whole video tutorial thing and I've put quite a few on YouTube, and I'm going to be adding more. I found it to be much more challenging than I ever thought it would be.

**Eric**: [52:38] It's tough. I've been doing it for a few years now, so I've probably forgotten more than I even know. When I started, it was like a Kickstarter, and I just wanted to do intro to Clojure. My first idea was I'm going to make like all of Clojure on videos.

[53:00] Then I would want something like $50,000 on Kickstarter to do that, and I could quit my job and just live off of that. Then someone convinced me, "Hey. If someone gave you $3,000 would you make something smaller and not quit your job?" I said, "Yeah. Probably."

[53:21] Then I reduced the Kickstarter down that, and I reduced the scope to just be intro to Clojure. When I did that, I spent a lot of time on production quality. I got a microphone. I worked on slides and put animation in them.

[53:38] I made sure every little bit worked together to make this really cohesive whole. It was great. I think it works really well. The problem is, the courses take a long time to make. While I'm making the courses, nobody's learning. They can learn from my older courses but they can't learn the new stuff.

[54:06] Over time, I've focused more on content and less on polish, like video polish. I find that people are just insatiable for content. That's my advice. If you're going to get into this, really think about where the sweet spot is between quantity and quality.

[54:36] At this point, I'm better off making a course quickly or making even one lesson, getting it out there, and getting people asking me questions about it. I can put those answers into the next lesson.

[54:52] Whereas, if it takes three months to even get the course out there before anyone can see it, because you want it to be a totally coherent whole. You don't get that feedback, and you have to do that much more prep upfront, to make sure it is answering every possible question.

[55:13] I think a lot about this. I think about the best way to film. I've got a whole setup for recording my keystrokes and stuff, my screen as I type in an editor. It's a lot of little pieces.

**Nader**: [55:31] It's a lot of little pieces, and it's a lot of being aware of all of these little things going on, putting them together. When you watch a video tutorial, you don't really realize all of the work that's been put into it, until you actually try to do one yourself.

[55:47] It's been really, really hard getting used to it. I've gotten much more comfortable now. When I kick off a new video, I always feel extremely awkward at first. Maybe that feeling goes away after a while. [laughs]

**Eric**: [56:03] I think it does, especially if you do it more often. Not just a number of times, but more often, you'll still be in the zone, for the next one. You talk about the details. One of the details that I had to figure out was not to have my cursor blink.

[56:24] Video stretches and compresses well. Meaning, you can stretch the time and compress it. No one wants to watch you type at 1x. It's too slow. They can read much faster than that. You put it at maybe 2x or 3x. Your cursor is blinking so much, and then there's some parts where you want to slow down, and now it's blinking slower and it's just a distraction.

[56:48] There's all sorts of little things like that, like configuring your editor so that it looks good on different screen sizes. You can play with the video in different ways. Making it so that if you make a mistake, it's OK. [laughs] You can fix it in post, or you can redo it. All that stuff. It's really hard to figure out.

**Gant**: [57:14] I know that this is "React Native" podcast. I feel like if we got the three of us in a room and start talking about the process of making screencasts, that would be a really cool chat just in by itself. Peter is working on his microphone setup.

[57:33] As being a developer becomes more and more communicating via technology, being a remote developer, or being somebody who has to send a message to someone else. Not just through their app, but through their videos and their communication.

[57:49] There's an entire spectrum...Nader, you should make a note here, man. We could a special podcast just on all this stuff alone. I am enthralled in what other people have gone through in figuring out the same stuff. That's amazing [laughs]

[58:06] I feel like there's definitely a need for helping others out there — especially people looking to buy their own microphones — go through the process. Maybe even understand what editing and post feels like.

**Eric**: [58:22] Once you edit, you're not done. You still have to encode your video. There's all sorts of stuff.

**Nader**: [58:29] That's a great idea. We can do an entire episode on content creation, including podcasting and screen casting, and even a little bit about blogging.

**Gant**: [58:43] That's awesome, yeah. Bring Eric in. I'm sure there's quite a few other video people that would be good for that.

**Eric**: [58:49] Those are careers of their own. How do you find the time to figure out podcasting stuff? I'm literally looking at a freaking Canon 7D that I set up on a tripod, that I've been trying to figure out how to throw into my workflow for videos. Versus just using my laptop camera.

[59:12] Then dealing with that footage. Then I'm like, "Crap. Do I really want to deal with 1080p plus footage right now?" Or, "Isn't it just easier to take it right off my laptop camera?" Stuff like that too.

**Gant**: [59:26] Exactly. Not only that. That microphone, if you're doing a video meeting tomorrow or the next day, you can't have the setup where it's going to be in frame all the time as well. There's a million questions. There's a new science here. [laughs]

**Eric**: [59:44] Yeah, for sure. I'm seriously thinking about having single purpose computers. I'm going to record...One is just for editing video. One is for my coding work that I still have to do. Another one is going to be for recording the video. It's going to have a nice camera, USB connected right into it.

[60:15] We're getting to that point where moving a laptop around so that you can be in different places, it's not working anymore. I'm going to need...

[60:29] [crosstalk]

**Eric**: [60:29] for everything.

**Gant**: [60:30] Take a look at musicians. They don't have to write their songs in the studio. They just have to be [inaudible] record it there.

**Eric**: [60:37] Then the problem is getting all the data to where it needs to go.

**Gant**: [60:40] [laughs]

**Eric**: [60:41] Video files are big.

**Nader**: [60:43] All right. Cool. We'll definitely do that soon. [laughs]

**Eric**: [60:51] Yeah, count me in.

**Nader**: [60:52] We'll definitely do that. We'll bring you back on for that. We'll go ahead and jump to the picks now. I'll start with Gant. Do you have any picks today, Gant?

**Gant**: [60:57] Absolutely. I have to say that I don't know when this recording's going to be out there, but for sure. I want to say that the Chain React Conference is coming up. As of this recording, it's in 13 days.

[61:11] You will see such fantastic people, like Nader will be doing a presentation there. It's really exciting to have the React Native conference in the US happening soon. I'm going to see all my favorite people.

[61:28] Eric, I'm surprised you didn't submit a talk. That would've been a good one for you to come out there, especially with all the React Native stuff, so you better submit next year.

[61:36] The videos will be available of course, if you're hearing this after the conference, we'll be going through con freaks. You'll see everything that you want, and it will be fantastic that you'll have missed an amazing conference.

**Nader**: [61:52] Totally looking forward to that conference, can't wait. I need to talk to you about the talk name, because I believe they saw my old talk name on the app, but I'll touch base with you later on today about that. Peter, do you have any picks?

**Peter**: [62:08] Yeah, so my pick for this week, like I foreshadowed earlier, is JavaScript Allongé, the "Six" edition. When I first read it, it was whatever they used to call it, ES3, ES5, I don't know anymore.

[62:22] Anyway, this one's rewritten, ES2016. Definitely check it out. A lot of the stuff that we talked about today, Reginald Braithwaite goes into very good detail, especially how you can apply it to everyday work scenarios.

[62:41] If you read it online, it's free. Otherwise, if you want to buy it, it's $35. It's definitely worth buying it because it's been an incredible book, and it's definitely helped shape my career.

**Gant**: [62:53] I tell you what, I'm buying that book right now.

**Nader**: [62:55] [laughs] All right, Eric, do you have any picks?

**Eric**: [63:00] I do, and this is going to be a weird one. We talked about using map, filter, and reduce in JavaScript, and how those are a good way to get into functional programming, in whatever language you're in, and how even in Clojure, when people are learning, they still are...

[63:21] Even though those are way more idiomatic, they don't do it. I read a book called "Refactoring to Collections," which is about functional PHP.

[63:34] It's about map, filter, and reduce in PHP. It was a super successful book in terms of the number of sales. To me, it's an inspiration. If you can teach PHP programmers functional programming, well, JavaScript programmers will have no trouble.

[63:57] Check out that book if you've ever had to use PHP, it will show you how PHP could be better if you just do a little magic with functional programming. That would be the motto that I would use for doing a course in JavaScript. Please steal the idea if you want to do it before I do, but I'm going to do that one day. That's my pick.

**Nader**: [64:26] My pick is going to be Graphcool. I'm not sure if we picked this before or not, but I've just thought of using it. It's basically a backend as a service for GraphQL.

[64:39] I would say it's similar to Firebase, or something like that. I got up and running with it about a week ago. Really enjoying it and I think we're going to have those guys on the show in about a month or so, so check out for that.

**Peter**: [64:52] I'd like to suck in to Graphcool. I'm more of a startup person than I am an open-source person. I used to spend all this time writing MySQL queries in Postgres, and then writing the APIs, and then figuring out how to connect all the data. Now, I literally just make my GraphQL Schema directly in Graph.Cool, and it just works.

[65:19] Definitely an incredible tool, just wanted to give them another shout out.

**Gant**: [65:22] Additionally, I want to say that, Nader, you did an amazing article on Medium. I was talking about React Native and such. I know you didn't want to pat yourself on the back with that one, so I'm doing it for you.

[65:37] Definitely, look at the React Native training Medium articles that Nader is putting out. Especially if this pick seems foreign to you, a good way to pick it up is to look at what he is writing.

**Nader**: [65:48] Thank you. Yeah, that post did pretty good, and I'm going to be having a new one come out this week as well about Microsoft Mobile Center, adding analytics and [inaudible] . Check out the blog when this comes out, you'll see two fairly new articles. OK, well, that wraps up episode 68 of React Native Radio.

[66:08] Eric, thank you so much for coming on the show. I think we had a really deep dive into functional programming. I think that a lot of people are going to enjoy it.

**Eric**: [66:15] Great, I had a blast. Thank you for inviting me.

**Gant**: [66:19] Yeah, we'll definitely see you back when we talk about [laughs] podcasts and recording, and all the other cool stuff, especially as you being a person who records that stuff. Wow, I think that that plus functional programming is really hot right now.

**Eric**: [66:35] Yeah, I'm a trend setter.

[66:39] [laughter]

[66:39] [background music]

**Peter**: [66:40] Let's start a new podcast where we just talk about our recording equipment, and then which JavaScript derivative we should go with.

[66:49] [laughter]

**Nader**: [66:51] Count me in. Thanks everyone for listening and we'll see you all next week.