CoRecursive: Coding Stories - Story: We are teaching Functional Programming Wrong

Episode Date: August 3, 2020

Today Richard Feldman shares his story of going from javascript developer to elm developer to functional programming teacher.  Along the way, Richard finds that people are teaching functional programming wrong.  We are teaching it in a way that misses how most industrial software developers learn best. In this episode, Richard Feldman delves into Elm, his approach, and how to make teaching delightful. Episode Page Episode Transcript Links: Book: Elm in Action A Taze of ATS Elm Language

Could you state your name and what you do? Sure. I'm Richard Feldman. I'm head of technology at NoRedInk. We make software for English teachers. And I've been, I guess, a web developer for more than a decade now. Almost a decade and a half. How would you describe yourself to somebody who can't see you right now? I have red hair and a red beard.

And I don't know. I guess those are my most notable distinguishing features. Hello, and welcome to co recursive. I am Adam Gordon Bell. Today, we have a fun story from Richard. It starts off when he's a JavaScript developer, and he starts learning about functional programming and a language called Elm. Part two, though, is my favorite. That's where he tries to teach the world about Elm and about functional programming, and he hits some interesting problems. In fact, he thinks that people are teaching these things wrong, and he has a strategy for teaching things better. Elm, by the way, is a Haskell dialect that compiles to JavaScript. But that is not how Richard would explain it. He'd explain it like this.

So I'd say, yeah, it's a delightful language for making reliable web apps. Why does he explain it that way? Well, we'll get to that. But let's start back when he was having lunch with one of his colleagues, back when he thought CoffeeScript was the coolest programming language ever. So his name's Deitch. That's his nickname. Aditya Seeram is his full name. So he gives talks about functional programming and stuff. And we happened to be co-workers at the time. I didn't know him before that, but we both lived in St. Louis.

So I kind of like knew of him because we went to the same meetups and stuff. But yeah, I mean, we were working on the we went to the same meetups and stuff, but yeah, I mean, we were working on the same project. I was working on the front end. He was working on the backend and we both used to go to lunch together and we'd talk about programming. And at the time I was, I was kind of like of the opinion. I was like, man, coffee script is such a game changer for the, you know, front end web development world. Cause, cause the syntax is different, you know, like, uh, you have you have like uh everything's an expression can you imagine that and it's um so my my sort of worldview is was relatively small compared to

what it has become since then um and he really expanded my sort of horizons like he would talk to me about lisp and about um like uh my my only static typing exposure at that point had been like java c c plus plus and i guess that's about it to be honest but yeah so like deech and i would go to lunch we talk about programming and um and he's he's sort of a connoisseur of programming languages i mean to this day like i don't know anybody who has a more like encyclopedic knowledge of not just mainstream popular languages but obscure ones too like he's given talks about um like ats and shen and like languages where it's not just that almost no one's heard of them but like he's

you know actually like built non-trivial applications in him he's not just you know just talking about it like i he read a paper about it or something he's like actually used it and got it building on his computer and stuff like that. Um, but yeah, I mean, uh, he, uh, he really expanded my horizons and, and sort of convinced me that, um, it would be worth my time to try, uh, to try one of these languages out. And I really underestimated how right he was about that. I mean, it completely changed the course of like my career and my relationship with programming. Like, what did he say that like he's like you got to check out ats and you're like rolled your eyes or no no i mean so actually

his ats talk is called not a taste of ats but a tase of ats because it's like it's pretty painful he has he has two different talks he's given on ats they're both like pretty funny the strange loop one in particular i i really i was just i in the audience, I was laughing my head off. Because he really pokes fun at all the sharp edges in the language, of which there are many. So your friend Deej, he got you excited about, I guess, Haskell-y type languages, it sounds? Well, there were two categories of things that he really opened my eyes to. And they're arguably two different extremes, although I think he would be quick to point out that neither of them is at the extreme. He would rattle off a few examples of things that are more extreme in either direction. But in the popular discourse, the two extremes would be Lisp on one side and Haskell on the other.

Haskell being very much about doing things at compile time and Lisp being very much about doing things at runtime. I guess other than macros, those are the things that Lisp things at compile time and list being very much about doing things at runtime, I guess, other than macros. Those are the things that list does at compile time. But yeah, he, he, he opened my eyes to sort of both of those and like the idea that you could have languages that were a lot simpler than like at the time I'd done Java, JavaScript, C, C++, Pearl and CoffeeScript. Oh, and like way back in the day, like basic and visual basic. Um, so those, whatever it is, half a dozen or so languages were sort of the, my main exposure to like the range of programming languages. Um, but like Lisp is just a way simpler language than, I mean, like fundamentally than any of those languages and half a dozen,

way more complicated language than, uh, of those, except maybe C plus plus. In this time period, when Richard was working with Deej and talking to him about programming languages, he was also working on writing his own fantasy novel. So I've been like kind of casually into fiction writing for a long time. Probably since I guess before high school even. And at some point I decided that I was going to write a novel.

And so I went around and looked at all the different novel writing software out there. And I tried a few different things and none of them really fit with the way that I wanted to do it. Which was kind of like, I wanted to write one long continuous document, but I also wanted it to be structured in a sort of chapter-centric way. Like there were certain things I wanted to know about each chapter, like how many words per chapter and like which characters appeared in which chapters and things like that. Um, and I couldn't find something that was all of those. Everything was either too structured. Like you had to edit only one chapter at a time and you couldn't see the flow of how things transition between chapters or they weren't chapter centric enough. And so, uh, being a programmer, I decided to scratch my own itch. And so being a web developer, I naturally gravitated towards building it in the browser.

And so I made the first version in JavaScript and used it. And I wrote quite a lot of words in it, tens of thousands of words. And I kept adding features and tweaking it. And eventually it got to the point where it was sort of unmaintainable anymore. And the sort of the straw that broke the camel's back, as I recall, was that I broke paste somehow, like paste wasn't working anymore, like just copying and pasting. And the way that I would work around this was if I wanted to copy and paste something, I would just go into inspect element and like copy out of the dom and then paste it somewhere else in the dom or like chunks of HTML, like move them around inside the content editable, which, you know, was was no way to live. But I couldn't figure

out like I didn't want to go back to before I introduced the regression because I couldn't, I also didn't want to live without the features that I, you know, built that caused the regression. So I kind of knew at some point, I was like, I'm gonna have to rewrite this thing. Because it's just become too much of a disaster. Do you see where this is going? So Deej is telling Richard, Haskell is awesome. Lisp is awesome.

ATS is crazy. I don't know. Deej is selling him all the beauty of these different programming languages. And then Richard's working on his writing app and it's just falling apart. So obviously he decides, Hey, maybe I should try something Haskell-y for a rewrite. I was convinced that I wanted to try it, but I didn't want to literally try Haskell because that's really, you can't really build UIs with Haskell proper and building UIs is kind of

what I really like to do. So, um, I was really hoping for a language that i could use uh in the browser to build uis but still there's like a pure functional language with type inference and all that so at first i thought that language is going to be roy uh which was the language that brian mckenna made um but he kind of got stuck part way through making the compiler and he ended up not finishing it um so i was i was sad about that because i was like well i don't who knows when something else is going to come along uh so I actually got really excited about pure script because pure script, um, also checked all those boxes. Uh, the one thing that it didn't have that kind of kept me from trying it out was, um, it didn't have a virtual Dom. So, uh, between when

like Roy came out and when I was looking to rewrite dream writer reacted, come out and I, I'd started using it and I got really into it and really liked it. And I really was like, this is like a deal-breaker for me. I've got to have a virtual DOM. And at the time, PureScript didn't yet have one. There was one project people were working on React bindings, and I was kind of cheerleading in the comments. I'm like, I don't know anything about this language,

but I really hope you get these bindings so I can use them and learn the language. And while waiting for that, this blog post came out that was blazing fast HTML in Elm. And it was basically announcing not only does Elm now have a virtual DOM, meaning it checked absolutely all my boxes, but also there were benchmarks showing it's like actually quite a bit faster than most of the sort of like leading alternatives at the time, like React and Angular and Ember and all that. So I just sort of was like, wow, this is everything that I was looking for. I guess now I'm going to learn this and try to figure it out. So what I did was I started my rewrite of DreamWriter right then.

I took the to-do MVC example for elm and i just try to figure out how to use the language and kind of like uh build it up from scratch and so i ended up rebuilding dream writer from to do mvc um basically from scratch uh and i never quite got it to feature parody but i got to the point where i switched over to using it because it was so much less buggy and you know actually it wasn't buggy at all the new version just everything kind of worked um and it was great i wrote probably like 60 000 words in that um uh before my my novel ended up getting derailed uh by just getting so in into elm uh that i started spending all my free time doing elm things instead of writing fiction uh so did you ever did you finish your book no i, I still have it.

And one of my friends is still waiting for it. He's like, hey, are you finishing it? I'm like, no, no. Because I've been sending him chapters along the way, and he really liked the story. But it's hard. I mean, I just fell so fully in love with Elm that I just started spending absolutely all of my free time

just doing Elm things and kind of never looked back. So what happened? So you have your, your dream writer and you start rewriting it. Um, like, did you just like take a weekend and you started just like, uh, trying to pull out parts and, and try them out in Elm or what was the experience like? That would have been smarter. Yeah. The smart way to do it is incrementally. Um that was not what i did what i did was i just started with to do mbc and just started adding on to it uh to you know like add a text editing and add you know this and that until it and add css i did i did keep my style sheets because i had them all in like a separate style sheet so i ported that over directly um but all the logic and all the rendering i just rewrote

from scratch uh from the ground up and didn't keep any of the old stuff. So at first, I mean, it was, it was not just one week. I mean, it took a, took a while before it was back up to the point where I could use it as my primary fiction writing thing again. Um, yeah, it w it was really nice. Uh, it was, it was a good experience. Um, although it, it definitely would have been faster and I would have been able to have something usable sooner if I'd done it more incrementally. I just, A, that didn't occur to me at the time. I didn't really know that it was going to be faster because I hadn't had any experience with Elm yet. And I mean, there weren't many people using it back then.

In those days, there was one Elm meetup, which was the San Francisco Elm meetup. And by sheer coincidence, I happened to be living in San Francisco at the time. And I went to it and there were like 15 people there. And so very, very small community at the time. Wasn't a lot of like, hey, how do you, you know, get advice on how to use Elm at work? Whereas now you just hop on Elm Slack, it's like 20 people immediately respond like,

oh, here's how to use Elm at work. And the advice they'll probably give you is to introduce it incrementally. Yeah. I can see why that would be more palatable. I imagine, like, because I've taken a side project and tried to redo it

before and gotten partway through and either regretted my decisions or abandoned things? Did you have moments of questioning your decision? I have on other projects, but not on this one. I was just having so much fun.

I didn't... Like I said, I just stopped wanting to do other things because it was just so much fun to build more stuff in Elm. I mean, it really... I've been programming since I was nine, and it just never... Nothing has felt like this since... When I was mean, it really, like, I've been programming since I was nine and it just never, nothing has felt like this since like, like when I was 10,

I got Visual Basic and I could make UIs. And I was like, whoa, this is such a game changer that it was like another, you know, almost two decades of, you know, like C++ and Java and whatnot and everything,

you know, felt like, I felt like I knew everything about programming or like, I knew close to enough that I was like getting diminishing returns. And all of a sudden I used Elm and I was like, I know nothing. knew everything about programming. I knew close to enough that I was getting diminishing returns, and all of a sudden I used Elm, and I was like, I know nothing. This is so much better than what I thought was available. I didn't know anything like this could exist.

And then, yeah, that was all I wanted to do. I just wanted to build more stuff in Elm. That's kind of what I've been doing ever since. I can tell you, the confidence I had changing my Java code bases compared to my Elm. That's kind of what I've been doing ever since. I can tell you, the confidence I had changing my Java code bases compared to my Elm code bases, it's almost like Java might as well be dynamically typed for the amount of help that I'm getting relative to what I experienced in Elm. It was just totally night and day different. I thought going in that the type inference

was going to be the big difference. I thought that it was going to be like, oh, this will be like Java, but without all the ceremony. And it was, but it turned out that that was such a small benefit compared to the real big benefit, which was what if the APIs and the compiler are in cahoots to make an amazing refactoring and maintenance experience, like nothing you've ever had before. That was the real benefit. But I had no idea that's what it was going to be coming in. I mean, other than like, you know, hints I got from talking to Deitch, like I didn't know what that was like until I sort of felt it. And then, yeah, then everything was different.

Did you like go into work and find Deitch or start telling people about how great this was? So at that point, I actually worked at a different company. Um, so I worked with each in St. Louis, but this was in San Francisco. So, um, it was like, uh, uh, I had a new set of coworkers and I did talk to them, um, about it, but I, it was quite a while before I actually introduced it at work because I felt that, um, I just thought it was too risky. I mean, we were a small startup and I was like, well, this is an unproven technology. You know, I mean, I've sort of like proven that it's great for my side project, but that's not the same thing as, you know, it being, uh, usable at work. But eventually we got to a point where, um, there

was one particular project that we worked on at work where it took several months to complete. And a large part of that was because we kept having to make major design changes to it based on user feedback. Like we'd make a version, take it out, test it out on, this was students. Like we were trying to teach middle schoolers how to do active voice and passive voice. It was a hard concept, even for adults. And so we kept taking out like a prototype and trying it out on them and then just watching it totally flop and they weren't getting it. Then we'd go back. It's like we care about efficacy and actually teaching kids concepts. These days, it's a lot more writing concepts than grammar like that one was.

But regardless, getting real feedback is important to us. And so I basically had the experience of, this was React at the time, I would come back and be like, okay, we need to make these major design decisions. All of my tests are invalidated by the new design. What can I do to get it back in a working state? And after having gone through a couple of these, I was like, wow, you know, when I would make major changes to DreamWriter, like even bigger ones than this, I would just change, change, change, change, change, and then just follow the compiler error messages until

everything worked again. Then as soon as it compiled, it pretty much always just, just immediately worked. And so like comparing those two experiences at some point, I was like, you know, if I could go back in time and like introduce element work, it would have like paid for itself on this project alone. Um, like all future projects would be easier to maintain. So I was like, I think I was just too risk averse. I think I was just, I missed an opportunity to use something that I knew was better because I was like, I don't know, afraid to commit, I guess. So I was like, well, let's not do that again.

And let's actually use it on our next project. I like how Richard's just, hey, let's use this on our next project. Richard is certain that Elm is revolutionary and it's going to change the world. And it's since become popular. just, hey, let's use this on our next project. Richard is certain that Elm is revolutionary and it's going to change the world. And it's since become popular, but at that time, basically nobody was using it and he was going to use it for their front end of their commercial startup project. I guess I would always be worried, like if I champion something and it seems a little obscure

that we will like hit some limitation I wasn't aware of and we'll be like oh oh god what did i do yeah i mean that's definitely a valid concern um so uh elm has javascript interop so there's always that sort of fallback if you know if something's like really not working it's not like well there goes the whole project it's like well okay we'd have to you know introduce a little like work around here in javascript but it has occasionally happened that we like needed to dip into JavaScript for, for one thing or another.

Um, actually rich text editing is a good example of that. We use, um, quill.js or something, which is like a really, uh, fully featured rich text editor for,

um, some stuff at work. Um, yeah, I, uh, I, I,

I was a little bit worried about that, but I kind of figured like, well, you know, worst comes to worst, we can do interop with like the old way of doing things and that'll be fine richard's committed to bringing elm to work but like javascript is javascript and everybody knows it where elm is like a purely functional programming language that's case sensitive and you know it's based

on haskell which is famously confusing to learn Unless my front-end developers were also PL post-grads, I don't think I would just assume that they would jump in and be fine and even be faster than they were when it was JavaScript. So you were motivated to learn this, but once you need to get people at your company on board, was that more of a challenge? So at the time, there were two things that I had going for me that made it easier to adopt Elm.

And by the way, most people today have an easier time adopting Elm than I did back then because the community is much bigger. It's way more battle tested. It's actually pretty stable at this point, too. And so you can just look around at all the existing success stories and be like, well, let's just do what they did um but back then i mean it there there was like one company that i knew of that was using it in production circuit hub um and uh and prezi was thinking about it yeah so so there were um the team was pretty small that was one thing i had going for me

um so there were only two people who were working on the front end and I was one of them. And the other one was, uh, it was his first programming job, um, out of a bootcamp. Um, so he was, he wasn't really going to like push back on my, uh, like front end architectural decisions. Um, the other people at the company knew, like they understood that this was kind of a risk, but you know, I was obviously going to be sort of taking responsibility for it. Um, so if it didn't work out, you know, they kind of a risk, but I was obviously going to be sort of taking responsibility for it. So if it didn't work out, they kind of trusted me to deal with the consequences of that. But the other thing was that I had a lot of credibility because the only other one time that I'd really strongly recommended and advocated for a front-end technology, it was React. Because React came out while I was working at that company. And I tried it out and I was like, this this is great this is going to be really big um y'all should you know we should

start using this um and you know even this is i don't know maybe a year and change after react to come out so less than two years after react had come out that i was advocating for elm um but it was pretty clear that you know like, like React was, was a good choice. Like it had moved the needle positively for us. And that was, this was like way before React sort of took over the front end world. But I mean, to this day, I maintain like, for me personally, I think there were three big milestones in front end web development. Number one was jQuery.

Number two was React. And number three was Elm. I think everything else in between just almost is kind of noise compared to those, at least for me. And I think those three are not the same in magnitude because I think the gap between jQuery and React is smaller than the gap between React and Elm. So pure functional programming, according to Richard, it's revolutionary elm is the biggest breakthrough in front-end programming since ever if i understand him um so if this pure functional programming style is so powerful why isn't it more popular the reason richard says is people are just teaching it wrong i think there's a really big gap in how effectively Haskell is taught versus

how Java is taught. And to be on the nose about it, I think that the way that people teach Haskell is, um, basically, uh, extremely focused on being able to teach like very motivated graduate students.

Um, if you're not a very motivated graduate student, you have basically no one who is interested in teaching you Haskell. Or at least there is no material out there. And when I say no, I mean we started using it at work and we looked for it and we couldn't really find any really commendable material that's for the audience of someone who wants to use haskell at work i mean none um and uh at least from my perspective as like someone who's spent

oh wow uh probably over a thousand hours at this point like teaching specifically pure functional programming in the form of elm granted um but i mean there's a lot of overlap in the concepts and i know like i've tried different ways of teaching and I've learned some that have worked and have not worked but like there's Haskell books I know there's lots of Haskell books there are yeah and yet when people ask me for a Haskell book recommendation I have like basically I say

someone says hey can you recommend me a really good book to get into Haskell? And if they're not a grad student, I'm like, I really don't have any like strong recommendations for you. Um, like if you want to use it at work or you want to use it to build stuff, like there, there is not a single book on Haskell that I'm aware of. Um, and again, like I said, I've looked, uh, and I know people who have looked, um, that's like build a thing in Haskell where like hello world is like earlier than chapter i'm going to say chapter three but i like usually hello world's around like chapter seven that's the norm you know um because printing to the console is io and you know the the way that the haskell books are laid out is like you talk about monads and monoids and

functors before you get into io and you don't to, but that's how they're all taught. Elm has exactly the same restrictions, where it's a pure language, side effects are managed, and yet chapter two of Elm in action is build an entire working page. Build a whole interactive website. Because you can do that.

You can teach it that way. Chapter one is basic syntax, and chapter two is build a whole working interactive thing. And then I teach the rest of the language from there. There's no reason whatsoever that you could not teach Haskell exactly the same way. Chapter one, basic syntax. Chapter two, build an interactive thing that works and uses effects. But again, culturally, it's just not done that way.

And in my mind, I think that's a major part of the reason that specifically pure functional programming is not as popular as it is today is that it's just inaccessible to a lot of people i mean i i i personally tried to get into haskell that way and ultimately the way that i got into haskell was just i mastered elm first and then after i had already mastered elm uh haskell was you know there was like a just a delta of like things i didn't know and i was able to learn those having already learned sort of the fundamentals of pure functional programming the easy way through elm um and then the other one is intimidating tell me why you think that people are are teaching these concepts of of like pure

functional programming wrong so i don't want to say that they're teaching it wrong i i think it's more that they're teaching for a particular audience and i don't know if that's intentional but i think that i mean when i look at who are the people who uh tend to be successful at learning and trying out haskell and they pretty much fall into two groups one group is people who are unbelievably determined and they just keep like banging their head against the wall and making a little bit of progress. And then eventually they grind it out

and they are able to build something. Really without a whole lot of help from teachers or from books. I mean, like, yes, definitely some like introductory material, but like there's very few people who are like, oh yeah, I just, I read about monad transformers and I got it and then I just used them. Like you don't hear that.

Um, it's, it's, it's really, um, they just like, there was a long grind and then eventually they got there. Um, and the other group of people is like I said, graduate students. I mean, people who are used to reading academic papers and, um, like a lot of papers and, and, you know, understanding them and are familiar with a lot of terminology that people who primarily do programming work in industry are not familiar with. And also there's a particular way of instruction. The way I like to think of it is like, let's say I give a talk to a room full of people at a conference. And at the end of the talk, I mean, I've done this many times, I've lost count of how many conference talks I've given at this point. At the end of the talk,

some number, some small percentage of the audience will come up to me and say, Oh, thanks, I really liked your talk. And, and I'll say, Oh, thank you. And I really appreciate when people do that. And then they'll maybe ask me some questions about it. And everybody else in the room will walk out of the room, because they're done with the talk, they're moving on to the next talk. So I don't get any feedback about what percentage of the audience understood anything i just said i mean i have no idea if if it just bounced off of everyone all i hear is hey nice talk so um based on that i have no like as a as a teacher like if i'm teaching a workshop it's different if i'm teaching a workshop like i'm going around and seeing what what questions people has they go through the exercises. And, you know, there are certain questions like, oh, you're really stuck. You're not getting this at all. Versus other questions where it's like, oh, you actually like, the fact that you're asking this question means that you understood it at an even deeper level because I didn't tell you the thing that would lead you to, you know, know the answer to that. but the fact that you're asking means that you absorbed what I'm talking about so far. Um, so I don't know how someone writing a book

about Haskell would like get that feedback. Um, and so when I say like, I think there's two groups, um, it's, it's based on, I'm filtering for the success stories I hear. Like I look at like, who's in the Haskell community? Who are the people who said I learned Haskell and how did they say they learned it? And one group is the people who went through a grind and just like pushed through and the other group is people who had a background in like graduate level computer science um and there is not really a third group that's like oh I used Python before this and then I learned Haskell and it was fine you know I learned I knew JavaScript I learned Haskell Java I learned Haskell is no big deal it's always Haskell. It's no big deal. It's always a big deal. Um, and so, uh, my, my sort of like proof of like this being the

de facto audience for the instruction is just, that's the group that successfully learns from that instruction period. That's, that's the whole, that's the entirety of that group. Um, everybody else struggles through it, um, on their own somehow. And it sounds like that's how you did like, it sounds like you're in the non-graduate student group. That sounds like your story. Yeah, well, I mean, and also, I'm not programming Haskell for my day job. That was just an experience I had where I grounded out. Yeah, probably bounced out around somewhere

around Monad Transformers. And which was the correct or in-fashion way to do it. Bringing it back to your original question, I don't want to point fingers and say that it's being taught wrong. I think that's like, that's like the natural way that it would be taught because that's, that's its origin story. That's where it comes from. It was, it was built by academics for academics. So why, how could it not have an academic focus in like the culture and how it's taught? Really the, the, the kind of weird thing is that it's being used in industry despite

that very intentional academic focus. And so when I say that I can't find materials that are geared towards learning it as someone who's a professional programmer and not with no academic interest, really, I don't mean that to say that Haskell should feel bad about that or that Haskell community is wrong for not having produced this magical book that would be convenient for me at work um but rather to say that you know uh just to make an observation that like that's that's that's what the status quo is and I think that when people express like ask the question why isn't Haskell used by more people you know even though it has all these benefits I think that's probably the biggest reason honestly is just that the teaching materials are all

historically so geared toward an academic audience even if they don't say they are like I mean if you look at who succeeds in getting through them it's an academic audience primarily and people in industries tend to struggle through it at best. I would characterize things stronger, what you said. Because people learn the language and they get excited about it. They immediately move to step two, which is advocating for it and writing tutorials and whatever. And if people are bouncing off of those, they've failed to a certain to a certain extent uh anyways you don't you don't have to comment on that but

well i i think um teaching is hard it's not it's not like uh if i mean that at least that's been my experience with it um i had a lot of hypotheses about the best way to teach Elm. And I mean, I was very surprised when I started teaching workshops at what things people got stuck on. And I had to like just learn and experiment with different ways of teaching it before I found out what stuck. And if I hadn't had that feedback loop of actually being able to try stuff out on real students and then see how it worked for them and then iterate with a fresh batch of students who are also coming in from scratch the reason i was able to do that was um so uh i agreed to do a workshop on elm for front-end masters and mark who runs front-end masters recommended he was like you know we've seen

people who do this work who do these workshops um you can really tell in the level of like polish and quality, the difference between people who have done like only one run through versus like, you know, upwards of five run throughs, like ahead of time of like doing the whole course and end. And so this is going to be a two day course, like, bootcamps. And I said, Hey, I'm, I will teach your students a free learn Elm workshop, you know, over this weekend, if you want, just, just give me a room at a projector and I'll just do that. And they can just have that if anyone wants. And I did this, I think I did it six times, actually six or seven before front end masters. Then I did front end masters and then I revised the material and then did front end masters again, two years later, after doing more dry runs of the new material. And I did an advanced course and done the workshop at like other conferences as well and so at this point i mean i've revised the material a lot and like learned a lot about a lot

of those things and if if i were to imagine like knowing what i now know about and again this is like pure functional programming which is not what's taught in schools and it's not what's taught at boot camp so it's not like you can just's not, there's not a playbook for how to do that. Um, yeah, I, like I said, I mean, I want to be very careful not to, not to say like people in the Haskell community are like messing up or like, or, or, or, um, doing a bad job. But I do think, I mean, I agree with you that there is a, there's a gap between maybe like expectations and reality there. Like I think people say, look at the number of Haskell books there are. Clearly, the problem is not education.

But I would say like, I mean, yes, look at the number of Haskell books there are, but they're all written in like variations on the same way, which is, you know, I mean, like one of the really popular ones, chapter one is not like element action, chapter one syntax, chapter two, whole interactive application chapter one of that book is lambda calculus right and that's like one of the most recommended haskell books um so uh i mean the the you can say like that's you know well well you can you can say whatever you want about that but like if chapter one is lambda calculus then and you think that your audience is industrial programmers, I mean, some, something has gone wrong. Um, so clearly that like, to me, if, if the audience is intentionally going to be people who are academic or, or at least academically like minded in how they're going to approach learning the language, um, there are lots of success stories with Haskell. I mean, like there's lots of people who learn it and use it in grad school or even an undergrad. I mean, um, or even who, you know, don't have a computer science degree

and just like learned it because they were interested in it. Um, but I bet you, if you've tried to find people who successfully learned Haskell and, uh, read fewer than one academic paper per month on average, um, it's, it's not going to be people who just like read a book and learned it that way. Um, it's going to be a lot more struggle and trying to build things and having a tough time of it, but, um, being determined to persevere through that anyway. No, I think it's a great point. And it feels like the, so, so the meta lesson that I take away is like, Hey, like test your stuff, right? Like get out there, get exposure. Uh, so, so like your learning approach. I, I, I honestly, I feel, feel pretty lucky that I happened to be living in San Francisco and there were these bootcamps and there was an interest on

the part of their students to learn Elm on the weekends, you know, for free. Um, I, I honestly don't know. Like, I, I, well, now that I say that, I bet, I bet that would work for Haskell too. Like if you were in a city with a lot of bootcamps, so like San Francisco, New York, that probably works fine. I mean, not right now during the pandemic,

but, um, but you know, in a normal year, um, I, I bet that that could plausibly work. Um,

but yeah, I mean, I definitely iteration, uh, is important, I think to, to being able to improve at that. And,

and I think also recognizing that if you want to get a different outcome than what previous teaching methods have done, I think you need to try to do things differently. So the meta rule is to test out your learnings. But what did you actually learn in teaching these things? How did that change how you teach? Yeah, totally. Um, so, uh, one of the, I'll say the most surprising thing was actually around syntax. Um, so Elm syntax is overall pretty similar to Python syntax. It's,

it's almost identical to Haskell syntax actually. Um, but the, the big difference is that you, when you call a function uh so like in in c for example you say function name open paren arguments separated by commas close paren um very familiar style to a lot of people in elm it's actually more like a coffee script in that you it's function name space arguments and the arguments are not separated by commas so there's strictly less syntax there in the sense of it's just like spaces everything's separated by white space kind of like in lisp um the difference is uh that if you do a nested function call um in like uh for

example javascript uh you you don't learn any new rules the the rule that you just learned is like you know just do the same thing just call the function and print blah blah but um because in elm and in haskell that would be ambiguous like since they're all space separated you wouldn't be able to tell where one function call began the next one ended or vice versa so what you do is you you introduce parentheses kind of the same way that you would in like a nested uh math expression where you put parentheses around the entire nested function call people aren't used to that in a lot of cases if they come from like a c syntax language um and so uh what i would see is that students would attempt to put the parentheses where they are used to them going like touching

the function like immediately after the function name but that's actually a different grouping than what you want so they get compiler errors they wouldn't understand like why they were seeing it because they'd be like wait why is this so off because usually another thing that i've found um in teaching elm is that the compiler helps out a lot and like because it gives very evan spent a lot of time like making the error messages really helpful um and so a lot of a lot of my revisions to the course material were like i actually don't need to spend time teaching this because if I don't mention it, the subset of the class that's going to stumble over that, the compiler will tell them exactly what the problem is and explain what they should have done. And then they'll just learn it that way. there was a lot of time that I spent trying to eliminate things that I was saying out loud. So, so that basically students could have like less mental bandwidth thinking about edge cases and more just like letting the big concepts sink in.

So I guess that was, that was kind of maybe my biggest macro level takeaway. Like the, the parentheses is maybe the most micro one, but the biggest macro one I think was, um, was trying to intentionally remove things from the curriculum and like, not, not mention edge cases out loud if they weren't important to what they were going to learn.

Just basically like have faith that, you know, what I'm teaching them, whatever the scope of that is, whether it's a workshop or a blog post or a, or a book, this is not going to be the end of their learning journey and just have faith that like, they're going to, they don't need to learn about every single detail right now. Quite the opposite. They, they're going to they don't need to learn about every single detail right now quite the opposite they they mainly need to learn enough to make it through their what they're learning right now um so that they don't get blocked and and are able to move on to sort of the next phase of their learning and realizing that like it's it's totally fine if some and in fact a lot of their learning happens outside the scope of what i'm doing and trying to like

manage my scope accordingly. In all the learning stuff I've taught, I've tried to pare down the scope to like say, OK, what's the goal? It's a term I learned at work because we make software for teachers, scope and sequence. It's like, what is the set of things that you want the student to be able to walk away knowing? Like, what should they be able to do? Like we say, like, finish the sentence like after this book or after this workshop, students will be able to do like we say like finish the sentence like after this you know book or after this workshop students will be able to dot dot dot and then work backwards from there to figure out okay what are the what is the list of things they

need to learn and in what order should i teach them so that they're learning things that build on what they just learned rather than being like okay you're gonna learn this and then we're not going to use it for another three chapters but but remember it for then, because of course they won't remember it. Try to teach it right before they're about to use it. So you do this workshop, teach people Elm, you have this new pedagogical approach that's kind of crazy, like build things, which doesn't sound crazy. I wouldn't call it crazy.

It's unusual within the realm of pure functional programming, but it's the norm everywhere else. So how, how did the book, um, how did you get into writing a book? I have your book here, by the way.

Oh, nice. Um, yeah, I mean, uh, so someone at Manning reached out to me. Um,

they basically, so I was at that point, um, one of the few members of the Elm community who had given any talks about it. I think I had given a talk at strange loop at that point. Although I forget that may have been before the strange loop talk, to be honest,

when they reached out, I gave a talk at a meetup about dream writer. That was the first Elm talk I ever gave. And it was recorded and it was on YouTube and got shared around a little bit. So I don't remember what the exact chronology was of when they reached out, but basically they were like, Hey, we've decided we're going to do a book on Elm. Um, and we're looking for authors. So, uh, it wasn't so much that I had decided I wanted to write a book, but rather, I mean,

I obviously like with fiction writing, I'd done a lot of writing in the past. I'd done a lot of nonfiction writing too. I actually used to write a, I had a weekly column for a magic, the gathering strategy website back in the day, back in college. Um, and, uh, and so I had some experience. I knew that I was capable of, of writing like both long form stuff from, you know, writing almost all of a novel at that point, um, and writing nonfiction from the strategy articles. Um,'d never tried writing a whole book about programming at most written blog posts. But basically what happened was when... So this guy, Mike, was like,

hey, we want your book about Elm. Can you hop on a call and we'll talk about it, potential authors? I was like, sure. So here are the people in the Elm community I could recommend. And at some point I was like, I don't remember if he asked me, I think I just, I just started volunteering this, but I was like, by the way, I think if you're going to do a book on Elm, it's really important that dot, dot, dot.

And I basically said a lot of the stuff we just talked about, like it should be, you know, about building stuff. It should not be about theory. There's a million books on pure FP that are theory. There's basically none that are focused on building stuff. You know, and I also, I had some other opinions about like in particular,

this may be culturally changing, but at the time, everybody in the front end community was doing JavaScript and was doing it, you know, dynamically typed. TypeScript was, I mean, this is a 2015.

So TypeScript was, it existed, but it was just a, it was nothing. I mean, it was, existed, but it was just, it was nothing. I mean, it was probably about the size that Elm was, to be perfectly honest, at that time. Despite the fact that the learning curve was basically zero. It was backed by Microsoft. But at that time, Microsoft was primarily known. VS Code didn't exist yet either, I don't think.

Yeah. At that time, Microsoft was primarily known as the Internet Explorer company. So the idea of like, you know, they're... Front-end devs weren't signing up. Which is a wild idea. Like if you, I mean, over the course of five years, they went from being the Internet Explorer Company just reviled by front-end developers everywhere

because they have to do all the most painful cross-browser testing on their platform to the company that owns GitHub and provides VS Code and TypeScript. Like, wow. What does it, that those, that's, that is quite a 180. But so at the time, basically, like, part of teaching Elm was reassuring people that doing type checking was going to be okay, and it wasn't going to be like Java. So I very intentionally, like, I don't introduce types

until chapter three, like chapter one, you learn the syntax and basic constructs, if and whatnot. Chapter two, you build a thing. And then chapter three, you add types, you learn about types, and you add the type annotations to certain parts of what you built in chapter two. So actually, the type inference turned out to be very useful from an educational perspective, because it let me get through chapter two, where you build a thing from start to finish without even mentioning types, let alone writing any. You don't even know the syntax for them at that point. Yeah, I think I actually noted this down. So I feel like you tried to sneak it in like it was vegetables or something.

Because when you introduce types, you introduce it as a form of documentation. You're like, oh, maybe we should just say what type this is so that we know when we look back. Yeah, exactly. I mean, I was kind of pitching it as like, you know, here's the advantage that type annotations have over comments. Like they, they don't get stale. Like comments can, you know, document and lie. I was, I was basically trying to motivate, why are we going to go through and bother adding type annotations to code that already works? This term motivate, it kind of made a light bulb go off for me. Like maybe that's, what's lacking from some approach to teaching things. We kind of throw concepts at people and we don't spend time explaining to them like why

they should care. I think it also kind of explains how Richard described Elm, right? He didn't categorize it as like saying it was a functional programming language or blah, blah, blah. He said something like, it's a delightful language for building web apps. He was kind of describing the, you know describing why you would want to use it. You'd want to use it because it's delightful rather than because it's a Haskell dialect. And I think also his project-based approach where you're trying to build something and

then you encounter a problem and then that is know, that is used to motivate the next concept you have to learn. It's also part of the secret of his approach. I still, okay. I still feel like, like you skipped this part and maybe cause it's, maybe I'm just projecting this onto you. Maybe it's not the case, but like you said, there was these Haskell resources, which you found not helpful. Um, and then you, like, they didn't fit who you are or however you want to characterize it. But then your book is all about building something. And like, I don't think that's the case necessarily of like other like pedagogical

approaches to functional programming. So like, is that the key here? Is that the key to your teaching experience? Or could you have done this just as well with doing small examples that never really build? And Manning does a lot of inaction books. That's like one of their series. They also have books like In Practice, which is sort of like, oh, this is a thing that's like, you know. And actually, like, you hear about like Real World Haskell or Real World O'Camel. Books where the title itself implies that, you know what, this is not normal, what you're doing. Like using Haskell in the real world, that's not the norm. This is a book for the weird subset of people who are using Haskell for real things. That is the implication of the title.

Imagine a book, real world JavaScript. What? That's the default. You use it in the real world to build stuff. And so I really wanted to make sure that it was clear right from the title, this is a book for building stuff. Oh, I'll put it this way. I think if someone were to write a book about Haskell, where the way that they taught Haskell was, step one, here's how to build a thing. And then I'm going to fill in the gaps on the theory after you've built the thing.

I think there would be a lot of interest for, a lot of demand for a book like that. I think there's a lot of people who learn effectively that way who are not being served right now in the world of like, they have an interest in learning Haskell. They've heard a lot of things about Haskell. They're motivated to try learning that way. And they would, they would be able to learn effectively that way, but that book doesn't exist as far as I know. All right. That was the

show. If you agree with Richard's approach to teaching, uh, let me know on Twitter. If you disagree, you know, let me know on, on Twitter on Twitter as well, or however you communicate. I have a couple of ebook copies of his book to give away to people who engage with me. So I'll probably do some sort of raffle. Until next time, thank you so much for listening.