Teaching Elm with Richard Feldman

Teaching Elm with Richard Feldman

Using Elm at work means teaching Elm. We learn some tips from Richard on how to introduce people to new Elm concepts.

PublishedNovember 8, 2021

Episode#43

Richard Feldman (Twitter) (GitHub)
Richard's Elm book Elm in Action
Richard's Frontend Masters courses
Richard's talk Teaching Elm to Beginners
Find motivation
Mloc.js conference (by Prezi)
Pairing as a way to teach Elm
Intro to Elm Frontend Masters workshop exercises are open source
South Park therefore/but storytelling technique
"I like teaching things the wrong way and then showing what's wrong with it."
The importance of finding good examples
Training From the Back of the Room
Dillon's Elm JSON Decoder koans repo
Gradual release of responsibility technique
Brian's JSON Survival Kit book
NoRedInk jobs (looking for Elm and Haskell engineers)
Richard's Frontend Masters advanced Elm course and Elm intro course

Transcript

And finally, it's been a long time coming here, but we've finally got Richard Feldman

Richard, thanks so much for coming on the show.

Yeah, great to be here.

And today we're going to be talking about teaching Elm.

Richard, you've got so many talks introducing Elm.

You've got your front end master's course, you've got Elm in Action.

You've got a lot of advanced talks, but for me, I appreciate both the ideas you present

and the pedagogy behind them.

I think you make a lot of really advanced topics really palatable, and I admire that.

And I hope that we can share some of your wisdom with listeners today on how to do that.

People get very passionate about all these very advanced, cool things you could do with

Elm, but it's an important skill to be able to present them well.

So really looking forward to picking your brain about that today.

That's very nice of you to say.

Oh, yeah, absolutely.

Yeah, no, I've watched some of your stuff for learning techniques.

And sometimes I actually went through Elm in Action when it was in the beta release,

just purely to see how you approach it pedagogically and how you sort of present the topics.

And it's really impressive stuff.

I remember that when I tried to pitch Elm at a previous company, I watched plenty of

your talks just to present it and it worked.

You make it look easy.

And having gone through that process, I know how hard it is to find a good path to presenting

So hopefully we can share some wisdom about that today.

Jeroen and I rewatched this ElmConf talk you gave about teaching Elm.

I really enjoyed rewatching it.

And so one of the key things you talk about is finding motivation, which I think is really

And so in the talk, you say that using Elm at work means teaching Elm.

And I think that's one thing our listeners might find useful.

I think a lot of people will find themselves in a position where they need to teach somebody

So what do you mean by finding motivation?

So I wish that I had rewatched that talk before coming out here so I don't contradict my past

But I mean, the way that I think about it is if people are going to engage with whatever

you're saying, they need a reason to engage with whatever you're saying.

It's not a safe assumption that just because you're saying some words that people are going

to be hanging on every word and really engaging with whatever you're saying, it's pretty easy

to by default just start saying, here are some facts.

Let me just transmit these facts from my brain into your brain and have it just totally go

in one ear and out the other.

So yeah, I think anytime you're teaching something, it's important to establish why the student

ought to care about that.

Sometimes students will be intrinsically motivated.

They're just like, I'm here.

I want to hear exactly what you're saying.

Every word you say, I'm going to pay attention to it.

But it's definitely not a safe assumption.

So start by establishing that.

Find some way to connect whatever their interests are, whatever they're looking for with whatever

you're planning to be teaching them.

So what I gather from the talk is that you try to find motivation behind the design of

something like why is this thing designed this way now?

What benefits do you get out of it?

What problems does it prevent?

And so the motivation behind the design.

And that's what I get that you're trying to convey to the person trying to learn Elm.

And he talked about finding the problem that will resonate with the person.

Why does this matter to you?

Like types, why should I care about types?

Well, have you ever had this problem?

Oh yeah, I've had that problem.

Well, here's why types are important because they help with that problem that is important

So you have to find something that's important.

But that does like mirror something Jeroen and I talk about often on the podcast, which

is like getting into the shoes, the motivations of like an author of a package, for example.

There's an interesting mirror.

Let's talk about both of those real quick.

So I think the types example is really good because when I first started teaching Elm,

this was a been 2014 or 2015, definitely no later than 2015.

This was when like signals were still in the language.

I remember doing, I did, I've done a lot of like Elm workshops just off the cuff, you

know, like weekend type things.

Yeah, probably at least a dozen of them, like doing a whole weekend and signals was like,

that was a different level of difficulty to teach.

So yeah, it's really made things easier with those little way in ODOT 17.

A big thing that's changed between then and today is back then it was like, I'm teaching

everybody here knows JavaScript, TypeScript, not a thing, just did not exist basically.

I mean, it literally existed, but it was just this weird niche thing that like Microsoft

people use and that was it.

Today it's very different.

So today, if I were to try and use that same motivation that was effective back then of

like, oh, here's why you should care about types.

A lot of people are gonna be like, yeah, we use TypeScript.

What are you talking about?

You know, I don't know that that's still gonna resonate today.

I think what I would focus on more is like, okay, let's assume that the audience is all

TypeScript people, just for simplicity's sake.

I mean, probably in practice, you'll have a mix.

Some people are not on board with types yet.

Others are, but let's say I'm pitching to an audience of TypeScript users.

I'm trying to motivate them for like why they should understand this Elm stuff I'm about

I would focus on trying to understand what are the pain points that people have in TypeScript,

that they don't have in Elm.

So ideally I'd talk to people who've used Elm and TypeScript and say like, what do you

miss about Elm when you're doing TypeScript?

I know one of the things is like, okay, in the Elm ecosystem, like if you download an

Elm package and install it, all the types work.

Like they're all correct.

They're all like, there's never like mistakes or mismatches between anything like that.

Like if it compiles, it's like, yeah, it's gonna run properly because it's all one language.

And today you don't have that same level of confidence in like the TypeScript ecosystem.

So that's like an example of a pain point.

So if I'm trying to motivate someone, like, why should you learn this different type system?

I can say, here's a characteristic of this type system.

Like, hey, like Dillon said, is this a pain point you have currently?

Oh yeah, that is a pain point to have.

Once you learn this, you won't have that pain point anymore in this world.

And then, okay, now I'm interested.

Now I want to hear what you have to say about, I'll learn this new type system so that I

can get to that point where I don't have this pain anymore.

But that might also change in the future.

Like if TypeScript becomes this pervasive thing and eventually everybody's writing all

their libraries and all their code in TypeScript, maybe that mismatch is not the top pain point

Maybe it's something else.

You know, compile times, for example, you get all this TypeScript out there.

Like I know which compiler is faster.

So yeah, I mean, it's definitely not a static thing where you just assume the motivation

is always the same.

It's always contextual to like, what is this person, this student's, you know, what is

the thing that's going to resonate with them right now?

Not you know, not what used to resonate with them.

You always try to adapt to your audience.

And it's tempting to take your favorite things, your pet peeves and the things that get you

excited and then project that onto the person you're trying to teach or, you know, explain

why Elm is interesting.

So is there a connection between like pitching and teaching?

Like, yeah, absolutely.

I mean, I think especially in the sense of like, both of them involve understanding what

the other person, you know, what their life is like, like, what, what are their pain points

and also just like, what makes them excited?

What what are they interested in?

You know, there's, there's different things that will, you know, basically, like, you're

trying to find some common ground in a sense, like, in both cases, you're saying like, Hey,

I people have accused me of being an Elm evangelist, many times over the years.

But I've never really thought of myself as that way.

Because I'm not trying to convert people.

It's really just I'm trying to let people know that this option exists.

Because I'm like, I've had this great experience.

You might also have a great experience.

I want you to know that that is a possibility for you.

But if someone's like, Hey, I don't want to use Elm because of, you know, I'd rather use

this other thing.

I maybe I don't maybe I like JavaScript, maybe I like TypeScript, maybe I like PureScript.

I'm like, cool, I just want you to know that the options there, you know, so I don't, I

don't try to like pressure people to convert.

So for me, the pitch is really just like, is that like, is what I'm what's excited me

about Elm, like what I love about Elm, here are the things that I think, among those many

things that will resonate with you, like, probably not, it's not going to be 100% overlap,

there's going to be some things that I really like that maybe you don't like, or maybe you

Classic example of this, I remember, especially in the early days, there were a lot of discussions

where like a lot of people would say, you know, I'm really used to react.

And I really like the components where I can just take a date picker and just like, boop,

just call it and it's going to do all the state stuff for me.

To me, I always felt that I liked Elm's approach much better.

That was a selling point to me of Elm, which is that the state is very explicit.

There's one way to do everything.

There's no lifecycle hooks.

There's no, now I, sorry, I shouldn't say hooks, because now that's like a different

But like, there's this amazing level of simplicity in how the Elm architecture works.

And yes, the downside is that when you're like reusing stateful things, you cannot just

drop them in like you can in React and just say date picker, go.

And like, you know, one line of code, you have to change things in a couple of different

And to me, that's so a price I'm so happy to pay for the benefit of like what the resulting

system looks like and how easy it is to understand like how all the data flows through everything.

But for some people, it's the opposite.

Like I have talked to people who like, even after becoming experts in Elm, they're just

like, yeah, I just still prefer the other way.

And that's totally cool.

Like it's totally fine for people to have preferences.

But if I'm trying to convince someone, like really the persuasive aspect is what I'm actually

trying to persuade people to do is to try Elm.

That is something where like legit, okay, fair enough.

Like I may not be trying to convert them, but I am trying to get them to try it.

And in that aspect, it's similar to teaching in that in both cases, I'm trying to find

a connection with the person, try to find out like what is going to get them interested

in what I have to say, whether that's how to use the language or why they should try

the language in the first place.

So with Elm, such a key part of what makes it an exciting language is that it's very

maintainable over time.

And how do you try to convey that to people?

That's a great question.

So I would say it's very context specific.

Different people have worked on different sizes of code bases and have run into maybe

different pain points with them.

So for example, if somebody is, if their main experience is doing mostly static HTML with

like a little bit of JavaScript, honestly, I probably wouldn't even try to mention the

maintainability aspect because that's just probably not something that's going to resonate

with them no matter what.

Like I've, you know, especially earlier on in my career, spent plenty of time doing mostly

static HTML with a tiny bit of JavaScript.

And it's like, oh, this is just not a maintainability problem because there's just so little code

It just doesn't matter.

If I could read the whole, the code, the entirety of the JavaScript code fits in my one text

editor buffer, you know, it's like, all right, well, that's fine.

But if someone's got a much bigger JavaScript code base, they probably have pain points.

I mean, this is like the first conference talk I ever gave about Elm was at Prezi and

they had this conference called MLoc.js, M L O C dot J S. And that was short for millions

of lines of code.

And as I recall, the basic premise was Prezi had invested a lot in Flash and they had like

a million lines of Flash code.

And at some point, early on, this was a totally reasonable choice, but then Flash kind of

became, became clear that Flash is like, oh, this is going away.

Like this, we just can't actually do this anymore.

So like, well, what do we want to move to?

And the idea of having, instead of a million lines of Flash, a million lines of JavaScript

was, as you can imagine, like kind of scary.

So what they were looking for was like, how can we scale?

Like how can we have a huge code base that, you know, compiles to JavaScript or something

that runs in the browser like Prezi currently does, but without Flash.

And that was the theme of the conference was just people presenting on different ways to

So I think if you're dealing with a JavaScript code base of that size, you're probably familiar

with the maintainability problems of JavaScript.

Now, if you're dealing with TypeScript, you probably have different maintainability concerns.

Like I mean, the upside of TypeScript for somebody who is coming from JavaScript is

that you can introduce it incrementally.

The downside is that it's introduced incrementally with varying degrees of accuracy.

And that means that you get a different level of reliability out of your types than you

get out of Elm.

So I think if I were trying to convey to someone what the maintainability benefits of Elm are,

it would be a different conversation depending on if they're familiar with like a big JavaScript

code base or a big TypeScript code base.

And it would also depend on how big we're talking about.

Is it like a really small JavaScript code base or like a medium sized one or like a

million lines, you know, like where in that spectrum is it?

And same thing with TypeScript.

So I think like concretely, when it comes to TypeScript, I would talk about, here's

what my life is like when I refactor an Elm thing, or actually, maybe an even better example

is here's what my life is like when I upgrade a package.

Like I have still never found another language.

Rust is the closest.

But like in Elm, when I upgrade stuff, it just works.

Like I just it's just such a non pain point.

Like I just like, yeah, and then like, maybe, maybe something made a major breaking change,

like some package did, in which case, I'm like, okay, let's see what broke.

And then it's like, okay, I'll fix the compile errors.

And then once the type checks, look at that, I'm using the new package and everything works.

That's just so normal.

And it's so weirdly, it's almost like alien.

If that's not the experience, it's so rare.

Whereas like, I still have some JavaScript projects on like NPM.

And you know, like for my pre Elm days, I guarantee if I go and update those packages,

they're all gonna be completely broken, 100%.

And TypeScript is not going to fix that.

Like they're just going to be broken, and their types are going to be broken, probably.

So I think that's an experience that a lot of people can resonate with is like, yeah,

maybe all the TypeScript code that I wrote, you know, tends to work.

But as soon as I start bringing in other people's libraries, the maintainability is just, just

But I still want the code sharing.

So of course, I'm going to use the libraries.

But just talking about like, what if you could have like, you know, as a baseline, really

reliable types, not just for your own code, but also all the like, the whole library ecosystem

And that's only part of the story, obviously, there's also like, okay, there's a bunch of

stuff that you don't have to worry about in Elm that you do have to worry about in TypeScript.

And I've seen some trying to find an adjective that's sufficiently family friendly, while

also, I've seen some TypeScript types that frightened me.

That are just not things that you find in Elm, right?

Like it's really, I mean, just like, pick a random package in Elm package and try to

find the scariest looking type in there.

It's like, probably not that long.

I may have made some of the worst.

Well, okay, but like, I'm not saying they're not there.

But it's like, they're hard to find.

Like, it's pretty rare.

I mean, I made Elm CSS, I'm aware of like, making crazy looking types.

You started your own down the path of the phantom builder pattern.

But yeah, I mean, it's definitely contextual.

And it definitely depends on like, not just what are the characteristics of Elm, but also

like, what are we comparing to?

Like what's the person that you're talking to used to?

And if you can, you know, if you if you can sit down with somebody and pair with them,

that's like a really powerful tool to make it concrete as well.

Yeah, just seeing it.

So I had a funny experience with this, which is one of my co workers made the comment,

so he actually did not learn Elm as a beginner.

And he had worked at no rating, and he was basically focused on like back end stuff for

And then he got into front end stuff after we'd already transitioned everything to Elm.

And so he was just coming in, like his first experience in Elm was in a huge code base.

We had I think back then we had like 300,000 lines of code now we're like almost half a

million and of Elm code.

And so the one of the first things that he did was like work, you know, in this giant

code base, like make some changes.

So he just got it right away.

He was like, oh, I get why this is great.

I just made some changes to this enormous code base.

I know like 0.1% of the code in this code base, and I made this like pretty invasive

And then once it compiled, everything just worked.

Like, this is great.

I see what all the hype is about.

And it's funny because then he subsequently would go to like Elm meetups and like teach

beginners and he's like, it's actually harder to teach people on like Hello World, like

what the benefits are, compared to like giving them a huge code base.

So I actually ended up revising based on that feedback, my front end masters course when

I when I redid the intro course, I made it so at first you're doing like Hello World

stuff like just from the basics.

I talked with Evan about this and and he made the point that it's also useful for people

to know like if you're making a new project from scratch, all you need is Elm make like

that's you don't need to do a whole complicated, you know, like thing you can just be like,

look, one file Elm make done.

So I basically started people off with that.

But then like partway through the course, I transitioned to like, okay, now we're going

to use the Elm real world example, we're gonna actually make some changes to this where like,

you're going to make some refactors and like fix some bugs and whatnot, as part of the

And that was basically I'm trying to give people a sense of like, you know, that code

base is not that big.

It's like 4000 lines of code, but it's big enough that in the span of the exercise, you

have like, you know, five, 10 minutes to do each exercise, you don't have time to learn

that whole code base, you're just like, I don't know what I'm doing around here.

But I know that I'm trying to make this one change.

And so the hope is that people can get a sense of like, it doesn't really matter how much

code is around this, like, the compiler is going to make this be totally fine.

And hopefully I succeeded.

I really appreciate that.

And you open sourced your workshop exercises to for anybody who wants to try that out,

which is really, really nice.

So I'm curious, Richard, like, you've got all these great nuggets, and you like seem

to have like an infinite well of these, these, like hidden gems of little like Elm techniques.

And like, I'm kind of curious, how do you?

How do you develop ideas?

And like, you've got like this very clear map in your mind?

Like do you have like a note taking system that helps you with this?

I'm, I'm very glad that it seems that way.

I just have a good memory.

I think the reality is it's to the extent that I have things to say on these topics,

it's two things.

One is just, I think about it a lot, and like how to improve things.

And two is I just make a lot of mistakes.

Like I mean, I try things out.

And then like, I watch them like work or not, like I actually used to weirdly I so I always

make a list of like, what are the hardest things to teach?

Like what are the things that I struggle to teach?

And I measure that by like, the types of questions that students ask, and like also kind of their

And so like, I know what they are right now.

But I remember one of them used to be well, so signals was always like the Okay, yes,

no one gets signals at it.

Another one was used to be type variables.

Like I used to struggle to teach that because I would like try to give people examples.

I don't even remember what examples I was using.

But I just like, people would always be like, okay, so then, is this is this true?

And I'd be like, no, not like that.

Let me give you a different example.

Like I tried to like make stuff up on the fly, because my slides, obviously, we're not

not doing the trick, these workshops.

And what I ended up figuring out is that all I needed was like a really basic example that

just demonstrates something like something where they understand what's going on.

And and then I can just like explain to your point earlier about like, the motivation of

like why type variables exist, and then they would get it hopefully.

And so the example I came up with was list dot reverse.

So basically, I was like, okay, here, I'm going to call list dot reverse, not not showing

any types, just saying list dot reverse on a list of strings.

And you see that it reverses the strings like, yes, obviously, everybody knows that.

Then I'm gonna do it on a list of numbers.

And I reversed it again, like, yes, obviously, that works.

I'm like, okay, so what's the type of list dot reverse?

What's obviously not list string to list string?

That wouldn't make sense, because it can also do numbers.

So how do you how do you have both?

This is the problem that type variables solve.

So it's actually list a to list a and then the lowercase thing means, I don't know what

this is, it could be a string, it could be a number.

But whatever it is, it's going to be the same in both places.

And so with that really simple example, where like, everybody understands each of the individual

pieces, they understand the motivation for like, why you need a language feature to solve

And it's like, all of these are like single argument functions, everybody knows what list

dot reverse does, like really obvious, the type of like list string to list string, and

then like list number, I think I may have used bool or something instead of number just

so I don't have to get into the whole like, that thing.

Oh, no, maybe it was int, I might have used whatever, it doesn't matter.

Point being, it's like, I can use a really simple example that where everybody can understand

each piece of it.

And then it just wasn't a hard thing to teach anymore.

So there are other things where I have not been as successful in figuring out a great

way to teach it.

But maybe they're out there.

So it sounds like it's just a lot of experimentation that you like, try things out, you try things

out in code, you try things out in ways of presenting things, and then you just iterate

That's, that's interesting.

Yeah, and there's also a lot of like, I mean, as a baseline, I usually would start with

like trying to put myself in other people's shoes.

I also, I also would start with thinking about like, what was hard for me when I was learning?

And like, what are those things do I think are specific to me versus what do I think

is like, probably a common experience?

Like I mean, one of the big things that I went on a different podcast, and I was talking

about teaching functional programming in general.

Actually, I guess I've done that on a couple of podcasts now.

But one of my sort of like pet peeves is that it's it seems very common to teach functional

programming by starting very differently than how you start teaching any non functional

programming language, like any non functional programming language.

It's always like you start with or non pure functional, even, you always start with Hello

And then you're like, let's let's build a thing that does this, you know, whereas it's

very common in pure functional languages, especially to start with, all right, here's

how types work.

And like, eventually, we're going to actually like make a program that does something, but

it's probably not going to be Hello World, it's probably going to be like, you know,

working with like, you know, the numbers in some way.

And that just never resonated with me.

I'm like, I like programming, because I like to build stuff.

And I don't think that's unique to me.

I think that's the norm.

That's like the default is like most people like, like, to build things with their software.

So you know, in Elm, like Hello World is, to me is like is about view.

It's like, let's render a thing on the page.

So I'm always like, whatever I'm teaching, I want to get beat the fastest path I can

get to to like, let's get somebody rendering, even if it's just static at first, you know,

you don't even need like Elm architecture yet.

It's just like, you made a thing.

Yeah, it's useful.

It's like it's something.

And then later on, I will layer types on top of that, like an introduce, like, here's the

types of the stuff you've been building.

So I actually, in all the things that I teach, like in all the beginner material that I do,

one thing that's very consistent, like, often I'll use different backing examples, I'll

use like, you know, different exercises, whatever.

But one thing that's very consistent is it's like, first teach you like the language basics,

like you need to have some vocabulary to be able to be able to do like, Hello World usefully.

So it's like language basics, like syntax and stuff, then Elm architecture with with

the messages being records.

Yes, I remember that from Elm in action.

And then that plants the seed for the motivation for union types or custom custom types.

Yeah, because because like, I and I always go out of my way to show like, let's suppose

we tried to keep going with records like this, you know, because in a small example, records

actually work fine.

Like if you have a small contrived example, but pretty quickly, it's like, I don't have

to add too many capabilities before it's like, Oh, this is not gonna go well.

It's like, okay, now I'm going to show you the fix for that.

And then that's actually like, where I get into types.

Well, so usually, I'll start teaching types first, and then I'll be like, okay, cool.

That's enough, you know, understanding the types.

And usually, I'll actually explain it in the sense of like, let's add type annotations

to what we just did is like kind of the next exercise.

And then I build from there into like, okay, now we wanted to add more things to this record.

Oh, and yeah, because because that concept of custom types is really new to a lot of

Because even in like, TypeScript, I don't think you have something like directly right,

there's not a tagged union, it's just a small step from the concept of an object.

And you sort of add a discriminant.

I mean, there's like, I think there's like enums, that's true.

In your writing, but yeah, yeah, the the South Park showrunners have this like, sort of storytelling

technique that has always stuck with me, which is they, they say that you can tell if something

is like a compelling story or not, by taking the core plot points, and seeing if you can

connect them, rather than saying, this, and this, and this, and this, if you can say this,

therefore this, but this, that shows that they're pushing each other towards the next

thing, and they're connected, and it compels you towards the next point.

Otherwise, they're just sort of disparate events that are happening, but it's compelling

when something is propelling you to the next thing.

And so, you know, I really like that technique you're describing of like, having having a

record for the message type, even if it's not idiomatic, even if it's not, I think,

as Elm developers, we really care about how powerful this system is.

And like, look, when you're using it, well, look at this awesome thing.

So we want to jump straight to that.

But then you're missing the opportunity to actually compel, like, okay, I taught you

this thing, but now there's a problem with that.

And you actually want to plant the seed of a problem.

So it lets you do two things.

Number one, it lets you plant the seed of a problem that you can introduce a new technique

And number two, it makes it so you don't have to introduce that, that next thing you're

going to introduce earlier.

So you can start simpler, have fewer plates in the air.

Yeah, I like teaching things the wrong way, and then showing what's wrong with it.

I think that's like a helpful, helpful technique.

There's a section in Elm in action where I actually, there's sort of a like fork in the

road where it's like, well, we could do this in one of two ways.

I don't remember what it was anymore, but it was around chapter four somewhere, could

be misremembering though.

I'm like, we could do it this way, or we could do it this way.

Both ways seem reasonable.

Let's just do both and see what we like about both approaches.

So I actually like in the page, it's like I put them side by side, and I just like,

draw out like, here's what we're doing.

So you can kind of see like, what are the differences.

And then at the end, it's like, okay, so like, what are the characteristics of each of these?

Oh, like this one seems to have more upsides than this other one.

And I specifically did that because the one that I wouldn't choose, I think is like a

little bit more concise.

And I think that's, it's often I found more difficult to teach a sort of technique where

it requires you to like write more code than the technique that I don't recommend.

Or that I think is worse, for some reason, because, like, we have all these heuristics

for evaluating whether something is a good idea or not.

And that's just such an easy one is like, which one's shorter?

Well, all else being equal, prefer that one.

The problem is all else is basically never equal.

And so there's always this question of like, how do you evaluate the trade offs and like,

convince yourself that like, okay, even though this is more verbose, it's actually better.

Quite often it is.

But I always have to be aware of that if like, if I'm trying to say like, this way is better,

trust me, I need to substantiate that more.

Like if it's more verbose, like I need to give more of an explanation of like, okay,

yes, this will be more concise.

But look at these problems.

Those are more serious problems than verbosity, especially if it's just a little bit of verbosity.

What I really like about Elm is that since it's easy to maintain, easy to refactor, something

I often give as advice to people is just try things out.

It will be pretty easy to undo and to do the other option that you thought about.

So I think it was a great idea to do both ideas and to compare them.

And if I think about how like giving advice to somebody who's trying to, you know, introduce

Elm to a coworker or teach somebody who's starting out with a new concept in Elm, I

think, I mean, if I put myself in their shoes, which we all can, it's so tempting to, you

know, just jump straight to the motivation.

But you want to, you know, remember to start with a compelling thing that showcases the

problem, which sometimes means not doing something idiomatically, not doing something the best

way you know how to in Elm.

Have an economy of concepts.

You want to introduce as few concepts as possible.

And then you want to see how the thing you're introducing is going to bridge the gap to

the next thing.

And it takes some discipline, you know, but it's interesting because on the one hand,

it is sort of a checklist.

And if you really look at that checklist and say, okay, am I introducing more than one

concept at a time here?

You kind of know, and you can go through that checklist and make sure, but you need to do

that deliberately.

But then there's also, it requires creativity and it takes practice to get good at finding

Finding good examples is one of the most difficult skills.

And it's one of my biggest pet peeves and one of my favorite things when people really

nail it, whether it's like package documentation, a tutorial, a read me for a project, whatever

it may be, when people nail the examples.

So like I'm a big fan of Sharon Bowman's like teaching methods.

She's got something called training from the back of the room.

And one of the things she's really big on, this is for, you know, people doing workshops

and things like that.

And I used to do a lot of workshops and like, she would always say like, don't get a room

full of people doing an icebreaker activity and like learning people's names and stuff.

She says like, that is a golden opportunity to teach people what they're there to learn.

So if they're there to learn about Elm, then instead of learning their names, why don't

you have them introduce themselves to someone and tell them what language they're used to

and what they already know about Elm and what they think might be different.

And now you're actually taking that opportunity to do what they're there for.

And to me, examples are the same thing.

Like if you do Fubar, you know, then you're missing an opportunity.

Every example is an opportunity to give motivation of why something is meaningful.

It's an opportunity to show a meaningful use case.

And if you do those things, it's going to stick in people's heads better.

So they're not because the way our brains work, our brains aren't just collecting disparate

pieces of information.

Our brains are association machines.

So if you can like take a problem and also the things that our brains will more strongly

remember things that are meaningful.

So if you can motivate a problem, connect it to the real world situation, and then have

that association to an a code technique or example, suddenly you've created this rich

field for people to remember something and understand it more deeply.

So yeah, I'm such a proponent of coming up with really good examples, but it's not easy.

It requires creativity.

Yeah, it's definitely hard.

I was thinking about, you mentioned like the checklist.

And another thing that comes to mind is when you're teaching a whole course as opposed

to like an individual concept or an individual example, you don't just have a checklist,

but you also have a dependency graph where it's like, in order for me to teach custom

types, you have to know about type annotations first, because otherwise I can teach you how

to do an enumeration version of it.

But as soon as I want to put like a payload in there, you need to know what types are

to say like, you know, what's going in there.

Likewise, you know, before I can teach the LM architecture, I need to teach you how function

calls work because that's going to come up and so on and so forth.

So there's this whole dependencies of like, before this concept can be taught, there are

these prerequisites, but then you don't want to just be like, oh, well, I'll just dump

all the prerequisites and then I can teach the thing.

It's like, well, no, like you said, you got to try and teach one, maybe two things at

a time, small number of concepts introduced incrementally.

And then yeah, it's like, what's the sequence of those?

And then another thing that comes up is, do you want to try to connect examples to previous

And if so, like, how frequently do you want to do that?

So I took the extreme approach to this element action, which in retrospect was, it's the

type of thing that I only did because I didn't know what I was getting myself into.

And like the entire book, like starting from chapter two is building up one giant code

Like every single chapter is like, we're going to add, well, you're building this application.

It's like a photo browsing library.

And every chapter you add stuff to what you did in the previous chapter.

And then by the end of the book, you have a whole like multi single page app, but like,

you know, multiple quote unquote pages.

And you wrote, you know, every line of code of that app, including like refactors and

changes over the course of the, you know, the preceding chapters.

One thing I learned the hard way about doing that is that if I realize like midway through

chapter three, where I'm introducing types that like, I want to do something differently.

And I want that code to end up in a different place.

I now have to go back to chapters one and two and potentially update those.

That's not that big of a deal.

If I realize that in chapter seven, like it's a change that like happens to affect all the

preceding chapters.

I don't have to go through and update them all by hand.

And it's not just like I'm going through and updating the source code.

It's like, I have to update the English words around them that explain those concepts.

Because maybe there's a whole concept that needs to be introduced like in a slightly

different order.

So some of these cascading changes got very expensive time wise, especially as things

progressed, which is going to be my excuse for why I slowed down.

And like, it took me longer to like write the last few chapters than the first few chapters.

Yeah, it's I agree.

Making examples is like, very difficult to do well.

So if you if you did element action again, would you have like more decoupled examples?

Or do you think it was worth it in terms of the meaningful connections?

I would think of it in terms of if I were to do another book, I wouldn't choose to do

But I think I still would have wanted to do it once just because I've never read a book

And I that was like, I don't know, I'm an ambitious person.

I wanted to see like, can it be done?

You know, so now I'm sort of like, I'm, you know, I'm older, I've learned some things.

I'm like, Well, I don't know if anyone else has tried to do this.

Or like, I don't know of any examples.

I'm sure they're out there.

I guess I'm not sure.

But maybe they're out there.

But now at least I know a reason not to.

Yeah, I know a compelling reason not to do it.

Was it worth it?

For reasons, but okay, cool.

That's good to hear.

The whole book is amazing, I think.

Yeah, I really like this.

I mentioned earlier that I read Elm in Action for for pedagogical reasons, because I like

knew those things, but I'm like, how is he going to present them?

And I enjoyed reading it, you know, for those things.

And it's sort of like a murder mystery or something where you want to end on a cliffhanger,

like every chapter, every section should end on a cliffhanger.

So you're like, how's he going to solve this problem?

And if people are asking that, that means you've found motivation, you've connected

it to people's motivation.

And every example in itself is both an example and creating motivation for the next thing.

So I just love when you can pack more than one thing into, you know, like have something

be multipurpose like that.

That's impressive pedagogical technique.

I yeah, I guess I wasn't thinking of it in these terms.

But maybe I got that from fiction writing.

So like in fiction, you sort of like, the ideal is that you have like a paragraph and

you want it to be doing like something like quadruple duty.

So it's like you want to be okay, yes, I want to be advancing the plot, like, you know,

saying like, what's happening.

But also, ideally, I also want to be developing characters somehow, like not necessarily every

single paragraph.

But it's like, if someone's doing something, it shouldn't just be they're doing that, because

that's what the plot requires.

But also because this is revealing something about the character or changing the character

And then you have like, okay, so not just those things.

But also there's like, pros, like, what are the words that I'm choosing to write it?

Like, are these like, creating vivid imagery in the reader's mind?

Is this like, a word that they don't know, and they have to like, stop reading and go

like, look at, get a dictionary or something to understand it?

Like, there's a lot of just like, you know, individual level things.

So and then there's also just like, setting, like, what is this, you know, what's going

Am I painting a picture of exactly what's going on in this place?

Or maybe I don't want to.

So it's just like all these different elements.

And like, the final product is like, as a reader, I'm just like, oh, this is paragraph,

I read it, and like, things happen to my brain.

But as the author, I have to be thinking about all those things at once.

And I think it's the same kind of thing with teaching where it's like, yeah, ideally, maybe

it's more work that I want to do again.

But, but it's like, ideally, yeah, it's like, I'm not just teaching you this concept, but

I'm also teaching you like, you know, yeah, like setting motivation for the next thing,

giving you a deeper understanding of like, why we did it this way, instead of this other

And like, and also, you know, giving you like, a concrete example to build on the next section.

In the Elm Conf talk, you gave a you talked about like, not getting too caught up on giving

all the details and trying to like, be honest, but not necessarily thorough.

Because, you know, at the expense of throwing too many concepts at once at people.

So like, how do you balance that line, right?

Because it I mean, we've all been, you know, if we're introducing Elm to people, I know

we've all been in that situation where your brain is firing off all these things you need

to tell somebody about the question they just asked, like, how do you navigate that?

Yeah, that's a great question.

So I would say the first thing that comes to mind is, if I've got this sort of mapping

of like, here are my dependencies, here's my checklist of like, things that I want to

be true about, like, what concepts I'm teaching in what order.

Basically, my sort of guiding principle is, I don't want to go off on a big tangent that's

going to result in my teaching a whole new concept here.

Because like we talked about previously, like, I don't, I don't want to teach too many things

One way I can potentially accidentally teach too many things at once is, if I'm midway

through teaching this one concept, and a student asks a question.

So classic example of this is starting off in the REPL, and I'm just like, you know,

one plus one, or I'm doing like a string concatenation or something like that, like, put in the string,

hello world, you know, concatenate another string.

But another thing that I might do is I might put in like, one plus two.

And if I do that, then the REPL is going to say three colon number and number is lowercase.

And if somebody notices and asks a question, like, how come that one's lowercase, the other

one's uppercase, I could be like, well, let me talk about type variables.

And then like, no, no, no, we're not there yet.

We don't need to go into all that.

And in fact, I don't even think if you're doing a beginner workshop, you need to explain

that concept at all.

Because on the one hand, like, yes, like, there's number comparable, appendable, and

even if you want to get really advanced, complement, but like, like, the upside of how those work

is just like, yeah, numbers work the way you expect them to, like, plus works on integers

Like, it's not like if you don't teach that, people are not going to be able to use L,

like, especially beginners, right?

In an advanced course, sure, you can you can get into those, like, if you know, if people

are interested in that, but that gets into that question of like, how thorough do you

And it's like, really, I think it comes down to thinking about, if I want to actually teach

you this, how much time is it going to take?

And is right now the right time to spend that much time?

On the other hand, if it's like a really small amount of time, it's not really going to be

like a big distraction, like, yeah, you can just like, answer it.

Or sometimes you can just give a brief answer and say, like, we'll talk about that more

later or even just like, ask me about it after the workshop.

And we'll all explain it.

Like for the number one, for example, if I did put that, so first of all, I'm actually

pretty careful in examples.

Like, I know I did this in element action in my like workshop slides, but even if I'm

just like doing something live, I'll always just choose floats.

Like just don't say, like, if I'm making a list, it's never going to be like, one, two,

three, it's going to be 1.1, 2.2, 3.3, because yeah, then that just doesn't come up.

And it's a little thing, but right, it's like, it can prevent a question, which might lead

So it actually helps keep the course focused.

And you can do things like that with examples in general, just sort of being like, well,

here's what comes first to my mind.

But if I do that, like, what are the questions people might ask if they see this?

It's like, what have they seen so far?

Is this going to show them something new that might lead them to ask a question about it?

If I'm not ready to teach that, I can just maybe pick a different example, what's not

going to result in their having that question.

So for instance, you would try to avoid having the person write HTML message with a lowercase

Because then they would actually understand that.

That's another good example is like, whenever I so, you know, I start with basic syntax,

then LM architecture, then like the third, you know, module or chapter, whatever is like

When I ask people to annotate stuff, even for the static HTML parts of the page, I'll

still have them annotated as HTML with a capital M message, even though they don't need to

it's overly constrained.

Like, I don't need to end like sometimes I'll have a student like, so one thing that'll

come up in a workshop is that students will be at different levels.

And like some some people, this will be all brand new to them.

But some people will be like, oh, they've used like, you know, OCaml before or something

And sometimes somebody will raise their hand and be like, Hey, does this need to be HTML

Or like, can I kind of do like HTML a or something like that?

And I'll just be like, Yeah, that'll work too.

I just like just try to answer it as fast as possible.

Like if this is going to be like, you know, this person knows what I'm talking about.

If I if I give them a quick answer, everybody else is going to be lost if I go into a whole

digression on it.

So I don't want to go on that digression.

So I'll just be like, Yes, like I try like one word answers quite often.

Like when somebody asks like a question that's like, too advanced for most of the class,

I'll just be like, Yes.

And you can say we'll get we're gonna get into more detail on that.

But you've got the right idea.

And they'll get the attention of the other students on this topic.

Yeah, well, often I don't even I don't even bother.

I'm just sort of like, I don't I don't want to go on the diversion.

So my my prioritization is just like, let's just answer the question of other people.

Like, I don't really understand the question.

But it sounds like the answer is yes.

So okay, whatever.

Then they don't they don't get pulled away from like the direction I'm trying to teach.

You can actually do a lot with your tone as a teacher slash facilitator.

If you give quick, upbeat answers short, then people are like, Okay, this is not a detailed

discussion that we're diving into.

Like if you say like, Yeah, that's right.

They're this and that then they're like, Okay, so the last follow up questions, then they're

like, Okay, and the next thing is,

yeah, that's a great point.

Yeah, like, like, I still want to be enthusiastic with my response and not and not, you know,

try to like, suggest that there's anything wrong with what they asked, like, totally

reasonable thing to ask.

Yeah, just just like, yes.

And you've got to stay focused on what is the goal right now.

And you know, so like, the goal right now is to teach this topic.

And we'll get to that later.

because if you think about it as the alternative, it's like just just imagine in your in your

mind like the two different scenarios, one where you just answer quickly and move on.

And the other where you're like, let's go in and spend, you know, the amount of time

that we could spend on this topic.

What's most of the class gonna be doing, they're gonna be like, like, what, is this like a

new module we're doing off the cuff now?

Like, you know, it's and also like, now you don't have slides prepared or whatever, like

to, you know, to back up what you're talking about, and to make you go more smoothly.

And yeah, you just end up ad hoc teaching something that, you know, either you were

going to teach later, or maybe that you decided, you know, you weren't going to teach in this

section at all.

And perhaps correctly, worth noting that there's there is a book equivalent of people asking

questions that are like more advanced, which is, if you're giving people early drafts to

read and give feedback on oftentimes, like people will suggest, like, Hey, are you going

to talk about this?

Or like, you know, I noticed that you didn't talk about that, I think you should.

And oftentimes, what people say is, I think better beginners will be confused by dot dot

And, but they're, they're not a beginner anymore.

So like, they, they, they might be right, but they also might be wrong.

And you have to be really careful about that of like, it's pretty easy to end up with,

like, what are the set of things that I should teach in this section?

And it's just the union of like, all possible things I could teach, because different people

who read it each thought that, like, maybe beginners will be confused by x, y, or z.

So there's some aspect of like, the most valuable thing, and this is unfortunate, because, you

know, as soon as you teach someone something, they're, it's too late, like, you can't go

back and ask them to like, learn it from scratch again, right?

Because they already know it.

And like, now they're, you know, they're not, so you got to like, try to find new beginners

But like, the most valuable feedback is like, getting a group of actual beginners who don't

know the material at all, and seeing what they actually are like, confused by in practice.

Before I started computer science, I studied piano performance, and my teacher, I mean,

studying music performance is one of the best ways to learn about pedagogy, because for

one thing, you have like, a master teacher, and hopefully, and then the other thing is,

they're working with you one on one, you know, so it's an incredible opportunity to learn

And my piano teacher was brilliant, and really influenced me outside of music, in addition

to within music, about isolating things to the most minimal thing and being very disciplined

So like, what are you trying to accomplish right now?

And if you're trying to produce the sound a different way in the piano, why are you

playing a complex piece with all these fast notes and passages and all these different

complex fingerings in the scale passage you're playing?

If you're trying to produce a different sound, isolate that and isolate down to that one

piece or if you're trying to, you know, so try to minimize the number of different skills

that you're exercising at once.

And I think having that discipline, and it's, so for example, like, that's one of the reasons

why I really love test driven development, because I think it's almost like, I think

of it sometimes like a pulley that it allows you to stretch out a large amount of work

over a greater distance, so it eases the work you need to put in.

And so like, when you're doing test driven development, you, all you're trying to do

is get the current test green.

You don't want to get distracted by, wait a minute, there's this thing that's wrong

Like, no, that's, the test is not telling you to do that.

You have one test, you're trying to get it green.

Like, yeah, but there's this one corner case.

You get the test green, then you get that, then you write a test for that corner case.

Now that's your sole focus.

And so just being with one thing, having that discipline, isolating it is like, just being

disciplined about that will get you a long way, I think.

Yeah, it's definitely tough because the temptation is if somebody asks you a question or, you

know, a reviewer says like, oh, teach this thing, you know, what about this thing?

You're like, oh, I know about that thing.

Let me talk about that thing.

There's definitely an allure to that.

Yeah, you got to be disciplined and not go down that rabbit hole.

I'm very curious to know about how you onboard new hires.

If you get a new hire, they don't know Elm at all, they know something else.

How do you teach them Elm?

The way I've always done it is pair programming.

Just have them drive, like have them be at the keyboard.

And yeah, I mean, in our case, like we have a substantial Elm code base already.

So usually just like, you know, pick a feature and have them dive into it and not even start

by explaining the Elm architecture necessarily.

Maybe just start by being like, okay, here's what's going on on this page.

We got this UI, it's doing these things.

We want to change this thing to do this.

And then just be like, okay, let's start by, here's this thing.

Okay, so we got this view function.

It says like, you know, view drop down or whatever, view, whatever it is.

That's what we're going to be modifying because that's the thing that we want to change.

So let's go in there and okay, see, it sees like lists.

All right, this is a list.

We're calling, here's some function calls.

Let's you know, so basically just like going through a similar kind of maybe progression

in terms of like what I'm teaching them, but doing it in sort of an ad hoc way in the context

So it's like, all right, let's find the part in the file.

I know where it is, you know, that we need to go look, let's go look here.

And then I'll just explain the syntax of like, literally what you're looking at, and contextualizing

it in terms of the project that we're working on.

And obviously, try to start with something that's, you know, pretty minimal, and don't

be like, oh, let's pick this next task, which is like rewrite this whole page, that's not

going to go great.

Something where you're making an incremental change.

And then yeah, just be like, okay, here's the syntax of what we're looking at.

And then here's the change we want to make, we want to make this function call do something

And at first, you can sort of, you know, just let them do like copy pasting without necessarily

knowing all the details of what they're copy pasting.

So you might say, for example, okay, we're going to copy paste this this function declaration

up here, and we're going to make a new helper function down below.

And we're going to change the the name of it to this, we're going to change the types

to this, don't worry about types, we'll come back to that later.

And then, you know, just kind of keep them focused on like, okay, I'm making a function

that's going to do this thing a little bit differently than what it did before.

One thing I like to try and do is to expose them to compiler errors pretty early on.

Because once they get comfortable seeing a compiler error, and like, and I'll let them

like, look at it, like, I won't try to explain the compiler error, I'll be like, okay, let's

And I'll say, that's not going to compile, let's let's go see what the compiler says,

and then let them read the error message.

And then if they don't get it, then I can explain it.

But you know, hopefully more often than not, they will get it.

And what's great about that from an onboarding perspective is that then once you're done

pairing, you can go away and they can probably keep, you know, some some extent stumbling

through some things and just having the compiler help them and like, pretty early on, you switch

from like, this person needs a human to help them to like, they're just good with the compiler

And like the only time they need somebody to help them just sort of like get more muscle

memory with the language and like get more reps in is when they're trying to do something

that's like in a whole category that they've never done before, like ports, you know, they're

like, I need to talk to JavaScript, how do I do that?

But otherwise, it's just like, yeah, you can, you can let people just sort of like, in my

experience, like go off on their own, they'll have some questions now and again, but like,

if you get them going on pair programming, and your goal is sort of, I want to get them

comfortable with the compiler and like knowing the basic syntax.

And then at some point, you probably have to stop and explain the LVAR architecture.

But but you don't necessarily have to like give them a thorough understanding of it really,

I mean, just being like, here's the rule, if I want to add a new thing here, I'm going

to add a thing to this message thing, then add a thing here, and then just follow the

compiler errors.

That'll get people quite a ways.

And once they get comfortable with the compiler, the compiler can be an effective, you know,

assistant to help them like continue learning on their own.

And once they get in the habit of reading the compiler errors, because many people are

coming from contexts where error messages are not helpful, they're just something that

tells you, okay, be annoyed and buckle up because you're gonna have some pain.

Now, please look at your code carefully and try to figure out where the error is.

No, you did bad.

It's an antagonistic relationship.

Whereas with Elm, like one of the things that our role is to do with people learning Elm

is to unlearn that behavior to have an antagonistic relationship with the compiler, but to actually

embrace the help that it gives you because it will help you if you read the messages.

But I remember being in the habit of not looking at error messages because I'm just like, oh,

annoying red stuff that tells me I'm having a bad time right now.

Yeah, yeah, I've been there.

So what is their next step?

When they get comfortable, you have not explained the Elm architecture, they have not explained

some concepts that you may see pretty early on in the Elm guide, for instance, or in Elm

What do you recommend them to get further learning on the topics?

So always start with the Elm guide because it's, number one, it's free, which is great.

And number two, it's...

Before the pairing?

Oh, no, no, no.

Like after the pairing.

And then once they've gotten the basics, and I think part of that is, A, just giving them

the confidence of, hey, I can build stuff in this code base and not feel like they need

to go do a bunch of examples before they understand anything.

To be fair, different people learn in different ways.

Some people will tell me, I don't want to get into the code until I've read something,

what should I read first?

In which case, great.

I have them start with the guide.

But one nice thing about the guide is that because it's pretty light reading, it's not

like a big time investment to go through it.

Like Elm in action is like a whole book with multiple chapters and stuff, whereas the guide's

I mean, it's got chapters, but they're way shorter.

So you don't need to ask someone to make as big of a time investment.

The other thing is that I think when someone's reading the guide and they've already had

a little bit of experience with the language, they can have this experience of like, okay,

I don't need to do all these examples.

I already know the syntax well enough.

I can just look at these things and just pick up details.

Like, oh, I know there's this thing called view and there's this thing called message,

and I don't really know how they relate.

You see the diagram, you're like, got it.

Now the pieces are coming together of the stuff that I was doing without fully understanding

Now I understand it more fully.

I get the concept and not just the...

There's this rule where whenever I want to add a new event handler, I put it in this

So that is definitely a...

It's a different path from somebody who's like, I want to learn this language.

I want to come in and just read through a thing that by the end of this, I will know

how to make things in this language.

But the nice thing about doing the starting people off with pairing at work is that hopefully

they can get a lot of that motivation just like from the hands on experience.

Even if they don't understand what's going on or why, they can get some of those moments

of like, oh, I didn't even know what I was doing and the compiler really helped me out

I want to learn more.

I want to do more of this.

Because one thing to keep in mind is that if you're teaching a coworker, to me, it's

kind of a safe assumption that your coworker isn't already an Elm fan.

Because how do you become a fan of Elm by using it?

So if you have to teach them, that implies that they haven't used it before, which means

that you do still have that motivation step of like, why should they bother going through?

Even the guide's a lot shorter than Elm in action or a workshop or something.

But it's still not a blog post.

I mean, it's a bunch of stuff to go through.

Why should they care?

And also, why should they not just skim it and just be like, yeah, yeah, okay, it's architecture

And I think the answer is give them a taste of it first.

So if you can, if you're in that sort of coworker situation, yeah, start by giving them a taste.

So you mentioned the hardest things to teach in Elm that Signals was the notorious big

one for a while.

And I think I heard maybe on Elmtown once, I can't remember if it was Evan or maybe

you talking about how teaching those workshops and your feedback from students in those influenced

the language design, which I thought was really cool.

That's very, it could have been me.

What are the hardest things to teach now?

Maybe we've covered some of them.

So there's two that stand out above everything else.

And my prediction is I would actually like for you guys to guess because I'm really curious

to see if you can guess what they are.

Well, at least what I consider them to be based on my experiences.

I'm not trying to say this is universal, but my prediction is that both of you will guess

one of them correctly and guess the other one incorrectly.

This is a good challenge.

By the way, I'll mention that it's not syntactic.

One of the things that's hard for beginners to pick up is where the parentheses go.

It's not hard to teach.

It's just like you teach it and people are like, got it.

And then they go to do the exercise and they're like, I messed up my parentheses because I

tried to call it like JavaScript style where the parentheses touch the function.

So it invokes something as if passing in a single argument is invoked with parentheses

and it works because it's a single argument function and then maybe on format fixes and

they're like, all right, this is that.

Yeah, that can't happen.

But what I found is that people get the parents think like by the end of the day, they just

like, yeah, they just figured that out.

But anyway, it's not that.

So two things, I'm just curious what your guesses are.

I'm guessing it's currying for one of them.

Oh, that's a good guess.

But only because I've watched one of your talks when you mentioned that currying was

one of the hardest concepts to explain.

It's a very good guess.

I want to say immutability would be one thing too.

You don't think so?

I mean, the one that people most complain about is JSON decoders, but I don't know

if that's the one that Richard would say it is.

I don't think it is.

That's what the guess is you're in.

Are you saying I wouldn't say that just because I made JSON decode pipeline or for a different

I think I'm going to be surprised.

And JSON decoding is a different mindset because people are used to just working with JavaScript

object notation from JavaScript where you just are like dot this, dot this, dot this.

And not validating.

It's probably right.

So, I think that's the answers.

Or didn't do you want to guess?

Well, the Elm architecture was the other thing that came to mind, but I mean, it's just a

more, it's a broader topic in Elm, but I'm not sure it's an unintuitive one.

I think it's intuitive.

So, I don't know.

What are they, Richard?

Jeroen got them both right.

JSON decoders and currying.

I thought that I didn't realize that I'd talked about currying being hard because I would

not have guessed that one.

I would not either.

It was surprising to me when you mentioned that in your talk.

I wonder if any new programming language designs will be influenced by this.

Who could possibly say?

So the thing about currying that's tricky is that, so first of all, what I've observed

is that I've refined my explanation of it in a couple of different times, but I have

not been able to break through this ceiling of just, as I'm explaining it, people understand

each individual step.

I'm like, okay, so I got this whole thing where I go through, let's take a function

that has three arguments.

I think pluralize is usually the one I use.

Then I'm like, cool.

Now let's, we know about partial, so actually partial application for some reason seems

to be easier to explain than the types involved in currying.

If I just say, hey, if I call this function, I can leave off the last argument.

When I get back as a function that takes that argument and so forth, they're like, okay,

As soon as I start turning that into types, that's where it gets hard is it's like, okay,

so the type of this function is like this arrow, this arrow, this arrow, this, and then

people are like, why?

Like that's weird.

Like that's not, no, this is like, that's for returns, not for arguments.

Like, okay, bear with me.

Let me show you why it's actually the same.

And so I worked my way up and I say like, here's pluralize and we agree that if I call

pluralize with one argument removed, it gives me back a function that takes an argument

and then yes, we agree.

All right, now let's try it with two arguments.

And then I just, I worked my way up and then basically just break it all the way down and

then show how like, and then build it back up and be like, well, if this is the type,

then clearly it's like this, like, but with, you know, the parentheses around the arrows

and then I'm like, and then at the end I'm like, finally like, okay, and then you don't

need to put the parentheses in.

So I just take all the parentheses out and I'm like, ta da.

The problem is that even though each individual step makes sense at the end, I look at like

the expressions on students face and they're kind of like, yeah, but they're still arrows.

Like you know, it's like, but that's still for returns.

And so it ends up being one of those things where people are sort of like, I believe you,

I don't, I feel like I must be missing something, but like, I'm just going to trust you like

whatever, they're arrows.

And so they get by, like, it's not like they're, they're so lost that like, they can't, they're

blocked like the, the, but they don't get it right.

Like the, the, the, like actually, and when I say they, I don't mean like every single

student, it's just like a lot of students, like maybe like half the class.

And I just like, every time I do a workshop, I'm like, all right, here we go.

It's time to teach currying.

I know what's going to happen.

Like half the people, I'm like, some of the people are like, that's so cool.

And that's like really cool.

But for most of them, it's, it's just like, they're just like, okay.

And it's, it's always like a low point in the workshop for me because like, I'm just

like, I, I'm teaching types and especially because it has to come so early because as

soon as like, I'm actually very careful to teach only single argument functions when

I'm teaching types like at first.

And then like, because as soon as I get to a multi argument function and in the type

section, I have to introduce currying because otherwise it just doesn't, you know, like

I, I, I, maybe I should try this as like, try to get through the entire workshop with

just hand waving away the arrows and just be like, yeah, it's weird.

That's just the syntax.

Anyway, moving on.

That's like, that's a defensible way to teach it.

But I, I don't know, maybe because I've always felt like, oh, this is, I just want to teach

currying, you know, I don't, I don't want to like have someone leave an eight hour beginner

workshop without knowing why the types are that way.

Cause it actually is really cool.

Like it's, it's genuinely like a very cool thing, I think.

But I just, I've never been able to crack it where, where people actually end that section,

like feeling like happy, confident, you know, whatever.

They're just like a bunch of them are just like, eh, what?

Okay, whatever.

You know, like grudging acceptance of like, this seems, it seems like there's a reason

I don't really understand it, but like, you seem to know what you're talking about, so

I'm going to go with it.

So that's that.

And then JSON decoders are just hard, I think.

It's funny because I don't feel like I've had trouble explaining currying, but explaining

the motivation for partial application that I can't get it across.

Like, Oh, why would, why, why would you want to have a add five and make that a function?

But that's probably not the best example.

And maybe I just need to find a better one, but that's where I get stuck.

I remember the example from Elm in action.

I actually remember there was something with like list dot map, which was a very good example.

And it was like, all right, let's, we give list dot map a function to apply for each

So, you know, maybe it's like anonymous function with an argument string, and then it returns

string dot two upper on each string.

And then it's like, actually, did you know there's a cleaner way to write this?

You can remove that argument in the anonymous function and then remove it from where it's

defined in the parameter and then remove it where it's passed in.

It's actually the same because of partial application.

Well, that way you don't even need partial application, right?

Cause like string dot two upper just takes one argument.

So I'll usually, that's true.

That's not exactly the same thing.

Well, but I'll start with an example like that.

I like doing that.

And then like a one argument thing, and then it'd be like, check it out.

It also works like a two argument function.

You just like leave out the second one.

So I admit it's not the strongest motivation.

I mean, like, you know, without going on a tangent about that, I mean, like I, my feeling

is that that's the main use case for partial application.

I know it's just like being a little bit more concise when you're using a higher order function.

Like that's, that's kind of it.

Separately you could go on a whole thing about like the pipe operator, like that works because

of partial application or at least the way that it works in L works that way.

Like Elixir and you know, other languages do it differently.

But the interesting thing to me is that well, an interesting thing to me is that if you

want to, you can go on like, well, this allows a lot of point free function composition.

Like if you don't have currying, it's a lot harder to do like point free function composition.

The thing is, I don't think point free function composition is a great idea in the general

And I kind of try to discourage it.

I actually periodically, I'm not kidding.

I forget that Elm has the like less than, less than, and greater than greater than operators.

Cause I just never use that.

Like literally never use them.

I just, I just pretend that they're not in the language.

And then I periodically remember that they're there like, oh yeah, I forgot about those.

I tried to do that too, because it always like hurts my brain just a little bit more

than it needs to at the cost of not declaring an anonymous function with an argument.

It's like just, it really doesn't save you.

It doesn't save you much.

It's going to hurt people's brains more.

And the second you need to like do something a little more nuanced where you need to like

add a let binding in there or whatever you need to do.

You can't do that.

You need to change to Lambda anyway.

For me, it's not even for other people.

Like when I, when I used to use it and I'd come back to code that I'd written in that

style, I'd just be like, what does this do again?

Let me just like inline the Lambda.

And I was just like, why don't I just save myself the trouble and just write it that

way in the first place.

It's weird because it's only a few characters different.

And one is so much harder to understand than the other one is weird.

Point free function application, like with the pipe operator, big fan.

Often I find it easier to read.

And you know, I don't know, I don't know exactly why that is.

Like you would think that like, I don't know, my brain or like, but also I, again, this

seems like one of those things where I don't think I'm weird in that regard.

I think most people are, seem to be that way in terms of what they find easier to understand

when they're reading it.

Another quirk in, you know, that people have learning Elm is, I mean, Elm is a relatively

small language.

Like the syntax is not that large compared to many languages.

And there aren't that many special cases of what things do, different ways of writing

But one thing that can trip people up is, you know, the constructor functions for variants.

So some, so you define, you know, type user equals admin with a record and, you know,

or you define a type alias user is a record with first name, last name.

And now wait a minute, is it a function or is it a type?

And it's both in the case, if it's type alias, it's both.

If it's a custom type, then there are things that live in two different spaces.

There's the type space, which you can use user, and there's the value space, bodies

of functions and stuff where you can use admin, but not vice versa.

And so Joël, how do you pronounce his name?

Jeroen Keneville?

Jeroen is my French translator.

But he's very deliberate also about teaching, and he was telling me that he sometimes introduces,

like, you know, if you're doing like a JSON decode pipeline and you start with like a

type constructor, he'll sometimes start with just an anonymous function that takes first

name and last name and creates a record.

Because it's just a confu-, and then he says, oh, you know what?

This is a little verbose, isn't it?

It would be nice if there was a shorthand for this, right?

So that's introducing that motivation.

And yeah, I really like that approach of, I think, I think this is a really good takeaway

for me and hopefully people trying to introduce people to Elm is don't be afraid to show a

non idiomatic way to do something, because it allows you to introduce fewer concepts

And then it actually gives you the opportunity to give motivation when you do introduce that

cool idiomatic technique.

So it's actually going to, to end up sitting in their brains better as a result, because

you gave them the motivation by teaching them the non idiomatic way first.

Yeah, that's exactly how I do it when I'm teaching JSON decoders and like the record

constructor thing is like, I'll first just make a, I'll actually use a named function.

I'll name it like, you know, make user or something, and it just does that.

And then I think it's like, usually it's the very last step.

It's like after I do the whole thing, I'm like, and also, by the way, you don't need

to write this make user function by hand.

You can just say user, and then that'll save you a little bit of time.

But the hard part is teaching the stuff leading up to that anyway.

So right, right.

And if you start with the motivation to like, I really enjoyed the Elm radio episode that

Yaron and I did about JSON decoders, because I think the podcast format is just a really

good format to talk about motivation.

And we could really dive into why, like, not so much how do you do JSON decoders, because

that part is actually not that hard.

What's hard is understanding, yeah, but why?

Why can't I just get the data?

And if once you understand that the rest of it makes sense.

Yeah, I, the thing that I find hard about it in a beginner workshop is specifically that

it's a lot of like higher order functions.

And it's a lot of concepts that people haven't seen before.

Like even if you try to do like the, like, you can start with not doing like JSON decode

pipeline, but starting with just like, you know, map two, map three, whatever for like

But like if you're doing JSON decoding, you're really gotta have records in there.

Like that's, I mean, like you could just be like, okay, we're getting a JSON payload from

You know, and like, you can do that, but people are like, okay, but what about a real JSON

Like the ones that we always see, it's like, it's always a bunch of like nested data structures.

And so you have to get into these, like, it's just a bunch of concepts all at once.

If you want to try and teach them the full, like, you know, parser combinators style of

like higher order functions and like how they compose together.

And it's just a lot like to try and like hit someone with all at once, especially in comparison,

like you said, to, you know, if they're, especially if they're used to just JavaScript and they're

not validating anything, they're just like, what about just JSON dot parse?

How about that?

Like, you know, so it's like a lot of concepts and it's a lot of advanced concepts.

And it's like, I mean, even with the motivation, it's just like the gap is so big that it's

just, yeah, it's just not a great spot.

That's also the part of it.

The compiler can't help you 100% all the way.

Like if you say decode dot field X and you make a typo, like, yeah, the compiler will

won't tell you, you will notice at runtime and the error is not all that great either.

Well, I think, so I actually really like, are you two familiar with cones or coins,

these little tests, you know, it's, there's like a small unit test suite and you gradually

get one by one passing and they're very simple examples.

And so people use them to like learn a language.

I created a little project.

I don't know if anyone uses it, but it's like a little, um, JSON decoders cones.

And I actually think it's a very good format for learning JSON decoders because you do,

you know, Hey, here's a string.

How do you do that?

JSON decode string.

Oh, it decodes.

Well, what if you wanted to decode an integer?

JSON decode in.

What if it might be no, and then, you know, you can, that sounds great.

And it's like, Oh, so you can piece together two decoders and then you gradually see it

building up in complexity.

So, I mean, it's sort of that idea of the, uh, what's it called?

The gradual release of responsibility.

You bring that up in, in your Elm conf talk, but there's this pedagogical idea of not flooding

every concept at once and having things that incrementally build off of each other.

And so I think cones are a very good format for that.

I totally agree.

That sounds great.

I mean, I think really the, if I could sum up what's, what's, what makes it hard to teach

them in like an intro course or an intro book, it's just that the amount of like you want

to do almost a mini course on it, you know, like building up just like, let's start with

Let's make a little bigger, a little bigger because there's just so many little variations

of things and yeah, but you don't really want to have like three chapters worth of JSON

Like one JSON chapter.

And that's right.

Cause otherwise it's just, it really takes the pace like really way off course of the

Brian Hicks actually has like a nice, uh, Jason decoding handbook, which I'll link to

That's like a nice little guide if anyone wants to do a deep dive on that.

But, um, but yeah, well Richard, I think we could like talk with you for hours just about

this one topic and there's like so much more we want to talk with you about.

Thank you so much for coming on.

Is there anything you want to share with people?

We mentioned Elm in action.

Are there Elm jobs at no red ink right now?

Yes, we are totally hiring.

And I can't believe I didn't find a way to work that into the conversation already.

We're we're I, yeah, it's wow.

Um, but since you mentioned it, uh, we're, we're hiring.

We use like Elm on the front end and increasingly Haskell on the back end.

Um, and we use Haskell in an Elm like style.

Like we, we, we call it like Elm flavored Haskell where we basically try to use Haskell

in as Elm like a way as we can.

We actually even ported over a bunch of the Elm standard libraries stuff to like Haskell

like HTTP and basics and stuff.

Um, and Elm test also, that's like our testing libraries, like Elm test ported to Haskell.

Anyway, um, we're big fans of Elm.

Uh, and yes, we have, I think still that we still have the biggest Elm code base that

I know of because you know, ours keeps getting bigger, but I know some, there's definitely

multiple, you know, hundreds of thousands of line Elm code bases out there, but I think

we're, ours is still the biggest, like close to half a million could be wrong.

Eurinia is doing his best to catch it up.

Turn that number down.

Trying to delete.

I mean, deleting stuff is great.

Don't get me wrong.

Yes, we are hiring.

Uh, so no red inc.com slash jobs.

And um, yeah, for anyone who hasn't done Richard's, uh, advanced Elm course on frontend masters,

definitely check that out.

If uh, if you're trying to point a newcomer to a resource, the intro course is excellent.

We could do a whole podcast episode about that type stuff.

I know there's, we, we didn't get into it, but I, you've got so many, so many great nuggets.

I, we should have just a Richard's nuggets, Richard's Elm nuggets episode just of all

the hidden gems you've got for these little Elm tricks.

Are these like chicken nuggets or like what?

Well, that sounds good.

I'd love to come back.

Well, thanks so much for coming on Richard and, uh, you're in until next time.

Until next time.