This interview was recorded for the GOTO Book Club. #GOTOcon #GOTOBookClub http://gotopia.tech
Richard Feldman - Author of "Elm in Action" Thomas Anagrius - Lead Developer at Humio
DESCRIPTION Elm is a purely functional language that compiles to JavaScript in less than 4 seconds. We sat down with Richard Feldman, author of the book Elm in Action to understand how learning to code in Elm can help software developers whether they work with it on a daily basis or not.
TIMECODES 00:00 Intro 00:50 Series introduction 01:11 What is Elm? 02:33 Will Elm take over the world? 05:31 Move away from the dependency nightmare 08:17 Why does Elm seem hard for beginners? 12:14 Benefits of using Elm in Large Organizations 15:33 Benefits of functional languages 18:45 Elm CSS 24:07 What does the book help you with? 30:15 Modeling with Elm 33:22 The seven takeaways
34:46 Outro
Read the full transcription of the interview here: https://gotopia.tech/bookclub/episodes/upgrade-your-frontend-game-be-an-elm-wizard
RECOMMENDED BOOKS https://www.manning.com/books/elm-in-action?a_aid=trifork&a_bid=a11d59e7
https://twitter.com/GOTOcon https://www.linkedin.com/company/goto- https://www.facebook.com/GOTOConferences #Elm #ElmLang #Humio #FunctionalProgramming
SUPPORTER This episode of the GOTO Book Club was possible thanks to the support of Humio, the only multitenant solution that enables organizations log everything to answer anything in real-time — at scale, self-hosted, or SaaS. Humio’s modern architecture enables complete observability to answer any question, explore threats and vulnerabilities, and gain valuable insights from all your logs in real-time. Humio’s frontend is developed in Elm, a functional language selected for its strong emphasis on simplicity, stability, and speed, which are all important capabilities in working with large data volumes in real-time and with high user interactions where data is being continuously explored. Humio offers low total cost of ownership and unlimited plans, with easy deployment at any scale, self-hosted, or SaaS. https://www.humio.com
Looking for a unique learning experience? Attend the next GOTO conference near you! Get your ticket at http://gotocon.com
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily. https://www.youtube.com/user/GotoConferences/?sub_confirmation=1
We've held a lot of go to conferences across the world and collaboration with some of the top creators and innovators within software in this brand new go to book club. Give you key takeaways from the Masters themselves in the form of interviews revolving around books. They've created their own strategies and to become a more efficient developer. As we dive into the first of my series of our Go to Book Club. This episode was made possible thanks to homeo humor as the market leader in real time logging and analyzing data, basic humor dot com. For more. Welcome to another episode of the Go to Book Club. Earlier today, we had a wonderful conversation with Richard Feldman and Thomas and Agnes. Richard is the author of Alman Action. Thomas Sloup, developer at Fumio and one of the very first and early adopters of em. We kicked off the conversation by asking Richard, what is Elm and will it eventually take over the world? What is L? So Elm is my favorite programming language. It's it's a language for building web apps, building web you eyes. So specifically like building you eyes in the browser. And generally it's used for building web applications as opposed to for example, just adding a little bit of interactivity for a static page. So Ellen compiles to JavaScript so you can use it instead of JavaScript. Also, it has JavaScript Interop. So if you want to, you can use it in conjunction with JavaScript. The most popular way that people introduce Ellum to an existing code base is that they will start off with an existing JavaScript code base and react or angular review or something like that. And then they'll introduce just a little bit of elm and then see it grow and grow and grow. And then maybe eventually it sort of shifts to where there could be it becomes Majority Ellum and then eventually, you know, almost all or entirely all L. That's what we did at my job back in 2015. And so now, five years later, we have somewhere around 400000 lines of code and very, very little, almost no remaining legacy JavaScript code. So a little bit. So, yeah, it's a it's a type cheque's language. It's purely functional. And it's it's got a lovely user experience I think will eventually take over the world. That's a good question. Personally, I think that Ellem will become popular, but not the most popular. I think it's it's sort of seen as slow and steady growth, kind of like Python did. So Python came out in like the 90's, but initially it was not a very widely used language, is it's kind of slowly and steadily grew. And then it became used in more and more different domains. And then eventually it became quite popular. Now it's it's sort of among the most popular languages. But I think when it comes to building applications in the browser, it's going to be it would take something really serious of a change for something that's not a JavaScript dialect to, like, take over the world, as it were. JavaScript says so much momentum. Having said that, for me personally, like having spent a lot of time with L now I just can't imagine myself taking a JavaScript or typescript or coffee script job ever again. It's really just I mean, if I'm building a Web app, I'm doing it l and I think that while also thinking that L was not going to take over the world because as we all know, popularity is determined by a lot more things than just sort of technical merit. So I think it's it's a great tool for me to use and I'm very happy to teach it to other people. But at the same time, I don't think it's going to be number one in terms of popularity. That's my prediction at any rate. Well, maybe comparing it to Python is not the best comparison either. Right. Because that's a general programming language. Whereas Elm and that's I think that's one of the really big strengths for Elm, is that it was tailored to doing Web applications. That's very true. Yeah. So I think you're right. I don't think it's going to take over the world either. I think that it's a somewhat niche language. It's focused. It's very focused and it's very deliberate and it's very opinionated in in how it does things. And I think the very popular things that you see out there are more, General. Right. Yeah. They have sort of a broader scope. And I think a big part in the like on the Web platform is that JavaScript is the assembly language of the web. Right. And as long as it will remain that people are going to write in JavaScript or share things that are close to it, because there's just there are so many benefits to just being able to run the code directly in the browser. You don't quite get that knowm right. You are quite far removed, actually, when you execute the code. The code that's being executed from what you write. Yeah. I mean, that's something I like about it, is that it's sort of an escape from JavaScript to TypeScript and that whole ecosystem and all the the complexity of it. Definitely. I mean, what one of the things that struck me a couple of months ago is that we have at Fumio, we have a code base of, you know, a hundred thousand plus two hundred thousand lines of code. And we have like 12 dependencies, you know. And yeah, yours being some of them, like on tests, for instance. Right. But that's nice. Yeah. But in a similar JavaScript application, you would have hundreds of thousands probably of you that I'm not even I'm not even joking that right there, which is the out of it. And I mean personally. You know, when things go wrong or when when I start to hack in my code is usually because I hacked. I need to hack around something that comes from a dependency. Right. So when when is your own code? You don't really need to do that. And sure, it's it's a little bit more effort, but in the long run, it's worth it. Right. Yeah. I mean, I would take that on a case by case basis. I mean, certainly some some packages that I get, you know, are really valuable. But yeah, definitely there's a cultural difference where in l I think you don't get this micro package thing that you see in the NPM eco system where people write, you know, left pad being the most famous example of that, where you have this like it's like a one liner that someone made a package out of. That doesn't only happen in Elver, at least not from what I've seen. Andy, I appreciate that. I would if it's just a one liner, I'd kind of rather write it myself and not have this ballooning explosion of dependencies. I think we I don't know if we've quite crossed it yet, but we're very close to 400000 lines of code at work. And we still have under 100 total dependencies like direct dependencies as well as their dependencies like you, out of all the dependencies we download on a clean bill, that's less than one hundred. I think that's yeah. That's that's normal for L. It's you don't really see that same explosion of dependencies, which is kind of funny because considering you've got Elm's dead code elimination, that's like so much better than what's possible in JavaScript, you would think the downside of getting more packages would be less like you don't because you don't pay for it in terms of comp. asset size. And yet, like we have, we have that great benefit, as well as not having to deal with the, like, mental complexity of having so many dependencies to keep up with. Take away number one, Elmas, and escape from the complexity of the JavaScript ecosystem, having a significantly lower number of dependencies. I think it's also it might also be one of the things that it's a little bit scary about them, because for new people like I often encounter encountered people when when they're just starting out now, they say, well, like, why is everything so hard? And of course, I don't I don't think that they're so hard. If something is new, then, you know, of course, it's it's unfamiliar. It's by definition harder than what you do. Yeah. I think that there's more than that, though, right there. Elmi is a very, as I said before, opinionated in how it does things. And it's very restrictive. You can't just go out and touch the dom willy nilly. Right. True. And like you're used to in JavaScript. So. So getting these or hitting these roadblocks can I think is a source of frustration for people because you don't understand it. Right. As you said, one of the motivations for writing the book is giving people a beginners in particular, a way to understand how to not just, like, learn the syntax of the language and the concepts behind it, but actually like learn how to build things with it. Because like you said, I mean, it is different from what you're used to if you can make from a JavaScript background. And hopefully the book has made it easier. Yeah, so. So in the book you take people from, like, learning the basic syntax. Right, because it is not a C family language. Right. So true. So yeah, the syntax is quite some would say exotic, some would say arcane to to what people are used to. And that can definitely be a factor as well. It's such a simple language at the same time. It is. Yeah. I mean I would say the syntax is closer to Python than JavaScript, but it's also not quite the same as Python either. I mean, in the sense that you have, you know, fewer parentheses, for example, than you do in JavaScript or maybe even Ruby, actually. But there are definitely differences. Yeah, but syntax really is, in my experience. I mean, I've I've taught workshops as well as like online courses for Front and Masters and the book. And it seems to me, based on my workshop teaching experience, that syntaxes is actually the quickest thing that people get. You sure? Yeah, exactly. It's more the way of interacting. That's what I meant. Right? That you did. Yeah. Yeah. Go. I wouldn't touch the DOM. You do things in a very strict manner and in very strict order. And I think before react you got really popular. Like the virtual Dom thing was was a very unusual thing. I think now people are more familiar with that. And maybe even that's you know, that's the most common thing I would say that people are used to. But yeah, like you said, the difference is that that's all you've got. Right. That's that's the only way to do things. There is no, like, alternative fallback. You know, all of you just reach out and you take this one thing. I mean, yes, you can do that with JavaScript Interop. But that's not till what? Chapter five. I want to say the book like halfway through. But yeah, I mean, that that's that's considered very normal in JavaScript to be able to do that whenever you want. And an Ellum. That's a very advanced, you know, like you need to learn several different techniques before you could do something like that. And it's of course, strongly discouraged. It's it's not like the language doesn't want you to do that. The language really wants you to, you know, buy into the, like, virtual dog concept and use that as as your exclusive way of rendering things. But if you do, you get all sorts of benefits. So it's like restrictive. But there's a there's a lot of benefits that come from those restrictions. They're not sort of arbitrary restrictions that. Right. It's a very good purpose. It's about getting people to appreciate what those benefits give you. Right. So we just hard to see when you're just starting out. Second, take away. The book teaches you the language syntax by focusing on building things. At my company, you know, we were a lot of developers with a big code base, and it just I'm never afraid of breaking the code base because I trust in compiler. I trust. Right. If it compiles, it works. And that's something that's a feeling that you don't. Security, sense of security, you don't really see, even in others strongly typed languages. Because they allow you to do like escape that safety. Right. Right. Really. Right. People ask me, like, well, you know, what's the difference between Elm and TypeScript? Is Elm just like, you know, a typed language? Will TypeScript Scott types, you know, what's the difference? And one of the easiest differences to point to and maybe the biggest one is any like in typescript you have any which is this escape hatch. That means that any possible types could be a lie. And you actually can't it's not achievable to have the same level of trust in typescript as you do in Elm. And that sounds like kind of an abstract thing. But like you said, I mean, the real benefit there is this feeling of like invincibility of like I can make whatever change I want and I'm not like once I get it to compile again, it's probably going to work again. And I've gotten so spoiled by that. I like like you said, I mean, we have this huge code base and we just make big changes to it whenever we want to. Like, if if we think that the code is going to be better, if we reorganize in a particular way, we just do it. Then we follow the compilers until it works again. And usually, I mean, we don't even need to change tests unless, you know, there there are also corresponding type errors in the tests. But it's not like we we need to, like, lean on handwritten tests to give us that same confidence. We do have tests, too. But but the compiler is like 90 percent of what's getting us back there. And we don't even have to write that code. It's just, you know, the compiler just did it for us just because we're using l like the amount of, like, code cleanup that we can do. And it's like such a faster speed has really been for me, just just something that I can't imagine giving up again. Like the ability to just say, like, I want to clean my code up in this way, I'll just do it and it'll be fine. Whereas I know that even other typed languages, I've used a lot of cases. I'm like, well, if I change it, is it gonna work again afterwards? I going to cause a bunch of regressions. I just never have that fear and l especially when it's someone else's code. Right. Oh yeah. Absolutely right. Yeah. I mean we have, you know, coming up on one hundred employees at the company neurotic where I work and like, you know, that's not a huge number of people. I mean, you know, as long as the companies have thousands and thousands of employees. Yeah. I mean, I don't know, you know, necessarily like if any of my co-workers are even aware of the code that I'm writing and I may not be aware of the code that they're writing. There's like parts of the code base that I haven't even seen before. Take away number three. The compiler ensures that no one breaks the code base, which is a great help in large development teams. Visit Fumio dot com and start your free trial. Today. Lock everything and answer anything in real time. That's a good point. It's one of the things that like the in in functional languages. One of the key differences, I think, is that what you see is what you get. What what you're looking at right now is what's going to happen. Right. It's you shouldn't be afraid of changing something in the invoicing part of the code. And it all of the sudden breaks the carousel on the front page. Right. Because because of side effects. Because there are none. When everything is a pure function, then that is such a game changer for large code bases, I think. Absolutely. I mean, I usually don't mention that one when people ask about events. I mean, Elman typescript, because it's it's a little bit harder to explain. But yeah, I've really felt that one when I have been comparing element rust. So rust. I've been spending time with as well. And I like it a lot. There's there's a lot of great things about rust, but the the refactoring ability is just not on the same level as what I get an elm. And it's like you said, it's because of side effects and mutation. Like Rust even has a first class concept of mutation tracking and they don't have any which typescript does. And it was a typed language from day one. So like the whole ecosystem is, you know, is typed. So in those ways, I would say Rust's type system is a lot more reliable to me than the type scripts. But even with that, I've still had bugs where I took some rust code. And I just habitually because I can do this and Ellum without any concern, I'll just rearrange the order in which things are happening. I'm like, oh, actually I think it makes more sense to like call this and then call this and then call this. Or I did some other refactor that resulted in code being in different places and it didn't work anymore. Afterwards it was broken. And I was like, why, why? How could this a broken cause, an elm. Yeah. Like you said, when you have the guaranteed it functions on have side effects, you really had to raise them. However, you want to make the code nicer and and really have the full expectation that it's going to work again afterwards. But even in rust, that has not been true for me. I've definitely broken stuff just by reordering it. Or isn't it. L like yeah, that's weird. It's fine if it compiles again, it's going to work and it almost always does to almost to a shocking degree, you can still code the wrong thing. Right. You can still code the wrong thing. But it's your work. It's not a hundred percent. There's, there's, it's not possible to guarantee that if it compiles it just works. But it is just ridiculous how often it is. I mean, it's it's certainly most of the time and it's like I don't know what exact percentage, but it feels like it's like in there like 80 percent plus range, you know, that like when it compiles get like to the point where if it compiles, I just expect it to work. And if it doesn't work, I'm very surprised. I'm like, what have it. How did this compile and then not work, which is a hard feeling to convey because it sounds so ridiculous at face value. I mean, if you if you spent a lot of time programming in other languages, I mean, that's that's not normal. Take away number four functions. Done right? Don't have side effects if it compilers expect it to work. One of the interesting things is that for for our application, whenever we have books, it's usually due to CSF because we don't own CSF. And yeah, maybe you can talk a little bit about what that is closer. Yeah. So LCROSS is a library that I made we use at work, although honestly I feel like every time I bring up LMC as us, I need to make a plug for Elm UI, which I kind of wish we were using at work, except that we just have so much legacy CSF. It's, it would be only about an object to convert to it. But Elm UI is one of the most beloved and like most popular Elm packages. So Elm UI is it was made by Mac Griffith and basically it's a CSX alternative where basically it's a way to do layout in the browser without even knowing CSX. Like you don't have to do any. No CSX concepts. Not no flex box, no grid, no float, no any of that. It's just a complete ground up scratch rewrite of like a layout system that works in the browser. And the way that it works is, of course, the behind the scenes compiles to see SS in the same way that Elon compiles the JavaScript. But the point is it has a completely unrelated set of primitives. And so some of the funny things are like I saw actually on Elm discourse. I thought it was yesterday. Somebody posted like, hey, I'm entering the job market. And one of the concerns that they listed was I got into frontin web development and I'm learning Ellem and I know Ayumu I but I don't really know CSX. And I'm kind of concerned that that's that's going to, you know, be like make it difficult for me to get a front end job because most places, you know, do you CSX? But I love that implication. It's just like. Yeah, like if you know LMB, why? It's like, yes, this is a lot harder because we had a big react code base before we started using Ellem. We we have legacy CSX. And so we sort of incrementally move that over to LMC. SS so LMC SS is I guess it's it's similar to what it was originally styled components I think was the one to react, but I think there's new names for it now. I think there's one that's more closely resembles the LMC, SS, UI or API. But I forget what it's called. I want to say it's emotion, but I might be misremembering that I've been like kind of out of the jazz world for so long. Edit other Dave's the things that he work. But the basic idea is that it gives you a way to do type checked CSX in your in your front and code. And it also you don't need to have a separate cyle sheet. So I can basically just add an attribute to any of my HDMI values, any my elements that that just sets CSX. And then the CSX attribute takes a list of typed CSX properties. So, for example, if I want my button to have a one pixel border, I can just say CSX and then square bracket, because you give it a list of of all the attributes that you want. And I just say, like, you know, border one, pixel solid, bubble one. And if I mess that up, like if I, if I mistype something in there, then I'll get an error. Compile time and then it behind the scenes will automatically generate a class. And then there's like a hash of the old styles in there and then reference tab and so on, so forth. So yeah, it makes things a lot easier, but it is at the end of the day, still fundamentally CSF. So it's sort of a way to make CSX nicer. We have I counted at some point it's like six hundred and somewhat different, like typed CSX properties in there. So it's not like the entire hundred percent of the CSI aspect, but it's you know, it's a lot. Whenever I see people complain about TypeScript Comp. Times, I'm like, what's that? What's what's the long compile time? So it's funny you said that because one of the reasons so we went for, you know, having everything in home is is quite a benefit. Right. Yeah. Like thinking about thinking about your application is not just the behavior, but also the way it looks because you can't really separate the two. Right. Yeah. In a Web application. But the at the time, which is now several years ago, the compile times were so excruciatingly low. Yeah. That it just it wasn't feasible to you know, you wanted to see how does this look when it's has a rounded corner and you have to wait the 80 seconds or something like that when you get to a certain size. It's not like that today, right? It's like a second. So yeah. Yeah, like twenty seventeen l compile times. We're not great. I think that was like everyone's favorite release of like the people who are using Ellem today but who are also using it like twenty seventeen like the one that just made the compiler just ridiculously fast. Yeah. I mean yeah that was a total game. We went from like two point eight, six minutes to four seconds for. Right. And that's like that's, I guess, a scratch build, right? For a seconds. Yeah, because, like, incremental compiled times are usually subsecond. That was a nice Reles. Take away number five Elm UI. It's one of the most beloved and most popular Elm packages. It is a way to do layout in the browser without even knowing s. Getting back to the book, the amount of code that you end up writing in the book, even though it is one application like starting in, so chapters two through eight are all about building one application. So like chapter one is just basic syntax. But then throughout the rest of the book, it's all about building an application from start to finish and then each chapter you like at the beginning, you get sort of feature requests from your manager and then you implement that feature requests over the course of the chapter. And then in the course of implementing that feature, you learn about the concepts necessary to do that. And the entire time, I think unless you have I guess I haven't tried I don't like a Chromebook, but I would expect it all compile times, like for the entire book would be less than a second. I'd be surprised if if someone's machine took more than a second to compile something. It's it's one thing that that struck me about the book is that it is really a journey from from absolute novice to being able to write a fully fledged single page application. Right. Where you even cover things like web components, like what you said before is that using JavaScript and so on is a big no no in Elm, or at least you're discouraged from doing it. Discouraged? Yeah. Why would you do it anyway? And how does that work with web components. Yeah. I mean so so Ellem has JavaScript Interop, but it's generally speaking, it's a fallback. It's not the it's not intended to be something that you use all the time. It's just like, you know, if there's something that you need, like there's a particular like there's one very specific JavaScript library and there's no el equivalent library of that thing, then, you know, if the alternative is like, well, we'd have to write this whole thing from scratch and elm, or maybe it's something where L doesn't have first class support for that like Web RTC or something like that then. Yeah. You know, you do JavaScript Interop for that. But the idea is that, you know, I think most people want to have a ratio of like ninety nine point nine percent elm Dilek point one percent JavaScript and their code base or typescript or whatever it is. It's not like you have like, oh, it's, you know, 70, 30 Elm JavaScript. It's like now that it's very much like that for us as well. The things that we use JavaScript interrupt for is so we're a log aggregation management platform, right, where we visualize people's log. So we have like live charts and Ellen didn't have a fully feature. Rich featured charting library. So what we could do then is use a Web component and just plop things in there and just wrap this little Web component as like a micro application running inside of our home and talk to that through a type safe API, which is just fits in perfectly with Elm. Right. Or as close the as close as you can get to it without breaking the model. Yeah, totally, yeah. The analogy I like to use is that talking to JavaScript is like talking to a server in the sense that you're sending immutable data, just sending messages, very much of that feeling. Yeah. And that's why it's actually the chapters are titled That Way. So I think it's chapter four is called Talking to Servers and the Chapter five is talking to JavaScript. And the reason the titles chapter titles are that way is because they're so similar. So you look at the concepts of like, here's how to talk to a server and then the next chapter, it's like, OK, now we do a very similar thing, except instead we're talking to JavaScript back and forth. I guess that's that's how it is with ports. But then with Web components. I've talked to people in like like I know people like the reactor team and the core team, angular and ember. And when I talk to them about Web components, it seems like El Muse's might be the biggest customer is a web components or specifically custom elements, and specifically just for JavaScript Interop, because they're so convenient for that, because in that case, if you're if you're rendering something and you want to be like, oh, I want to take this JavaScript widget of some sort, like I have a I don't know, like embedded calendar or something that I really like or like this. There's an visualization libraries. There's a lot more a lot more robust now than they were choice of a team. But then there's also, like, you know, calendar of date, picture type things. But let's say there is some JavaScript thing that you really want a Google map. That's a good example. There definitely is not a you know, L. I can't imagine any whatever exploit all the trouble of like, do I get a. Google Maps and pure l be very impressive. I actually think there was an L Europe talk a couple years ago about doing a like a pan and zoom type map, but it's not like the full featured, you know, map thing. But if you want to embed one of those. Yeah. I mean, the way that I would do that is with a custom element. And yeah, it's really convenient for that. And the other book goes into how to do that. I used both a custom element and also ports in the job search interop chapter because I think they're both useful techniques to use it. You use it for different things like custom elements or more for visual things, whereas if you need to just talk to a JavaScript library, it's gonna do some calculations or whatever or some sort of like a common thing that people will do is if they've got like an analytics provider, like rollbar or bug snag or something like that, that provider will provide some JavaScript library that just automatically does all the correct talking to their server thing. People just talk to that out of a JavaScript port rather than writing it all the specific reverent like there's a couple of wrappers like Elm, Elm, like entirely elm wrappers to look for, like bugs, nag and rollbar. But I don't know about that. There's a lot of services out there. They probably don't all have a pure elm implementations. Take away number six. The book is one big Hands-On example, building a complete application from start to finish. Visit Fumio dot com and start your free trial. Today. Lock everything and answer anything in real time. One of one of the biggest takeaways, I think, that I have from you. Thanks. So if I if I were to never touch Elmo again and I think I still think I would if I still think I've benefited from being a home developer because the focus or the the way that I write home is I start by modeling things. Right. Really modeling the problem. And I don't think that I've ever done that in any other language or platform. And I think I wonder whether that's because of necessity or because why that is. That's a good point. Yeah. Yeah. Just like getting getting the data model. Right. Like getting getting the data. Yeah. And in Elm it is so beneficial to, you know, the the the famous phrase make illegal state unrepresented. Yeah. It but it's, it's not just for Ellem. Right. It's something that you go into Java and you can do exactly the same thing and get exactly the same benefits, but you just don't feel the pain as much if you don't do it. And I think that's because you, you know, you have to handle every contingency. Right. If if your model allows you to both have a field, says you got a server error and another where it says here's the successful data. Right. Those two are incompatible. Right. You've got to remember to handle the failure possibility. Yeah. The compiler tells you about edge cases. It's not like you find out about them, you know, way after the fact, after it's like a bug report. It's like you find out about it when the compiler tells you you didn't cover this case. Yeah, I, I, I totally agree. I also don't I would say rust is maybe the the only other language where I've done that because Rust and Elm have similar like type system capabilities in terms of like some types and product types. But yeah, it's, it's definitely changed the way that I've thought about programming like for the better. I definitely think that the way that I write Ellem code is just more robust and and better. Like, the language sort of guided me to do that. I don't I don't think that was like a I think that was just like a cultural phenomenon that people just decided to do. I think it's like the experience of using the language. I think it just makes me move in that direction. And that's a good direction takeaway. Number seven has changed the way I thought about programming for the better, even if I wouldn't touch Elm again. I still think I would have benefited from being an Apple developer. This has been amazing. Thank you, Richard. And thank you, Thomas, and see you next time. And they go to Book Club.