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.
November 8, 2021


Hello, Jeroen.
Hello, Dillon.
And finally, it's been a long time coming here, but we've finally got Richard Feldman
on with us.
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.
Wow, thanks.
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
to you.
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
to teach them.
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
dislike even.
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
do that.
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
is that way.
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.
That's true.
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
a long time.
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.
Got it.
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?
Or like,
I'm, I'm very glad that it seems that way.
I just have a good memory.
No, no, no.
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
this problem.
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.
That was it.
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
on that.
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.
It's right.
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
to solve.
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
good examples.
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
it again.
But I think I still would have wanted to do it once just because I've never read a book
that did that.
And I that was like, I don't know, I'm an ambitious person.
I wanted to see like, can it be done?
Like, why not?
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?
I don't know.
I hope so.
For reasons, but okay, cool.
That's good to hear.
The whole book is amazing, I think.
Thank you.
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.
Thank you.
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
in some way.
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
on here?
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.
I don't know.
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
at once.
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
and floats.
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
want to be?
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
to a tangent.
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
M. Oh, sure.
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.
But it's fine.
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
like that.
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
each time.
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
how to teach.
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
about that.
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
right now.
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
of some code.
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
do this.
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
helping them.
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.
And that's it.
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.
Oh, yeah.
Try again.
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
in action.
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.
Yeah, yeah.
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
message thing.
I get why.
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
a lot.
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
or whatever.
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.
I don't know.
It's probably right.
All 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 knows?
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,
got it.
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.
Okay, got it.
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.
Funny, huh?
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
for this.
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.
Let's move on.
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?
Oh yeah.
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.
It's for me.
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.
Now I get it.
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.
So yeah.
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
at once.
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
the object.
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
the server.
It's a string.
That's it.
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
a small one.
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
whole course.
So, right.
Brian Hicks actually has like a nice, uh, Jason decoding handbook, which I'll link to
as well.
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.
Oh yeah.
Trying to delete.
I mean, deleting stuff is great.
Don't get me wrong.
Yes, we are hiring.
Uh, so no red 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.