Grokking Simplicity

In this episode, I talked about my new book "Grokking Simplicity - Taming complex software with functional thinking".

HTML All The Things

Transcript

Matt: Hello everybody and welcome to the HTML All The Things podcast, Episode 63. Grokking Simplicity with Eric Normand, I'm here with [inaudible 0:14] Lawrence and I'm joined again by my co-host, Mike Koran.

If you've been enjoying the podcast so far, and you want to support us, there are a couple of ways that you could do that. You can review us on the apple podcast or on the podcast platform that you are listening to this on.

You can check us out on Patreon, we only have a couple of tiers right now but that three-dollar tier will give you a shout out in the podcast and we'll even share a link to your website in our show notes. Probably the most important one is just to tell your friends that we're here and we're ready to be listened to. Get this out there. Just share.

We really need a slogan for that, "Just Share," or something like that. It almost sounds like "Shazam." We also have a discord server, so if you're ready to do more than just listen to us, if you want to come and hang out, you can come and join us in our discord server, which now has over 200 members.

I'll do my best impression of a party noise maker, [screams] , but anyway, [inaudible 1:08] come, join us in that discord server to come chat about off topic things, about development things. We got people in there talking about WordPress, HTML, CSS, JavaScript, jQuery, BHP, everything under the sun.

There's probably something that we're not talking about in there, but anyway we have a whole bunch of stuff we're talking about. If you want to come and hang out with a cool group of developers from all walks of the industry, from the experience through the non-experience, feel free to do so.

Link to that discord server will be in the description almost said, what is this, YouTube? It might actually be, but anyway, we'll be in the show notes. Now, in today's episode, we will be discussing the book, "Grokking Simplicity: Taming complex software with functional thinking" with none other than the author himself, Eric Normand.

He started with functional programming in the year 2000 and has since watched the industry slowly take notice. Eric has spoken at conferences around the world covering topics like functional programming, Clojure, ClojureScript, property-based testing and concurrent programming.

On top of that, he also offers consulting and training services having worked with the likes of the federal government through non-profit companies. If you'd like to pick up Eric's book, we have a promo code available which is podhtmlall19.

We'll be including a link to the place where you can actually purchase the book as well as that promo codes. You can easily read it, just copy and paste it. That'll be in the full show notes on the HTML all the things website. We also have actually five copies of the book to give away for free.

We'll be putting two of those codes in the show notes on htmlallthethings.com. Now, full disclosure, these are single use codes, so first come, first served. If you're lucky enough to grab one of these codes, now if you copy them, they aren't gonna disappear. You better copy that code and immediately try to redeem it.

Also, one thing to just note in case there's a delay of some sort, these codes are only valid for two months from September 12th, 2019. Make sure you claim them in time before they time out. Now, I did mention that we have five codes that we can give away.

The other three, we will be giving away in our discord server. I will be tagging the @everyone tag for anyone that's in the server. I'll be explaining how we're going to give those away and they'll be given away within a day or two as of this recording, which is, let me just read the date to make sure this is official, which is October 8th, 2019.

Make sure that you go and check that out if you're listening to this as a fresh episode. If you're in the future, I'm sorry, but you can use that discount code if you'd like to get a nice discount.

Now, without further ado, let's cut to that, let me say juicy, but I don't know what I meant by juicy like am I just thinking of the keg, the juicy steak. Anyway, let's cut to that interview with Eric and Mike, stay tuned.

All right everyone, we have Eric on the line, and as is the tradition around here, Eric, please take it away. Let us know what you're doing, what you're up to, and a little bit of your back story.

Eric Normand: Hi. I'm Eric. I am currently writing a book about functional programming for beginners to functional programming, but people who have had some experience with at least one language. It's called Grokking Simplicity, and it's published through Manning.

Basically, it's supposed to be a fun trip through the paradigm shift of functional programming. That's one thing I'm doing. I'm also a teacher online. I record videos, courses on Clojure and functional programming. You can find those @purelyfunctional.tv. That's about all I do.

Matt: Great, thank you for being on the show. I'm really looking forward to this episode because we haven't really done...I don't know if we've done any talks. Maybe Michael will have a comment on that, done any talks at all on functional programming on the show.

This should be a really interesting one, especially for a lot of our listeners because they are usually either hobbyists or beginners or some veterans in their course, but this will be a really interesting sort of a topic to cover since it's so new to us.

I'll jump right in here. These are going to be some preemptive questions regarding the book in the segment Writing a Book in our show notes there. "Grokking Simplicity" isn't complete yet, but rather has been released as an early access title. Why did you choose to go the early access route?

Eric: The idea behind early access to get more feedback faster. Writing a book is a long process. It's good to know how the book is going to do [laughs] before you finish the book. If it doesn't do well, you could try to figure out why. Get some feedback from some of the early readers and pivot. Maybe they'll ask you good questions that directs the new chapters that you're still writing.

I've talked to the people at Manning. They say that the reason they started it was because technology changes so quickly that often a new version — let's say you're writing a book about a database — of the database could come out before you finish writing your book.

It's a shame because the first three chapters have been ready for a year. [laughs] If someone could have been using them and gaining some value out of it before the final chapters are done. I look at it like that.

It's a good way to get it out there. It's very motivational when people buy it. I'm not done. Oh, some people are buying it. OK, I better keep working on it. I better finish it up. I do that with my courses as well. I knew what I was getting into, and I really think that it helps a lot.

Mike: How do you choose when to stop and release the early access portion, or if that's not enough, or it's much? When do you cut yourself off and be like, OK, this is enough for an early access bit?

Eric: Good question. Manning has their own process behind it that I'm not really in control of. I don't really have that much introspection into how it works. But this is what they've told me that they want to release something when it has significant value and it's not embarrassing.

Something where you've put some good quality content in there and it's not too rough that people would be like, "What is this?" Then the idea is publish one new chapter or a significant update to the book every month just to keep the momentum going, keep people who have bought engaged with the book. Don't let it go too long without new content so that they'd forget what the book is about and why they were reading it.

Mike: Another thing. Matt and I read the chapters that we got. You mentioned in those early chapters future chapters. Like in Chapter 17, we'll cover this and that, and stuff like that. Before you even begin, you have a full outline of what you're going to be covering chapter by chapter.

I'm assuming you have to send that to the publisher, get that approved. There's probably a big process where your book is planned, it's just those other chapters aren't refined yet, right? Is that how it works?

Eric: Yeah, that's right. After we signed the contract and everything, the first thing they ask me for...This is the publication contract. The first thing ask me for was a table of contents. I was like, "Are you sure? I could make one up, but I don't really know [laughs] what I'm going to have.

They were like, "Yeah. That's what we want." We want to know what are the topics you think you're going to cover. It can change. It's not a commitment, but that's where we work. At first, I was just very hesitant to do it, very reluctant but the more I thought about it, the more I was like, "OK, I have these ideas in my head. They don't know what I'm going to write about. They have no idea. They need something. [laughs] They can't just wait for me to write them."

I sat down and I made up the table of contents. They send it out for review to other functional programming experts and asked them questions like, "Are there any topics missing? Are there any things that you think are important?"

Sort of grade the thing on one to five. Is it good quality? Do you think that this would be worth reading? Questions like that. Everyone said, "Yeah. Those things sound good." At the same time the people who weren't functional programming experts like my editor and other people at the end manning, they were like, "I don't know what this is about."

[laughter]

Eric: What is that chapter about? One of my chapters is, "sets."

[laughter]

Eric: They are like, "Sets? What does that have to do with functional programming?" I'm like, "Well, you wanted me to write the topic with the chapters. This is it. This is the topics of the chapters." Since then, the table of contents has refined.

I've gotten better about understanding how to craft the title of a chapter and what I actually want to say. Actually, I think you read...Yes. You read the first release the V1 of the MIP.

In the V2 which is coming out really soon, I can't say when it's out of my hands but it's close. There's a totally different table of contents because I reorganized the material in a much better way. It's evolving. It starts somewhere and it evolves.

Matt: Sorry. What I was going to ask there was, how open are you and maybe the publisher are to actually changing the maybe not the addition number but the previous chapters? Do you guys get stuck on, "OK, I've written parts." Let's say parts one through four. You keep refining and refining that.

Then struggle to get on to part five in this case? Or do you keep writing ahead and then just keep going back when you receive that feedback and do like little changes?

Eric: Yeah. This is another interesting question. Just a little background. I've been blogging for over 10 years. I'm much more comfortable like, "Let me just write a first draft and hit publish." [laughs] Then my publisher is there.

They want me to go over and like, "Oh, this could be better." I'm like, "Yeah, but it's good enough for the MIP, right? I'll come back later." They're like, "Well, while you're here just finish it." I'm like, "Just send it out."

There's a little tension there because I really do have this tendency of just like, "Get the idea out, see what people think. Get some comments before regretting sending it out [laughs] and definitely change it."

I would much rather finish a sketch of all the chapters and then come back through because by the time you get to the end, you've learned so much that when you do the second pass you can incorporate that learning.

My editor is much more like, "No, first impressions matter." Like, "We know how to improve this. Let's just keep improving this until we can't." Really in practice what happens is we do that until I feel stuck.

I feel I could improve this, but I'm tired of it. I'm burned out on this chapter. Can we just put it down and move on? That's what happens. It's more like, "I just don't want to work on it anymore."

[laughter]

Matt: I guess that's when you know you've put enough work into it, right?

Eric: Yeah. I guess so. I don't know. I've never seen him stop. [laughs] Maybe we can keep going and going and going. It's really maybe that's what he's doing. He's pushing me until I can't go anymore. I don't know.

Matt: The next question here, so when would you say is a good time to start writing a book? Couple of things to compare to. Like, how much expertise do you need to have? Do you need to perceive things a certain way? Do you need to have a level of mastery in some way?

Eric: That's a good question. I think it depends a lot on your goals. What are you trying to get out of the book? One of the things is that you don't want to...You don't want to fake expertise, fake mastery, fake more experience than you have. You don't want to do that. People can see through that really easily.

That being said, I think that if you're a good writer you can make a compelling story or a compelling read out of your beginner experience. If you could turn that into something, I think it's there. However, depending on your goals, you might...

What I'm afraid is someone who doesn't have a lot of expertise will waste their time. It takes a long time to write a book, a lot of effort. If your goal is something like write this book and make a lot of money or sell a lot of copies or even gain some notoriety in the community, you're much better off earlier on publishing smaller things.

A blog for instance, articles in the magazine. Smaller things that you can finish and see how well you're doing you're developing the craft of writing, you're developing your communication style and the message that you want to have.

You might find that, "OK, I have written 10 magazine articles. I think that I've got a book idea now." "This is too big for a magazine article." I think that it should come naturally and organically.

For instance, my book, my goal is to spread functional programming. I think that is one of my goals. I have several goals for the book. One of them is to make functional programming more accessible, more popular.

I just had this idea, this little core and I had to BS the rest of the table of contents. I knew that there was a core there. As I developed it, it turned into a well fleshed out table of contents. It's big enough for a book. I knew that.

I only knew that because I've written a lot on my blog. I've given conference talks. I've published these videos. I knew that it was a major thing. I couldn't do it justice in a blog post.

Matt: That's interesting. I like how you broke it down. For me, when I think about writing a book, it scares me right away. I think it's because I don't have that body of work that you're talking about. I don't have something that I couldn't say in a blog post. I think that's my issue.

Whereas what you're saying is, when you get so many blog posts, and you're like, "OK, I've planned out seven or eight different blog posts on the same topic." Maybe that's the point when you're like, "OK, maybe I can expand this, because I have so much to say about it, into a book."

I really like how you broke that down. I think that'll help the audience understand when it is you should start thinking about writing a book, rather than, "Do I have the knowledge? Do I have the expertise?" Stuff like that.

You're right. That's the wrong way to think about it, because it's impossible to tell.

Eric: Right. I didn't know I was going to write a book until I found that idea. It wasn't like, "OK, I need an idea for a book, let me brainstorm ideas." No, it was the opposite. I had this thing...

I wrote a blog post and it was about different paradigms like, "How do you define imperative programming? What's object-oriented programming? Then, "What's functional programming?"

In doing that I realized I came up with a pretty unique formulation for what it is. This is from years and years of writing about functional programming and talking to people, going to conferences, practicing functional programming. Then I was invited to speak at a conference, and they said, "You pick the topic."

I said, "I think I want to talk about this idea about what functional programming is." I gave the talk. Then I realized, "This is a big idea. The talk couldn't contain it. I need to turn it into something bigger."

I started podcasting about it, and it's just like streaming out of me, all these topics on functional programming. No preparation, I just start recording and start talking about a topic.

Then, I would do that multiple times a day [laughs] like so far ahead, I was like I should publish two a week as I am never going to finish my recorded episodes. Then, I decided, "OK, it is going to be a book."

Matt: That's cool. It's a cool little insight into an author's mind, I guess. [laughs] One question and this is more of an organizational project planning kind of question, how do you break up your day? How much time do you spend writing your book?

Is it like a daily thing where like this day is just meant for the book or do you break up your day, be like four hours book time, four hours not book time? What is your process?

Eric: My process is really disorganized.

Matt: [laughs] Like all of us.

Eric: Yeah. I'm trying to think if there is some like, "Oh, this is my ideal," like I have done it for a week and it was awesome. I'll tell you, what I try to do is have a day for the book where it's like, "Tuesday, I'm going to sit down and work on chapter six."

That lets me get into the book, forget other things. I close my email, I close all that, just work on the book. I have two kids and they disrupt my schedule a lot. One of them is a baby, so it is very disruptive.

The book also is not very text-heavy. When I write blog posts, I'm like, "OK, I want to write a lot of blog posts. I have a big post to write." I have a schedule like, OK, I'll wake up early in the morning, and I just get my keyboard and a coffee and I just start writing. I just type.

This book isn't like that. I really need to be able to work in different modes. It is also such a big topic. I have to take notes. I have note cards, I am like saying, "This is later. This goes in that section."

It's also a lot of mouse work, like laying pictures out, doing codes, snippets, and things in the book. It's not quite as like single-minded focus as I remember from writing a lot of blogs. That's why I like to have the whole day because I don't know how long it's going to take.

I want to be able to just spend all day with no cards like shuffling them around, maybe I don't produce any pages that day.

Matt: How vital would you say is — I guess this is more toward blog posts — hitting those targets that a lot of engagement specialists and a lot of marketing folks will say, "You should do a blog a day or a blog every other day."

How much pressure do you put on yourself to actually reach targets like that like, "Oh, I need to post something every Wednesday," let's say, or something like that.

Eric: Right now, the only schedule I really try to keep...I guess I have two schedules. I have the podcast. I feel like that should be regular, I don't know why but I feel like I want a podcast to go out every Monday and Thursday.

I've got my newsletter that goes out every Monday morning. I want to do at least an hour of video per week — video courses. Other than that, I feel like I cannot really sustain anymore.

I have also, in my blogging, gone more toward a longer form and more comprehensive guide approach because I think at the point where I am at, in terms of you SEO and authority building and stuff, I really want...

I'm working in Clojure, that's what I'm teaching. I want there to be a comprehensive Clojure learning site. These little one off 500 to 1,000 worded blog posts are not going to ever get there. I need to say, "OK, I'm going to look at every single data structure," and just list them out.

For each one, I am going to talk about when to use it, when not to use it, and that turns into an 80,000-word thing. That's just the link that has to be. I think that works better for me where I am at.

I do think that there is something to having a schedule because I am not typing so much right now like typing words for writing stuff, I find that I hesitate a lot more like "Oh, maybe I shouldn't type that," whereas when I have a schedule like, "OK, every day, I have to post a blog post."

I don't think. I'm like, "I've got to get this thing out," because [laughs] this is a lot of words. You know I had tricks. Here's a trick that I used to use. I was for, I don't know, a few months posting a blog a day.

What I realized was, when someone would ask me a question in email, I wouldn't hesitate, I would just open up the email, hit reply, and just start typing an answer. I thought why does blogging have to be harder than that.

What I would do was the night before, I would email myself a question. I would phrase it like, "Hey, Eric. I'm a big fan. I have a question about Clojure," and [laughs] then I would write out the question like I was really asking it.

Then, I'd go to sleep and then in the morning I'd wake up with my coffee and I'd open up the mail client like, "Oh, an email from a fan," and [laughs] I'd open it up. Just like, "Oh, nice question, Eric."

I would always start like I was actually responding like, "Hey, Eric, nice question, thanks for reaching out, enter." Then, I'd just start typing the answer and then that will be my blog post. It worked, it was like a psychological trick to get me to write more without hesitating and second-guessing, "Is this worth it?" or whatever. No.

It wasn't like these comprehensive guides. It was a specific question, a specific answer and it worked. It's really great.

Matt: It's like setting your clock ahead by 10 minutes. You're just tricking yourself every day.

Eric: [laughs] Yeah, exactly. By telling your friend, "Pick end between 10 and 20" and set my clock ahead so I won't know how far ahead it is.

Matt: [laughs] Yeah, exactly. It works, it's been proven to work. That's a cool little trick there, that's awesome. In your blog post would you actually keep the header parts?

Eric: That's a good question. What I would do is say, "Hey, that's a great question. Let me rephrase the question for you just to see if I understand it and then I'm going to answer it." I would start the paragraph like, "Someone just asked me, duh, duh, duh, duh." [laughs] and then I'd answer it. Yeah.

Matt: Giving away all your secrets to your fans. Everyone thought you were just getting asked all these questions but...

[laughter]

Eric: Sometimes they were directed at me, but usually it took me a month to really come up with the answer. Now that I sent it to myself...

Matt: Now it's in writing and it's there in front of you. That's cool.

Eric: Exactly.

Matt: With that all being said, there was a segment about, "How to write a book" and stuff like that. I want to move on to functional programming because I think it is an important topic. I learned about it a little bit when I was studying in university. We learned about all the different programming paradigms.

When I sat down to read your book, I didn't know what to expect obviously because you and I had never talked and I had never read anything from the Grokking series. Grokking is a series from what I understand it right that you're just adding on to as an author?

Eric: Yeah. Series is a book term. They're not related like you got to read this one, then the next one, and then the next one like a television series. You have to watch them in order. They do have a similar style and they're supposed to have a similar scope and feel to them.

Matt: Yeah, exactly. When I sat down to read it, I was actually in a hotel room and I popped out my iPad and went through it. It was actually a really interesting and engaging read. Even for someone that maybe wasn't expecting it and wasn't looking for, "OK, I need to change all my stuff to functional programming."

I thought it was good in the sense that it taught me what I was doing that was already functional and how to think a little bit differently as well. Which is valuable to anyone at any point in their programming life. If you're just starting out even, I would say this is a valuable thing to know about. To know about a thing called functional programming.

Because not only will you know about, "OK, this is how to think functionally," but you'll know that what you've been doing, there's certain things you've been doing that are already functional. It's cool to label what you've been doing because it's tough.

When I was first starting out, you just sit down and write code. Your code just looks however it is — spaghetti code, functional code it doesn't matter. It just works. It's tough to talk about it to other industry professionals. It's tough to label it, it's tough to organize it in your head as you go forward.

It was definitely a helpful reminder of functional programming and a very much a "scope-broadener." It definitely broadened my interests in it which was cool. I like the way book was laid out like you were saying, it wasn't text-heavy. It's very much diagram-heavy and picture-heavy which is a really cool way of doing a programming book.

Because I read a few of them and a lot of the ones that I have read have been text-heavy and they've been a little bit harder to sit down and read in an afternoon. I sit down and read when I need to like, if I pick up a book usually about programming, it's usually because I need something from it period.

It's not an entertainment thing for me. Whereas a Grokking-type style like this style of book was almost an entertainment thing. I sat down with a coffee like you were saying, you were writing it, I sat down the same way reading it and I was like, "Wow, this is actually really interesting." Props to you on creating that atmosphere in your book and...

Eric: Thank you.

Matt: Yeah, no problem. I just want you to give a quick overview to our audience because our audience is usually very new to programming. Usually new to web development in general. They're looking at it from a very beginner point-of-view, so if you can give a nice overview, doesn't have to be too in-depth obviously of what functional programming is.

Eric: Sure. I do want to say thank you for all the nice things you just said about my book. I feel like you hit the nail on the head or I hit the nail on the head. [laughs] That was my goal. What you said is my goal. It's to make it feel like, "Oh, I know some functional programming."

I do want to also thank y'all two because there's a lot of beginners out there and you're making great content for beginners and really making it very accessible for them. Anything to help people along, any content out there, thank you so much.

Matt: Thank you.

Mike Koran: Thank you very much, yeah.

Eric: OK, an overview of functional programming. This is not going to be the Wikipedia definition of functional programming, because I think the Wikipedia definition of functional programming does a disservice by being too academic and obtuse.

There's a lot of baked-in assumptions about what you need to know to understand that definition. This book is trying to take people who don't have those assumptions already and give them a perspective for how to see their code. So that that definition might one day make sense to them.

Functional programming is a paradigm. You might have heard of imperative programming or object-oriented programming. Functional programming is one of those. Those are three different paradigms. It's a set of perspectives and skills that you approach problems with.

You have some programming problems, how do you look at it? What are the first things you do? What are the things you look for? How do you look at the problem, and then what kinds of programming skills are you going to bring to the table to solve it?

The way I define functional programming is the first perspective, the first distinction that a functional programmer makes is to divide everything into actions, calculations, and data. Actions are things that have an effect on the world or if your system is affected by the world.

If you get an event like a mouse click, your program is being affected by the outside world. Or you could send an AJAX request that's having an effect on the world. Because you're posting some data to the server, now the server is different.

Calculations are pure computations. That means that it's something like addition. You know four plus four doesn't have any effect on the world. It just calculates eight and it's going to calculate eight every time. Doesn't matter when you run it. It's timeless. It's just always going to do that. You can write your functions to do the same.

If you wrote a function that would just return four plus four. That function now, every time you run, is going to give you eight. It's going to give you the same answer. You know you can make a more complex function of course that has arguments.

If, for the same arguments, it returns the same value and it doesn't send Ajax requests or do any actions, then it's a calculation. It's something that you don't have to worry about when it runs, whereas for instance, if your system sends an email, you do have to worry about when that runs.

I want to send the email, or at least I have to worry about how many times it runs. Sending the email zero times is totally different from sending it one time. There might be things that you have to do in a certain order like I want to set the button to spinner, like get the Ajax request, and then that response is going to...Now, I'm going to put the value into the button.

These things have to happen in a certain order and it's hard to have order in a Async environment like JavaScript. It turns out other systems, other languages that don't have Async stuff, they still have the same problem.

Then data. This is the third thing. Data is just what you would call data. Numbers, strings, data structures. What's interesting about them is they are totally inert. They don't do anything. They just sit there. You can send them across the wire. You can save them to a disk. You can do whatever you want to them. They can be interpreted at all ends of that sending and receiving.

Because they don't do anything, they need to be interpreted by something. They need to be interpreted to give them meaning, because the number four doesn't mean anything unless you know how to interpret it.

The same with a huge Jason blob. What do I do with this? Oh, I'm looking for the user ID, which is down in this object deeper in here. OK, that's where the user ID is stored. You're interpreting that object in a certain way.

Data is the safest, because it can never crash. It can never have any problems you can have bad formatted data, of course, but it's data, it's still data. It's not going to cause any problems.

Calculations are good because they're pure. They can be easily tested. One thing about testing is you're probably going to want to run the same function multiple times. You don't have to set up any environment for a pure function, for a calculation because it doesn't depend on anything on the outside except the arguments, and you pass those in and you can choose exactly what to pass in.

You can run it on a different machine. You can run your test on your billed server. That test is going to be valid for someone's browser, when the JavaScript is running in the browser.

Actions are the most problematic but they're necessary, because you need to send that email or you're not doing what your software is meant to do. We need them, but we also know that they're most dangerous. They're the most difficult to work with.

A lot of functional programming, starting with these divisions, splitting things up and identifying these are my actions, these are the calculations, these are the data. Once you split them up, you can start to focus more attention on the actions because that is where the problem is. You just pay more attention to them.

You can move code from action into calculation. You refactor stuff. Pull it out, "Oh, look, here's this little calculation I'm doing inside of this big action." I can now make that into a function, which is a calculation. You're moving code out, making it more testable, more reusable.

This is a large part of what the first part of the book is about. It's about how to identify them, how to refactor stuff out, how to work with data so that it's immutable, meaning you never change it.

Then, the chapter wraps up with a little bit of architecture, a little design called stratified design, where it's about how you can design these layers of meaning so that the layers of code align themselves with how fast they change.

You'd imagine the fastest changing code is on top and the more stable code is on the bottom. That's really nice because the stuff on top is built on the stuff below it. You don't have to change the stable stuff. If you had to change the stable stuff, [laughs] everything on top would topple over.

Because it changes less frequently, you've sort of reduced your maintenance to the minimum.

Matt: Yeah, that's a really good, succinct functional programming overview. Thank you for that, that's for sure.

Hopefully, with that, people can kind of form something in their minds of what functional programming is because as we're going to move forward, we'll talk a little bit about functional programming as well as when to use it and stuff like that. Just keep what Eric had said in mind.

Next question here would be, most developers, especially ones listening to the podcast, wouldn't label themselves in one of these paradigms because they're just starting out like they're just doing JavaScript.

JavaScript can be one of many things [laughs] when you're writing it. That's one of its things. How important is it, two-part question here, to know about all the different approaches that are out there like all the different paradigms out there right away as you're starting out developing?

How important is it to use one and then strictly follow it, like really dive into only functional programming and be an expert in that?

Eric: I have two answers to that [laughs] . I don't think it's so important to be strict on any one paradigm when you're programming. I look at them as sets of skills. In my book, I'm really breaking up functional programming as a set of skills that happen to be used by functional programmers.

These are things that come from that perspective. They're not exclusive to functional programmers, but I would say that they're more common, functional programming team, but they're useful. They need to pay the skills and the approaches, need to pay for themselves right away.

Meaning you should not think if I'm not a 100 percent functional, it's not worth doing at all. You should be able to see, "Oh, if I just made this one thing immutable, then I would solve the problem that I have."

You don't have to make everything immutable, just this one thing or this function is getting really long, let me factor out all of the little calculations inside. Maybe that's one little thing you do in one place in your code and it just makes it a little bit better.

That would make me very happy if people learned to do this kind of piecemeal functional programming. That said, in terms of learning it, I think there's something to be said for immersion.

If you're really into learning object-oriented programming, you might be better off choosing a language that makes it really easy and makes everything else hard. Then you're going to have to figure out how to solve problems with those skills and those perspectives rather than some other one that you might already know.

Likewise, with functional programming, I think it is easier to learn if you are in a functional language so one that makes functional programming the default.

That's not to say that you can't learn it and you can't learn the skills, but it's just like learning a language. You can learn to speak a few words and even some grammar and make sentences, but everyone knows the best thing is to just live in the country where you're forced to use it.

Matt: Absolutely. Just to follow up with that, what would you say are the functional languages then like? Do you have a few in mind?

Eric: Yeah. Clojure, Haskell, Erlang, Elixir, PureScript, TypeScript. Not TypeScript. I wouldn't put TypeScript in that. Elm on the front end. Rust is pretty functional. Swift is functional.

Matt: Swift is functional. Where would you label something like JavaScript?

Eric: JavaScript is multiparadigm. I would say that you can do functional programming in it but it's not...It's like a city where you can speak both German and Spanish. If you speak Spanish, you're not going to learn German because you're just going to speak Spanish every time.

If you know imperative programming in JavaScript, it's going to take a lot of will power and discipline to stick with the functional stuff which might be good. If you're working at work and you just need to get features done, sometimes you're just going to do it the familiar way.

Then sometimes you're going to say, "OK I've more time, let me see how I would do this in a functional way." That's a perfectly fine way to learn. Do it again. Once the way you're familiar with and then the second time try to approach it with different set of constraints. That's a great way to learn it fact.

Matt: That makes perfect sense. I think with the web developing crowd in general it's kind of these concepts are always a little bit harder because of that multi-paradigm approach of JavaScript.

When you're talking to someone and you're like, "Just use the object-oriented approach" They are like, "Why? I'm just writing this code." Like, "Why are you trying to get me down in certain specific path?"

Eric: I'm just getting it to work. [laughs]

Matt: Yeah, I'm just getting it to work even though if they were using something like Java, they would be forced to use the object-oriented and it's a lot easier.

Eric: You see the opposite which is someone who overuse its OO. That's great because they're exploring the class keyword, the new class keyword in JavaScript. They want to do everything with that instead of the simple way which would just be use the function. Like, "Why are you making a class for that?"

That's great except if you're doing it on production code like that's not your time, you're spending. [laughs] You're spending company time on your learning. Maybe you should be doing that on your own time to explore that thing.

See, I think doing these extreme things which is like, "I want to use the class everywhere, I want to find the limits, right?" That's great. I've grew up on that kind of stuff like, "I'm never going to call. I'm never going to write a function. I'm going to only do methods."

Sure, do that. Then that might not be the actual most professional way to write it. You have to recognize that.

Matt: That makes perfect sense. One thing I bring you back to the book a little bit, in the book you actually chose to use JavaScript as the language to explain functional programming. I think you do a good job explaining why.

I just want you to point out to everyone. It's also important for our audience to know that when you're going to be reading the book, most of you are familiar with JavaScript so this book resonates with you more than someone that's not familiar with JavaScript.

Eric: Good question. I feel the need to emphasize that it isn't a functional programming in JavaScript book. This a very common question that I get because they're like, "Oh, I read this other book which is all about functional programming in JavaScript."

I'm like, "Yeah, but it's not what this is about." It is a functional programming in general book language neutral, but then I needed a language to write code samples in and because I did want it to be in the code seeing refactoring exercises in code.

I had to choose a language and I chose JavaScript because it like a lingua franca. Even if you're...Front-end programmers sure, very familiar with it. Even back-end programmers they sometimes have to go in into JavaScript. It's got a similar enough syntax to Java and C# and C that you could read it if you needed to.

We don't go into any super detail about like some weird feature in JavaScript. I tried to write all of the code samples not in pure idiomatic JavaScript. People comment on that all the time. They are like, "That's not how I would write it." I'm like, "No, that's not the point."

I'm using a very clear style for that's like even a Java programmer can understand this JavaScript. As much as possible I'm trying to do that. It's written for clarity of code. It's not trying to teach you like, "This is the best way to do functional programming in JavaScript."

Matt: How useful do you think functional programming is in sort of a...if you take it right into web development into like a rapid-fire web development agency that is working with a whole bunch of libraries, a whole bunch of different new technologies? They have some older clients that are on older technologies.

They're all over the place because they have different servers. They are using Apache and Jinx, the whole bit. They're all over the place. How useful or not useful do you think functional programming is for people that are using so many different technologies across maybe a team or two?

Eric: I think that there's a lot that functional programming can add to help manage the complexity of all of those libraries. That's not to say that you're not going to have to like cheat and use some just straight up imperative code somewhere.

That first idea of identifying, "This is safe to call at any time. I don't have to worry about side effects of this code. I can call it a hundred times and it won't matter. I don't have to set anything up. I don't have to set up any global variables. This is a safe function to call."

Versus this other function, "I have to be very careful when I call it. I have to set up systems of making sure that it doesn't get called twice, or making sure that it gets called only after this other thing gets called."

That first distinction that you make between code that's safe to run at any time versus code that you have to be careful with. That I think it's just universally applicable. It doesn't matter if your agency is using some specific library that's not functional legacy code. I think that is just something to be aware of all the time.

Matt: Yeah, that's a good way to approach starting using functional programming, I think. Another thing is like if you're working in a small team of people and you can just differentiate those two things like code that is just a calculation isn't immutable and stuff like that versus the code that will perform changes.

If you could just differentiate those two things inside of your team, it'll make communication a lot clearer when they take up your pay, when they take up your code and for all their Git workflow and stuff like that.

I think even there is a good place to start, if you're not going to fully delve into a functional programming approach.

With that being said, I kind of want to point out, one of the things that I do a lot of and I'm one of those people that don't define which approach I use at this point although that might change when I start working on larger projects with more of a team.

Right now, what I do is I use a very data first approach to programming where I spend a significant amount of time structuring my JSON responses, structuring my APIs, structuring the data that's going to be used in the application before I start structuring my functions and my calculations and how I'm going to be using that data essentially.

How well would this approach work with something like functional programming?

Eric: Yeah, I think really well. I think that that's a really great thing to do is spend a lot of time on your data because that's like the new interface. You have some web endpoints that say send me a Jason like this and I'll do stuff for you.

There's two parts to it. There's the URL, which is the name of the endpoint. It's its public name, how you access it. Then there's the JSON that gets sent to it. That's public. You can't change it once it goes out there. You don't want to break backwards compatibility with any clients that are using it.

I really think that spending a significant amount of time designing your data, imagining how it's going to be used, that'll pay off a lot.

Matt: Cool. Regardless of the approach, right? It does work with functional programming.

Eric: Yeah, regardless and with functional programming. The whole third part is about data modeling. We're in JavaScript, so we're using arrays and objects basically. How do you use those to model whatever domain you're trying to model? It's something that I think was lost in the OO years.

When everyone was so gung-ho about OO, it was all about making an interface and putting some methods on a class and having a class hierarchy. That was what modeling was. A dog is an animal, and a cat is an animal. [laughs] Things like that.

Silly exercises that don't really help you solve the problems of your code, but you would sit there and you'd draw these diagrams, and then deal with all the problems and if statements. I feel like the straightforward data modeling approach of saying, "What data do we need to capture?"

I didn't define data. Data, if you look it up in the dictionary, it says it is facts about events. An even being something that happens. Just an informal event. A fact is some piece of information. You have all these events that happen.

Web requests come in, and the fact is this was the body of the request. That probably represents some other event. The user clicked this button, and it was a buy button. We're capturing that that was clicked and that they intended to buy.

That's all encoded in the data. How do you do that? How do you encode that in the data because this JSON blob is going to leave the browser, be sent across the world to another server, and now it's going to have to communicate all of that to the server?

I'm trying to show how profound this is, that somehow you can encode the user's intention in a string [laughs] basically that then has an effect and sends them a fidget spinner or whatever they buy on their site. That's amazing that this Jason can do that, but you have to design it well. It has to be well crafted to be able to do that.

Matt: When you start thinking about it like that, it's crazy. Bringing it back to functional programming, it's all asynchronous as well. You don't know how many times it's going happen. You don't know when it's going to happen.

Eric: Are there retries?

Matt: You have to account for that, somehow. [laughs] It's definitely an interesting paradigm. Technically, we don't usually think of it in that sense. We usually think of it as, "OK, I need to wait for this to happen and then do something."

I don't know. It's tough to explain in this kind of context, but it's cool that we bring it down to earth about how crazy these systems are. With that, I want to do a precursor to what I'm about to ask. I understand that this is bad practice, what I'm going to ask right now.

I know from experience and from talking to a lot of other developers and programmers that this happens a lot where you want to invest time into doing project planning and design, gathering requirements, doing your UML diagrams. What's the functional diagram that you were pointing out in the book?

Eric: A timeline diagram?

Matt: Timeline diagram, yup. Doing timeline diagrams for projects. A lot of the time, your management or your team will just be like, "Just write the code." As much as you want to fight back, you don't really have much of an arsenal to fight back when you're just starting out as a junior developer.

What are your one or two points that you would throw back at them for getting the paid time to actually do those diagrams and plan out your code?

Eric: There's a t-shirt that I saw recently that says, "Weeks of coding can save you hours of planning."

[laughter]

Matt: I like that. Now I want that t-shirt.

Eric: I know. I wanted it too. It's so true. I don't know how many times I spent so much time coding and then realize, "Oh, if I just sat down and thought about this, I would know that it was a dumb idea." [sighs]

I don't know how to convince someone that thinking is actually work in our line of work, that that is the most valuable thing you can do. I do think that there's something to be said for prototyping, like let me do some experiments with some code.

Too often we don't really have a good, clear statement of what problem we're trying to solve, so we don't even know where we're going to wind up [laughs] if we start solving it. We don't know what we're doing. We simply don't spend enough time thinking about why we're doing it. Is there a better way to do it? Let me think of a few ways. I don't know.

I know the feeling of being rushed and how, "Oh, I could solve that," and just type it up. I do. I get it out the door and it feels good. It's the thing that I often later regret. Now, the thing is also, there are a lot of obvious problems where I've solved this before. I've solved this 100 times. I know the way to solve it. Those come with time.

Also, in a startup, you often make those tradeoffs like I'd rather have the wrong feature out today, then the right feature out in two weeks. In that perspective, thinking is indistinguishable from procrastination.

The trouble with recommending that someone thinks more is you're not giving them a concrete process to go through. You do learn that over time. I do think we need more step-by-step processes to follow in our industry to arrive at solutions.

Matt: I guess it'd be more presenting it to the management staff. If you're trying to convince your management, "Hey, I want more time to plan. I want more time to think about this rather than just jump right in," are there any tools that can easily... ?

Maybe they be organizational tools like a Trello or something that where you can more easily line out, "This is why I want to think about this," and hand that to maybe a non-technical staff member, or someone who's maybe a little less tech-savvy to try to convince them, "Please give me the extra three hours so I can think about this"?

Eric: I wouldn't ask for permission.

Matt: [laughs] Fair enough.

Eric: It's not because they're not going to give it to you and you should just do it anyway. It's more because as a professional, you have more of an understanding of the process and what needs to be done.

When you ask for permission like that, often what I find is they say no, but they're not saying don't do your job correctly. What they're saying is, "No, I'm not going to do your job of deciding to do that or not, to think or not."

What I would do is if it's something big, like a bigger project, I would write it up as a proposal. I would shop it around in the team, ask for comments on it, turned it into an artifact that can be shared, write it up in English, and spread it around.

I've often found that when a manager, the non-technical person who's asking for a feature, let's say, when they give me the feature, they often think this should be really easy, "I've thought a lot about it. It should be easy." Then ask questions. Show them that it's not easy. It's not complete.

What is the error message when this times out? What happens if they type a long email address that's more than 20 characters like 10 percent of our users have? How does that get displayed in this tiny box that you've drawn on this picture?

Really push at it because I think that they don't see the complexity. You're going to do it. You're going to do your best to do what they asked for, and it's going to be wrong according to what their idea was. I really think that asking questions is a good tool. Something that's maybe more internal, I would shop it around in a written form.

Matt: Sometimes you have to take charge of your own project and make sure that you do your own job rather than throwing that to management being like, "Can I please...?" [laughs] "May I please do this to do this correctly?"

Eric: I feel the same about code clean-up, people talking about, "Oh, can we have like a sprint to clean up our code?" No, don't ask. Just do the cleanup. If they say, "Oh, can we get this feature done?" It's like, "We'll put it on the backlog," just like you would say about anything if you are busy with something else.

In some sense, it's not their decision to make of what operations in the code you're doing are. They shouldn't have to be managing that part of the situation.

Matt: That's a good way to put it. I think that that's a good way. A lot of employees, these days especially, will be more timid, if you will, especially if they are junior employees or the brand new, they'll be more timid.

You just have to make sure you do your job properly. At the end of the day, if you hand whatever it is in and it's not done correctly, whether it be assignment or an actual production thing that's not going to be just for school or for learning, it has to be done correctly. You have to do your own due diligence.

With that being said, I'm going to transition nicely into the next question here, which is, in the first pages of the book, you lay out a scenario where a developer ask a manager if they can use functional programming on an email app, the manager looks up the definition and sees that "avoids side effects," and that sending an email would be a side effect.

With that being said, the manager then says that functional programming is too risky to use on the project. If a programmer needed to use a variable, a function, or even recursion on performing part of their duties, they wouldn't have to ask the manager for each step of the way. They would just implement the solution their way.

This leads into a couple of questions here. With that being said, what is so different about functional programming that would warrant asking permission? Second one here, is this a situation where the entire team and not just one programmer must adopt functional programming for it to be effective?

Eric: That's a really good question. To give some context for that part of the book, my intention — and whether I did a good job with my intention, it's another matter — is simply to have a little narrative for why there's a miscommunication with management and that functional programming definition you find on Wikipedia.

It wasn't really like this is a common scenario where someone's asking permission to these functional programming. That said, I do think that in certain companies, they might have a code style guideline. They would have some rule in their style guide that says we use classes not functions. Something like that. I'm just making it up.

They would have some rule where it's harder to do functional programming. You are going up against the team. Maybe you need someone higher up to allow that exception to the rule. That's what I was thinking.

Does that mean that you need the whole team to buy in? I think they do need to buy in, but I'm going to preface that by saying that, like I was saying before, these are principles that work in any paradigm.

They're skills that are used by functional programmers, but it doesn't mean you have to be like all in on functional programming. They should see the benefit like you should be able to say, "Look, if we just make this a pure function, it would be much easier to test."

If you know your team needs to test stuff like, "Oh, yeah, you're right. That is easier to test." It should be as clear as that. Buy in, yes, because we work in teams. You can't just be a renegade and just do whatever you want in the code without regard to the style of the code and how you practice coding on a team.

You do need buy in, but like I said before, it doesn't mean like everything has to be functional from now on and you have to go 100 percent on everything.

Matt: Yeah. That makes some good sense because I would be worried as a junior guy even, if you come in and you're all about functional programming. That's what you've been learning and then some of the senior guys are just kind of ripping through their own code.

You're just like, "Ah, I don't really want to go and bug all them," and be like, "Hey guys, let's change this whole project." That's like...

[crosstalk]

Eric: Yeah. A monad would be really great right about here.

[laughter]

Eric: Just to be clear, there are a lot of, let me call them, advanced functional techniques that we're not even going to get into in the book. Functional programming is a huge field. We can't do it all in one book.

A lot of times they would be very unfamiliar. If you just saw it right in the middle of the code, you'd be like, "What is that thing doing?" I'm not suggesting doing that. I'm suggesting these more fundamental ideas, like the ones we go over in the book or just good ideas in general. They should be easy to convince people of.

Matt: Next question here then, it's mentioned that functional programming is more useful in more complicated applications, like in something like a distributed system. Is there any benefit for a beginner programmer in trying to use functional programming in the simple applications that they're writing or learning on?

Eric: Is there any benefit? Yes. These are principles and skills that they're design and architecture ideas that really pay off more at scale. The benefit is there, but it's very small. If you got a small program, any old style, any old discipline, no discipline is fine. Just get it working.

As the program grows, you're going to find that you're slowing down, it's turning into a mess, you're getting lost, like, "What does this do anymore?" You're starting to get bugs that you can't identify.

That's where disciplines help. There's object-oriented disciplines that could help, there's functional programming disciplines that could help. That's my answer. There's a benefit, but it's small.

Matt: I think we've touched on this a bit already as well, but would you say that someone who's maybe they've mastered the stage of program that they're at, so when they go and approach, so they're not just learning the syntax.

They're at the stage of when they go and approach another problem, and it's still a simple problem, they're able to just do it. They're able to think it up in their head. They know what's going on, generally.

Would you say that at that stage, even though it's simple, would you say that that's when they should maybe start learning some of these paradigms like functional programming?

Or, should that still be left to where they're given a huge project and they're like, "Wow, I don't know how to do this now I got to look up these paradigms to sort of organize this big project"? Or, is that too much all at one time?

Eric: I would say that bringing experience of getting into a mess [laughs] would help. It definitely helps because then you're like, "I wish I had some skill to get me through this or to avoid it." I think that it doesn't take long before an undisciplined approach...

I'm talking about a few hundred lines of code you start to get lost, and like, "Oh man, that function's really big. Maybe I need to break it up a little bit, but I don't know how." It really starts there. To give advice for someone who's still struggling to just get something working, don't worry about a paradigm. Just code.

When you start to feel like, "Wow, there must be a better way. Is there some discipline that I could have?" That's when you should start looking into other code styles, paradigms, things like that. Little rules, disciplines that help you make sense of what's going on.

There's a lot going on there. People have come up with quite a lot of good guidance and, I want to call it wisdom, over time of, like the three categories. Actions, calculations, and data. Just identifying those and saying, "Wow, I've got quite a lot of code and actions. Maybe I should start removing some of that code."

If you're in an object-oriented approach, and like, "Oh, this would make a really nice...I've got a lot of conditionals in here. Maybe I should encapsulate the differences and use polymorphism." You have the terms that come from the paradigms. They can start helping you solve these problems.

Mike: I'm just thinking, I want to bring it all together for the audience. This is an impromptu suggestion. You could shoot me down, both of you. What I'm thinking is maybe we should go through an example functional programming, just a quick functional programming example, and maybe do that breakdown that you were just mentioning with the actions, data, and calculations.

One of the examples that I was thinking of off the top of my head was one that you used in the book, which would be really simple to explain, which is the pizza ordering, the online pizza ordering application. What do you guys think of that right now?

Matt: Sure.

Eric: Yeah, sure. Let's do it.

Mike: Let's do it. For that, I'm just going to break down what an online pizza ordering application would do, then we can classify the steps, just quickly. We don't have to do every single step, obviously, but classify the steps that would be considered actions, would be considered calculations, would be considered data. Which parts of the steps would be considered each?

A pizza ordering application would take an order from a user. That user could enter his information, and he would order the pizza that he wants, depending on which toppings he wants and stuff like that. He would then place that order, having already sent all the information in.

Then the process of actually creating the pizza will start happening. You would have many different steps in that process for putting the cheese on, spreading the sauce, putting all the toppings that the user defined. Then putting it in the oven, waiting for it to cook in the oven, taking it out, putting it in a box, putting it in a delivery capsule or whatever, and sending it to that user's house.

That's just a one user example. There's billing in there and stuff like that, but I'm thinking at the start, the user entering his data. How would we break that down?

Eric: Let's say they have a web page that they can enter this stuff on. The web page is loaded and there's form fields that they're filling out. All of that entering, the typing, the moussing around, that's generating events. That's going on to the event queue, which goes into the event loop. This is all actions.

However, the little piece of data that's sitting on the queue, that's just data. It's already happened. It's in the past already. By the time it gets processed, that mouse click is old. It just happens so fast. We don't think about that, but it's old. It's already happened. That's just some inert data that's sitting there.

You might do some validation. That validation on the data in the form before you submit to the server, that could be a pure function. That could be a calculation. It's just like true, false, is this good? Do they complete the order correctly? It could maybe return a string, the error message or something if it's not good. That's certainly a good candidate for a pure function for a calculation.

Sending it to the server, that's an action, because it's having an effect on the world. Presumably, if you didn't send it, you wouldn't get the pizza. The zero or one time that it gets sent is important.

That's a rule of thumb for an action if it depends on when it's run or how many times it's run. When it's run, it's often about the order. It's relative to other things happening. We'll probably hit more examples of that.

Then the server receives this request. That's an action as well, but the request, itself, is data. It's just some JSON that's traveling over the wire. Then probably some validation. Again, that could probably be a calculation. This gets sent to the pizza kitchen, I guess is the next step. Is that right? Next step is pizza kitchen?

Mike: Yup.

Eric: Pizza kitchen is getting this data, represents the order, one pepperoni pizza. There's some steps involved. There is a recipe that they're going to follow. The recipe is data. Maybe there's two pepperoni pizzas, so they have to multiply all the ingredients by two. That's a calculation.

Another rule of thumb that I like to say about calculations is they're often very hidden because you don't see them happening. Because they're not having an effect on the world, you couldn't see them. It's like what you're thinking in your head like, "I'm planning. Oh, two pizzas. I'm going to need twice as much pepperoni."

You're doing all the calculation in your head. It's not having an effect on the world. Until you actually go get the pepperoni, you're not having an effect. If you think of calculations as all the hidden planning and thinking that goes on between actions, that's a good way to think about it.

Then there's all the steps of rolling out the dough and putting the toppings on, putting it in the oven. That's all actions. What was the next step? The oven?

Mike: The oven.

Eric: You put it in the oven. You just wait 10 minutes or however long, an action. You don't want to wait 10 minutes at the wrong time because you'll burn your pizza. That means it's an action. Take it out, put it in a box, ship it over to the person.

Probably, there's going to be a ticket on the box that has their address, data again. There's got to be calculations in there. For instance, you're taking that address and turning it into a GPS location with directions to get there.

That could probably be a calculation, although it is more complicated because it's usually a cloud thing. You're communicating with another server that's doing that calculation. For the sake of argument, let's say they don't have a cloud GPS thing. They're just getting directions on their Garmin or whatever.

Mike: Even in a JavaScript sense, it could be a calculation, because when you're communicating with the cloud, that can be done in a separate calculation function that would always return the same thing every time no matter what with the same input. It still would be a calculation even though it's communicating with a cloud.

Eric: I would tend to agree. The only complication is sometimes it could time out.

Mike: Oh, because it's not your server.

Eric: Right. Whenever you communicate across the network, there's a possibility of having a 500 error or something that you would never get from multiplying two numbers together.

Mike: Cool.

Eric: Yes. Other than that, it is cacheable. Like you were saying, it's going to give the same thing every time. This is getting deep into the functional programming stuff, but because it's cacheable, what you're saying is that it doesn't so much have an effect on the world as it's bringing in information. It's going to bring in the same information every time.

That means zero request is different from one request, but then that second request, I don't need to do because I cached it. It's item potent. Item potent means zero or one time makes a difference. Classic example of item potent is the elevator button. You press up to call the elevator. It lights up. If you press it again, it's not going to have any effect.

The difference between not pressing and pressing it is important, but that second press, the third press, those don't matter. It's the same with calling to the mapping service. The first one matters, but then after that, it doesn't matter.

This is the kind of reasoning you can start to do with these concepts of time and whether it matters or not. Then they arrive at the house. They give the guy the pizza. Eating it is definitely an action.

Mike: [laughs] It's the best action.

Eric: Yeah. [laughs]

Mike: I like this example. I wanted to bring it into play because I just wanted the people out there to understand a little bit about functional programming. Even though it might be a little bit over their head or whatever, but it's important to know that there is something like this out there, a structure to what they're doing.

It's OK if it's over their head. They can, A, either get your book and read it or, B, just look at it yourself, go and watch some videos and study it, something you would probably do in a university class. We have some high school people listening to our podcast. It's important for them to know that this is a future thing that they might be looking at.

There's definitely a lot of little side questions. As you were talking about that, I was going to interject and try to get some clarification on little, very intricate things in functional programming which is cool to me.

Again, I didn't want to bog down the users, but maybe in the future, if people are interested, let us know. We can have you back on, and we can have a more in-depth functional programming discussion...

Eric: Yeah, I'd love that.

Mike: ...where we talk about the little intricacies of functional programming...

Eric: If you have questions, bring them in.

Mike: ...which would be cool for me.

Matt: Moving on to the question there, it flows nicely because we're talking about a complex application now. If you're already in some app development team, or something like that, and you have an existing complex application that was not at all developed with functional programming in mind, is there any way that it can transition to functional programming moving forward?

Would it be better if you maybe rewrote the whole application under the guideline of functional programming?

Eric: My big hope is that the book shows that you don't have to do a big rewrite, that you can get benefits in an incremental way because I can't recommend that someone rewrites their application.

Matt: Right. Yeah.

[laughter]

Eric: It's too much work to do all at once. It's probably going to kill the business to do that. In fact, the chapter I'm working on now is all about immutability and one of the ways to implement immutability is called copy-on-read.

It's a discipline that if you call a function, and you get a value out — let's say it's on JSON, it's some object — you instantly, right away, immediately make a deep copy of that. This is your copy because you don't know what this code that you called is going to do with that object that it gave you.

It's one of the things in JavaScript and a lot of other languages where you have these immutable things. It's not clear if you own the thing, if it's a newly created thing that only you have, or they're going to pass the same object to some other code. You just don't know what's happening to this object.

It's like if someone gives you a message on a piece of paper, or you write down a message to yourself, you put it in your pocket. Then later in the day, you pull it out of your pocket. You don't expect that it has changed. You expect that it is the same message, that nothing touched it.

In the computer world, we have this thing where you can share references to the same object, and you can't expect that it's the same when you look at it the second time. To mitigate that you do copy-on-read. "I'm going to make my own copy. You can keep that or just let it get garbage collected, or whoever else has a reference can keep it. I'm going to make my own copy."

When you do that, that lets you interact with all your legacy code, because they don't have to be functional. All that code that I'm talking to, it can do whatever it wants. It can mutate as much as it wants. It can change the memory, change the values. I have my copy and I can now treat it as an immutable thing and be functional.

Yes, it's a thing. I think about it a lot. How do you slowly, gradually introduce these functional ideas without going whole hog on an existing codebase? It's really important.

Matt: I think that's a really great wrap up to that question because it's one of those things where a manager or management team would ask. "You want to introduce functional programming now? We're two years in, we've been updating this whatever app for this many years. Now you want to change the paradigm we're using? What's that going to mean? How risky is that?"

Eric: Right. What I hope is, like you were saying, you wouldn't even have to bring it up to the manager. Let's say you're pairing on this code and someone's like, "Oh, man, they're passing me these objects, but I know they're going to reuse this object and change it and pass it to someone else."

You just know right away. "Yeah, copy-on-read. That's how we do it." And then it's not a problem anymore. It's a little local solution to the problem that you've got in that code. You don't have the budget to go rewrite that whole thing, to make sure it doesn't make changes to that object. No, just a local solution.

I feel like the functional programming skills I'm teaching in the book should be able to be used that way, like we have this one problem, we're just going to use it right here.

Matt: With that being said too, even as early in the book, again, if we take our example and your example combined with the pizza timeline diagram, within a couple of pages of each other from the beginning of the example through the end, there are already variations where the person that owns the pizzeria, whatever she does, she edits what's going on there.

That's an attestment to she didn't have to tear down her own pizzeria and rebuild the whole thing. She can just go in and be like, "No, no, no, let's put a dotted line here. Let's move these around. Let's take this, take these procedures and make them a different order," etc., etc., etc.

That's an attestment to how functional, [laughs] if you will, functional programming can be in an already thriving production environment.

Eric: Yeah, I hope so. I hope that people look at them like refactorings. It's just ways to reorganize little pieces of your code locally. You don't have to change everything, just like, "Oh, this code is getting messy," or, "We're losing control over what it's doing. Let's apply a little functional programming to it and make it better."

Matt: Awesome. The final question in the segment here is, how much time is spent planning when using functional programming versus nonfunctional programming in your experience?

Eric: I don't think that there's any real difference. I think that planning is important for everything. For all coding, it's equally important, let's say, between all paradigms. It's very important.

Matt: I think that would be one thing that our users or listeners, especially as beginners, would, if they start thinking in less terms of, "Oh, I have to do this application. I'm just going to start coding it."

If they start thinking in these paradigms, that's one of the questions they're going to think up, like, "Whoa, I gotta spend a day planning what's going on here." In reality when you have a complex application, whether you do object-oriented or whatever, or functional, you do need to do a fair bit of planning ahead of time. that's important for beginners to acknowledge,

Eric: Sure. How do I put this? As an experienced programmer, I've been programming...I'm 38 years old. I've been programming a while. I don't want to count how many years [laughs] I've been programming.

Matt: [laughs]

Eric: I sit down and I see code. I can be like, "That's a code smell." If we're looking for a bug, let's say, I'm like, "We should look there. We should look there. We should look there." It takes me a minute to see it.

A junior programmer sitting next to me, it will take me hours to explain why. I've done this before where I'm like, "Well, you see, what's happening here is where let's trace through the code and you see how this thing is calling this and then it modifies them and something else is modifying it at the same..." You see this instantly.

What I'm trying to get at is I don't think any amount of planning can get you to see it faster. Do you know what I mean? You can't just say I'm going to plan away all the problems.

Matt: [laughs] Right.

Eric: As a junior, you're going to make code that does those things. There's code I still make problems too. I have a bag of tricks that I can use to plan. What I'm saying is they don't have the bag of tricks. Maybe planning is not as valuable when you're starting out.

Matt: That's a really good way to put it. As you were explaining it there, the first thing that popped into my mind was I'm from an IT background. One of the first things popped to my mind was when you bring the trainee on board, the beginner, you teach them, "This is how this is how we format hard drives. This is how we install graphics cards. This is how we do whatever."

As you get more experience as you go on, when you read a ticket, just reading the ticket, sight and seeing computer is, you haven't looked at that person's laptop or their desktop. You're just like, "It's probably the hard drive. It's probably the CD drive." To them, they're like, "How would you know that?" Then you have to explain, "Well, it's doing a ticking."

Eric: You smell and hear it. [laughs]

Matt: Yeah, exactly.

[laughter]

Matt: It's one of those things where it's almost like a muscle memory you develop with that bag of tricks like you were saying.

Mike, I know you were mentioning something...We usually do the web news here, but you were mentioning something how we think we've cover more or less the questions in here.

Mike: We're approaching an hour, 40 at this point. I'm thinking the web news might be a little bit extra. We've had a lot of good discussions. I don't know, Eric, how you're feeling. If you're up for the task or not, but I'm feeling like it's probably already pretty late where you are. I don't want to put any pressure on you to do any extra talking...

[crosstalk]

Eric: If I could step out that would be good.

Matt: OK, cool.

Eric: I feel like...

Matt: Well...Sorry...

[crosstalk]

Eric: I feel like I've laid down some good stuff.

Mike: Oh, yeah.

Matt: We want to thank you again for being on the show. We'd like to invite you at this time to share what you're up to. We know we were talking about your book, but anything you're up to. Any links or anything you'd like us to include in the show notes. You have the floor. Please, take it away.

Eric: I have a podcast if you're interested in this kind of topic. It's called "Thoughts on Functional Programming." It started as me exploring the ideas for the book before I started writing it. It was really just me with my phone driving or walking around. Little moments between driving somewhere to pick up my kid from school. I would just turn on the camera and talk.

It had very informal style. Now I do a little bit more planning and better audio than you can get in the car, let's say. It's at lispcast.com/podcast. I got, man, 140 something episodes now. If you're interested in this, go check it out.

If you're interested in the book, you can go to lispcast.com/gs, for grokking simplicity. That will take you to the page on the Manning site. It's in early access now. First three chapters are available. Soon to be the fourth. Maybe even by the time this is published, it'll be out.

When you do early access, you get the eBook right away, but then you can...If you get the print version, it'll be delivered to you when it's done. You can still get the print version with the [inaudible 101:47] . That's it.

Matt: Awesome. All right. Thank you very much once again for being on the show. It was a really informational episode. We hope you enjoyed it. Thank you for listening. Make sure you don't miss an episode by subscribing on the platform of your choice.

You could follow us on the socials via @htmlallthethings, that's on Facebook and Instagram. You could follow us on Twitter @htmleverything. We are on Medium and we're on GitHub. Remember we're on Patreon. That's patreon.com/htmlallthethings. Check out the tiers and give that a go.

Many thanks to our three-dollar-tier patrons. Sean from RabbitWerks JavaScript. You could find him at YouTube.com/rabbitwerksjavascript. Also, Garrick from Local Path Computing & Web Design. You could find him at localpathcomputing.com. Craig aka Cosworth.

Ryan Gatchel from Blue Black Digital. Find him at blueblackdigital.com. Chris from Self Made Web Designer. You could find him at selfmadewebdesigner.com. And as well Tim from The Web Hacker. You could find him at thewebhacker.com.

Remember we have that promo code or the discount code, and two full book promo codes. You can get a free book, single use. They do expire as I mentioned in the beginning.

Make sure you check out the full show notes which are usually posted shortly after, a few hours after the actual episode goes live. They're published on the HTML All The Things website. That's htmlallthethings.com.

[background music]

Matt: Feel free to leave a comment or a review on the platform that you are listening to this on. We are signing off.