The Changelog: Software Development, Open Source - Functional Programming (Interview)

Episode Date: October 28, 2017

Eric Normand joined the show to talk about Functional Programming. We talked about FP vs OOP vs Imperative, why FP is popular again, the advantages and disadvantages of Functional Programming, and teaching Functional Programming concepts.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by CircleCI. CircleCI is how leading engineering teams deliver value faster. By automating the software development process, using continuous integration and continuous delivery,

you are free to focus on what matters most, which is building value for your customers. CircleCI is everything great teams need. Support for any language that builds on Linux, configurable resources, advanced caching options, custom environments, SSH access, security through full-level virtual machine isolation, interactive visual dashboard, first-class Docker support, and more. Get started with their free plan, which gives you unlimited projects and 1,500 bills per month. Plenty to get started with.

Head to circleci.com slash changelogpodcast. Thank you. We're talking about functional programming versus OOP versus imperative, why it's popular again, the advantages and disadvantages, and teaching functional programming concepts. So Eric, functional programming is not a new idea. In fact, LISPs go back to what, like the 1950s or 60s but definitely something that's in vogue and a conversation that's being had from developers around the world functional versus object-oriented versus some other thing kick us off with a little bit of what you know about functional programming writ large we'll obviously focus a little bit in on closure because that's your bag of tricks but let's talk about functional first can you give us a little bit in on Clojure because that's your bag of tricks. But let's talk about functional first. Can you give us a little bit of the background and kind of the state of the world?

Yeah, so functional programming, it has a long history. Like you said, beginning with Lisp, there was a paper in 1958 where John McCarthy described the language. And really what the challenge that they faced at that time was, how do we actually write papers about programming and ideas and programming? Like, do we just do it all in assembly? Which machines assembly do we use? You know, there was no standard back then. And he proposed a language that was much higher level than assembly that you could easily implement on any machine and then say, well, this will be a good language for

talking about programming and describing algorithms and things like that. He never thought it would be a language, like a real language that you would actually run on a computer, but his grad students did and they implemented it and it just ran from there in the lab because it proved to be so useful. And this was also

at the same time as Fortran was being developed. And so Fortran was the first non-assembly level programming language. But what's interesting is that Lisp was done by a team of grad students in university at MIT. And Fortran was like a multi-billion dollar project.

And so it always had this bootstrapping root. Anyway, that's a little bit about Lisp. Functional programming has been sort of evolved over time to be this paradigm that uses functions, that uses lambda calculus. It grew mostly in academia because of its roots in math. Roots that go back to lambda calculus and theorem proving, stuff like that.

And recently, it's gotten a lot of attention in industry. And no one really knows why. I've tried to figure out if there's some event or something like that. But what I can see is that people have been big names in the industry have been warning people about

functional programming, We need it and it's better than object-oriented for some things like for concurrency, for parallel programming. So I actually want to take a very simplifying view of why it's increasing in popularity. I think the size of the industry, the number of programmers is just growing by itself. It's doubling every five years. And so what we're seeing is that small portion of people who are always into functional programming are growing. And because of the internet, they can connect no matter where they are in the world.

And so now we're hearing about it, that it's just the network effect. So it's simply the small 5% of the industry that cares about functional programming. I'm just throwing that number out there. I just wanted a small number. It's now a sizable, absolute number of programmers. And coupled with the fact that most software now, it doesn't matter what language it's written in because it's running on a server in the cloud somewhere and it's not running on somebody's machine.

That was a big obstacle back in the day to what languages you could actually write software in. I think that it's just an opportunistic thing, just being able to run anything you want. One of the reasons that I heard, maybe three, four, five years ago, of people kind of prognosticating why functional programming as a paradigm is necessary now or is going to take off was because of,

you mentioned it's lends itself well to, uh, parallelization. Right. And, you know, we had Moore's law breaking down and we had this, this statement that we were going to now go sideways and have all these cores. And so you need to be able to parallelize across those cores. And I think so far in practice, I mean, I just bought a brand new laptop this year and I think I have four cores or maybe eight. But it's been like two cores, four cores, eight cores. I'm talking PC grade hardware, not server stuff, for a while now.

And so what do you think? Has that just not, hasn't happened yet, still going to happen? Or was that people were off on the whole parallelization of cores? The background on that is that they can't make transistors smaller anymore. It's reaching fundamental physical limits

of how many electrons you need to push through the transistor versus the amount of heat it's making and the leakage to other transistors next to it. And so there's what's called the right-hand turn on the curve. The curve was like this exponential curve. This is the Moore's Law curve. How many transistors we can fit or the cost of transit. It was like doubling every 18 months.

And so they started just spreading out and just making more cores that were essentially identical processors that shared memory. And yeah, so there was this idea that now there's no free lunch. You can't just wait 18 months and your software is twice as fast. So what are we going to do? We actually need to use all of our cores in our software. And I think about 10 years ago, that was a pretty good argument. That's what it looked like was going to happen. Cores started

coming out. You had two cores. And then really soon after that, four cores. That was 10 years ago. And I think the high-end MacBook Pro has... No, the Mac... What is the Mac Pro? The one, the all-in-one? Yeah. That one has 16. And so we haven't really had that doubling every 18 months. I was promised thousands, of course.

I remember people saying, you're going to have it in your laptop. Thousands, of course. That sounds so crazy, you're going to have it in your laptop, thousands of cores. That sounds so crazy. Yeah, and you would think, oh man, my software can't parallelize that much. What am I going to do? I better learn a language that lets me do that.

But it just has not panned out for probably a number of reasons. I think the biggest reason is that for software that you have to run on your computer, there's so many programs running anyway. Your operating system can't handle the amount of parallelization you need. So what I mean by that is, I have a Slack window open, I have tabs open. The tabs are each in a different process.

So the operating system process, it can soak up a lot of the cores that you've got. You don't need a single OS process that can do parallelization so well right now. That said I think that it is the

only way to grow really. Yeah. It's future proof in the sense that we can go that direction. Another reason why I think it's at least delayed is because of consumer demand with regard to what kind of features we want in our machines.

Most laptops are fast enough already for most people. Well, we want some battery life up in here. Yeah, exactly. And the processors, the manufacturers, the intels of the world, AMDs, they've started to focus on power efficiency more so. Maybe because that's where they can get big wins.

I don't know. Not my area of expertise. But I think that's delayed our demand. We're not demanding faster computers. We're demanding smaller computers. We're demanding higher efficiency computers. Well, It depends on the kind of person you're speaking about though. Because of the proliferation that he was talking about of the internet we've got a wide chasm of user type.

You've got some people who simply use mobile type devices, iPhones, Android phones, tablets that only really consume. There's some creation in there you know in in terms of like images or like user-generated content kind of creation but like our type of creation is like software creation you know like right not i wouldn't dare say true creation but it's a different style of like what you need to create and so our differences are way different than their differences or their desires or needs. And we're in a minority and there's just not enough volume

to justify designing a whole 1024 core machine just for programmers. Which is what the Mac Pro was, which is what you're talking about. It's for the extreme video editors, the extreme audio editors, the people who are producing, maybe they're even doing data science type stuff that need 12 cores to spread those processes across. But you also need software that actually utilizes those cores, which is the hardest part about buying that machine is like, do I actually have software that uses 12 cores?

And in most people's cases, no. Exactly, and then there's another aspect to it, which is, I hate bringing up this example, but I think it's so important. Some of the biggest, most scalable websites in the world are built on PHP, which is a single thread per request. The concurrency model is simply one request has its own memory, you do whatever you want, and then it's just blown away

by the operating system when it's done. That works. Do we need to have one process that can handle the concurrency and all the problems that that comes with? Even on the server, you don't have that thing. Now we have these virtualized things where if you need to scale, you scale horizontally. The servers themselves might have many cores,

but then they're running 20 VMs on them. And so those are taking up all the core. Each one is a separate core. We've worked around that problem in so many ways that I don't think we've had an opportunity for functional programming to have a real need, like a real pressing, this is our future kind of need. That being said, you're building a business

around teaching people functional programming. You're obviously big into it. Oh no, you're doing it all wrong here, functional programming you're obviously big into it you're doing it all wrong here Eric you're not selling it the way you need to we appreciate the honesty there if that promise is being worked around in other ways and we're seeing it even with clustering and all these other cloud infrastructures

scaling out horizontally there are pros and cons and all these other cloud infrastructures scaling out horizontally. There are pros and cons to programming paradigms, and functional programming is something you've been doing for a long time, and you are out there teaching people the gospel of FP. What is the benefits then, if it's not just mere parallelization? The summary of my answer,

I know this is like a programming interview talk show, so it will get longer. But the summary is that when we're programming, especially with, you know, we choose a paradigm like object-oriented and we start to approach problems if all we have is one paradigm, one perspective to solve that problem with,

we're going to be limited in what we can actually do. We could paint ourselves into corners and things, which we often do when we only have one solution, one way of solving a problem. And so to me, functional programming is a way to break out of that by just approaching the problem from a totally different perspective. It's to get out of your local maximum, get to a higher hill where you can combine different paradigms. I went to college, started in the 90s, and then the hype cycle for object-oriented programming was crazy.

Peak. It was. I mean, yeah, it was at peak hype where people were talking about, it was a panacea, it was going to solve the software crisis, the reuse, maintenance, and it just hasn't. No fault of the paradigm. People were just overselling it. I don't want to do that for functional programming.

I think when I look at my code, I see the influence of procedural, functional, object-oriented all throughout my code, and they were all useful in the same block of code. And so I don't think I would want to sell functional over any of the other paradigms. So I like that. The idea is not to pick the better hammer.

It's to have multiple tools in your box and be able to wield them when it makes the most sense. And the only difference is also... It makes sense thinking about it in the light, too, of the show we just had, Jer, because he said we're not paid to write code, we're paid to think. And the code is an artifact of the process of thinking.

So if you only have one perspective for which to think from, then you're limited in your ability to solve the problem. Absolutely. That's right. And I like to look at the paradigms in terms of, you know, a lot of people look at them like a list of features, you know, like object-oriented is message passing with encapsulation or procedural is like subroutines and um i liked and functional would be like oh first class functions immutable data that kind of thing um i think that's a useful perspective like you know perspective about a perspective uh it's it's useful to um to see the the paradigms that way sort of like a naturalist, you know, like, well, the red-breasted robin, you know, has red feathers on the breast.

So it's useful to be able to identify, like, oh, this language is object-oriented because, look, it has classes and methods. but I am starting to really develop more of a notion of them as holistic approaches to problem solving. And this is still being developed. I don't want to say this is it, this is the idea, this is the end all. And I would love to discuss this with you. I'd love your input on this. But so I see procedural as a very valuable paradigm because so many ways

that we approach a problem are step by step. Like you have a certain number of operations that you're allowed to do and you just compose them like in sequence and you can build up solutions and sub-problems you can solve

with sub-routines and stuff. So it's kind of like with procedural, the features are very much in line with the sort of abstraction that you're trying to build, right? So it makes it easy to confuse the two, the features with the thinking process. And then object-oriented is all about

objects that pass messages to each other. So how do you build this network of little computers that talk to each other to solve the problem? Which to me is like very unintuitive because that's not how i perceive the world right as like communicating objects no like i'm the one solving the problem it's not like these two things paradigm. And then functional, to me, functional is all about identifying the data that you need, the calculations on that data that you need,

and the effects. So often called side effects, the things that aren't pure calculation, they're like sending a message, sending an email, outputting something to the screen. And when you break the problem down into those three pieces, you can start to compose them together and get a solution out of that. I like thinking about it like that. I think there's something about um when

you look at a list of features or you know kind of your naturalist observationalist way that you're you're mentioning which we tend to do um let's compare two things well let's list the pros and cons of one on the left and the pros and cons of the other on the right and just thinking about that in light of procedural programming which is very kind kind of frowned upon, you know, because it's the simplistic, less featureful, old school, you know, way we used to do things. But what you said there was resonates with me because a lot of what we do is literally like procedures. Yeah. When you, when the procedure is known, right.

You're breaking it down into subroutines or sub procedures that are manageable sizes. Right. But it's like the perfect solution for a job of a list of known procedures. Right. Exactly. You know,

the steps to solve it, just write them down. Right. And it's actually one of the most satisfying things you can do because it's like, I don't know, just very straightforward and accomplishable. You know, we denigrate it a little bit by calling, you know, usually call those scripts like, oh, it's just a script. Like, anyways, point being is, is thinking about them holistically means that you recognize when procedural is actually a perfectly fine paradigm for a problem that you need to solve.

Exactly, exactly. And when you think about it, if you're doing object-oriented programming, very often inside of a method, it's just a list of steps that you need to take. It's very procedural. And so, like I said before, I find myself going through my code,

like, how did I do this? Oh, this actually I was thinking of it as a series of steps. Oh, this one is where I was like, oh, these are objects that need to talk to each other. Or at least this, you know, the main thread, you know, is talking to this other object that's doing something else on the side. I'm just passing in messages like I'm thinking of it in terms of these paradigms and then sometimes I'm separating out the data and figuring out what my calculations are and where my effects are going to happen. And so I hope to get this more formalized

and publish a really nice blog post about this because I feel like this is something that has been argued about for so long. What is object-oriented programming? And really the key insight that I think is valuable is to remove the features from it and put the features in their place. Well, of course, in object-oriented programming,

you're going to see a way to define the object's behavior, the data behavior, and that's called the class. So that's just an artifact of how that language happens to let you express what an object does. But there's other types of object-oriented programming besides class-based. There's prototype-based. There's prototype-based. There's actor-based like in Erlang.

And so if you remove the features and say those are just incidental, those are things that have been sort of built up over time as useful ways of doing that kind of thinking or expressing that kind of thinking, then you just look at it as an approach, as like a holistic perspective. Let's look at some functional languages. Well, first, let me just say for a guy who runs a website called Purely Functional TV, it sounds like you're not quite as a purist as perhaps one might assume because you're saying multi-paradigm approaches are good, right?

You're not saying functional only. Right, I'm not. I understand purely functional. It's called mostlyfunctional.tv. Oh, yeah. It's a good play on words. Kind of functional.tv. Yeah, exactly.

That's my point is the purity is being lost. But I agree with you with regard to multi-paradigm usage is a good thing. And so let's list some languages out there in the wild. So we've done a little, you said Lisp. You mentioned Fortran previously as a procedural, really, language. And then what are some that have both that are out there that people would recognize um beyond javascript which maybe people don't realize that javascript has functional

yeah aspects to it and prototype based object orientation as well it kind of has a little bit of everything into it but what are some other ones that people can kind of look at and latch on to say okay that's what that's what multi-paradigm means? Multi-paradigm languages. Often you'll see something like Python. Python is kind of just basic procedural, but then they added classes to it. There's also a little bit of features, you know, features from functional programming.

You know, you can have Lambda statements and stuff. So I kind of object to the question because... Okay. Because it's kind of going back to the features and not the thinking. Like you said before, thinking is the job of the programmer and writing down...

Well, I was more thinking of not feature lists, but languages which represent these paradigms. Languages which represent the multi-paradigm paradigm? Yeah, exactly. Which are like exactly friendly it's all yeah like i i guess well you mentioned erlang so erlang is a message passing right erlang language people say it's the most object-oriented language ever because it's all about message passing uh the processes um have a little bit of state in them. But then the interesting thing is that it's very functional too. Exactly.

So that's a good example that I'm looking at. Okay, right. Okay, that's good. And then it's also procedural because when you're passing messages, you have to sequence the messages. And so you're thinking in terms of like, well, I do this and then I do that. I would say Clojure is a good example of multi-paradigm. It's built on the JVM and its object system.

So the problem is JVM doesn't really have messages. It has methods, but they're a close approximation. And you have this ability to create objects and define their interfaces. And so then you can... Closure wouldn't be possible without that idea of an object with an interface to it and that has its own encapsulated state that is totally managed by the object and then the procedural like you're just

you know the inside of a function you can do anything you want in sequence so it's it's very procedural that way. Coming up, we talk through a post Eric wrote on dev too, a site we highly recommend by the way, Eric's post answers the question, can I do functional programming in my language? We also talk through object arena programming and functional programming on the front end, ClojureScript and React, and PurelyFunctional.tv, a site Eric runs to help any programmer get into Clojure. Stay tuned. This episode is brought to you by DigitalOcean, who just launched Spaces, a beautifully simple object storage service that's designed for those who want a simple way to store and serve a vast amount of data, such as hosting website assets, storing user-generated content like images and large media files, archiving backups in the cloud, and storing logs. Just like you're using S3,

you can use DigitalOcean Spaces. And in fact, you can use S3 and DigitalOcean Spaces at the same time, so you don't have a single point of failure. This is a standalone service, no droplet is needed, and pricing is extremely competitive. To make it easy to try for both new and existing digital customers, you can get started today with a free two-month trial of Spaces by going to do.co. And by TopTile. TopTile is the best place to work as a freelancer or hire the top 3% of freelance talent out there for developers, designers, and finance experts. In this segment, I talk with Josh Chapman, a freelance finance consultant at TopTow, about the work he does and how TopTow helps him legitimize being a freelancer. Take a listen. Yeah, in my arena within TopTow, I specialize in everything from market research to business plan creation to pitch decks to financial modeling, valuation, and then that leads very naturally into fundraising strategy, capital raising strategy, investor

outreach, closing a deal, deal negotiation, how to value the company, how to negotiate that. And all those skill sets that I have continued to hone over on the TopTal side are ones that I actually deploy every single day in my own company. Freelancing can sometimes be seen as not legitimate or subpar work. Now, I would argue that when you work with a company like TopTal, they put so much vetting into not only the companies that you work with, but also the talent that you work with, which I'm on the talent side, that it adds a level of legitimacy that isn't seen across other platforms. And that for me, as the talent side, is incredibly fruitful and awesome to be

a part of, right? I enjoy the clients. I enjoy the other talent that I get to talk to. I enjoy the TopTal team. And that creates an overall positive experience, not only for TopTal, but for me as the talent and for the client as the company on the other side. And that is really not seen or is the experience across other platforms in the freelance market. So if you're looking to freelance or you're looking to gain access to a network of top industry experts in development, design, or finance, head to TopTal.com. That's T-O-P-T-A-L.com and tell them Adam from the Change Law sent you. For those wanting a more personal introduction, email me, adam at changelog.com. so eric you got a awesome post on dev 2 which is a great website anybody can go there and publish we highly recommend you check it out if you haven't yet. Dev.to. And you recently published, Can I Do FP in My Language? Which seems like

a fairly logical question that you would want to ask. You're a wayward programmer. You're not really sure of a paradigm or you get turned on to functional programming and next thing you know you're thinking, well I know JavaScript. Can I do it in this language? Can you kind of state some of the things you share in that article and kind of help us understand why this question is so commonly asked? Yeah. All right. So I'll start with the last thing. This is a stack. I just drop questions on the stack. I pop them off. Keep them popping.

The reason I think people ask this question a lot is they, like we were saying before, they hear a functional programming as a list of features and they're like, well, I have functions and I have, uh, you know, data and I have a recursion in my language.

Like what does some functional language give me that I don't have? And they want some magic feature that you need when you switch over. So it's almost like a challenging question. It's like, why should I even, I know functional programming because I know how to make my data immutable. I know how to work with that. I know how to write a function. I do callbacks all the time.

And so the question is more like why can't I just do functional programming in my language? Why should I learn Clojure or Haskell? And so my answer to that is yeah, you can do functional programming in any language just like you can do object

oriented in any language including C. You can write your own little object system that passes messages and encapsulates state, that kind of thing. But are you really going to learn object-oriented programming by learning C, by staying in C?

Probably not. When someone actually does develop an object system in C, it's probably because they've been versed in Java or C Sharp or some other object or any language and they're kind of backporting that into C because that's

what language they have to use. And so I have the same answer that if you want to program functionally in any language, sure. But it's not going to give you any help for learning it. And to just think of it in terms of a few features, such as map, reduce, filter, those kinds of functional tools, you're not going to really get that holistic perspective, that holistic approach to a problem. You're just going to sprinkle it where it seems convenient

and it's going to be too easy to just back out to the stuff you're already familiar with. I mean, it's just like learning a language. You want to immerse yourself, like a spoken language. You want to immerse yourself in the language. If you set up conversations with a buddy so you can practice speaking, the first rule is we cannot use English. We can only speak French for this hour, whatever language you want to learn. If you don't have

that rule, you'll notice by 30 minutes in, you're mostly speaking English with a couple of words in French. And you need to just jump in, jump in the deep end. I like the idea of immersion. So you state that you can do functional things or you can do functional programming in any language. But if you want to learn the concepts, the paradigm of functional programming you can't just sprinkle it into your current environment because you're not going to expand

you're not going to actually learn and i took six years of spanish uh through high school and in college that's a lot i mean that's a lot of time right a time but i never i was never immersed into a environment that i could actually use it beyond the classroom with a bunch of other english-speaking people that were just joking around in spanish and because of that i never became fluent in the language even after six you know years of study because there was no immersion now i had a classmate who she went to um i can't remember exactly where she went, but she got immersed. She was baptized in Spanish.

Yeah, she was immersed in the language for a summer. And she came back just like, she had learned it. She was fluent. And so I think that is a good translation. Oh, see what I did there. Ah, yes. Well, immersion is a form of focus, and it's a well-known fact that if you want to do anything, whether it's learn something new or achieve a goal

or whatever it might be, in this case, examine or fully check out the idea or the paradigm of functional programming, you've got to totally focus on it. And without that total focus, you can't expect focused results. You're only going to get focused results by focusing or

in Jared's case, immersing. You might learn a thing or two, but you might learn a few vocabulary words or something. They have boot camps while they have the bunkers where you disconnect from the internet and program for a week straight with blinders on. You can't see your buddies

to the right or left of you. Your eyelids are taped open. Your hand is glued to the keyboard so you can't use the mouse you got to learn vim intravenous mountain dew whatever it takes and like that's that's how you get there well right that's not the only there's also it's it's one way of getting there and you have to you have to convince your brain that you actually need it. You need to learn this thing. Because if you have the option of speaking English, you're not going to learn Spanish. Not as well.

But if you have this, let's say two hours a day where you're only speaking Spanish, you set this up with somebody, your brain is going to be like, after a couple times, like, oh man, I really need to start thinking in Spanish a little bit more. And it's going to kick in. And the same with functional programming. You're going to struggle with it for a week

and then one day you're going to wake up with, you know, you had a dream where, you know, it was immutable values and recursion and stuff. And you'll be like, oh, I get it. I see how to solve the problem now. And you can't do that just by learning the pieces in isolation.

So you can do functional programming in any language. Yes. However, your argument is that you can write object-oriented programming in assembly too, if you want to. If you really want to learn the paradigm, don't limit yourself.

Exactly. You got to jump in. Alright so you set us up for the big hook now so how do you jump in? So I think you'd say learn Clojure. Clojure is a good one. I like Clojure

I've been into Lisp for a while and I also learned Java in college. So to me, it was just like, oh, this is the best of both. And so it was an easy transition for me. There's a bunch of other ones that might be better for each individual depending on their history. Haskell is notoriously very functional. for each individual depending on their history. Haskell is notoriously very functional, right?

It takes functional programming very seriously. And so, you know, if you want to jump right in the deep end and you have a couple of years to spend, you know, figuring out how to... I want to put this in a good way. Haskell is a great language. So if I say something frustrating from my experience with Haskell, it's only because it is frustrating

to have to learn a totally new type system and a totally new environment. But it took me a while to learn Haskell, even though I'd been doing functional programming for a while, just because the type system is so different. And it's powerful. Once you learn it, you get it on your side, it actually does help you. There's all sorts of options like Elm, which also has a type system, but it's not quite as complicated as the Haskell system. PureScript, Elixir, all sorts of great options are emerging right now in functional programming.

That's a good one that you mentioned with Elm, too, is that in our most recent issue of Changes All Week, I can't remember the exact link we shared, but it was something around front-enders diving deeper into Elm. I think it was the 20,000 lines of Elm link we linked out to Jared, if you remember that one. But for front-enders, you might be thinking to yourself, well, this is totally foreign to me. I don't really do much programming. I'm more building front-ends or I'm doing JavaScript type stuff. That's a great spot to start is Elm.

Yeah, for sure. I think Elm is a beautiful language. They've solved a lot of the difficulties of front end programming but in a walled garden kind of way. So it's not like you can apply this outside. So they have their own way of styling things and their own way of styling things and their own layout model and stuff like that. But it does eventually output HTML and CSS. So you can do

front-end web programming in a functional way. And it's nice. People really like it. It's a good introduction. It's got a Haskell-like syntax and a Haskell-like type system, but it's super friendly. The creator is very into making sure that it remains accessible

in ways that Haskell, because of its academic roots, has not been accessible to JavaScript programmers. You're a JavaScript programmer. You learned by copy-pasting from other people's sites, and you didn't really learn the type theory and stuff. Well, you can still use Elm and approach it easily. I like Clojure. That's what I teach on purelyfunctional.tv.

It's got both a JVM backend and a JavaScript backend, so you can do frontend and backend programming. And the Clojure script, that's what it's called when it's compiles to JavaScript it uses the most common way of doing DOM stuff is with React and wrappers on React and React is really friendly for functional programming

you just write functions that output HTML and boom you have a UI and I almost left front end programming because I was so tired of one pixel off CSS and HTML problems

and dealing with mutable state and updating the DOM and stuff like that but then React came out and I was just it just made it fun again and so I recommend React with ClojureScript came out and I was just, I don't know, it just made it fun again.

And so I recommend React with ClojureScript a lot. It saved my front-end career, I guess. Nice. That's a good thing to mention too with Ohm and even React is that traditionally the web front-end folks are most often thinking in objects. If you're in a design program, you're thinking about objects. This is a module, or there's different terms you use for it. So you're sort of baked into this object-oriented type thought until you hit React Realm.

And then you kind of get to explore other ways of doing things. It's foreign to the way you have been doing things. Yeah, and it's interesting you mention that because when I see, so I do mostly ClojureScript and React and it just works. We don't have a lot of fatigue like I hear about in the JavaScript world. And I've dipped my toes in JavaScript and React and the whole bundler, builder, I don't even know what they're called these days, webpack and stuff like that.

And I have to say, I see the fatigue. I understand. Because people are rewriting their build systems every six months and having to... Well, let's be clear. They don't have to do that. They don't have to. It's their choice.

Shiny objects. Right. That's one of the things of the fatigue. Yeah. We're not going to go down the fatigue route because I'll get going. But you don't have to grab the brand new thing every time. You can just continue with what you're currently doing.

We're just in a state of constant innovation and this is the effect of constant innovation. Well, so I'm going to push back a little on that because the weird thing is if I was in ClojureScript for like two or three years and I didn't touch any JavaScript and then I came out of that ClojureScript bubble and I was trying to help someone with their JavaScript and I couldn't anymore.

And I know that's a long time to be gone, but the syntax had changed. I didn't understand all this NPM business and what it meant to globally install an NPM thing and locally. It was really jarring. I had a lot to learn, even though I was like, I've been doing JavaScript for years. What is this stuff? And then I went back and did more ClojureScript and I came back and it was different again.

So you say you don't have to learn it, but if you want to help someone on their program, you have to learn what they're using. Learning and rewriting something is two different things though. So I'll back you up on that. I was speaking to the person who is actively developing a product or piece of software that maybe is a long, you could just keep doing your ClojureScript thing and everything's going to be just fine. I mean, I'm not saying that JavaScript isn't moving,

the state of the art isn't moving. It definitely is. But it's not like every time it changes, you know, its paradigm or its framework, you have to rewrite your entire application. I regret bringing this up because I- I told you, we'll get stuck on the fatigue thing and we're not talking about functional anymore.

We don't want to talk about fatigue, but what I was trying to say, which ties back to what we were talking about before, is when I've looked at React code in JavaScript, I don't see much functional.

The potential is there, but it seems like the people aren't... All components, right? Yeah, they're making components that are very object-oriented. They're doing all sorts of stuff in the lifecycle methods that's like AJAX fetching or setting some variable. They're doing something that's very procedural and effectful. I'll just tell a little story. I was hired as a contractor

to functionalize some React Native code. What I did is I came in, I added Redux, I started stripping out all of the effects from all the components and made it really removing bugs in the process.

I would finish up with one class, one component, and I'd go work on something else. Then I'd come back and find that the component I had just functionalized two weeks later was all sorts of state everywhere.

I don't know that that has been my that has been my experience with you know doing trying to do functional in javascript is the problem is i guess commitment lack of immersion um lack of understanding of why why you want to reduce the number of side effects, things like that. So in that case, you have a team that's not in the same mindset as you are. The team you're coming into is still on a different mindset. And of course, in that circumstance, they're going to continue doing what they know to do or what they're comfortable doing. And that's a natural thing. So when it comes time to learning that, so you were talking about

getting outside of your comfort zone in terms of a javascript or a c++ or a ruby or wherever you're comfortable at in some sort of either procedural or object-oriented little bubble the call to action is immerse yourself in something that is functional because you can learn more purely, more quickly, more thoroughly. You're not going to revert to using some mutable variable somewhere just because it's convenient, because you can't in the functional language. The language will constrain you into the way that you have to do it,

not just the way that you might want to do it. And then give yourself six months in that language. Let's call it Clojure, let's call it Haskell. Immerse yourself. And then when you come back to the JavaScript, you'll have all the tools, the mental models, the strategies for approaching a problem where you won't immediately turn to variables.

You'll say, well, variables are one option, but there's three other ways. We can put it in Redux, we can send a message, we can make an action, whatever it might be. So yeah, that's what I think the biggest advantage of learning functional programming is. So when you get back after six months, you can change all your React components into

functional. Exactly. And your teammates will turn them right back into object-oriented when you're not looking. Now, a lot of my customers on purelyfunctional.tv, I guess, share this similar mindset where they're like, my team does not like functional whenever I do it. Or they're just tired tired of object oriented. They're tired of the abstract proxy factory methods, those kinds of things. And they want to get out of that world and they see functional programming. There's jobs now in functional programming and they see it as an escape from that and

into a new rationality that they can buy into. And so, you know, what I do is to, you know, kind of holistically show that, yes, there are jobs. There is a way to learn the stuff you need. You don't need to learn quite as much as you might think. You don't have to be like an expert in functional programming to get a job in a functional language. Things like that. You can learn on the job. People want good programmers more than they want functional programmers.

So where does this fit in then? So we've gone through a lot of what you're sharing here. So what is, how does purelyfunctional.tv fit into your mission to introduce to all the developers listening to this that have not immersed themselves or don't think they have the time to get involved in this?

What's your mission here with this? How does it fit in? The mission of purelyfunctional.tv is to help people thrive with functional programming and right now i'm very focused on closure so you know thrive with closure um in their career right so it's all about um i have lessons that come out regularly uh it's video. And I'm teaching closure. I'm teaching functional programming principles. Giving lessons and exercises and things like that. So the mission is really to make

functional programming, to support that the viability of it as a job, as a career, that you don't have to just go into object-oriented programming. Tell us about the jobs. So this is definitely, I mean, you gave us a little bit of the history coming out of academia, you know, many of, many LISPs specifically, but even things like, well, I was going to say Erlang, but that wasn't academia.

That was a... That was industry. A very small niche of industry. Important, but kind of a bubble. But you have these things moving out to where now there are big businesses doing Clojure, they're doing Haskell. Is it Scala or Scala? I've never known how to say that. Scala is huge. So where are the jobs and what kind of jobs are they? Tell us about the jobs.

Just about every big tech company has at least some functional code. Facebook right now has Clojure, it has ML, OCaml. What is that called? Their new system? It's like a JavaScript syntax on OCaml. Anyway, they do a lot with that.

They use Haskell for their spam detection. There's a lot of stuff in e-commerce. The system that processes Walmart's receipts from every Walmart store in the world is a closure system. It's run by a small team that manages it and maintains it.

Banks, finance, they use a lot of closure. Amazon uses it, eBay, PayPal. You just go down the list and you can find functional languages at a lot of these companies. There's kind of a curse, if I can say that. The curse is that these systems are so much more maintainable than the object-oriented systems that have been around for 20 plus years now

that they don't require a lot of jobs. You have this team of 10 people with this receipt processing system from Walmart. That's one example. A lot of the companies that use Clojure, the bigger companies, they probably acquired another company and acquihired the team.

So that team is still there and it's still maintaining the system. I think Walmart is an example of that too. Twitter's analytics stuff was done in Clojure and was acquired. Would you really want to maintain something that doesn't really need maintaining for the rest of your life just because you need a job though?

Wouldn't you want as a a programmer, to be challenged? Sure, except people really want the paycheck. Right, job retention. Everybody wants job retention. Who wants that? Yeah, and so when you say, well, we're actually putting programmers out of work by writing enclosure,

that's not the biggest selling point. The thing is, the number of jobs are increasing. There's more and more companies every day that are using Clojure. Both startups, they're a small team, they're probably not hiring that many people. And big companies who are doing a new system or sometimes a rewrite of an existing system,

and they chose Clojure or Haskell or whatever functional language for whatever reason. And there's plenty of evidence for this. If you go to the Clojure conferences, they do a survey of all the attendees, and they figure out if they're being paid to do closure and where they're working and stuff like that. It's just growing. Every year a higher percentage are getting paid, a higher percentage have their company paying

for them to attend, things like that. Adam, this reminds me of a guest that we had on a while back, and it's one of these, I'm blanking, where they had built a system that we had on a while back and it's one of these, I'm blanking, where they had built a system that was popular and open source and their model for sustainability was going to be support. But they were very humble,

but they basically said in a very humble way, it didn't work because basically they didn't have enough bugs like their software actually didn't need support because it was just that good or something does that ring a bell for you it does i'm not placing it though if you're listening and you know the show email us and tell us because we'll put the show they put their code was so good they put themselves i do recall the conversation it rings a bell it's funny because that's one of the... Oh, I don't know what you would call it,

but it's a thing that people talk about in the Clojure world. They're like, what, this library hasn't had a commit in six months. And people are like, well, there's no bugs. If you report a bug, we'll fix it. But it's done. It solved the problem and it's done. Which I think is kind of like it is scary when you see there hasn't been any activity on this. Is this alive?

If I ask for a bug fix, will it happen? But also it should be the goal, right? It's just to finish. To solve the problem and move on. And that actually is one of the things that has appealed to me about Clojure and functional programming in general, really, is the way you can just attack a problem, solve it with the right abstraction, and then just you're done.

That's a good spot to leave it then. Let's call this show done. And thank you so much, Eric, for coming on and being so passionate, for sure, on functional programming. And then, obviously, all the time it takes to produce teaching around it and encouragement. It's purely functional.tv, right? That's right. Purely functional. It's purely functional.tv, right? That's right.

Purely functional, not kind of functional.tv. Not mostly. I'm going to register that domain real quick. Somewhat functional.tv. Purely functional.tv. Purely dysfunctional. That's right. No.

Yeah, thank you. This has been a blast. And I hope I wasn't too humble about functional programming. Thanks, man. All right. Thank you for tuning into The Change Law this week. If you enjoyed this show, share it with a friend, rate us on Apple Podcasts. And thank you to our sponsors, CircleCI, DigitalOcean, and TopTow.

Also, thanks to Fastly, our bandwidth partner. Head to Fastly.com to learn more. We host everything we do on Linode cloud servers. Head to Linode.com slash changelog. Check them out. Support the show. The changelog is hosted by myself, Adam Stachowiak, and Jared Santo. Editing is done by Jonathan Youngblood

And the awesome music we feature Is produced by the mysterious Breakmaster Cylinder You can find more episodes Just like this at changelog.com Or by subscribing Wherever you get podcasts Thanks for listening Thank you.