Evan Czaplicki Thesis Statement

02:27 – Evan Czaplicki Introduction

02:32 – Richard Feldman Introduction

02:38 – Elm

04:06 – Academic Ideas

05:10 – Functional Programming, Functional Reactive Programming & Immutability

16:11 – Constraints

24:24 – Compilation

27:05 – Signals

36:34 – Shared Concepts & Guarantees at the Language Level

43:00 – Elm vs React

47:24 – Integration

52:23 – Upcoming Features

54:15 – Testing

56:38 – Websites/Apps Build in Elm

58:37 – Getting Started with Elm

59:41 – Canonical Uses?

01:01:26 – The Elm Community & Contributions

Extras & Resources


The Pragmatic Studio: What is Elm? Q&A (Aimee)
Elm (Joe)
Student Bodies (Joe)
Mike Clark: Getting Started With Elm (Joe)
Angular Remote Conf (Chuck)
Stripe (Chuck)
Alcatraz versus the Evil Librarians (Alcatraz, No. 1) by Brandon Sanderson (Chuck)
Understanding Comics: The Invisible Art by Scott McCloud (Evan)
The Glass Bead Game: (Magister Ludi) A Novel by Hermann Hesse (Evan)
The Design of Everyday Things: Revised and Expanded Edition by Don Norman (Richard)
Rich Hickey: Simple Made Easy (Richard)
NoRedInk Tech Blog (Richard)


(Editor's note: transcripts don't do talks justice. This transcript is useful for searching and reference, but we recommend watching the video rather than reading the transcript alone! For a reader of typical speed, reading this will take 15% less time than watching the video, but you'll miss out on body language and the speaker's slides!)

Hello. I am Evan Czaplicki. I designed this programming language called Elm. And according to the website, it's a delightful language for reliable web apps. And I work at this company called NoRedInk, which is, as far as we know, the biggest Elm user. So they've got about 100,000 lines of Elm running. Any new code will be written in Elm. And in the year and a half they've been using in production, still no runtime errors. So that's pretty neat.

So day to day, I work on Elm all the time. And there's lots to say about the technical aspect of that. But I want to emphasize how storytelling influences these technical decisions and how design comes from trying to communicate with people. So when I think about storytelling, we start with people who don't care. They're living their life. And we start-- I start by observing some conflict. There's something out there that people are anxious about, or it makes them angry or whatever.

And from there, I try to find some shared language, some way to talk about that, that is productive and constructive. And then I try to tell a story about that. And finally, I try to create news so people actually learn about this story. And hopefully, at the end, that anxiety is resolved.

So let's observe a conflict. Say we see these two people talking. And so I wonder what they're talking about? And they're talking about types, OK? It's a sad situation.


Dynamic types are the best. Static types are the best. And instead of slowly backing away, you decide to say, ooh, there's an interesting question we can ask here, which is why is there disagreement here? Surely, if both people can see the same facts, they should come to the same conclusion. And so the root problem is this perhaps overenthusiastic person is thinking about their experiences with Haskell, and this person, who's a little lukewarm, is thinking about Java.

And so they're not seeing the world in the same way. So in this discussion, someone can truthfully say, types make me more productive. And another person can say, types make me less productive. And those two true things have to coexist with each other.

And so the root problem here, as I see it, is we have this problem of meaning. When someone says a word like types, they're really picking out an experience they had. So maybe they're picking out this experience where the first thing which they learned was Java, and all the things that are hard about learning a programming language for the first time-- forgetting semi-colons, not understanding for loops-- all those things get wrapped up in that experience. And so when you look back and think about how is Java different than, say, if you're using JavaScript now, well, it had types, and this doesn't. And there's all these problems I no longer have.

So that emotional content, those experiences, are what you're talking about when you talk about types. And for someone else, maybe a coworker of mine, she got hired out of a bootcamp, so only new JavaScript, and started learning Elm at work. And so for her, it's like, oh, this is pretty nice. It's not a complicated relationship.

And someone else, they learned about it at university, and they had a professor who writes these interesting academic papers and gives it this other dimension. And so that's what they think about. And all of these-- everyone out there has their own particular experience and background and meaning. And so the question is, who's right? What does this word really mean?

And it turns out this is an old question. So from my reading, the oldest answer comes from this guy Nagarjuna around the year 200. But there are more contemporary treatments. So you can look at philosophy of language, semiotics, postmodernism, media studies. A lot of people are concerned with this question. I am concerned with this question. This is my hobby, to read this stuff.

And so what I want to do is bring in an interesting work and see what it can tell us about design in Elm and storytelling, in general. So there's this book, Public Opinion, by Walter Lippmann, written in 1922. And he's primarily concerned with media and how people communicate with each other and what that means for democracy. And he also created the modern term "stereotype." So before this book came along, when people said stereotype, they are thinking of this thing, printing out the exact same image again and again and again, with no nuance and details that you might get from handwriting.

And interestingly, the French word for this is a cliché.


Anyway, what does Walter Lippmann have to say about static types and dynamic types? He says, useful discussion, instead of comparing ideals, re-examines the visions of the facts. So it may be that both parties in this discussion see exactly the same reality, but the difference is that their emotional experience of those facts is different. And that's where the conflict comes.

And so to have a useful discussion, you want to pick out what is that emotional experience, and what does that mean for people's understanding? So we can proceed by trying to find a shared language. That's how I talk about this kind of stuff.

So let's start with a true statement, I think a weak statement and one that I wouldn't say about Elm in general, which is that Elm has a sound type system with full type inference. That's a true fact.

And so I think a useful and valid vision of this is, yeah, who cares? So what? And when you think about the sentence, the actual content, useful content, it's very low, right? So for someone who's new to programming, they might say, well, what's a type system? I'm not really sure. And with a sound type system, that doesn't really make any sense to me. And well, type inference, I'm not really sure what that was, in the first case. And if it's full or incomplete, I don't really know.

So basically, the sentence is, Elm has a thing with some stuff.


And so that statement so what, I think, is the correct answer. So one thing I try to do in my communication is be concrete I never want an audience or a user or a reader to infer the benefits. I want to just say, here's what the benefit is. So let's try to do that with this factually correct statement that is not communicating my emotional experience.

So it catches errors at compile time. This is a factual statement. And so someone from JavaScript might look at this and say, OK, but now I'm going to have a slower development cycle. That doesn't sound good. And I bet the error messages suck. So this also doesn't sound good. So I now will have runtime errors, which give me these stack traces, and this new, other kind of error, that I didn't have before, and doesn't give me any context about how it works. So this sounds like a strictly worse experience. OK, fair enough, fair enough.

So maybe I can say, so this is where it's questionable. I can say, well, they're better error messages. It's not about when they arrive. It's about getting experience where it's clearer, and you can fix it more quickly. And division of this would be, yes, says who? Who-- well, you say it's better. Obviously, you'd say it's better. It's your thing. On some level, I have a lack of authority on Elm because of this.

So let's try a different direction. So I could also say, you don't need any type annotations in Elm. You can get all the benefits, but you don't have to write down any types. And for a JavaScript person, says, I already don't have to write down types.


All right, so you're offering me all the complexity that I never asked for with all the convenience that I already have.


OK? This is a weak, a weak pitch. So let's try a different direction. All right, another implication is there's no runtime errors. And the reaction here is wait, is that possible? Or to say it more clearly, are you a liar? I think that's the subtext--


--when I say that kind of thing about Elm. But I really like this. So in a sense, it creates a curiosity about the project. Like, is that technically feasible? I'm going to go fact check this guy. And ha, ha, ha, now you're trying it out. Hopefully, you like it.


But it's also communicating my emotional experience, right? So when I learned Standard ML, which is in the same family of languages, as Elm, I had this experience of already enjoying programming, but having this special kind of joy of writing big programs and changing it, and it feeling really pleasant. And by saying the same thing in a different way, I've communicate that emotional content in a way that translates across communities, where words don't necessarily mean the same thing.

So once you've found some shared language, that's great. But if you don't tell anybody, who cares that I found that phrase is fine? So the next step is to tell a story. And Walter Lippmann has some tips for us. So first is on visualization. So any description in words requires an effort of memory before the picture exists in the mind. But on the screen, the whole process of observing and imagining has been accomplished for you.

So again, he's writing in 1922, and seeing the rise of moving pictures. So as a reader, you're like, just thinking about that reality, where, on some level, he sees the power of this new kind of communication that's more powerful than radio and books or images, and also sees the risks. So another tip he gives us is about context. So no visual idea is significant until it has enveloped some stress of our own personality.

It's not enough to show the image clearly, but it has to be relevant to my life. So if I walk through a park every day, there may be a bench there, but I don't know. But on the day where I have a rock in my shoe, that bench is going to be really important to me, and I'm going to want to tell my friends about it, or something. I don't know. It will be important to me.


So I want to explore a particular story that we told in Elm that has worked well. So it's that we have friendly error messages. So we do this primarily with a visual. So if we look at this, you can look at lines 3 through 6. There's this problem with this if. If it's less than 0, then I say the string negative. But otherwise, I just give back the number. And so the same expression can produce different kinds of values, and people who use this function may not know how to deal with them.

So we've visualized the benefit of our type system. And the emotional content here is this experience people have of, why is this code crashing? So you're at work. You find some undefined is not a function on your console.

And maybe 10 minutes or 20 minutes or 2 hours or the next day, you figure out the root issue was someone wrote a function over here. And if the string is longer than 80 characters, then it's undefined. But this function forgot to handle that scenario. And if it's actually less than 10 characters, then it's a null. And this function forgot to handle that. And then, in combination with this particular string, you're going to get a crash.

And hunting that all down is rough. And in this case, we can say, oh look, this function it's giving back a string sometimes and a number some other times. You have to handle both cases explicitly. If you do so, then you can proceed.

So it's not just this day-to-day concern, but behind this question of why is my code crashing, is a question of am I good at my job? Why is my company paying me all this money so I can sit here and not know what's happening all the time?


So there's actually quite a lot of emotional content here. And it also addresses this idea that types are [? lame. ?] This is a thing that-- this an idea that exists in the world. And when I show a visual story like this, you at least have to account for this story, right? So you may still think types are [? lame, ?] but now it's like, well, but they do give you these error messages. And that goes into this equation.

So this story's doing double duty. It has emotional content. It's addressing a broader concern about the style of programming in Elm, and it has a very clear and visual story that you can go test out and play with.

So once you have a story that you think is nice, you've got to create news. Just having a story is no good. If I write a book and put it in my drawer, it's not going to have a big impact. So Walter Lippmann has some tips for us again. Before a series of events becomes news, they usually have to make themselves noticeable in some more or less overt act, generally to a crudely overt act. And he goes into an example of a businessman who mismanages his money, and for a decade, people know. But it only becomes news on the day that he files for bankruptcy, because you have that actual event where it becomes a newsworthy thing.

So in programming, things are a little bit easier for us, because releases are news. We have this built-in mechanism, where everyone in your community, and even in other communities, is going to look and say, oh, what's going on over there? And in Elm, I use this technique called batching, which I think helps create stronger stories for each of these releases.

So in a typical project, someone will open an issue. And the ideal is that it gets resolved, open issue resolved, open it. And so you're optimizing for latency. How quickly can I respond to everybody on the internet who has things to say to me?

In my projects, I use a different approach, that I think is controversial. But it works well, in my opinion, which is that someone opens an issue, and we say, OK. And someone else opens another issue. And over time, we let these build up. And we do a more high level analysis of all of the concerns people have. And so when you look at them holistically, you can find one fix that addresses all those concerns in a way that's clear.

And I think this, in the end, leads to better design. But from the perspective of storytelling, it also means you have a stronger narrative. Each release is about-- we did this work on the compiler. Elm has an emphasis on developer experience. You get a broader narrative than 40 things happened. So I always am sad when I see a language release, and it's just a list of 200 pull requests which were merged in. It's like, OK, but what happened?

So I want to show this process on what I'm working on at the moment, which is single page apps. This is a term that I think needs to be in quotes.


So step one, observe a conflict. This is easy for me to do, because people just yell at me about stuff.


So people come from outside. How do you do this? If it doesn't have this feature, then it's not possible. People within Elm are just like, I'm not sure how to approach this. And a lot of people think, well, if Evan just got around to writing the docs, it would be clear, or writing this feature, where we basically just need a object-oriented language, and we'll be fine.

So once you see this conflict, it's trying to find some shared language. So things people talk about when you dig for the details-- what are they actually referring to. One is tree shaking, which-- I hate almost all these terms, the idea of shaking a tree, and like-- but good parts might fall off, too. I don't know. This has a name, a dead code.

Anyway, people talk about code slicing. So how can I cut up all my assets into smaller pieces so that I can serve them at the right time? There's lazy loading, so once I've cut them up, how do I make sure people get them when they transition from page to page? There's server side rendering. There's routing. So when people transfer between pages, you want to handle that properly.

There's multiple pages. OK, if I find this very interesting.


OK, there's something weird here. So when I look at this, I think about it in terms of asset management. The root concern here is, how can I get people their content quickly, and how can I minimize bandwidth, get the pages to load? So I want to think about it in those terms.

And so the next step is to create a story. So for me, a story isn't some word that's not rhetoric. It's how can I take my-- what's the story I want to tell, and then what needs to be true technically for that story to make any sense? So step one of this is implement all these features. We need that code elimination, da, da, da, da. So I'm working on this kind of stuff.

And the broader goal is to address this concern of, is my site fast? Which branches out into these broader questions, like why am I having a hard time? Am I good at this? And so right now, it's in the technical phase. I know the story I want to tell, but I need certain technical things to be true. And so the point is that those technical details are in service to a story I want to tell, not for their own sake.

Yeah, so when we come back and look at storytelling overall, I think this process, it's not anything particularly-- there's not a recipe. Walter Lippmann isn't giving a recipe for this. I think anyone who has a knack for communication will find these pieces and consciously or unconsciously perform this process. And so what gives this process ethical and moral character is how people use it.

And so in my case, I have this joyful experience using Standard ML, and I thought, if I can have this kind of experience, I bet people who are learning programming or struggling with a project or getting alienated because they're struggling in some sense, they could have this experience, too. So the goal is to take some anxiety, some conflict, and actually resolve it in a nice way.

For Walter Lippmann, he's actually interested in media and how people communicate, and implications for democracy. But you can see this process in advertising and in politics. And often, you take a fear, with no intention of resolving it, just an intention of stoking it and using it to guide people. So the moral character of this is quite interesting. And so if you're interested in that aspect, I recommend checking out Public Opinion.

But there's also this documentary, if you want to watch things rather, the power of visual communication-- Century of Self which gets into a guy called Edward Bernays, which will tell you a little bit more about the dark side of this process. And if you're interested in Elm, you can check out the website. Or I talk about it on Twitter, and I'm low volume. So hopefully, this gives you some insight into the process behind Elm features and gives you-- stokes your curiosity in an interesting field of study. Thank you.


Categories: 1

0 Replies to “Evan Czaplicki Thesis Statement”

Leave a comment

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *