Episode 29 • Joel Hooks

Math and Functional Programming Aren't Exclusive to Wizards with Brian Lonsdorf

Joel and Brian Lonsdorf discuss the pain and growth of learning, math as a source of truth, dispelling that idea that you need to be a wizard to enter the functional programming space, and finally how you can start including functional concepts in your day to day work.

There's a reason that mathematicians tend to be the best functional programmers. The theories and patterns directly apply, it has truth and purity. It's powerful, almost powerful enough to describe everything, so what makes people turn away from it?

Traditionally, math gets taught in a dry manner from a young age, tables are memorized, and facts get drilled. It isn't until much later that interesting concepts like set theory get introduced, and at that point, it's too late for many people.

Material that's "dry" doesn't have to be taught that way. It's been three and a half years since Brian first put Professor's Frisby's guide up on Github and it brought light and friendly perspective to heavy material. It showed that the functional programming paradigm was learnable without requiring a deep dive into Haskell.

The deep dive doesn't work for everyone. There's merit in starting with something like Gatsby and just getting something out there that you can play with immediately, and then later learn the fundamentals of Javascript. The same thing applies to learning functional programming. You can start composing with Lodash and ease into the deeper patterns and concepts.

Transcript

"Math and Functional Programming Aren't Exclusive to Wizards with Brian Lonsdorf" Transcript

Resources:

Brian Lonsdorf:

Joel Hooks:

Transcript

Joel: So, are you sick of talking about functional programming yet?

Brian: You know honestly, it has been kind of something that I wanted to avoid being that guy. I'm doing other things and trying to get into mathematics and trying to get into machine learning and AI and all that so hopefully I'll be able to kind of step out of that role, but so far that's what's define me.

Joel: Yeah, I mean I was gonna ask you because we're talking about functional programming if you're a mathematician, if that's your background. Math.

Brian: Yeah, no certainly not, certainly not. I always kind of put...it's funny because you see all of these Mathematicians and they come over and they're the best functional programmers or just the best programmers and they're like, "Oh yeah, I can solve that in one line if you know these theories," but yeah, no not at all. I just end up watching a lot of YouTube's about topology and whatnot. Trying to catch up and it's something I enjoy that I found out after I started functional programming that I was like, "Oh this is cool. I'm gonna try to get into this." And so far I'm still really bad, but it's a lot of fun.

Joel: Yeah I have this theory that like all these frameworks and languages are really kinda just trying to abstract math away from the masses right like so but it's still even difficult and people will like approach math like it's this impossible thing. You have to be basically a wizard to even approach it which is interesting to me and it seems like something that you actively try to fight against. With an attitude right. Like you have to be some sort of magician to even be able to do anything in this space.

Brian: Yeah no I would think it would be great if...I mean I guess my perspective is if you took every...like if we had one...we'd try to take every language in every community and we tried to progress the industry forward and said, "Okay, now Pythonistas and Jsers and Rubyists and whatever Java people, let's all sit down and decide what's the best way to solve these problems? It would be like that scene in Lord of the Rings or the Hobbit when everybody...a big battle happens and people are just tearing each other apart and their like, "No, this is the way to do it. No, this is the way to do it!" and I feel like math would be like the one thing we could probably agree on and just use to further the industry. So that's been my...I was like you know what if I can learn this I'm sure anybody else can and if we can all talk about it together, instead of making this impossible barrier maybe we can shift the industry onto a track we all agree upon.

Joel: Yeah it seems like a lot, I mean the purity of math right when you get down to, is this truth. Like you can get there with math, you are not going to get the truth with react for instance. With math we are able to do that, but then is it like a systemic problem? Like starting way back when kids start learning in school? I don't know...I'm curious about that sort of thing. Obviously I haven't found any solutions but...

Brian: Right. I don't know. I know that it's powerful enough to describe everything. And we might not be right. Math might not be the ultimate way to describe facts and hold onto them. But it's probably the best thing we have so we should just go with it. (laughter)

Brian: I was just helping my daughter Vera with her homework and she was...she's doing negative division and like oh god this is terrible! This is just so not fun at all! And you get into set theory which is a lot of fun, so there's a lot of like...you kinda just ruin math for everyone from the start.

Joel: So we recently switched in our house to the Life of Fred books. Have you seen those?

Brian: No, I haven't. What's that?

Joel: So it's a whole series and it starts from Pre-K all the way through basically undergraduate degree in college mathematics.

Brian: Wow

Joel: But it does this story driven approach and there's no fact practice. There's no...everything is like a story and it gets into it and it starts getting into set theory and different things like that in a very young age. And it's probably my favorite approach so far. Unfortunately, we just found it and we've been homeschooling for 20 years. But you know, better late than never. (laughter)

Brian: Wow the older kids would be like "Hell, you know we missed out on Life of Fred for me."

Joel: I bought all of them and put them on a shelf and offered them to all of them so they still have the opportunity it's just their responsibility at this point.

Brian: (laughter) Right on that's awesome.

Joel: So talk about learning and teaching more importantly, so it's been 3.5 years almost since Professor Frisby's Most Adequate Guide to Functional Programming was first posted on GitHub. I looked that up.

Brian: (laughter)

Joel: And is it finished?

Brian: You know, I just added a couple of chapters last winter about a year ago because I just felt like it didn't provide the entire toolkit. It got you really close, but then you hit these problems like nested types that aren't necessarily flattenable or joinable. So I added a couple, but I think I'm done. I'm over it. (laughter)

Joel: You knew that at some point right?

Brian: Yeah, I don't know if we merged it. I never finished the exercises so I think they are still in a PR...

Joel: I think it's friendliest presentations in terms of giving somebody a link and saying "Oh, you want to learn more about functional programming." I think it's really amazing and approachable and it has kind of a almost light feel when you get started to some very heavy material as you wrap it up. I assume that's on purpose?

Brian: (laughter) Yeah, thanks for saying so. It was kind of a weird, the way I started it was I had been struggling myself for quite a while and I think this happens to a lot of people who learn functional programming, is they're like "Wow, that was hard, if only I could help others." And you get another monad tutorial right?

Brian: I think the book turned out to be something that I had written a couple of blog posts and had a few conversations with people and I was like boy, if you know...this is really great stuff and I want to share it out and I want to do it in a way that the things that resonated with me as I tried to figure out the surface area of what was going on. I wanted to make it a clear path and really hit those points that open my eyes as I went along.

Joel: I mean you got feedback over the years I assume. And what sort of impact do you think or have you people expressed to you that's had on them in terms of their learning functional programming?

Brian: I mean most of the feedback I got was I consistently wrote "it" apostrophe "s" when it should have been "its." (laughter) Seriously, there are so many people that contributed to that and I really hear a lot of great stories from people who said they were able to learn because of that book and that really meant a lot. There's a lot of translations which was pretty cool. I feel like it's really done a good job of guiding someone into the paradigm without having to teach them Haskell or something like that.

Joel: And then from there every time, so this is one of my favorite things to tell people because I'll have people be like "Oh well, that might not be egghead style" and I always point them to Professor Frisby Introduces Composable Functional JavaScript where you take the Professor Frisby character and you stop motion animation hedgehogs to explain difficult programming concepts which to me is amazing and a lot of people like it as well.

Brian: I still get the surly "That voice is too high!" And I'm angry about it. But that was a lot of fun to make and actually kinda fell out of the process of...well first of all, there's a lot of definitions of functional programming. A lot of stuff you have to explain and it's pretty dry and it takes a long time. Something with that many definitions instead of just hit the ground running and here's some code and let's actually make stuff.

Brian: It always blew my mind with something like ballet when someone would have try to learn all the moves for years before they can even dance. With guitar, it was like, here's a power cord have fun. And you can actually enjoy it while you learn whereas something like ballet or functional programming, not that you can compare the two, but we have to cover a lot of ground before you can start to move forward. In a pure sense at least. And there's a lot of dry stuff so I thought that would spice it up and I taught the course in person so having students talk to me in the class that kinda capture their questions and were able to recreate that setting. [crosstalk 00:09:39]

Brian: I would take off my giant plush suit...

Joel: [crosstalk 00:09:46] Yeah yeah, there's a full party for a functional...like that would be amazing. I would totally buy a ticket to that Brian. I would support that.

Brian: Excellent (laughter)

Brian: You get a lot of pushback from people...they are like "Oh...I'm mad at you! I've wanted to do it this way and that way is not the way I want to do it and now I'm mad." And you get those questions and a lot of skepticism so having the fake character students ask those questions to try to address some of those is kind of the motivation there so you can kinda clear the air on some things that [crosstalk 00:10:19]

Joel: Like a rap battle right, where you just kinda filler out your own disses first...

Brian: (laughter) There you go I love it.

Joel: I was actually amazed cuz most...I saw all the feedback from that...course when it first came out it was like this weird polarizing...most of the feedback's really positive, but then some people just get super mad that you would do that thing so outrageous as to use puppets and [inaudible 00:10:41] serious topics.

Brian: Right right. And you know I was a little...I work a lot with accessibility and I was just totally...there's just like this tension between creativity and art and actually being accessible. And I think I dropped the ball on the accessibility side for that so if there's something I can do to help the people who have a hard time english as a second language whatever. Or other things that make it less accessible I'd like to address that.

Joel: That was on us too though. Egghead didn't have transcripts, well we had transcripts, we did not have that was...I got charged a little actually for those transcripts by the way. There's a flag if anymore cartoon hedgehog voices come through [crosstalk 00:11:26] on our transcript.

Joel: They were angry with me about this of course, but so we had transcripts we didn't have subtitles which we've since...I'm guilty of ignoring accessibility. We are building the business and I use that as an excuse and I feel like actually now I feel like it's a really bad excuse and I'm glad accessibility is really getting more playtime. But now we have subtitles so people can read along, which I think helps out quite a bit.

Brian: That's great. I was just watching Mighty Boosh the other day and I was like I need subtitles for some of this. (laughter)

Joel: I watch everything in 2x speed these days and [inaudible 00:12:00] that's amazing, because I can't really watch 2x without subtitles but you turn subtitles on and you can really...

Brian: Nice...that's pretty great. I should learn that trick. I've been watching 1.5 for that reason.

Joel: I started there and I bumped it up recently.

Brian: Nice.

Joel: Just to get back to...I'm curious in general and I've noticed that programming itself has a jargon barrier...put terms around it where like you almost have to have a glossary or use flashcards or something. To me, it gets back to even like math facts practice right, to learn math we need memorize all the timetables. And I'm wondering is that true? Do we have to? And what other ways can people approach this? Cuz functional programming is really hard and I think it's a good paradigm, but it's really hard to get people to adopt it so I'm curious to how to get past that and make it more interesting.

Brian: THere's always 2 sides to this and it's a battle that I've seen come up again and again and it's weird because there is a jargon problem. Math has a jargon problem for sure. And on the other hand, english is just...it just fails us like everyday right? And you think that you go into a code base and if it's not use a term like monad it's like "Oh I have a fetcher and my fetcher it gets flows and the flows store process connectors and..." you know, like, what the hell are you talking about. (laughter)

Joel: [crosstalk 00:13:30]

Brian: Yeah like this is so easy why don't you understand it?? And it just comes down to I'm familiar with this domain, I made all these things up. We all collectively decided on these terms and you get down to what...if you have a name for something and everybody knows it and it describes that thing, then there's no problem. But, we haven't really agreed that we can do that. I think the bizarre names actually help define something very distinct. Whereas people say "Oh it shouldn't be functors, it should be mappable," oh that's great, but you miss tons of defining features that something that may be mappable would miss. And something like a functor has very precise definition. Well, I say that and you go to reason and they are all like "Here's a functor, it's not what you think it is." (laughter)

Joel: Was it Smoosh?

Brian: Yeah, you know one of those.

Joel: And it's interesting to me too because this isn't a functional programming problem if you look at the objective oriented side, we've had these design patterns that are well defined. And then every 3 or 4 years somebody wants to rename one of these design patterns and present the same thing. As a business owner, being in the business of helping people solve the confusion it's good for business, but at the same time it's frustrating as a developer. You see it all over I think.

Brian: Right. It's kinda force us on a great job of naming things and we all agree with that right?

Brian: I don't think that anybody is going to solve naming. My favorite thing is that Boolean is named after some guy, some mathematician and everyone's like "What do you mean, it's just a Boolean." (laughter)

Brian: So...whatever.

Joel: It's really what people are trying to do is try to find a better way to describe, a better way that makes more sense in their head. I'm not like subvert the Gang of Four system, you know, stick it to the Gang of Four man or whatever. If people are really trying to understand and explain it with terminology that they think is better.

Brian: Yeah, and that terminology is all subjective and you have stuff like bounded context cuz like the terminology changes with each context.

Joel: So when you personally, whether is math or any other complex topic or new hobby, what's your approach to learning in general? How do you...when you tackle something that's difficult, how do you approach it?

Brian: Sure...well I turn on egghead and I get right into it. No, so I'm trying to learn machine learning right now. I'm a machine learning learner. I'm realizing what my process is by going through this again and being a fresh learner and I think the idea is I go and buy a book and I'm like I'm going to read this book, and I'll know what I'm doing. And then I read a couple of chapters and inevitably stop. I don't know what happens, but every time I get...something happens where I stop reading the book.

Joel: It's the chapter four wall.

Brian: Yeah, I don't know if I need an alarm every day or what. But I'll stop reading the book, but inevitably what I end up doing is kinda covering as much surface area as I can across blog posts and just try to absorb the material. Not by really learning it and getting deep into it, but kinda scanning over the surface until I see things again and again. Those things are important, you know, they keep coming up. And I start to feel more comfortable. Maybe copy some tutorials and get them to run and change it a little bit for your stuff and see if you can get it to work. Eventually, before you know it, you can do it.

Joel: Something like machine learning...cuz I've dabbled in that...I always hit the...for me, one I buy all the 5 star books, not just the one book I have all of them put them in a nice stack next to my desk and just hope.

Brian: (laughter)

Joel: Just light a candle then turn to Google and do basically the same thing you describe. It's weird with programming especially something like machine learning. I end up at the limit of my math skills. When I really get to what I want to do...oh yeah...

Brian: And then you do the same thing for the math right? Buy a book, read the book...(laughter). It turns out just muddling through the things and trying things and playing around really getting deep into it is the only way I learn. I found out the hard way through many things that if you just read from afar and you don't actually do it, you're not going to learn.

Joel: For me, starting a business or learning how to code. For code, I ended up for me I got into frameworks and the framework was able to allow me to actually do something and then I was able to work back from doing that into understanding what's actually going on. Right? Like that was...

Brian: Exactly yeah. The high level...that's huge...just for me using rails to start, by the end I was mad and thought rails was dumb, but it gave me a whole career basically. And taught me how to program in that exact way.

Joel: I see people say "Oh, you can't do that. You can't start with frameworks, you have to learn core Java Scripts" I'm like that's boring. It's hard and boring. And if you don't understand, you can't really build anything. Where with rails, or something like Gatsby lately for Java Scripts specifically you can fire this up and all of a sudden you have a website. You can start tinkering.

Brian: That's probably the best way. You get a little bit more and a little bit more and in fact I think that's a good general rule. For machine learning, at least for me, I'm starting with Keras and working my way back to PyTorch and TensorFlow JS. And you kinda start with the higher level stuff until you get comfortable and go a little bit further and a little bit further.

Joel: The onion right?

Brian: Exactly. Get down to the beautiful, delicious core.

Joel: The big onion.

Brian: (laughter) Yeah, exactly.

Joel: There's a book I love that kinda talks about this Apprenticeship Patterns. Have you seen this book? It's by Dave Hoover and it goes into this idea one of the chapters is called the Breakable Toy. It's a great book altogether, but this is the one that stuck out to me most. It's this idea that when you are learning something complex and it's specifically target to programming you need something, right, you need something that's yours. Nobody else cares about that you can break and build. Whether it's your blog or some sort of fitness tracker what have you, just something that you can stand up and when you are learning, it's something you can apply what you are learning to. And that's always stuck with me it's just an important concept. Like the idea of tinkering and being able to play and build at the same time. I think it gets the core of how we learn complex things in a lot of ways.

Brian: Yeah exactly. I think my favorite thing was in that old book, that classic "Don't Make Me Think!" where people don't want to learn how to do something. They just muddle their way through until it works for them. They have people who...I can't remember the exact description, but they would google the term to get to the google page and then click on the page even though they...there's long path people they are able to watch people do that they've learned it that way so they would do that way. Like they will google a website...

Joel: Google the dot com and then get into the website that they are actually going?

Brian: Exactly. And it works for them and then they will find a better way later on. But at least they got started and muddle their way to success. Fake it till you make it.

Joel: This idea that when...people are always trying to make learning fun. Learn to me has always been almost like an effort and frustration and you start getting at the definition of fun and what is fun. It turns out that it's actually we want to be challenged, we want things to be difficult, we want to be a little bit frustrated but then overcome it and see the end. It's like the outcomes are what is fun, it's not the actual learning that is fun.

Joel: It's not true universally. Some people really enjoy it, think learning is fun fun fun. But in my experience, it's not really the case.

Brian: I read in Psychology Today magazine or something you are happiest when you have a goal and you make a big step toward that goal. It's one of the most fulfilling things. Some philosophy talks about how it gets down to the core meaning of life. You start with nothing and you learn and you grow and you improve and you...this is something that is tied to our being...is actually growth and sharing. It's kinda cool.

Joel: Yeah it is cool.

Joel: SO in a practical sense, I'm a programmer and I've been interested in dabbling in functional programming whether it's through Lodash or what have you, for the last several years. But I want to go deeper, but I'm on a big project and how do I learn enough functional programming, how do I start changing the paradigm that I'm using in my day to day if I'm using rails or I'm using something similar. How do I get in there and really go deeper with functional programming? Where do I even start?

Brian: Right on. Well that's a good question. For me, I guess there's a bunch of different paths. But I would start understanding that the core of functional programming is centered around composition and data flow and if you can just compose a data flow without just mutating in line and jumping around in your data flow. If you can just really really work on data flow from beginning to end, I think that would be a great way to start.

Brian: So of course you can make things immutable. That's a pretty easy thing to start with. And then you can work on your composition functions which works on...even if you have methods and objects, just separate your actions, dots and text is still composition. And that's what the practically are the Professor Frisby's "Introduces Composable Java scripts" all does...dots and text composition. Just anytime you hit a block, you can use either actual flows from Lodash or compose, but just try to compose and then when you actually hit a block just try to learn the solution to the thing that's preventing you from composing. And that's really why you end up with all these big fancy abstractions is you're like well I have two different inputs now and I want to compose those. Or I have two different async calls and I want to compose those...and you find out here's the tool to compose it. It always comes down to composition.

Brian: It's much different from object oriented where you are like "Oh I have this problem to solve and I want to figure out what pattern is used to solve that problem." It's always composition. And now it's just the problem becomes how do I compose this.

Joel: You just kinda composing objects at that point. Is that...

Brian: Yeah [crosstalk 00:25:07]

Joel: I think there's a big separation mostly in naming things and we're actually going to call this what we perceive it in this physical world, but then conceptually there's a lot of the same things going on under the hood. We're just abstracting that away. And something.

Brian: Exactly. I think the biggest thing my team has adopted is just using either InTasc to compose control flows for if-else and async really made the biggest difference. And now we're doing stuff like point-free compositions, which presents some extra challenges and then you're looking into lenses and it becomes this path to end up at Haskell I guess. Either way, those are probably the biggest wins. Everybody kinda gets sold on the fact that wow I can actually follow data from beginning to end and just read this code instead of having to know the whole application to understand what's happening. And that's the biggest advantage, is the composition.

Joel: That's interesting because with a typical object oriented, you have all these connections right? To follow the data flow there's a lot, for me, in JavaScript and in full text searches and that sort of thing, to follow it around. But in this paradigm, I'm able to just look at a slice of the data and understand where it's going and how it's being transformed and what's going on. Is that...

Brian: Exactly, and action. And that's where you end up with the 2 camps right? The pure FP people and the people that aren't pure. But if you are going to subscribe to the composition story, then you end up returning a task typically or an IO or something when you do an action. And that composes. So everything kinda keeps...you can keep following this control flow even though one of them is just write to the screen and you're like well what happens next, well follow where that IO got sent or where that task got sent. So it's pretty interesting to be able to compose the world and follow that. And it really tackles the 2 hardest problems right is control flow and state and directly hits those nerves which is why it's been so successful, but also probably much more challenging to actually fight those then it is to mutate inline and change things inline. Because it's harder people tend to want to resist it and say no this is harder to write right now so I don't want to do that. But if you actually try and work with it, it makes everything a lot easier to read later.

Joel: So you said, either InTasc...what's the next step after...and I'm not going to get into what those are. We will try to maybe link to some explanations or something, but what's the next step past Lodash? I can't go all in. I can't be pure. I can't use pure script or jump right into Haskell, just wouldn't work. Where do I go to get one step past Lodash or whatever it is that we are currently using.

Brian: I recommend, so monoids tend to be probably the most useful pattern across the board...the single greatest thing that I've discovered and it's just these cascading layered monoids that allow you to build up really really complex workflows into one big concatenation. I would really spend some time looking at how to apply monoids in your code because they are fairly easy to understand. And they have an incredibly best use case. So maybe introduce some monoids and then once you have those in place and you are kinda describing your [inaudible 00:28:47] control flows with those, you start hit other challenges and start to go higher up in the ladder of functional programming to compose other things in the same way as monoids. Definitely a shout out to monoids.

Joel: Yeah shout out to monoids. I'm going to have to look that up when we are done, but I'm really...I have these...I have specific problems that I think this stuff will be useful for right now. That are just difficult state problems that are hard to get my head around in terms of object orientation so this is long term goal of mine personally, been trying to solve.

Brian: Right now. I definitely think state is difficult and if you can cheat with a closure...you know, I wouldn't say cheat, I would say if your problems easily expressed with a closure, just do that. Then you don't need to bring in state monad that always makes it really complex really fast. Then you have to deal with monad transformers and it's just...I think there's this balance that you can get ton of benefit for following a lot of these rules and then once you're really really comfortable and you want to go all the way and start modeling things with semirings and what not. Then you bring in the heavy lifting stuff. That stuff is..I think part of the reason people get turned off by functional programming is you keep going, you start to hit another barrier and that barrier is kinda ridiculous and the benefit isn't as obvious and immediate.

Joel: Ian Hofmann-Hicks has a really state monad and JavaScript course that we published it's a free community resource. And it's neat because the title's all saying monad in them but he doesn't even use the word monad a single time in the entire course.

Brian: (laughter) That's awesome.

Joel: And he kinda has a joyful approach to all this. Feels like you guys should hang out actually.

Brian: I'm familiar and I love his crocks library.

Joel: Yeah, crocks is amazing and he just...he's actually lives in the same town as me. We get to hang out. He's a great great human.

Brian: That's nice.

Joel: Anyway, it was great to talk to you Brian.

Brian: Yeah, right back at you.

Joel: Learn more from you in the future and I'll talk to you soon.

Brian: Alright, see ya.

More Podcasts

Browse All