[00:00:00] Dillon: Hello, Jeroen.

[00:00:01] Jeroen: Hello Dillon!

[00:00:02] Dillon: you are listening to 101. 91 KELM Radio, live from Elm Town. And today we have a special guest, the mayor of Elm Town. Jared Smith. Jared, thanks for joining us.

[00:00:17] Jeroen: Welcome! Welcome to Elm Town!

[00:00:19] Jared: Mayor, when did, when did this vote happen? I don't remember there being a vote. I might have taken myself off the ballot.

[00:00:27] Dillon: It's been a long year. Well, you were the only one running, but it was a landslide.

[00:00:32] Jeroen: I submitted your name. You're welcome.

[00:00:34] Dillon: It was a write in. Yeah.

[00:00:38] Jared: We should get into this a little bit. Um, what we're doing is we're completing this Inspired by Elm series, and we're going to have a discussion here of Elm inspired tools with Dillon Kearns and Jeroen Engels,

[00:00:50] Sponsored by Logistically

[00:00:50] Jared: but first Let's talk about our sponsor, Logistically. At Logistically, we make intuitive software to help logistics teams make better decisions and improve efficiency.

[00:01:03] We build the front end for all new features in Elm. If you're interested in our mission and enjoy writing Elm, please drop us a line, elmtown at logisticallyinc. com. I'll put a link in the show notes.

[00:01:14] Introduction

[00:01:14] Jared: And to get started here, of course, we don't need any introduction for these two folks.

[00:01:21] Of course, if you want to hear about their journey with Elm, you can go to Elm Town 61, Turning the pages with Dillon Kearns, and Elm Town 65, Let's roll with it with Jeroen Engels, the co hosts of Elm Radio, of course.

[00:01:36] And a little bit of backstory about this series. So I recorded an episode with Hayleigh on Gleam and an episode with Richard Feldman about Roc and then I went pretty far out there and recorded an episode with Christian Rocha about Bubble Tea, a Go library.

[00:01:56] And as I ventured outside of Elm Town from the Gleamshire to Roc City and even out into the Charm Galaxy, waves from the radio called me back. thank you, Dillon, Jeroen, for joining me. It was totally unscripted, I swear.

[00:02:20] What does it mean to be inspired by Elm?

[00:02:20] Jared: I think the first question that I wanted to ask, and this is kind of an Elm Radio thing to do, I think, but kind of philosophical here, and ask, so what does it mean to be inspired by Elm, anyway?

[00:02:32] Jeroen: I think I'm gonna start because otherwise I'm gonna have nothing to say. Uh, I don't know. Uh, get inspired. I would, you know, that line that says, stealing is the best form of flattery or something like that. Well, I would say being inspired is pretty much copying and stealing things from other tools or people.

[00:02:57] Oh, don't steal from people, but you get what I mean, right? Hopefully. So yeah, you see what others do. And you see that they have done something that works well, that, uh, has a lot of benefits and you think that there's worth in having that in more places. So you do the same. I would say that that's being inspired to some extent.

[00:03:22] And now Dillon is going to complete it in a much better way.

[00:03:26] Dillon: no, I mean, uh, I think that there's a certain way that, um, the people who, who build a community set the tone. And I think that Evan and Richard really set the tone, especially in the early days of Elm with their conference talks, um, and their tools, including, but not limited to Elm. Um, and I, I, I've always thought of Evan as a very good product manager, um, Because people think of him as, um, you know, a super smart guy, but he's like a disciplined, focused product manager who is like, relentlessly focused on solving a problem.

[00:04:12] And he likes to think things through from first principles. And he also built a language that lends itself to First principles thinking, because you have this beautiful explicit domain modeling, things like custom types and exhaustive checking and, um, you know, not having runtime exceptions and things like that.

[00:04:36] It just, um, in an interesting way, it both lends itself to explicit modeling and, um, once you go down that path of explicit modeling, you kind of have to. Think through the entire use case for the user. Like it's a little hard to articulate why, but, um, once you start making undesirable, um, things impossible, kind of shielding the user from foot guns, um, you then have to think through what are all the things that are valid to do.

[00:05:13] And so. So once you embrace that way of using custom types and modeling the domains and Making undesirable states impossible, not just impossible states, but confusing states and less meaningful states. Once you take that to its logical conclusion as a tool or package designer, then it really informs the way you're building tools.

[00:05:41] So you could sort of port over some tools in a half hearted way where you're sort of taking some javascript thing and, you know, Oh, this is sort of the API that they had in this NPM package.

[00:05:53] Elm philosophy

[00:05:53] Dillon: But once you really start modeling things, um, it lends itself to these principles of taking responsibility for user experiences and, and all of these ideas from, um, from the Elm philosophy, which is a great tweet that we should link to.

[00:06:09] Jared: Yeah. That's great. That makes me think of it as a sort of holistic approach, right? As opposed to like, here's a language, here are the properties of this language. Now go, you know, build all the things that already exist with that. It's all, it's, it's much more than that, because it's really thinking like, like you said, first principles, like how can we do this?

[00:06:30] but in a. Just breaking it down to the very basic, like, what are the things that we need to start with and what are the goals and then build up from there. So yeah, that's, that's really good. I'm glad you brought up the Elm Philosophy tweets as well because I have those in front of me and I thought, shoot, maybe we should just list those out because I think those embody a lot of the things that inspire, that cause people to Copy, right?

[00:07:00] Like, um, of course, you know, you've given some concrete examples, but like, you mentioned discipline, and I think discipline as a sort of virtue, if you will, that's kind of maybe a bad word to use, but like, um, just like, uh, something that you strive for, right? So, like, you're copying because you're striving to be similar to that, and that's that, you know, imitation is a flattery thing, so.

[00:07:28] Yeah, that makes sense. Um, and I, and I'll read off that list, but one of the things I wanted to mention is that I was kind of taking a little hike before we started and I was thinking, like, what does it mean? And I kept doing like this, I kept thinking of examples of like what it means to be inspired. And then I was like, well, it's sort of like being motivated to act, really.

[00:07:50] It's like, you know, you're, the inspiration is the, the thing that says, Oh. Now I'm going to do that. So like, as soon as someone decides, I'm going to do this thing. And now this thing is going to copy this other thing. It's because they were motivated by that other thing.

[00:08:07] Dillon: yeah, yeah. And there's a sort of coherence to it. I mean, if you, if you think about it on the one hand, like, um, if you're, you know, trying to play to your user base, which if you're building an Elm tool or package is Elm users, then it's like, well, what do Elm users like? Well, they chose Elm, so they probably like good error messages and explicit contracts.

[00:08:32] And safety. So, you know, what if we did more of those things, but, you know, obviously it's like, it's not like you're getting paid for publishing an Elm package. So it's, you know, it's not like you're, it's not like you're doing user research and trying to figure out, you know, focus groups and how to, how to get the users to really love this package.

[00:08:54] But, um, but that's the culture that, that is how a culture gets formed to a certain extent. And, and I think. We cheer each other on when we see these things and we're like, wow, this is really pushing the boundaries of what safety means in Elm. You know, I mean, elm-review is sort of like a standout example of that, of like, wow, like this actually makes Elm more Elm because it's safer.

[00:09:19] It's more of the thing it's trying to be. Um, so I think that builds a real coherence to the ecosystem.

[00:09:26] Jared: Yeah. Jeroen, anything to add to that?

[00:09:29] Jeroen: Yeah, I want to go back to the culture part that Dillon mentioned. I think that a lot of things in the Elm community, like the quality that we see and that we replicate across packages and tools, it really comes down from the It comes from the early tools that we had, so mostly the compiler.

[00:09:51] The compiler is the one tool that you have to use if you want to use Elm. And it's really well done, it has great error messages and all And setting the example, uh, makes you want to do the same thing, and therefore the quality will be high. So, the fact that in Elm, all those things were The bar was set so high, so early on in the community, made a lot of difference in my opinion, compared to other languages, which I don't have examples for.

[00:10:28] So for instance, the core packages documentation is really nice. It reads well, it explains things very well, there's a nice guide as well. And I think that inspired me, at least, to do great documentation for elm-review. The Elm compiler inspired me to do great error messages for the, for elm-review as well.

[00:10:53] Uh, for all the rules and the tool itself, because it also reports a few errors. And because I did those things, maybe other people were inspired as well. So that culture, if you set it right from the beginning, is a thing that replicates. And I think, We see that in other communities. I think Gleam, for instance, has a very nice community because Louis Pilfold set the bar high at the beginning.

[00:11:26] He set the, not the constraints of the, of the rules of the community, but he, he created expectations. And I think that people will appreciate that. Follow them and it makes for a great community. And I think we have had the same, we still have the same, uh, the same thing in Elm.

[00:11:45] Jared: So I guess one thing to kind of bring this to the, some kind of Elm philosophy is, thinking about with elm-review, and I believe, Jeroen, didn't you have a conversation with Richard about taking responsibility

[00:12:03] Jeroen: Yeah. Yeah. I think I mentioned this in several places, probably on Elm Radio at least once, um, that when I was at Elm Europe 2017, I was working, uh, 2019, I was working on elm-review, uh, still called Elm Lint back then. And it wasn't published at all. No one knew about it. Um, but I wanted it to, to, to be released, uh, around that time.

[00:12:32] And I want to talk to Richard about it because I want to get hired by NoRedInk. But it was like the first conference where he didn't say we are hiring. So I didn't go to NoRedInk. Um, and yeah, I ended up having a conversation with him. Uh, where I said, I have this thing. It's almost ready. Like, it's going to be usable.

[00:12:56] And we talked about, uh, the fact that, well, he told me this, the author is responsible for the user experience. And that's what we're talking about was the fact that I can release this. It's not going to, it's going to have a lot of rough edges. but it's going to be usable, but it's going to be iffy, like in some edge cases. But when he, when he told me that I was like, okay, yeah. If I release this with all these rough edges, it's not going to give a greater user experience and we can do better. Like the Elm compiler does better. Like it never reports a weird crash or at least. It tries not to, uh, and I should try to as well. and that led me to working on elm-review two additional full months before releasing the tool. Uh, but it was much nicer. Like, uh, there was a lot of crashes that didn't happen anymore. Uh, the API, it looked better. Um, it was just much more useful. Useful and usable. And I'm really happy that I did that because that prevents me from receiving a lot of, uh, issues of bug reports saying, Oh, this doesn't work when.

[00:14:18] This happens. And I would reply, yes, I know. I, I just gotta get, get to that at some point. Um, which I now do, but for other things like API requests, like, yeah, we, we want to have that as a feature. Like, I'll get to that at some point.

[00:14:37] Dillon: Right. But that's a big difference between like a cool feature we could build and something that's not quite airtight, something that's not really, um, taking that holistic approach and saying, uh, you know, what should the user not have to deal with, like what foot guns can we get out of the way from the user, or how can we think things through in a way where there aren't foot guns along this path, the way it's designed.

[00:15:04] And I think. Um, Users really build a relationship with their tools. And, um, early on it's, when I say relationship, it's over time you build this and, and early on, if you have a bad first impression of a tool, um, you may, you may lose trust in that tool. And earning that trust back isn't just, well, we fixed those things now.

[00:15:34] People still have that relationship with the tool. They still say, oh, uh, why are you deleting that folder? Oh, it just works better if I delete this folder. And they do these strange incantations. It's like, have you guys heard of this, um, psychological experiment where they like, uh, I read about this once where they had somebody like, they had some actors in this waiting room and, , you don't know that other people in this waiting room are actors, but you have like one real participant go in and, uh, whenever this like bell goes off or something like that, People just stand up, right?

[00:16:14] And eventually you're like funneling people through the waiting room, so the actors are getting called through, and then real participants are getting funneled in, and eventually it's all just real participants, but when all of the actors are gone, um, they retain that, uh, superstition, you know, so you can get superstitious with tools and, um, you can build in super superstition is a relationship you can build with a tool and complete trust is a relationship you can build with a tool.

[00:16:44] So if you had released Elm Lint early on, and you're like, well, let's just get it out there because it, you know, it's useful. It provides some value. Then, um, you're, uh, allowing people to build that first impression of the tool where they might get superstitious about certain things, or they might learn to not rely on it for certain things.

[00:17:08] So trust is a relationship that's earned with a tool. And, um, so when you truly take a holistic approach and take responsibility for the big picture and think about like, how is the user experiencing this in, in their work, like not just. What is my tool doing? But what is this allowing the user to do? And what is the full experience?

[00:17:33] Then you earn that trust. And so like when the Elm compiler tells you something is wrong, you're like, Oh, there's probably something that's actually wrong. It's not just yelling at me because I didn't do some incantation. It's not yelling at me because. You know, it's like, oh, this thing is actually the same type, but I need to cast it or something like that.

[00:17:55] And if it tells me everything is safe, then it is safe. Like, I had that in my Java days, I felt like that was such a scary experience, where it's like, if the compiler yells at me, It might be, um, that things are totally fine and I just need to shut it up by casting something because it's correct. And if, uh, if it's not yelling at me, then it's like, I hope everything works.

[00:18:26] Because it might just blow up. I might've done a cast incorrectly somewhere. There might be some weird reflection error or no pointer exception. So, um, Elm has this experience where if it says things are good, they're good. If it says things are bad, there's probably a real problem. And that trickles down to Elm Tools as well, where we're influenced by that philosophy and, and try to give that same experience.

[00:18:50] Jared: Yeah, so you're creating trust, and so that ties into that, um, philosophy of take responsibility for user experiences and, you know, talking about the discipline to wait until that point, I think ties into the philosophy of it's better to do it right than to do it right now.

[00:19:12] Dillon: exactly.

[00:19:14] Jeroen: Yeah. Because it takes a lot of time to put that level of polish, right. It might take an additional two months before you release something. And if you, if it's already out, then maybe it will take a bit more time to release a new feature. Because you, every new feature you release, well, has a lot of edge cases that you have to think about, or interactions with other features or interactions with other, um, tools or packages.

[00:19:45] And. You're going to discover them as you develop that tool. And yeah, you'll just have to spend a bit more time working on it. And if that takes time, that takes time, but yeah, you'll, the end result will, will be that people trust the tool. Um, if you release a watch mode for elm-review, people won't have, uh, won't think about like, Oh, well, I don't know if it's updated yet.

[00:20:13] Let me just, Close it and restart it again. Hopefully now it will give me the correct results.

[00:20:21] Dillon: exactly. That, that was a big trust thing for me as well with, elm-pages was, for example, I, I noticed when I was working on an elm-pages app. If I was adding a new route or changing a route or something and I try to go to a page, and it's a 404 page because I haven't created the route yet.

[00:20:41] And then if I add the route, If it still stays up as a 404 page, what am I going to do? I'm going to, like, kill the dev server, remove some folder, npm install, elm make something, restart the dev server,

[00:20:59] Jeroen: Get out of your chair, dance around the computer.

[00:21:04] Dillon: Stand up and clap my hands and spin in a circle, you know? Um, so, I noticed that feeling in myself as a user.

[00:21:15] And I tried to address that and build in that trust. So what I ended up doing was just, you know, it, it just takes work and elbow grease. You know, there's no magic formula except caring about that a lot and saying, this is part of the definition of done for me. This is, this tool is not done until I have addressed these things.

[00:21:37] So when I, when I understand that, This is the experience. That's something that I prioritize and it's not releasable until I've addressed this. So, um, I, I made it so that, uh, first of all, it live reloads. And, if you are looking at a 404 page in the elm-pages dev server, and then you add a route.

[00:21:59] Boom, there goes the route. But also that's not enough because sometimes you don't add the route you think you added, or you're not looking at the page you think you were looking at, right? It happens. So not only do you have to live refresh, You know, what if you're working on a different app?

[00:22:18] Well, if you're working on a different app, it's kind of hard to give feedback on that. But what if you add a different route that the page you're looking at would not respond to the route you're at? So what I do is the 404 page lists out all the different available types of routes and it says, The route you're looking at didn't match.

[00:22:40] Here are the possible routes that are registered. So when you add a new route, suddenly in that list you see a new route, and it says, I didn't, I didn't match this route because Or if you, um, if you have a specific set of routes, you know, like elmradio. com slash episode slash slug and you go to does not exist, episode slash does not exist It will say, I found a route for Episode Slash, but there's no way to get there.

[00:23:14] No specific page for does not exist. So by giving more precise feedback, um, you're telling the user, I hear you. I, I see what you're trying to do, and this is, uh, what I tried to do, and this is why I couldn't give you the thing you were looking for. So it's not just giving the thing you were looking for.

[00:23:36] Some feedback, but it's giving precise feedback and letting the user know that you heard them, like, honestly, as a tooling author, I think that's sort of what you're doing. You're like, I hear you. I am putting myself in your shoes as a designer.

[00:23:50] Jared: Yeah, that makes me think of the idea of compiler as assistant. Right. That's, that's kind of what I think embodies a lot of these ideas, but to bring that to the Elm philosophy, I think, you know, there's number one is be kind. Right. And so you're being kind by trying to provide as much information. Which is number three, collaboration requires communication.

[00:24:15] If you're an assistant, you're collaborating. And so, you know, you're thinking of a tool as a, a part of, you know, as a part of your work as a, um, as an assistant or a collaborator, um, and, and you're thinking about, yeah, how do I communicate, uh, as clearly and as much as I can in order to not waste someone's time.

[00:24:43] And, and to be helpful, and yeah, I think

[00:24:46] Dillon: and, and there is a strange empathy to it too, where it is like emotionally frustrating when a tool is just, you're like, what do you want? And you, you know, you can get worked up when you're debugging something, you're like, why is this not working? And there's just this fog of war to it where you cannot see what is happening in the internals of some tool.

[00:25:08] It's just telling you it's not happy about something and you have no idea why. Yeah. And it, um, and, and the thing is we were, we're human. We, we make mistakes and, and if we don't know if we're on the right track, if you're not getting precise feedback, you don't know if you're getting hotter or colder, you don't know if what you're doing is being seen and heard.

[00:25:30] So there is an empathy to that, where emotionally, like you're like, is this tool seeing what I'm doing? Like, is this tool even listening to me? That is a real thing in a weird way. There's a, you can give empathy through a tool.

[00:25:43] Jeroen: Definitely.

[00:25:44] Simplicity is not just for beginners

[00:25:44] Jeroen: I think a lot of, of that also comes down to the fact that Elm is so simple. Um, for instance, uh, if I play with TypeScript, like I tried adding, or I have added TypeScript to the elm-review CLI project, and there's a lot of errors that are triggered because I configured the tool wrong, or because I need to configure it differently in order not to get, uh, some kind of error.

[00:26:14] And nothing tells me about those. Like, I'm guessing most people know about those because they get experienced with it. Like they, they Google it, they find a stack overflow, uh, issue and they, they now know, okay, well now I need to turn on this, this, uh, configuration.

[00:26:33] Dillon: Mm

[00:26:34] Jeroen: you don't have that as much for, uh, Elm tooling.

[00:26:38] Like the compiler has no configuration. It's the elm.json, which lists the dependencies. You give it the list of main files. That's pretty much it. Uh, you can optionally give optimize and debug. That doesn't change much. Uh, and even elm-review is like, well, you are the list of rules you want to enable.

[00:27:01] That's it. Like there's not much you can configure wrong. So Elm's simplicity, uh, transpired across tools because elm-review also, uh, has very little configuration. Yeah, well, that creates a lot of benefits, including like just not having to explain a very complicated, uh, why an error is showing up. Like, no, you have an error.

[00:27:32] That's it. You don't, don't look at the configuration. Or in the case of TypeScript, it's like, Hey, you shouldn't look at the configuration. You, you messed something up. Or I I need you to tell me how your project is structured. You don't have that in Elm. So this is much simpler, which means you can give much more precise feedback.

[00:27:53] And because we know like we can provide more, better feedback, we are going to put more effort into it because it's not that hard to figure out what the user wants in practice.

[00:28:09] Dillon: Yeah, there was some, there was an insight I had with elm-pages where, um, I mean, it's so interesting with, with many of these sort of more meta tools that don't just live as a package, right? They live with an accompanying tool like elm-review and elm-pages. Um, yeah. Sometimes we have to build out certain things that Elm isn't really designed for in a certain sense.

[00:28:34] For example, like Elm doesn't have a concept of like an interface that something has to adhere to, a protocol or an interface. Different ecosystems have different terms for it. Elm doesn't have that concept. So you can't say, I need a module that implements this interface. But in elm-pages, you have route modules and route modules need to export.

[00:28:55] a type called data, and they need to, you know, expose a message type, and they need to expose, you know, a route that defines the route with the init and update and all those things, right? So, so what do you do? Because you could just say, well, I mean, Elm doesn't have a feature for interfaces, so. That's just something the user is unfortunately going to have to learn.

[00:29:24] So maybe I'll write a note in the documentation that says, well, you need to expose these types. Um, things will crash because I'm wiring things together through code generation. And that's, that's just how it works. Elm doesn't have a feature for interfaces. So what can I do? Or you could say, well, uh, from first principles, I know that this problem needs to be solved.

[00:29:46] And I know that I'm taking responsibility for the whole holistic experience the user's having. So, given that I know I need to solve that, and not going in with any preconceived notions of what am I responsible for as somebody who's publishing an Elm package and tool, how do I fix this experience? And basically what I realized is if A user of elm-pages is seeing an error message that's pointing to generated code.

[00:30:15] That means I've done something wrong. Um, so if it says, uh, I'm, you know, you're talking about route dot about dot msg, and I couldn't find that type. and it's pointing to generated code, I've done something wrong. So what I ended up building, um, which again, takes a lot of love and elbow grease, but it's, it's not rocket science.

[00:30:46] It's just, you care about this thing a lot and you work hard on it until you've solved that problem. And so what I ended up doing is, uh, building some internal elm-review rules that are applied to the user maintained code. that check the contract. I called it no contract violations. And so essentially that is an interface in Elm.

[00:31:10] So I have to, I say the, the things in the route folder must implement the, uh, uh, this interface of a route module. And if they don't guess what, instead of, uh, generating the code and giving them a compiler error that points to my code that I generated as the, the designer of the tool, it, uh, it gives them a custom error message that comes from elm-review that, uh, is nicely highlighted and says, uh, this route module of this file name needs to expose these types and it's not exposing this type.

[00:31:48] Jared: Wow. So, Elm Tools, Inspiring Elm Tools, and

[00:31:53] Dillon: And using Elm tools. Yes.

[00:31:58] Jared: And, would you all agree that simplicity is not just for beginners, considering what we've been talking about here? Okay.

[00:32:08] Jeroen: Absolutely, like, uh, uh, yeah.

[00:32:12] Jared: Yeah, yeah, I think that's, you know, that's, um, philosophy number seven, if we're putting numbers on these in this, from this tweet, How many did we skip?

[00:32:22] Oh, um, we've talked about one, two, and, um, three, but, so,

[00:32:31] Jeroen: Let's go with seven,

[00:32:33] go ahead. I think it's, it's, it's seven. Simplicity is not just for beginners, but, yeah, so we've talked about that a bit.

[00:32:38] What are tools?

[00:32:38] Jared: And I think The other thing that we've been talking about quite a bit, and maybe we haven't defined it well enough, is what are tools anyway? Like, what is a tool?

[00:32:51] Dillon: Well, I mean, maybe we've already been talking about it. Um, but I think we first need to define what a definition is. So Jeroen, A definite, no, okay. I thought you wanted me to go there.

[00:33:06] yeah, let's do it. Actually do it. What is it?

[00:33:07] Jeroen: Oh man, this is not my native language, you know that, right? Uh, a definition explains what another word means.

[00:33:20] Dillon: Not bad.

[00:33:21] Jeroen: Oh, no, it's not another word, because you can define definition, which I, is exactly what I did.

[00:33:28] Dillon: Or itself.

[00:33:29] Jeroen: Or itself.

[00:33:31] Dillon: There you go. You. You solved for the base case.

[00:33:34] Jeroen: I did. It was reasonable, reasonably simple. Can we go into further detail? Maybe. Do we want to? I don't know.

[00:33:43]

[00:33:43] Dillon: Let's just pretend that we aren't going to need to define explain there, and I think we're good. Um, but maybe we've been talking about what a tool is. I mean, to a certain extent, like, um, it is.

[00:33:56] Feedback & guarantees

[00:33:56] Dillon: So, uh, to me, um, one thing that's not on the Elm Philosophy tweet, um, that I would say is of the things most near and dear to my heart as a programmer and that made me fall in love with Elm is feedback.

[00:34:12] To me, like building software is all about feedback. I mean, we talked about the feedback to the user, giving the user empathy by uh, saying I, I see what you're doing and this is what I need from you that I'm not able to do this thing, or here's the thing in action now that you've changed this thing. Or, you know, unit tests or compiler feedback telling you this is the line that something needs to be changed at.

[00:34:38] And this is why it's not working. I mean, precise about feedback, um, feedback makes you move faster. And, um, you know, to a certain extent, um, maybe you could say a tool is something that, helps automate some, um, process or build something for you and gives you feedback along the way. I would, uh, I would add that caveat that, you know, a tool that just spits something out and helps do some heavy lifting for you, uh, is not taking responsibility for user experiences.

[00:35:10] So feedback, I think is also an important part of that process.

[00:35:13] Jeroen: Yeah. I think this is where the difference between me and Dillon will occur is that, uh, to Dillon, a tool is sure something automated. I agree with that, or maybe like a wrench is not automated, but, uh, it's something you use to build stuff with,

[00:35:33] Dillon: Mm

[00:35:34] Jeroen: right? I totally agree with the feedback part. I'm not going to say anything about that.

[00:35:39] And to me, a tool has something about. It is there to create guarantees. That that's a lens that I, uh, use quite a lot. It obviously applies more to elm-review than elm-pages. And building applies more to elm-pages than elm-review, which is why we're building different things. He allows you to do something and I prevent you from doing things. Um, but the, the, the part that I quite like is that to me, whenever you, you make a constraint, you get guarantees out of that. So for instance, in, in Elm, you can't write one plus a string that is not allowed. That is a type error. So the, the, the type checking is a constraint. What it gives you is a guarantee that you're not going to have, um, impossible operations happening in your code.

[00:36:42] And you have that all over the type, uh, type system. So the Elm compiler constrains what you can do, but it gives you guarantees return that, uh, you, you won't have crashes because of, uh, invalid operations. And elm-review is also there, like we constrain what you can do. You will not be able to write code in this way.

[00:37:08] You will not be able to have a unused function for instance, but you get a lot of guarantees. Out of that, for instance, you know, for instance, that every function that is mentioned, uh, that is written is used somewhere. And I just like this lens because you see that a lot of tools are there maybe to build something or to constrain something, but they will always give you some kind of guarantee. Uh, for instance, elm-pages will guarantee you that some page will be available, even something as that, right? And elm-review is going to say, you're not going to have any dead code. And there's going to be some caveats, for instance, if you configured your rule not to report errors for this file, then you're going to say, okay, well, I have the guarantee that I have no unused functions across my code base, except for the files that are configured not to be reported.

[00:38:06] And I just like this, uh, this vision

[00:38:11] because guarantees allow you to go faster, right? If you know that something won't crash, you won't be worried about it. Again, the, the question about trust from before. And Elm gives you a, Elm has a lot of constraints, right? Because, uh, it's not a very rich language. So it doesn't have a lot of features.

[00:38:36] And features. Is what removes constraints. So if you have a language that allows you to have to mutate things, to write GOTOs, to have loops to, declare variables in three different ways. There's a lot of possibilities are created, meaning a lot of constraints that are removed, meaning a lot of guarantees that are removed.

[00:39:00] So the, the entire system becomes, becomes less knowable, less predictable. And it's going to be harder to figure out all the edge cases. It's going to be harder to give a great user experience, uh, and to keep everything airtight. So that is a lens I quite like, like I'm actually writing a blog post about it.

[00:39:20] That's why it's in my mind. I can't get it out of it.

[00:39:22] Dillon: I absolutely love that. You're in. I think that's a brilliant lens.

[00:39:26] Tool as contract (not slicing hot dogs nor fingers)

[00:39:26] Dillon: It makes me think maybe another way to frame that. To really get down to defining what a tool is, if we're really going to do this, is

[00:39:38] Jeroen: on that actually. Yeah, I forgot about that.

[00:39:42] Dillon: Is it maybe a tool is a contract, right? And contracts have certain constraints on their inputs and they have certain expectations of the outputs, right?

[00:39:52] So For example, a, uh, a blade saw, you know, more, more modern blade saws. It's becoming part of the expected contract that, number one, uh, they're not able to slice hot dogs. And number two, they're not able to slice fingers. Um,

[00:40:11] Jeroen: would say number one, they're, they can saw wood. That would be the,

[00:40:18] Dillon: that's true.

[00:40:19] Jeroen: that would be number

[00:40:20] Dillon: Well, it depends, right? I mean, what is, what is its main purpose. Is it more important that it does no harm to neither humans nor hot dogs? Cause they're both important. Uh, or is it more important that it saws wood? I mean, put it this way. If you had a thing, um, that all it did was not chop off human fingers, or you had a machine that all it did was saw wood.

[00:40:47] Which one, which one is a better tool? In some sense, you might argue, Hey, any tool that doesn't chop off fingers is at least better than a tool that does chop off fingers. As it doesn't matter what job it successfully does, what positive thing it does. If it doesn't chop off fingers, it's better because that is a really bad thing that we don't want to allow.

[00:41:08] So, um, It's a contract, right? And actually, um, I, I had a listen to the, uh, Gleam episode with Hayleigh of Elm Town, and, um, she was talking about sort of this 80/20 of, uh, being able to perform effects inline as opposed to having to call out and having a first class way of doing FFI where you can synchronously, um, call out to JavaScript or Erlang BEAM, uh, you know, without having having to, uh, assume that it might fail, right?

[00:41:47] You can just say, Oh, these, these are the types I'm going to get back. This is, you know, let's assume this is going to succeed. And, and she was saying, you know, maybe 20 percent of the time it's a problem, but, basically Gleam's theory of that problem is that, um, it's, uh, it has enough benefit that outweighs the potential problems you introduce, which is a totally valid theory of that problem. That's why a lot of people also love, um, TypeScript and, uh, you know, Rescript, things like that, right? So that is a totally valid theory of that. And Elm has a very different theory and philosophy, which is even 1 percent is too much.

[00:42:30] It's not about 80 20 rule. It's not about let's, uh, you know, let's be Uh, 80 percent safe or 99 percent safe or 99 percent 99. 9 percent safe. What happens if we turn up that knob to 11, right? That is the Elm philosophy on that. And yes, there is a high cost. there's a high cost for tooling authors, because we really have to think through all the possible ways a user could use the tool and, um, provide mechanisms for them to do that.

[00:42:59] Safely and explicitly and model that. Um, and there's a cost to users because, um, sometimes foot guns, things that have possible foot guns are more convenient. Um, but as Jeroen was talking about, like having that feeling of being very safe. allows you to move faster. And, uh, that, and, you know, we talked about this a little bit, Jared, in the episode I came on, uh, to Elm Town. so as someone with ADD, that really is the case for me. If I can just, turn off that part of my brain that's worrying about this one little thing. I can move so much faster. So say, so Elm's theory is that being, uh, paying the cost of being safer lets you move faster and that benefit outweighs the cost and both theories are valid, but that is Elm's theory of that.

[00:43:59] And that is, uh, I I'd say Elm tooling's theory of that as well.

[00:44:02] Jeroen: So you're against saws that saw fingers and against guns that shoot in feet.

[00:44:15] Dillon: Yeah. Well, why would you even invent a foot gun? Like, why does that even exist? Is the sole purpose of a foot gun to shoot feet? Like,

[00:44:24] Jeroen: I don't know.

[00:44:24] Dillon: understand.

[00:44:26] Jared: destroy it.

[00:44:27] Dillon: Just don't invent it.

[00:44:29] Jared: don't make it in the first place or get rid of it if you've already Yeah, that's a great point. I think, listening here, I've had a lot of time to kind of synthesize this maybe. I'm hearing about feedback and features and guarantees and to me this sounds like a tool is striking a balance between features and guarantees.

[00:44:52] And, and you, we talked about a lot about users and being useful. So I think it's, it's creating something that's useful by striking that balance. And then through that process, providing communication, because communication is contribution, right? And so that is, that is a feature I think of it is, is providing that feedback. And that's useful.

[00:45:18] Lobbying for tool as contract

[00:45:18] Dillon: and a contract is a way to provide feedback too. I'm, I'm, uh, lobbying for my contract definition here, but if you, if you have a contract, if there's a violation of that contract, then you, you let the person know. A hot dog is trying to be sawed and it shoots straight down. That's the contract

[00:45:36] Jared: yeah, and I think that that ties into this idea of constraints, right? So like a contract is creating a certain set of constraints. And I think, you know, kind of tying into what you're saying about going back to the episode with Gleam is, I have this kind of personal philosophy of there's freedom in your limits.

[00:45:59] And I think this ties into what you're saying about like freeing up your mind, right? To not have to think about those edge cases because you're collaborating with your assistant, right? Whatever that tool may be, it may be the compiler, elm-review, elm-pages. Um, but all those tools that you're collaborating with, um, are creating constraints and they're providing something useful.

[00:46:19] But you're finding that because of those limits, there's this increased productivity. And of course, with a direct FFI that, that kind of, you know, um, that kind of eliminates, um, that, I mean, just, you know, that it's just something that it's a trade off, right? Like, it's like, where are you at on the spectrum?

[00:46:38] But like, by introducing that, it creates a whole different culture. And I think, you know, kind of going back to what we were saying in the beginning is creating a culture around these guarantees. Was not something that was an accident. It was intentional and it was intentional by things like requiring docs to be there, right?

[00:47:00] Like in the first place. So you're more likely to make great docs. You don't have to, but you're more likely if that constraint is in place. And so I think, you know, coming early on at the very beginning and saying, these are the constraints of the community. We're not going to have direct FFI. So now not only do we require the language to have certain constraints? Now the packages within that language have to have certain constraints, within Elm, they need to have that because they just can't do that. So now you have to work around it. You have to think in that particular way. So, yeah, it's created some interesting, um, things.

[00:47:40] And I think one of the things that Hayleigh had pointed out was that, uh, the way that she created, uh, elm-, elm-web-audio, I think it was, was, uh, informed by those particular constraints and that kind of building an Elm architecture out of that based on audio as the view,

[00:48:02] uh, was a kind of an aha moment because of those constraints.

[00:48:06] So yeah, I think that it's really powerful. Yeah,

[00:48:09] Tool as an expression of a point of view

[00:48:09] Dillon: Yeah. Yeah, I would offer another alternative definition of a tool if we're, uh, if we're still, if we're still on the, this is what you get when you invite two Elm Radio co hosts on. Um, the, uh, I think another way to think about a tool is it is a, um, an expression of a point of view. Um, in, at least in my opinion, that is one, um, one sign of a, of a great tool.

[00:48:39] Jeroen: is that your point of view?

[00:48:41] Dillon: yes, this, uh, this podcast is a tool, actually. This episode

[00:48:47] Jared: nice. Yeah.

[00:48:48] Dillon: It's a tool for getting ideas and bad puns into your ears.

[00:48:55] But, uh, uh, yeah, I mean, uh, I think it often makes a tool feel incoherent and unsatisfying. In my opinion, this is my point of view. Uh, if, uh, if, uh, if you don't take a firm stance, like what are you, I mean, As an example, Elm saying, no FFI, you know, you have to go through ports and treat it as an external, potentially unsafe thing.

[00:49:27] Uh, versus Gleam saying, go ahead, just treat it with care. Have, have this sharp knife because it is so powerful that it's worth giving you access to. Those are two points of view, and they're not watered down. You go all in on that point of view. Um, you know, when I was building elm-graphql, I was really trying to think through like, what is the Elm way to do this thing?

[00:49:54] And like, for example, I was trying to do things in a sort of, um, building up a selection set, like a query builder style API, rather than a write your GraphQL query string and spit out a, a single Elm function that goes and makes that request. Uh, so it was like, well, how do I port all these concepts to the Elm language, not concepts from some NPM package I saw, but what would this GraphQL concept looking at first principles look like in the context of native Elm code?

[00:50:28] so you, you end up really expressing a point of view. And I think like when you dial that knob up to 11, it makes things more interesting.

[00:50:37] Roc

[00:50:37] Jared: I want to mention Roc here because I think that we have talked a little bit about Gleam and I think that Roc in particular takes this idea of, you know, these constraints and in what guarantees that you have in Elm and provides it in a different way. In a different place, but one of the things that Roc is, is considered a direct descendant of Elm.

[00:51:06] So I think that, you know, that's a huge bit of inspiration there. And so, yeah, just, um, I just wanted to comment on that, that I think that there is a way of thinking about, like, how can we provide these constraints and be useful in a particular, uh, paradigm that you might not think could, could be.

[00:51:29] It's kind of mind bending to me to think that, like, you know, it makes sense within this Elm Architecture, but then, like, you're going to try and apply that in a different way. Of course, I mean, that's, that's taken a lot of time. I think Richard started that in 2018. So, you know, there's been a lot of discipline there and, and waiting, several years to, um, have different releases and being very Uh, considerate, very thoughtful about how to communicate what each of those releases means.

[00:52:00] And, and like, even by the quality of the website to show like, um, you know, this is not polished at all. This is, you know, it's just like a couple of links because we, we don't have much yet. And then it kind of gets better, you know? And so I think that's, that's pretty interesting,

[00:52:19] Dillon: uh, yeah, well. So, to me, one of the things, I haven't been following Roc super closely, but one of the things I find really neat about its approach, you know, the opportunistic mutation, I think Richard calls it, of going in and, you know, it's like, From a user's standpoint, you are dealing with immutable data, but from a performance standpoint, and at the bare metal level, I mean, to me, who cares what's going on at the bare metal level, as long as your experience of it, um, is coherent and, and you can think about it in that high level way.

[00:53:00] Right? So that's the magic trick. And, um,

[00:53:04] Contracts & purity

[00:53:04] Dillon: And again, lobbying for my contract definition of a tool, uh, I think one thing I think about a lot as a tool designer is, um, and a tool user, um, if I give you this thing as a user, what can you do for me as a tool? So, um, if I give you, um, not mutating any code, From my standpoint, that's my end of the bargain.

[00:53:37] What can you do for me? Oh, well, I can do these cool optimizations under the hood because I now have these guarantees about your code. So if you can offer me the, these guarantees, I can then take those guarantees and do some cool stuff knowing those things. We've talked about this many times on Elm Radio, but, uh, I mean, you know, the, the best part about elm-review is that its target is Elm, right?

[00:54:01] Like, many of the interesting properties of elm-review are just piggybacking on the fact of like, well, given that we know these things about Elm code, what guarantees can we give you building on top of that, right? So, the more The more constraints that you as a user of a tool are able to give, the more the tool can do with it.

[00:54:23] But that said, I think that's a really important part of the design process of a tooling author is, um, what, what is the user going to get by giving me this constraint? Because it is, it is paying a cost. It is a burden to the user. It's constraining them, which is not in itself good, unless it's just a purely bad constraint.

[00:54:45] Like sawing hot dogs. That's just making the world a worse place, objectively. But if you, um, I think it takes thoughtful consideration at a high level in the early design stages of a tool of just planning out, okay, let's just imagine I am very extreme about this constraint. What would I be able to do with that and offer the user in return?

[00:55:16] I think that's a really useful way to look at designing tools.

[00:55:20] Jeroen: Yeah. Purity is such a undervalued constraint.

[00:55:27] Dillon: Yeah.

[00:55:28] Jeroen: It's one of those constraints where you, you, you look at the opposite, like, Oh, what can't I do? Like, how am I constrained? And you don't see the guarantees that it gives you, and I think that's a shame. And sure, it is very nice to sometimes be able to mutate things and all that, but yeah, there's a lot of things that you lose, that you don't notice, because they're harder to find.

[00:55:57] For instance, I mean, we've had linters since the 1970s with C. And I don't know if there are many other linters out there that looked at, Hey, what if we only had pure code and figured out like, Oh, well, we can actually do super good dead code elimination or we can simplify code a lot more easily and more reliably. And, uh, there's a lot of other opportunities. Like for instance, uh, Mario Rogic, who made, uh, Lamdera says, Lamdera would not be a thing if it was not for Elm's purity, because a lot of things break down or it becomes a lot more, uh, a lot less reliable.

[00:56:49] Um, uh, this is something I really like about the, the Elm tooling is We are still uncovering the benefits of purity and of the language simplicity and the, the small set of features that we have, like, Elm is such a tiny language and it feels like you can do so little, but in practice we can do a lot.

[00:57:14] I mean, we can do something very reliable and people are still uncovering features, making great tools, like Lamdera, like elm-pages, like elm-review. that exploration I find super interesting.

[00:57:27] Jared: Yeah. Yeah, I like that. I think I'm glad you mentioned Lamdera, because that one is definitely one that, when you see all the like pieces that are eliminated that you just take for granted when you're building those different parts. And I think this is true with elm-pages too. It's like you are by setting this particular set of constraints and building on, right?

[00:57:59] We're, we're inspired by Evan's work here. Um, we're, we're building on and we're going to do that by we, I mean the, you know, like collective we, I'm not actually building these tools, sorry, but, uh, not trying to imply that, but yeah. So like the community is building these tools with that inspiration in mind and built on top of that, like that really strong foundation of like, okay, here's this purity.

[00:58:24] What can we do that if we applied it here? What if we applied it there? What if we, you know, pushed in this direction? What if we pushed in that direction? I mean, in one way, you're kind of, you know, you're pushing against those constraints, but you're just kind of like, if I move this wall out a little bit, like, is that, is that wall going to keep standing?

[00:58:43] Is it, you know, 100 percent going to stand, you know, by moving it out a little bit. And, um, and I think that applies. There's a, um, a lot of tools and I, I can't mention them all, but I think something like elm-ui is doing this as well with the, um, the way that, you know, kind of going back to a tool is a contract by creating more explicit contracts with the, with the API for the user interface of like you know, you have to have some description for an image, right? Like, that's just going to make a nicer experience for folks because of that increased constraint. So, yeah. Heh

[00:59:26] Jeroen: one thing that I don't like about the contract analogy.

[00:59:30] Dillon: Okay. Yeah.

[00:59:33] Jeroen: You can breach a contract.

[00:59:36] Dillon: It depends on whether we're talking about the Socratic ideal of a contract or the human implementation.

[00:59:44] Jeroen: Yeah, but like, it feels like you should be, like, it's like laws. If you do this, which is not allowed, then you're punished. And a contract is like, you're going to do this, and I'm going to do this, and we're both going to be happy. But if one of us does this, and then The other one does that, then there's, then the contract is breached and you won't get the guarantees or the benefits from it, but also like, there's going to be some punishment or there's going to be some failure somewhere.

[01:00:19] Dillon: If you violate the contract of the, uh, bladesaw, the punishment is your finger will be chopped off,

[01:00:26] Jeroen: For

[01:00:27] Dillon: but it's a self enforcing contract. So.

[01:00:30] Jared: I think there's this mutual trust required for that, right? Like, I think that, you know, like a social contract, for example, right? There's, you have to have trust that you're going to, everyone is going to adhere to that contract for it to be valid. And I think that that applies with tools too, because someone had to make those tools, right?

[01:00:47] A human, and they had to do their best to make it adhere to these. They could, you know, go rogue, uh, they could break bad, right? And like, suddenly, um, change the way that it works to do something evil, right? So I think that it is this, like, it's, you know, this community to say we are going to adhere to this requires everyone to agree to that contract.

[01:01:13] Jeroen: wait, do you trust humans?

[01:01:17] Dillon: He has no choice.

[01:01:19] Jared: Yeah,

[01:01:20] Jeroen: All right. All right. Yeah, sure. the fact that in Elm, you don't have a lot of these features. That means that those contracts can't be breached, uh, and you get those guarantees for sure. If you stray a little bit away from Elm and you add FFI, you add mutability, and more features, you are going to lose some of the features that makes Lamdera work super well, that makes elm-review work super well.

[01:01:49] And you, you're gonna have to think really hard about, like, really hard about if I introduce this thing, what do I lose? That's gonna be really hard to figure out, I think and also like, do you really want to lose that or do you want to, or is it fine?

[01:02:07] Jared: Yeah, it's those trade offs.

[01:02:08] Jeroen: it, it is absolutely trade offs. Like even the fact that Elm has, a number of features is a trade off with, with something else. Like it has, I don't know, uh, if expressions. It could be case ofs. That is a trade offs, a trade off that it chose to do. Uh, it can, it supports numbers. Why? Because there are advantages to it.

[01:02:35] It also creates some problems. Like now you have, uh, numbers that loop from 2 billion and, well, it's JavaScript under the hood, or, but you, you can have numbers that go from positive to negative when you add plus one. You lost some guarantees there, but there was worth in having numbers.

[01:02:58] Dillon: Right.

[01:02:59] Jeroen: So everything, the only guarantee that you can have that nothing works, uh, none in a way that is not expected.

[01:03:07] Uh, if you really want to be sure about everything, then design a language with no features at all, just an empty language.

[01:03:17] Dillon: Right,

[01:03:18] Jeroen: And you're going to be sure that it's not going to do anything wrong, but it's also not going to give you anything at all.

[01:03:25] Dillon: yeah, right. It will never produce a bug,

[01:03:28] Jeroen: It will never produce a bug.

[01:03:31] Dillon: One thing that, uh, I think is underappreciated about Elm, I mean, we're talking about all these great tools that are inspired by Elm, but I think it's more than being inspired by Elm. I think a lot of great tools are fueled by Elm, as we're talking about, because this purity, as a feature, is so powerful for building on top of.

[01:03:53] So like, if you think, for example, about, um, how do you want to define your configuration? Do you want to define configuration in an unconstrained general purpose language that can perform side effects every time you read the configuration? Or maybe are you going to use JSON? Because it can't do much, and that's good.

[01:04:15] That's what you want, because you just want to read the configuration. You don't want any weird stuff happening. Like, Rails has had so many security patches because YAML has some security vulnerability because it's too smart for its own good. Well, Elm is not too smart for its own good. Elm is very well behaved code.

[01:04:32] It is very constrained and it's, this inversion where it can't perform things in the outside world, but it can send out messages to be performed in the outside world, like Hayleigh talked about with audio, which is a brilliant insight, right? It's like, what if we just yeah, we need to connect to the outside world.

[01:04:50] I can't do audio myself, but I can tell some external thing how to do audio, right? Well, what about elm-review rules and configs? It's like this highly constrained design language. It's like a domain specific language for Describing rules in a pure way. And you know, you know how, you know, it's pure because it's Elm code and it's a general purpose language, except that it can't perform side effects.

[01:05:16] So it's well behaved, highly constrained, highly predictable code that follows its domain modeling perfectly, so you know exactly what contract it upholds. It's a beautiful way to express what the contract is to the user. It even gives you beautiful package documentation that allows you to annotate what these things are and see exhaustive lists of all the types you're dealing with and all the functions you're dealing with.

[01:05:41] And then What does Jeroen do? He takes some external tool that actually does something with it in the real world, because if you have pure code, it doesn't do something in the real world. So you take that pure code, you have it give you back information, and you can call back and forth to it to give it information and get back information, and then you do things in the real world as a result.

[01:06:03] So I think that's an underappreciated thing about Elm. Lamdera is the same thing, right? It's um, sort of serializing These messages and using that to, to keep track of backend data and. You know, even can even play things back and stuff like that, right? There are all these things that come from a time traveling debugger, um, because of purity.

[01:06:25] And if you want to do things in the real world, you can, but as the tooling author, you have complete control. You know, there's no funny business in the thing you're sending things back and forth to. And if you design that, um, contract and interface really nicely. you can create beautiful tools. So Elm is highly toolable.

[01:06:45] Elm is a great target for tools.

[01:06:47] Jeroen: Yeah. The,

[01:06:49] Dillon: another reason why we see so many high quality tools in this ecosystem.

[01:06:53] Jeroen: for the case of the configuration, I've seen a lot of takes, uh, about linter configuration where they say, Oh, you should never, uh, use a programming language code as configuration, because it's going to change every time you're going to have to execute it in order to be sure that nothing changed.

[01:07:12] Dillon: Mm

[01:07:13] Jeroen: And I'm like, well, Elm code is fine.

[01:07:18] It's static and I didn't allow it to change whenever I run the application because I could make it, I could make it take the current time and it could decide to give different rules based on that, but I don't, I constrained it to be static and it's a static by default as well. So yeah, purity. Oh,

[01:07:41] Jared: Nice.

[01:07:45] So we may have actually defined what tools are here...

[01:07:49] Jeroen: Oh we're not done!

[01:07:51] Jared: That's just step one.. Now we start the episode. But, yeah, so I guess

[01:08:09] What's next for Elm?

[01:08:09] Jared: What do you all think is next within the Elm community for Elm inspired tools? maybe if you're considering building something with the inspiration of Elm, then take that action. You know, take that first step and, and try something and see what happens because

[01:08:32] we might be talking about that next.

[01:08:33] Jeroen: don't know what's gonna happen next. I think at some point, someone is gonna have a need, and when people have needs, they will create tools. And hopefully they will be inspired by what others did and they will make something very high quality and they will make use of purity or they will, or they will not, I don't know, whatever makes the tool work the best.

[01:09:02] Yeah, I think someone will have a need that they will need to solve and they're going to, for some of those tools, they're going to figure out, oh well, in the case of Elm, because of its purity, because of its simplicity, I can do something that is much nicer than anywhere else. And that is something like we have a few tools out there in the Elm ecosystem that are just the best out there.

[01:09:34] Like, uh, elm-graphql is. I, I, I dunno if there are better tools out there, uh, for JavaScript or something. Is it super, is it reliable? Very, I, I, I can't compare it to other things. For elm-review, I would guess that it's one of the best linters out there. Just again, because it's, uh, targeting Elm and using Elm.

[01:09:59] Is it the fastest? No, I'm working on that. But you get the point. Yeah, I'm waiting for people to explore more and to scratch their itch. And I think we're gonna see great things. I think we have seen great things. I don't know what is more to come, but hey, let's uh If we anticipate everything, it's not gonna be exciting.

[01:10:22] Dillon: I love that. I, uh, you know, what comes to mind is Ruby was a pretty, um, small community before Rails, right? And it just exploded. I'm not necessarily saying that the Elm community is going to explode, but my, my point is that, um, when, when a language comes along and a tool finds that that language meets its needs really well, then a beautiful thing can happen, right?

[01:10:54] So in the case of Rails, um, and again, this is a, Um, this is a totally different, um, sort of underlying theory of productivity or developer experience with Ruby and Rails. The theory there being, Hey, metaprogramming gives us all these super handy things, right? And Rails is completely built on, on that principle.

[01:11:18] Other things have come along and said, actually, we, we like some of the principles of convention over configuration, things like that. But, um, We like to be a little more explicit, like Elixir and Phoenix, for example. But, uh, but that is a point of view, uh, that Rails has, and the Ruby language really suited that point of view, and made that possible, and that made the language shine.

[01:11:42] So I think that Elm has very unique qualities that are turned up to 11. It has a strong point of view. And, um, yeah, when tools come along and make use of that, then beautiful things happen. And it will be cool to see what those next things are. I think that Elm is in a very cool place for, um, uh, just ecosystem exploration, you know, there's so much exploration happening.

[01:12:06] So many cool tools being built. Um, I think we could see really cool things with AI. You know, Joran and I did an episode a while back about AI and Elm. And I think, um, Elm is actually a really interesting language for AI because I think that AI stuff hits a limitation when you're, um, just generate some code, but if you can have a feedback loop and, you know, augment the generation by actually executing and verifying and getting compiler feedback and having constraints can actually be an interesting property for AI, even though, in a way, it seems like, uh, antithetical to it.

[01:12:50] Um, I think interesting, I think interesting things happen when you blend these, uh, generative tools with more traditional, highly constrained tools with strict contracts and good feedback.

[01:13:02] Jared: Well, I think that's a great place to end it. If y'all want, we could move on to picks.

[01:13:10] Jeroen: Wait, have we defined tools yet?

[01:13:15] Jared: No, but all I know is that I know nothing, and I think that,

[01:13:21] Dillon: And,

[01:13:21] Jared: if I, I there's create no, no code, then I will not have any problems, nor will I have solved any problems.

[01:13:29] Dillon: And there's a 20% discount down at the hardware store on blade saws so.

[01:13:35] come on down.

[01:13:38] Picks

[01:13:38] Jared: Well, Jeroen, have you thought of any picks?

[01:13:43] Jeroen: Go to Elm Camp if it's organized next year, or where it's going to be organized next year, because I think they're working hard on it. This year was amazing. I know you've had Wolfgang and Katja on to talk about it. It was great. Go there next year. And I hope to see you there if it's, uh, available for me without a plane. Oh, small pick. Uh, try to save the planet, please. And if you can avoid taking the plane, that's great. Is that a pick? I don't know. Is it worth mentioning? Probably!

[01:14:23] Dillon: pick.

[01:14:25] Jared: so. I, you know, that's kind of, uh, creating a balance there and, and, you know, it's kind of creating some drama between these two, right? It's like, well, you should come to Elm Camp, but also, you know, think about the planet. So.

[01:14:38] Jeroen: yeah, like

[01:14:39] Jared: I don't know. It's...

[01:14:40] Jeroen: For instance, I'm very happy to see Dillon

[01:14:42] when he comes over to Europe, but I'm also like, I wouldn't be, it wouldn't be all that bad if I never saw him again, because I know that some guarantee that he didn't, uh, put a lot of CO2 in the atmosphere would be great. I don't know. But yeah, if he can take the train or something, that's great.

[01:15:03] I had a 20 hour trip to Elm Camp in Denmark last year, and that was the way to the camp and back again, and that was okay. Maybe it's because I'm still on the younger side, less and less so, but it's doable, so that's my pick.

[01:15:25] Jared: I'll have to take a blimp. Sounds like a good way to, to go.

[01:15:29] Jeroen: Yeah, unless you put a match next to it.

[01:15:34] Jared: Yeah, not, not hydrogen. Not a hydrogen, uh, Zeppelin. What about you Dillon, what pics do you have?

[01:15:42] Dillon: well, on a, in a similar vein, uh, I, uh, I would pick, uh, just being kind to people because, uh, I had a son eight months ago and it just puts certain things in perspective and one of the things that just, um, is always needed is kindness. So just be kind to people, be kind to somebody. Make their day a little better.

[01:16:08] and, uh, second pick would be, um, elm-pages scripts. I think, uh, they've really, um, blossomed, this year, with, like, a feature set around, streams and being able to execute shell commands and stuff like that. So I think it's a really interesting way, um, to, to do, um, Small scripting tasks, you know, in a way where you don't have to memorize magic incantations in bash and hold your nose and spin around in a circle.

[01:16:39] , A lot of these things we've been talking about of designing with the user experience in mind and these things, like I designed them to be as seamless as possible where you, um, you know, the script module is just, uh, So, a single Elm module, um, in an Elm project folder with an elm. json file and its dependencies. So, the minimal boilerplate is an elm. json file, and a single module that exports your run function. And you can even execute remote scripts by pointing to a gist. You can paste in an exact gist URL. You can even execute scripts, uh, by pointing to a file in a GitHub repo.

[01:17:23] You can just take the link to a file in a GitHub repo and paste it in and execute that if it is an elm-pages script. Um, not to mention running local ones, but it's a single command to just execute that script. You can even compile it to a standalone JS file. Um, so, uh, we can link to the, um, elm-pages docs, uh, page on, on elm-pages scripts.

[01:17:49] Um.

[01:17:49] Jeroen: I would love it if there was a podcast episode about it or something, that would be

[01:17:54] Dillon: oh, that's a great idea. We'll have to get on that. Wink we already did.

[01:18:02] Jeroen: did we? Really? I'm sure there's more to come about that. Maybe Final Pick, unless you have more. I've heard of a good podcast called Elm Radio. We're not recording at the moment, because Dillon prefers being with his son being with me. Oh, sorry, you said something about being kind. Um, okay. Um, but there's like almost a hundred episodes of about an hour, an hour and a half each.

[01:18:34] As you can notice, this episode is probably probably also going to be quite long because,

[01:18:39] the record?

[01:18:40] I don't know, I think we might have set it last time that we were on the show anyway. So, um, yeah, that's what you have with with us, I guess.

[01:18:51] Jared: Yeah, that's great. So, I want to go back and, with scripts, you didn't even mention spinners. I mean, I feel like there has to be a whole

[01:18:58] Dillon: Oh yeah!

[01:18:59] Jared: episode because there's spinners now.

[01:19:01] Dillon: True! There are spinners!

[01:19:03] Jared: yeah.

[01:19:03] Dillon: Everybody loves spinners.

[01:19:05] Jared: I need to use those. I, I use elm-pages scripts for publishing Elm Town episodes, so.

[01:19:12] Dillon: Awesome.

[01:19:13] Jared: Yeah, so, um, I find it quite useful as a tool.

[01:19:17] Dillon: That's amazing. Love that.

[01:19:20] Jared: Um, I only have one other pick. I'll just move on to that. The Elm Catalog by Alex Korban. And the reason for that is there's a whole list of tools on there, and those are broken down by category as well as Elm packages, uh, broken down by category.

[01:19:36] So if you are curious of all the things that are out there that have built up in this community because of all the inspiration, then you might want to check that out. But otherwise, I want to say thanks for coming to town, and thanks to Evan for creating Elm, because of course, we wouldn't be doing this without him.

[01:19:59] And rate and share if you're enjoying the show. You can listen to the backlog of episodes of Elm Radio as you, as you wait patiently, um, for new ones. So, yeah, I'd definitely go back from time to time and check those out. So, yeah. But thanks, Jeroen. Thanks, Dillon,

[01:20:19] Thank you so much!

[01:20:20] Jeroen: Thanks for tending to this town, Mayor Jared. Until

[01:20:25] Dillon: was a pleasure. Until next time.

[01:20:28] Jeroen: Until next time.