We're Teaching Functional Programming Wrong

With Richard Feldman

We're Teaching Functional Programming Wrong

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 engineers learn best.

Richard also delves into Elm, his approach, and how to make teaching delightful.


Note: This podcast is designed to be heard. If you are able, we strongly encourage you to listen to the audio, which includes emphasis that’s not on the page


Adam: Could you state your name and what you do?

Richard: Sure. I’m Richard Feldman. I’m head of technology at NoRedInk. We make software for English teachers. I’ve been, I guess, a web developer for more than a decade now, almost decade and a half.

Adam: How would you describe yourself to somebody who can’t see you right now?

Richard: I have red hair and a red beard. I don’t know. I guess those are my most notable distinguishing features.

Adam: Hello, and welcome to Corecursive. 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. 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 the JavaScript, but that is not how Richard would explain it. He’d explained it like this.

Richard: I’d say, yeah, it’s a delightful language for making reliable web apps.

Adam: 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.

Lunch With Deech

Richard: His name is Deech. That’s his nickname. Aditya Siram is his full name. He just talks about functional programming and stuff. We happen to be coworkers at the time. I didn’t know him before that, but we both lived in St. Louis. I knew of him because we went to the same meetups and stuff, but we were working on the same project. I was working on the frontend, he was working on the backend and we both used to go to lunch together and we talked about programming. At the time, I was of the opinion, I was like, “Man, CoffeeScript is such a gamechanger for frontend web development world because the syntax is different. Everything’s an expression. Can you imagine that?”

My worldview was relatively small compared to what it has become since then. He really expanded my horizons. He would talk to me about Lisp. My only static typing exposure at that point had been like Java, C, C++ and I guess that’s about it to be honest. Deech and I would go to lunch and we talk about programming and he’s a connoisseur of programming languages. To this day, I don’t know, anybody who has a more like encyclopedic knowledge of not just mainstream popular languages, but obscure ones too. He’s given talks about ATS and Shen and languages where it’s not just that almost no one’s heard of them, but he’s actually built nontrivial applications in them.

He’s not just talking about it like he read a paper about it or something. He’s actually used it and then got it building on his computer and stuff like that. He really expanded my horizons and convinced me that it would be worth my time to try one of these languages out. I really underestimated how right he was about that. It really changed the course of my career and my relationship with programming.

Adam: What did he say that he’s like, “You got to check out ATS,” and you’re like rolled your eyes?

Richard: No, his ATS talk is called Not A Taste Of ATS But A TAZE Of ATS because it’s pretty painful. He has two different talks he’s given on ATS. They’re both pretty funny. The strange one in particular, I was an audience, I was laughing my head off because he pokes fun at all the sharp edges in the language in which there are many.

Maybe You Should Look at Haskell

Adam: Your friend Deech, he got you excited about, I guess, like Haskelly-type languages?, it sounds? Was that-

Richard: 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 does at compile time.

Yeah, he opened my eyes to both of those and the idea that you could have languages that were a lot simpler than … The time I done Java, JavaScript, C, C++, Perl and CoffeeScript and like way back in the day like Basic and Visual Basic. Those or half dozen or so languages were my main exposure to the range of programming languages, but Lisp is just a way simpler language fundamentally than any of those languages and Haskell is way more complicated language than all those except maybe C++.

Writing A Novel

Adam: In this time period, when Richard was working with Deech and talking to him about programming languages, he was also working on writing his own fantasy novel.

Richard: I’ve been casually into fiction writing for a long time, probably since, I guess, before high school even. At some point, I decided that I was going to write a novel. I went around and looked at all the different novel writing software out there. I tried a few different things and none of them really fit with the way that I wanted to do it which was like, I wanted to write one long continuous document, but I also wanted it to be structured in a chapter-centric way. There were certain things I wanted to know about each chapter, how many words per chapter and which characters appear to which chapters and things like that. 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. Being a programmer, I decided to scratch my own itch. Being a web developer, I naturally gravitated towards building it in the browser. I made the first version in JavaScript and use it and I wrote quite a lot of words in it, tens of thousands of words. I kept adding features and tweaking it. Eventually, it got to the point where it was unmaintainable anymore and the straw that broke the camel’s back, as I recall, was that I broke paste somehow. Paste wasn’t working anymore, just copying and pasting.

The way that I would work around this was if I wanted to copy and paste something, I would just go to go into inspect element and copy out of the DOM and then paste it somewhere else in the DOM where chunks of HTML move them around inside the contentEditable which was no way to live, but I couldn’t figure out, I didn’t want to go back to before I chose the regression because I also didn’t want to live without the features that I built that caused the regression. I knew at some point, I was like, “I’m going to have to rewrite this thing because it’s just become too much of a disaster.”

Thinking About the Rewrite

Adam: Do you see where this is going? Deech is telling Richard, “Haskell is awesome. Lisp is awesome. ATS is crazy.” I don’t know. Deech is telling him all the beauty of these different programming languages and then Richard is working on his writing app and it’s just falling apart. Obviously, he decides, “Hey, maybe I should try something Haskelly for rewrite?”

Richard: I was convinced that I wanted to try it, but I didn’t want to literally try Haskell because really you can’t really build UIs with Haskell proper and building UIs is what I really like to do. I was really hoping for a language that I could use in the browser to build UIs, but still there’s a pure functional language with type inference and all that. At first, I thought that language would be Roy which was the language that Brian McKenna made, but he got stuck partway through making the compiler and he ended up not finishing it. I was sad about that because I was like, “Well, who knows when something else is going to come along?”

I actually got really excited about PureScript because PureScript also checked all those boxes. The one thing that it didn’t have that kept me from trying it out was it didn’t have a virtual DOM. Between when Roy came out and when I was looking to rewrite at DreamWriter, React did come out and I started using it and I got really into it and really liked it. I really was like, “This is a deal breaker for me. I got to have a virtual DOM.” At the time, PureScript didn’t yet have one. There was one project people were working on React bindings and I was cheerleading in the comments stuff, “I don’t know anything about this language, but I really hope you get these [inaudible 00:08:44] so I can use them and learn the language.”

While waiting for that, this blogpost 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 actually quite a bit faster than most of the leading alternatives at the time like React and Angular and Ember and all that. I just 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.” What I did was I started my rewrite at DreamWriter right then. I took the TodoMVC example for Elm and I just tried to figure out how to use the language and build it up from scratch.

I ended up rebuilding DreamWriter from TodoMVC basically from scratch. I never quite got it to feature parity, but I got to the point where I switched over to using it because it was so much less buggy. Actually it wasn’t buggy at all. The new version just everything worked and it was great. I wrote probably 60,000 words in that before my novel ended up getting derailed by just getting so in into Elm that I started spending all my free time doing Elm things instead of writing fiction.

Adam: Did you finish your book?

Richard: No, I still have it. One of my friends is still waiting for it. He’s like, “Hey, you’re 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 just felt so fully in love with Elm that I just started spending absolutely all of my free time just doing Elm things and never looked back.

The Elm Rerwite Of Dream Writer

Adam: What happened? You have your DreamWriter and you start rewriting it. Did you just take a weekend and you started just trying to pull out parts and try them out in Elm? What was the experience?

Richard: That would have been smarter. Yeah, the smart way to do it is incrementally, but that was not what I did. What I did was I just started with TodoMVC and just started adding on to it like add text editing and add this and add CSS. I did keep my style sheets because I had them all in a separate style sheet. I ported that over directly, but all the logic and all the rendering, I just rewrote from scratch, from the ground up and didn’t keep any of the old stuff. At first, it was not just one week. It took a while before it was back up to the point where I could use it as my primary fiction writing thing again.

It was really nice. It was a good experience, although it definitely would have been faster and I would have been able to have something usable sooner if I had done it more incrementally. 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. There weren’t too many people using it back then. In those days, there was one Elm meetup which was the San Francisco Elm meetup. By sheer coincidence, I happened to be living in San Francisco at the time. I went to it and there were 15 people there.

Very, very small community at the time. It wasn’t a lot of like, “Hey, how do you get advice on how to use Elm at work?” whereas now you just hop on Elm. It’s like 20 people immediately respond, “Oh, here’s how to use Elm at work.” The advice they’ll probably give you is to introduce it incrementally.

Adam: I can see why that would be more palatable. I imagine 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?

Richard: I have on other projects but not on this one. I was just having so much fun. Like I said, I just stopped wanting to do other things because it was just so much fun to build more stuff in Elm. Really I’ve been programming since I was nine and nothing has felt like this since when I was 10, I got Visual Basic and I could make UIs and I was like, “Whoa, this is such a gamechanger,” and then was another almost two decades of C++ and Java and whatnot and everything … I felt like I knew everything about programming or I knew close 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.” Yeah, that was what I wanted to do. I just wanted to build more stuff in Elm. That’s what I’m doing ever since.

Everything Was Different

Richard: I can tell you, the confidence I had changing my Java code bases compared to my old code bases, it’s almost like Java might as well be dynamically for the amount of help that I’m getting relative to what I experienced in Elm. It was just totally night-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, “Oh, this will be like Java, but without all the ceremony.” 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 other than hints I got from talking to Deech. I didn’t know what that was like until I felt it. Then, everything was different.

Elm at Work

Adam: Did you go into work and find Deech or start telling people about how great this was?

Richard: At that point, I actually worked at a different company. I worked with Deech in St. Louis, but this was in San Francisco. I had a new set of coworkers and I did talk to them about it, but it was quite a while before I actually introduced it at work because I just thought it was too risky. We were a small startup and I was like, “Well, this is an unproven technology.” I’ve proven that it’s great for my side project, but that’s not the same thing being usable at work, but eventually we got to a point where 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.

We make a version, take it out, test it out on just the students. We were trying to teach middle schoolers how to do active voice and passive voice which was a hard concept, even for adults. We kept taking out a prototype and trying it out on them and then just watching it totally flop and they weren’t getting it and we go back. 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 really, it’s getting real feedback is important to us. I basically had the experience of, this is 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?”

After having gone through a couple of these, I was like, “Wow.” 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 immediately worked. Comparing those two experiences, at some point, I was like, “If I could go back in time and introduce Elm at work, it would have paid for itself on this project alone. All future projects would be easier to maintain.” I think I was just too risk-averse. I think 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. I was like, “Well, let’s not do that again and let’s actually use it on our next project.”

Doubts About Elm

Adam: I like how Richard is 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. It’s since become popular, but at that time, basically, nobody was using it and he was going to use it for their frontend of their commercial startup project. I guess I would always be worried, if I champion something and it seems a little obscure that we’ll hit some limitation I wasn’t aware of and will be, “Oh, God, what did I do?”

Richard: It’s definitely a valid concern. Elm has JavaScript interrupt, so there’s always that sort of fallback. If something’s really not working, it’s not like, “Well, there goes the whole project.” It’s like, “Well, we’d have to introduce a little work around here in JavaScript,” but it has occasionally happened that we needed to dip into JavaScript for one thing or another. Actually, Rich Text editing is a good example of that we use quill.js or something, which is a really fully featured Rich Text editor for some stuff at work. Yeah, I was a little bit worried about that, but I figured like, “Well, worse comes to worse, we can do interrupt with the old way of doing things and that will be fine.

Advocating for Elm

Adam: Richard is committed to bringing Elm to work, but JavaScript is JavaScript and everybody knows it where Elm is a purely functional programming language that’s case sensitive. It’s based on Haskell which is famously confusing to learn. Unless my frontend developers were also PL postgrads, I don’t think I would just assume that they would jump in and be fine, even be faster than they were when it was JavaScript. You were motivated to learn this, but once you need to get people at your company on board, was that more of a challenge?

Richard: At the time, there were two things that I had going for me that made it easier to adopt Elm. 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 battletested, it’s actually pretty stable at this point too. You can just look around at all the existing success stories and be, “Let’s just do what they did,” but back then, there was one company that I knew of that was using it in production, Circuit Hub and Prezi was thinking about it. The team was pretty small. That was one thing I had going for me. There were only two people who are working on the frontend and I was one of them and the other one, it was his first programming job out of a boot camp. He wasn’t really going to push back on my frontend architectural decisions.

The other people at the company knew, they understood that this was a risk, but I was obviously going to be taking responsibility for it. If it didn’t work out, they 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 our frontend technology, it was React because React came out while I was working at that company and I tried it out. I was like, “This is great. This is going to be really big. We just love using this.”

Even this is, I don’t know, maybe a year and change after React did come out, certainly less than two years after React did come out that I was advocating for Elm, but it was pretty clear that react was a good choice. It had moved the needle positively for us. This is way before React took over the frontend world, but to this day, I maintain … For me personally, I think there were three big milestones in frontend web development. Number one was jQuery, number two was React and number three was Elm. I think everything else in between just almost is noise compared to those, at least for me. I think those, 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.

Teaching Haskell Wrong

Adam: Pure functional programming, according to Richard, it’s revolutionary. Elm is the biggest breakthrough in frontend programming since ever, if I understand him. 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.

Richard: I think there’s a really big gap in how effectively Haskell has taught versus how Java has taught, and to be on the nose about it, I think that the way that people teach Haskell is basically extremely focused on being able to teach very motivated graduate students. 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. When I say no, I mean like 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.

At least from my perspective as someone who’s spent, oh, wow, probably over a thousand hours at this point, teaching specifically pure functional programming in the form of Elm granted, but I mean there’s a lot of overlap in the concepts. I’ve tried different ways of teaching. I’ve learned some that have worked and have not worked.

Adam: There’s Haskell books. I know there’s lots of Haskell books.

Richard: There are, yeah, and yet, when people ask me for Haskell book recommendation, I have … Basically, if 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. If you want to use it at work or you want to use it to build stuff, there is not a single book on Haskell that I’m aware of.” Again like I said, I’ve looked. I know people who have worked. That’s like, “Build a thing in Haskell where Hello World is earlier than chapter,” I’m going to say chapter three, but usually Hello World is around chapter seven.

That’s the norm because [inaudible 00:22:56] console is IO. The way that the Haskell books are laid out is you talk about monads and monoids and functors before you get into IO and you don’t have 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 built 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. Chapter two is build a whole working interactive thing. Then I teach the rest of 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. Again, culturally, it’s just not done that way. 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 personally tried to get into Haskell that way. Ultimately, the way that I got into Haskell was just I mastered Elm first and then after I had already mastered Elm, Haskell was … There was just a delta of things I didn’t know and I was able to learn those, having already learned the fundamentals of pure functional programming the easy way through Elm. Then the others are not as intimidating.

Adam: Tell me why you think that people are teaching these concepts of pure functional programming wrong.

Richard: I don’t want to say that they’re teaching it wrong. I think it’s more that they’re teaching for a particular audience. I don’t know if that’s intentional, but I think that … When I look at, who are the people who 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 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, yes, definitely some introductory material, but there’s very few people who are like, “Oh, yeah, I read about monad transformers and I got it and then I just use them. You don’t hear that. There was a long grind and then eventually they got there. The other group of people is, like I said, graduate students, people who are used to reading academic papers and a lot of papers and understanding them and are familiar with a lot of terminology that people who primarily do programming work in industry are not familiar with. Also, there’s a particular way of instruction.

The way I like to think of it is let’s say I give a talk to a roomful of people at a conference. 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 like your talk,” and I’ll say, “Oh, thank you,” and I really appreciate when people do that. 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 out to the next talk.

I don’t get any feedback about what percentage of the audience understood anything I just said. I have no idea if it just bounced off of everyone. All I hear is, “Hey, nice talk.” Based on that, as a teacher, if I’m teaching a workshop, it’s different. If I’m teaching a workshop, I’m going around and seeing what questions people has as we go through the exercises and there are certain questions, where I’m like, “Oh, you really stuck. You’re not getting this at all,” versus other questions where it’s like, “Oh, 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 know the answer to that, but the fact that you’re asking me is that you absorbed what I’ve talked about so far.”

I don’t know how someone writing a book about Haskell would like get that feedback. When I say like I think there’s two groups, it’s based on, “I’m filtering for the success stories I hear. I look at who’s the Haskell community, who are the people who said, “I learned Haskell,” and how did they say they learned it. One group is the people who went through a grind and just push through and the other group is people who had a background in graduate-level computer science. There is not really a third group that’s like, “Oh, I used Python before this and I learned Haskell and it was fine. I knew JavaScript. I learned Haskell. I knew Java. I learned Haskell. It’s no big deal.” It’s always a big deal.

My proof of this being the de facto audience for the instruction is just that’s the group that successfully learns from that instruction, period. That’s the entirety of that group. Everybody else struggles through it on their own somehow. It sounds like that’s how you do it. It sounds like you’re in the non-graduate student group. That sounds like your story.

Types and Stuff

Adam: Yeah, and also I’m not programming Haskell for my day job. That was just an experience I had where I grounded out. Probably bounce out around somewhere around monad transformers and which was the correct or in fashion way to do it?

Richard: Bringing it back to your original question. I don’t want to like point fingers and say that it’s being taught wrong. I think that’s the natural way that it would be taught because that’s its origin story. That’s where it comes from. It was built by academics for academics. How could it not have an academic focus and the culture and how it’s taught? Really, the weird thing is that it’s being used in industry, despite that very intentional academic focus. When I say that, “I can’t find materials that are geared towards learning it as someone who’s a professional programmer and with no academic interest really, I don’t mean that to say that Haskell should feel bad about that or the Haskell community is wrong for not having produced this magical book that would be convenient for me at work, but rather to say that, just to make an observation.

That’s what the status quo is and I think that when people express, ask a question, why isn’t Haskell used by more people 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. If you look at who succeeds in getting through them, it’s an academic audience primarily and people in industries that tend to struggle through it at best.

Adam: 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. If people are bouncing off of those, they’ve failed to a certain extent. Anyways, you don’t have to comment on that, but-

Richard: Well, I think teaching is hard. At least, that’s been my experience with it. I had a lot of hypotheses about the best way to teach Elm. I was very surprised when I started teaching workshops, what things people got stuck on. I had to just learn and experiment with different ways of teaching it before I found out what stuck. 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 were also coming in from scratch.

The reason I was able to do that was, I agreed to do a workshop on Elm for Frontend Masters and Mark who runs Frontend Masters recommended, he was like, “We’ve seen people who do these workshops. You can really tell in the level of polishing quality the difference between people who have done only one run through versus upwards of five run throughs ahead of time, doing the whole course. This is going to be a two-day course, eight hours each day.” What I did was I went to local boot camps and I said, “Hey, I will teach your students a free learn Elm workshop over this weekend. If you want, just give me a room and a projector and I’ll just do that and they can just have that if anyone wants.”

I did this six times actually, six or seven, before Frontend Masters, then I did Frontend Masters and then I revised the material and then did Frontend Masters again two years later after doing more dry runs of the new material and I did an advanced course and then done the workshop at other conferences as well. At this point, I’ve revised the material a lot and learned a lot about a lot of those things. If I were to imagine knowing what I now know about, and again this is pure functional programming which is not what’s taught in schools and it’s not what’s thought at boot camp, so it’s not you can just … There’s not a playbook for how to do that.

Like I said, I want to be very careful not to say, “People in the Haskell community are messing up or doing a bad job,” but I agree with you that there’s a gap between maybe expectations and reality there. I think people will say, “Look at the number of Haskell books there are.” Clearly the problem is not education, but I would say, “Yes, look at the number of Haskell books there are, but they’re all written in variations on the same way.” One of the really popular ones chapter one is not … Elm in Action chapter one syntax, chapter two build a whole interactive application. Chapter one of that book is lambda calculus. Right? That’s one of the most recommended Haskell books.

Well, you can say whatever you want about that, but if chapter one is lambda calculus and you think that your audience is industrial programmers, something has gone wrong. Clearly to me if the audience is intentionally going to be people who are academic or at least academically like-minded in how they’re going to approach learning the language, there are lots of success stories at Haskell. There’s lots of people who learn it, use it in grad school or even in undergrad or even who don’t have a computer science degree and just learned it because they were interested in it, but I bet if you’ve tried to find people who successfully learn Haskell and read fewer than one academic paper per month on average, it’s not going to be people who just read a book and learn it that way. It’s going to be a lot more struggling and trying to build things and having a tough time of it but being determined to persevere through that anyway.

Adam: I think it’s a great point. The meta lesson that I take away is test your stuff, get out there, get exposure, so you’re learning.

Richard: Honestly, I feel pretty lucky that I happen to be living in San Francisco and there were these boot camps and there was an interest on the part of their students to learn Elm on the weekends for free. I honestly don’t know. Now, that I say that, I bet that would work for Haskell too if you were in a city with a lot of boot camps. San Francisco and New York, that probably works fine, not right now during the pandemic, but in a normal year. I bet that that could possibly work. Definitely iteration is important, I think, being able to improve at that 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.

How Do You Teach Differently?

Adam: 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?

Richard: Yeah, totally. I’ll say the most surprising thing was actually around syntax. Elm syntax is overall pretty similar to Python syntax. It’s almost identical to Haskell syntax actually, but the big difference is that you when you call a function, in C for example, you say function name, open paren, arguments separated by commas, closed paren. Very familiar style to a lot of people. In Elm, it’s actually more like CoffeeScript and it’s function name, space, arguments, and the arguments are not separated by commas. There’s strictly less syntax there in the sense of it’s just spaces. Everything’s separated by white space like in Lisp.

The difference is that if you do a nested function call in, for example JavaScript, you don’t learn any new rules. The rule that you just learned is just do the same thing, just call the function, open paren, blah, blah, blah, but because in Elm and in Haskell, that would be ambiguous. 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. What you do is you introduce parentheses the same way that you would in that nested 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 C like syntax language.

What I would see is that students would attempt to put the parentheses where they are used to them going, touching the function immediately after the function name, but that’s actually a different grouping than what you want. They get compiler errors, they wouldn’t understand why they were seeing it because they’ll be like, “Wait, why is this so off?” because usually only thing that I’ve found in teaching Elm is that the compiler helps out a lot because it gives very … Evan spent a lot of time making the error messages really helpful. 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.” Trying to condense the material.

There was a lot of time that I spent trying to eliminate things that I was saying out loud, so that basically students could have like less mental bandwidth thinking about edge cases and more just like letting the big concepts sink in. I guess that was maybe my biggest macro level takeaway. The parenthesis is maybe the most micro one, but the biggest macro one I think was trying to intentionally remove things from the curriculum and not mention edge cases out loud if they weren’t important to what they were going to learn [inaudible 00:37:30].

Basically have faith that what I’m teaching them, whatever the scope of that is, whether it’s a workshop or a blogposts or a book, this is not going to be the end of their learning journey and just have faith that they don’t need to learn about every single detail right now. Quite the opposite. They mainly need to learn enough to make it through what they’re learning right now, so that they don’t get blocked and are able to move on to the next phase of their learning and realizing that 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 manage my scope accordingly.

Sequence and Scope

Richard: In all the learning stuff I’ve taught, I’ve tried to pare down the scope to say, “Okay, what’s the goal?” because the term I learned that 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? What should they be able to do?” We say, “Finish the sentence. After this, book or after this workshop, students will be able to …” and then work backwards from there to figure out, “Okay, what is the list of things I 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, “Okay, you’re going to learn this. Then we’re not going to use it for another three chapters, but remember it for them,” because of course, they won’t remember it. I try to teach it right before they’re about to use it.

The Book

Adam: You do this workshop. You teach people Elm. You have this new pedagogical approach that’s crazy like build things, which doesn’t sound crazy.

Richard: I wouldn’t call it crazy. It’s unusual within the realm of pure functional programming, but it’s the norm everywhere else.

Adam: How did you get into writing a book? I have your book here by the way.

Richard: Nice. Someone at Manning reached out to me. They basically … I was at that point 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 figured that may have been before the Strange Loop talk to be honest when they reached out. I gave a talk at a meetup about DreamWriter. That was the first Elm talk I ever gave. It was recorded and it was on YouTube and got shared around a little bit. 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 and we’re looking for authors.”

It wasn’t so much that I had decided I wanted to write a book but rather … Obviously with fiction writing, I’ve done a lot of writing in the past. I did a lot of nonfiction writing too. I actually used to write at a weekly column for Magic: The Gathering Strategy website …

Adam: Nice.

Richard: … back in the day, back in college. I had some experience. I knew that I was capable of writing both long-form stuff from writing almost all the novel at that point and writing nonfiction from these strategy articles, but I’ve never tried writing a whole book about programming. I’d only at most written blogposts, but basically what happened was when … This guy Mike was like, “Hey, I want you to write a book about Elm. Can you hop on a call? We’ll talk about it, potential authors.” I was like, “Sure. Here are the people in the Elm community I could recommend.” At some point, I was like, I don’t remember if he asked me, I think 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 …”

I basically said a lot of the stuff we just talked about like, “It should be 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.” [inaudible 00:41:06] opinions about in particular, this may be culturally changing, but at the time, everybody in the frontend community was doing JavaScript and was doing it dynamically typed. This is 2015. TypeScript, it existed, but it was nothing. It was probably about the [inaudible 00:41:29] that Elm was to be perfectly honest at that time, despite the fact that the learning curve was basically zero, it’s backed by Microsoft, but at that time, Microsoft was primarily known … VS code didn’t exist yet either. I don’t think

At that time, Microsoft was primarily known as the Internet Explorer company. The idea of they’re-

Adam: Frontend devs weren’t signing up.

Richard: Which is a wild idea. Over the course of five years, they went from being the Internet Explorer company just reviled by frontend 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, [inaudible 00:42:03] that is quite a 180. At the time, basically part of teaching Elm was reassuring people that doing type checking was going to be okay. It wasn’t going to be like Java. I very intentionally … I don’t introduce types until chapter three. Chapter one, you’ll learn the syntax, basic constructs, if and whatnot. Chapter Two, you build a thing.

Then chapter three, you learn about types and you add the type annotations to certain parts of what you built in chapter two. 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 even wrote the syntax for them at that point.

Adam: I think I actually noted this down. 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?”

Richard: Exactly. I was pitching it as, “Here’s the advantage the type annotations have over comments. They don’t get stale. Comments can document and lie. I was basically trying to motivate, “Why are we going to go through and bother adding type annotations to code that already works?”

Teaching Motivations

Adam: This term motivate, it made a light bulb go off for me. Maybe that’s what’s lacking from some approach to teaching things. We throw concepts at people and we don’t spend time explaining to them why they should care. I think it also 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 describing why you would want to use it. You’d want to use it because it’s delightful rather than because it’s Haskell dialect. I think also his project-based approach where you’re trying to build something and then you encounter a problem and then that is used to motivate the next concept you have to learn, it’s also a part of the secret of his approach.

I still feel like you skipped this part and maybe I’m just projecting this onto you, maybe it’s not the case, but you said there was these Haskell resources which you found not helpful and then they didn’t fit who you are or however you want to characterize it, but then your book is all about building something. I don’t think that’s the case necessarily of other pedagogical approaches to functional programming. 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?

Richard: One of the things that was similarly important to me about this book was that … The title of the book is Elm in Action and it’s from Manning and Manning does a lot of in action books. That’s one of their series is. They also have books in practice which is like this is a thing that’s … Actually you hear about Real World Haskell or Real World OCaml books where the title itself implies that, “You know what? This is not normal what you’re doing. 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,” right? 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.

I really wanted to make sure that it was clear right from the title like, “This is a book for building stuff.” 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 a thing,” I think there would be a lot of interest, 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 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 be able to learn effectively that way, but that book doesn’t exist as far as I know.

Adam: All right, that was the show. If you agree with Richard’s approach to teaching, let me know on Twitter. If you disagree, let me know on Twitter as well or however you communicate. I have a couple of eBook copies of his book to give away to people who engaged with me, so I’ll probably do some raffle. Until next time, thank you so much for listening.

Support CoRecursive

I make CoRecursive because I love it when someone shares the details behind some project, some bug, or some incident with me.

No other podcast was telling stories quite like I wanted to hear.

Right now this is all done by just me and I love doing it, but it's also exhausting.

Recommending the show to others and contributing to this patreon are the biggest things you can do to help out.

Whatever you can do to help, I truly appreciate it!

Thanks! Adam Gordon Bell

Audio Player
back 15
forward 60s

We're Teaching Functional Programming Wrong