Cassidy, Ceora, and Matt discuss functional programming and where it got its reputation as “the mustachioed hipster of programming paradigms.” Cassidy used to run a workshop teaching functional programming with JavaScript and currently works with Elixir, “a fully functional programming backend.”
Here’s a useful primer on functional programming with JavaScript.
This tutorial will guide you in exploring the fundamentals of functional programming with React.
If you’re looking for more info on functional programming in React, we’d like to tell you why hooks are the best thing to happen to React.
Functional not your thing? Learn why object-oriented programming (OOP) has become such a dominant paradigm.
Matt Kiernander So, for example, when I was going through university and doing computer science, they had stopped teaching Java in favor of teaching Python, which is again another very flexible language. It reads very much like English, and I feel like I would have preferred having a more structured learning experience going through Java or C++ or something like that, that would have taught me object oriented, and then moved into more functional and flexible ways of doing things.
Ceora Ford I see your point, but I actually disagree with you because I found that Python was the perfect level of constraint with also being flexible at the same time.
[intro music plays]
Cassidy Williams Hello everybody, and welcome to the Stack Overflow Podcast. We are so excited to have you today. My name is Cassidy, and I am accompanied here by my lovely co-hosts Ceora and Matt.
CF Hi!
MK Hello!
CW I am very excited to talk to you both today about functional programming, because this is something that we've lightly touched on in previous episodes. And I guess my first question to either of you is, have you ever done it? Have you ever worked with functional programming?
CF Yes, I have. I think when I was working with functional programming, I didn't realize it was functional programming, but I have.
MK I think there's a lot of developers out there. I didn't know, I was the same thing. I rocked up on my first development job and they were like, "Oh, so we're doing functional programming." I was like, "Oh, I thought that was just programming. That's just what we've been doing for so long."
CW What languages did you use?
CF For me, functional programming was done in JavaScript.
CW What about you, Matt?
MK Same with me. It was all JavaScript based. I think this may be because JavaScript is a very functional programming friendly language, just in terms of it's written and its syntax and it's very declarative in how you structure things. And with React as well, everything is very functional. You've got pure React components, which are immutable and they always return the same thing. There's a lot going on there that really lends itself to functional programming.
CW I love that you both said JavaScript because I feel like this would cause a Twitter ratio galore of people arguing if JavaScript can be functional or not. Because there are the very pure languages like Elixir, or Haskell, or Scheme, or Racket, or Lisp, because my first experience with that was with those more very pure languages. I did Racket and Scheme for a while, which was basically just parentheses everywhere. But you definitely can do functional programming in JavaScript, but I think because you also can do object oriented in JavaScript, and there are elements of both in React and in a lot of these other frameworks, it's fascinating to hear that that is your experience with it because I've seen so many arguments for and against. Some people might not know what functional programming is so I want to address the definition really quick. Functional programming, a lot of people call it like the mustachioed hipster of programming paradigms, where it's very, very specific in its rules and stuff, and it provides abstraction through clever ways of combining functions. And so there's two specific things that you need to know to understand what functional programming is. And that is that functions are immutable and functions are stateless. And so in terms of functions are immutable, it means if you want to change data in an array, you just return a new array with the changes. You don't change the original array. So things are completely immutable and don't change the original. And also functions are stateless, and so they act as if for the first time, every single time. So your function should probably accept at least one argument. They should either return data, which is again, that new piece of data or another function. And you probably don't have loops in said functions. So anyway, immutable and stateless are what functional programming is. And once again you can do this in JavaScript, but there's also languages for this which we listed some already. There's also Scala, which is kind of like Java, but much more functional, and Clojure, and there's also Elm, which I think compiles to JavaScript, but it's much more strictly functional.
CF Have you learned all these a little bit?
CW I've dabbled. I was really into functional programming for a while.
MK This is all sounding very impressive.
CW Oh, I also used to teach a ‘Functional Programming in JavaScript’ workshop back in the day. So I am very into this topic. But also in my current job, our entire backend is written in Elixir. So it's a fully functional programming backend which is very interesting because with services that are made functionally, and there's again, so many different languages with that. If it works at runtime, or if it works at compile time and when you're building it, it will work in prod. It will work for your users. Because by nature of it, functional programming doesn't have side effects. And that's where if you hear someone say, "Oh, well React is kind of functional now with how it has moved to hooks." It kind of is, but there's still useEffect. So there are side effects that can change how those functions work. But anyway, that is high-level what functional programming is for those who might be wondering.
CF Yeah, I think for me, this is why I probably say that I didn't realize I was doing functional programming because now looking back, I probably was really doing a combination of the two. But I think for me specifically, I took a live webinar course where the instructor was specifically exclusively doing functional programming in JavaScript. But I'll say too, I struggled a lot with learning JavaScript because it's such a flexible language and there aren't that many constraints and there's so much you can do and I always felt like I wish there were more rules if that makes sense. And like you mentioned, the fact that you can do both and it's kind of a combination of both almost all the time, is a good example of how flexible JavaScript can be and I kind of found that annoying.
MK I found the same. JavaScript doesn't really punish you at all. You can kind of just do what you want. So for example, when I was going through university and doing computer science they had stopped teaching Java in favor of teaching Python, which is again, another very flexible language. It reads very much like English. And I feel like I would have preferred having a more structured learning experience going through Java or C++ or something like that, that would have taught me object oriented and then moved into more functional and flexible ways of doing things.
CF I see your point, but I actually kind of disagree with you because I found that Python was like the perfect level of constraint with also being flexible at the same time. Or maybe it was the learning content that I was consuming that taught me Python that had a lot of standards and like, "This is how we do things and this is how it's supposed to be." And I found that things really clicked for me with coding when I learned Python. I gave up so many times when I was learning JavaScript because I just didn't understand what was going on. And like I said, the amount of freedom you have, for me it was like, I need some guard rails, I need some direction. I kind of consider Python my first official coding language that I learned, because like I said, I picked up JavaScript and did that on and off thing for a really long time. But Python was the first coding language that I started learning. I learned object oriented programming with that and it really clicked for me. So Python has a special place in my heart for that reason.
CW Nice.
MK I do have a question, Cassidy.
CW Yes, please.
MK So coming from the JavaScript land of things. And then you're talking about all these other languages like Elixir and Haskell. What is the difference between a language like JavaScript, for instance, versus something like Haskell or Elixir which is much more functional friendly. Like, what is the difference there in terms of what the language offers and syntax or whatever it might be, that makes it much more catered towards functional programming?
CW Right. So something that JavaScript allows you to do, for example, is make classes. So you could have, for example, a student class that has a constructor and the student can have a getGPA function and you can have a changeGPA where you pass in the current GPA and change the GPA, something like that. And you could create a new student object being like, "Let Matt equal new student”, and pass in variables or something like that. And then as you do that, you can say, "Oh, I want to loop through an array of new students and then change each of their GPA’s one by one." That is something that you can do in JavaScript. Also available in JavaScript, but the way that you would do it in these other languages, is instead of creating this object with these functionalities built in, you would just have an array where it's like, "Okay, let students equal..." and then an array of these objects, we could probably say arrays or something where it's like, "Ceora GPA 3.9, Cassidy GPA 2." Something like that. I did better in school than that, I promise. And then if you want to have your array of students with changed GPA’s, if you want to, let's just say I actually got an A in a class for once and Ceora suddenly got a B, oh no. If you want to change the GPAs you would run a map function over that and you would have a new array of students with their GPA’s. It doesn't update the previous one. And so there's no state that is shared across things. It just works that one time, every single time. And it's very recursive. You rely on recursion a lot. And you can return a function that returns an argument, or you could just return a certain result, but you never change something. That's what the immutability factor is.
MK So are you just saying that these languages, they kind of remove your ability to create classes and focus much more on that immutable function composed side of things? Like it just doesn't allow for that?
CW Right. Exactly.
MK Okay, cool.
CF So JavaScript isn't really purely functional at the end of the day.
CW It is not. No it isn't. And what's cool about this style though is, because it's all functions, and layers of functions, and functions calling functions and stuff, it's incredibly modular. Because if let's just say you want to debug something, if you have to deal with state and stepping through a bunch of different pieces of code, it can get kind of messy with object oriented because you're trying to say, "Okay, well, we know that at the end of the day, the student ends up with this GPA. We need to figure out where exactly that happened. We need to say, okay, was it when we called this function here or this function there? Or when did the object change here?" But with functional programming, because it's so modular, you know exactly which function was called, and you know exactly which function changed what, and which function returned X Y or Z. And so that's why a lot of people call it 'pure' because there's no things that could change what is actually being returned except for what you define to be changing things. If that makes sense.
CF Yeah. Yeah. Yeah. I have a question for you both. What do you enjoy more? Object oriented programming or functional programming? I feel like I know your answer already, Cassidy.
CW I mean, I love functional programming. I think it's so interesting because it's so weird. Honestly, I'm probably more comfortable with object oriented, purely out of practice and everything, and again, I didn't actually answer before, my first language was Java and then I went from Java to C++, and then eventually learned Python and stuff. But then when I did start learning functional programming, I was like, "That's amazing. It's so clean! This is how it should be." But it's not for everyone because it's a complete mind shift.
MK I find value in both, I think. Just coming from kind of like the enterprise JavaScript world where we've moved away from creating classes for everything now to more like React components, which are supposedly 'functional'. For things that put the same inputs into a function, they should give the same results back and you've got Object.assign, and all this stuff with state is kind of funneled into a more functional paradigm. But I want to start exploring other areas, like game development for instance, is very much object oriented. And so for me, who's not done object oriented programming at a professional level or is too familiar with it, I want to jump into that so I can be able to talk to this with a little bit more experience. But the one thing I really do like about functional programming is that it is modular. It's way easier to test and I find it reads better in my mind because I understand exactly what each small snippet of code is doing, and it helps me compose things better. So I'm going to do the cop-out answer and say 50/50.
All [laughter]
CF Oh, that's interesting. That's interesting. I'll say for myself, I think I dislike both equally because, I think naturally I gravitate towards functional programming just because I have to do some mental gymnastics to get into the object oriented programming mindset of classes and stuff like that. Like when I was first starting to learn how to code, I dabbled in quite a few different languages. And most of them, like I said, I did a little bit of JavaScript on and off. I never got to the point where it was really like you're learning functional programming or you're learning object oriented programming. So I didn't really know what was going on. And then at one point in time I learned Swift, believe it or not. That's object oriented I believe. Yeah. I'm pretty sure it is. That was years ago though.
CW I think there are elements of Swift that are functional, but yeah, it's mostly object oriented.
CF Yeah. Because I do remember having to deal with the classes and all that kind of stuff. I didn't enjoy that at all. I didn't like that. But when I learned Python, I was doing some object oriented programming with that. And that wasn't completely terrible. But now I have been on a quest to improve my front end skills, as a recreational, not too serious kind of thing, since I'm realizing I really fall more into the backend side of things. So I was like, "Let me kind of beef up my front end skills.", and I was taking a course and they introduced object oriented programming in JavaScript. And I didn't like it. I just didn't enjoy it. I think for me, although I'm realizing now that JavaScript has elements of both functional and object oriented programming, I don't really like when JavaScript is leaning towards the object oriented side of things. I can't really explain why, but it just didn't mesh well with my brain is what I'll say. I didn't like the vibe. I wasn't feeling that. That's my reasoning for everything with coding that I don't like. I don't have a concrete reason until I talk to people who really know what's going on. To me, it's just like the vibe was off. I just didn't like it.
CW I mean, in a way that's a big reason why I'm not deep into TypeScript land, because TypeScript, don't get me wrong, it has a large fan base for a reason. And the little I've touched it, I've been just like, "Oh, dang." Yeah, I understand the value of it. So full disclosure there, especially when I was a Java developer and then tried TypeScript, I was just like, "Oh, I could use this language that I'm comfortable with, but on the internet. Great!", and started dabbling with it. So I do get the value of that. But there is a verbosity in object oriented programming, not just in these languages, because I know Python, for example, is a much shorter language. So I'm not talking about long variable names or needing lots of brackets, but in ensuring that objects are constructed correctly, and inheritance is set up well, and all of the different aspects of polymorphism, so that way you can kind of shapeshift objects to adapt to certain classes. There are elements of that that I think are very powerful and that is why object oriented languages and that paradigm is so popular. But anyway, I like the idea of composition more than inheritance and that is more of an element that's in functional programming where you can kind of compose different components, functions, things, together. And that's something where I think React does pretty well as a library.
CF See what I mean? You just explained the vibe. Honestly, I'm realizing that I am a very lazy developer. I want to get started and make something quick and easily. And for me naturally, if I'm going to build a little JavaScript little doodad program really quickly, my first inclination is not to do object oriented programming. Because like I said, to me, to come up with the structure of the program and all that kind of stuff, to me takes a lot of thought process and I don't feel like doing all that. So that's why I gravitate toward functional programming first, because I feel like it's just easier for me to get up and running quickly. And I don't know if that's because that's how functional programming is inherently, or just because I understand it a little bit better than object oriented programming. But you also bring up a really good point about TypeScript, which is that I want to try out TypeScript because I think a lot of the gripes I have with JavaScript about it being too flexible could be solved with TypeScript because of the types and stuff like that. Has that been true in your experience with it?
CW Yes. I mean, TypeScript enables types, which at first you're just like, oh, so instead of, "Let this string equal whatever," it's a string that equals whatever, but it is much more strict and as a result the debugger is really, really powerful for it.
MK That was a major pain in the bum thing that we had integrating TypeScript into all of our projects, was we spent so much time fighting linting errors and all this kind of extraneous stuff that is there to help us work faster in the long run. Like, getting rid of PropPipes for React components and just having everything do that for us. That was amazing. But just when you're trying to hack together something, and if you haven't spent the time to really learn and respect the TypeScript rules, you're just going to end up fighting a lot of hurdles and smacking your head against the desk from time to time. But I enjoy working with TypeScript projects more now than I do with the older JavaScript ones.
CF Yeah. Okay, that's good to know. I think I really want to try it out because me and JavaScript have this love-hate relationship. I think it's really cool and I think people do really great things with JavaScript, but I don't know, we don't get along. And I feel like TypeScript would work out a lot better for me so I think I'm going to try that. And maybe next podcast I'll update you all on how that went for me.
CW There's also a concept that I think might interest you a lot, Ceora, and that's currying. Have either of you heard of the concept of currying?
CF I have. Do I know what it is? No.
CW Cool. Great. Well, a quick definition is basically, currying is when you break down a function that takes in multiple arguments into a series of functions that take just a part of the arguments. And so it's kind of like what you say, where if things get kind of gross and big and shapeshifty, it can be hard to maintain. In functional programming, you're encouraged to curry things and make a lot of things that do one thing really well and then combine them. And so if you break down a function, like let's just say you want to add two numbers together. You technically could do a function that takes in one number, a different function that takes in another number, and then another function that takes in the add function, and then a function that combines all of those together to just add something. Which when I say it like that, it sounds like why wouldn't you just do ‘return A plus B’ or whatever, but for more complex things, for more verbose things, it's basically writing really small functions that do one thing well and then combining them together.
CF See, and that's what it is. I just realized, hearing you describe that, I feel like object oriented is very big-picture, if that makes sense. Meanwhile, while I'm programming and I'm using functional programming, I don't have to think too hard about how things are really going to end up. I'll think, "I need a function that does this," and then I'll just make that function. And then later on, I'll probably implement that function in another function, like that, instead of having a big class that just does a thing, and I have to think really hard about how it's going to carry out the thing that needs to be done. Am I communicating that well? Is that coming across well? Because that's basically how I view it.
CW It makes sense.
MK You've actually hit a nail on the head there. So I was reading an article by Eric Elliott a little earlier on today, and he was talking about the imperative versus the declarative nature of functional programming. And it was pretty much exactly what you've just said, where a lot of object oriented stuff is very imperative in the sense that a lot of the things you write as an object oriented programmer is very statement based. You're saying, "This is going to do this. This is going to do this." And you're writing the execution. Whereas the declarative style of functional programming is a lot of the stuff that you do, you express it, I guess, in a sense. You're using utility functions like map or reduce or things of that nature where you're using expressions to evaluate what you're doing. So it's a lot more readable instead of say, for example, you've got an array and you need to manipulate or change items in the array, or you've got an array of objects, all that kind of stuff. You can just write a simple map function, which says I'm going to change, say for example, you want to add one to a list of test scores for students, for example. You can just write a map function which will go through, you do, person.testscore plus one, and it'll do that for you without you having to worry about the looping or the iterations or anything else that's just all tidied up into a single line of stuff. Which is a lot more friendly than having to go and do all the other stuff around the object oriented nature of things.
CW Yeah. A really good example of that, too, is jQuery versus React. Where jQuery is very imperative driven where, let's just say, I have a counter on the page and I want to increase the value of the counter. With jQuery, I get the element for the counter. I get the value in the counter. I parse that, then I increase the number. Then I repaint the DOM and put the new count on the page. And so it's a lot of trying to find the thing, then changing it, and then trying to change it on the page. Meanwhile with React, if you want to change something in the counter, you call the function 'increase count' and it just has the virtual DOM that changes it on the page. And that's really the difference, where I don't care how it's done as long as it is done. Also a real world example is, if you're driving in a car, if you have one of those older cars where you have a temperature knob, you could say, "Okay, well, I generally am feeling kind of warm, so I'm going to turn the knob lower to cooler. Oh, I'm starting to get hot, okay, I'm going to change it." Or whatever. You slowly adjust the temperature to what you want. Meanwhile, in the more modern cars you could say, "I want my car to be at 65 degrees Fahrenheit." You set that, you forget it. And if you want it to be hotter you just say the temperature. And so there's no adjustment because you get the exact temperature you want. That's the difference between imperative versus declarative. It's how you get there and manipulating things as you go, and just declarative saying, "This is what I want. This is what I want to be done."
MK I'm really not sure whether or not being called 'The JavaScript of Cars' is a compliment or not.
[music plays]
CW Alright. Well, let's do a lifeboat before we sign off for the day. A lifeboat badge is an answer score of 20 or more to a question score of negative three or less, that goes on to receive a score of three or more. So, it's someone saving a question from obscurity with this answer and the award went to M-M, who answered the question, "Find the area of an n-interesting polygon.” Kind of an interesting one. That being said, thank you so much for hanging out with us, functionally, object orientedly. Whatever your preference, we love chatting with you. I've been Cassidy Williams. I am Head of Developer Experience and Education at Remote. You can find me at @Cassidoo on most things.
CF I'm Ceora Ford. I'm a Developer Advocate at ApolloGraphQL. You can find me on Twitter. My username there is @Ceeoreo_.
MK And I'm Matt Kiernander. I'm a Technical Advocate here at Stack Overflow. You can find me on Twitter @MattKander.
CW See you later!
MK Bye!
CF Bye!
[outro music plays]