Joe: I've been having a lot of fun with elm-codegen, so shout out to elm-codegen. Thank you. I'm perennially confused using it, but I'm having a lot of fun.

Jared: Hey, folks. Welcome back to Elm Town. I'm your host, Jared M. Smith. We'll be visiting with Joe Thel today.

[00:00:17] Disclaimer: AI & Publish Time

Jared: Hey, folks. I just wanted to give a quick disclaimer here. Joe and I recorded this episode November 7th, 2025, and I'm about to publish it about a year later. And we delved a little bit into the topic of AI. Nothing too extreme. Uh, we definitely had a healthy degree of skepticism and care for human connection, but our comments are a bit out of date, of course, and so beware of that, and I hope you enjoy

But first,

[00:00:50] Sponsored by Logistically

Jared: let's talk about our sponsor, Logistically. At Logistically, we make intuitive software to help logistics teams make better decisions and improve efficiency. 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@logisticallyinc.com. I'll put a link in the show notes.

[00:01:11] Introducing Joe Thel

Jared: Now, let me introduce Joe. Joe Thel is a staff software engineer at Deepgram, a voice AI company making text-to-speech, speech-to-text, and voice agent APIs. He writes Elm at work.

He also wrote his personal blog, joethel.com. That's J-O-E-T-H-E-L.com, using elm-pages. Joe, welcome to Elm Town.

Joe: Thank you for having me

Jared: Yeah, I really appreciate you coming on. Um, a little bit of backstory here. We met at Elm Camp in Michigan, summer of 2025 this year as we're recording this, and, um, I got to hear a little bit about your backstory, you know, how you, um, you just kinda casually, um, told me a little bit of it and I was like, "Hey, you know what?

Let's, uh, make this, uh, permanent and and bring you on Elm Town." Yeah, accountable even, yeah. Oh, oh. Um, I think about that a lot, uh, more than I should probably. But, um, anyway. Yeah, uh, I wanted to hear a little bit about your backstory. So how did you get started just, um, generally in computing and then we can move on to

Joe: Yeah.

Jared: else?

Joe: um, I, uh, I'm one of those sort of lateral entry people, I guess you call it. Uh, I, I started out, uh, I went to music school. Uh, I was, uh, an oboist. I was not very good at it, uh, but I was good enough to scrape by basically. Um, and it was fun, but, uh, being a musician, it, for me, was a little tough because, you know, month to month, I'd have a good month, a bad month.

So, um, I ended up finding a day job in tech just doing like technical support. Um, that sort of slowly transitioned into like some QA, some, uh, you know, database crawling around kind of stuff. Um, and then I just got a bug for writing software, basically. Uh, and then, uh, started, you know, uh, learning from the engineers after hours, writing more software.

It started with Ruby and Python, both of which are languages I've completely forgotten how to write anything in. Uh, sorry to them. Uh, and then just over time, you know, uh, ended up becoming an engineer and then one day found Elm and then found a job that let me do it, and now that's pretty much all I write.

Jared: Right on. Yeah, so you made that transition. Was that all in the one company where you were learning Ruby and what was it? Python, you said?

Joe: Yeah, yeah. Like at the company itself... So that was like a Rails company. Um, uh, and so people were very primed to teach me Ruby, but I was just doing, you know, like very classic like, um, what are those? You know, like Codecademy or, or those kind of things, just like in Ruby, 'cause I had people who were around to teach me it.

Um, uh, by the time I had actually like started working, I was entirely a JavaScript person. Um, uh, Node and, and React, pre-hooks React. Um, this is ancient history I guess now, but, um, I, I transitioned to Elm at right around the time hooks came out. Uh, so I tried them, didn't like them, and then went to Elm

Jared: Was that... Well, let me, before we get into the why Elm , um, so JavaScript. You, so you were learning Ruby and this was just kind of getting your, yourself acquainted with programming in general, but then you said you were really writing JavaScript. Was this at that same company where they were like, they need somebody or

Joe: Um, no, no. By that time I had actually, uh, left and I, I went and did a boot camp. There was a boot camp in the middle of this, which I kind of like elided over. Um, but, but that, uh, you know, at most boot camps, like your, your goal is mostly to get hired. Like, you wanna learn software, but, you know, it's, it's goal-oriented there in that sense, right?

And so JavaScript certainly in 2018 when I was doing this, it's like, it was kind of the obvious choice. Um, I, I don't know what else you would pick that would give you like the, uh, the widest range of options, right?

Jared: Yeah. Sure. Okay. And so I'm trying to understand this, uh, transition. I mean, obviously that makes sense with JavaScript, but now thinking about Elm, I'm like, okay, you learned Ruby, you learned Python, and then JavaScript, and then suddenly like, wow, types.

Joe: It's, um... Yeah, well, so it, it-- Yeah, well, types was new for me, for sure. I think, you know, when I was in JavaScript land, some of that was TypeScript too. Um, and my feeling on TypeScript, which hasn't really changed, w- w- is, uh, I love what's going on here. I don't really get it, and I would love something simpler.

Uh, I think, you know, there's lots of stuff like trying out TypeScript again from Elm, where I find, you know, uh, in Elm, I say like, "Well, I just wanna like make some enum," I'm trying to use gen-generic language here, and then like pattern match over it. And then I ask someone, "How do I do that in TypeScript?"

And they're like, "Well, just, you know, it's a couple of these like magic lines of invocation here, and then some settings in the compiler, and now you can do that thing." Right? Um, but TypeScript was an on-ramp for me, and I, I do actually have a lot of appreciation for TypeScript. Um, it was that, and also I was working in a, um, an environment that it was React, but it was like a hyper-functional React.

If, if you remember Recompose as a library. Um, it's basically like maybe half of your components are higher order components, as, as we used to call them in React. Maybe those still exist, I don't know. Um, but you would s-stack them up. You'd pass them into a composition function, um, and that was how you like defined an application.

Our utility, we didn't use Lodash, we used Ramda, kind of

Jared: Mhm,

Joe: kind of a corner case thing. But so like we had a lot of functional content in there already, um, and I was always like interested in functional programing to some degree 'cause I found it easier to, to reason about for me than, uh, imperative, I guess you would call it, and certainly more than object-oriented.

Um, but yeah, those were kind of like... I, I just had like all these little moments for me that stacked up, TypeScript, Ramda, uh, that for me made Elm kind of an obvious option. Um, especially at the time. Yeah

Jared: Yeah. I mean, that makes sense now that you mentioned that with TypeScript and then using something like Ramda. I haven't used that one itself, but Lodash had an FP version and that like, when I was like trying to figure out like how to, yeah, gain some sanity in the front end, and I was like probably 2017 or so exploring different options, and that was one of them that I looked at, was like, you know, like what kind of JavaScript libraries, how far will that get me?

You know, I was looking at Flow and TypeScript and all those things at the time, then I'm like, "Yeah." And then I found Elm and I was like, "Oh, okay, like that does, checks this and all that. Okay. Yeah, it makes sense." So yeah, and then you're, um, so you're kind of... It seems like this was a pretty quick transition though.

Like over what time period did all this happen?

Joe: It was fairly... I mean, you know, this was like, by the time I had a- was actually working in software, I'd only been working in it for like three or four years by the time I was writing Elm. So, um, not like phenomenally fast, but like for me it was like I was always moving in that direction ultimately.

Not, not that I was always conscious of it per se, but, but it was something that was continuously happening to me

Jared: Yeah. Yeah, I mean, that, that, that, um, makes a lot of sense to me. I definitely recognize that with myself. Um, but I, I mean, it was over a long period. I had-- I did-- I'm not lucky enough, I guess, to, to have, uh, had like 10 years of grind and then like, "Oh, okay. Wow, I found the, you know, the tool that I love." But yeah.

Yeah, I mean, that's really cool. And you found a job where they allowed you to write Elm. So maybe let's talk a little bit about that. Is that at Deepgram where you were first able to write Elm at work?

Joe: Um, so the way that went was I had, uh, you know, come across Elm independently. I, you know, knew a lot of the sort of like, uh, related content. I was a big, uh, Magic Readalong fan, that podcast if you know it. It's ages old now, uh, it... no longer recorded, but, uh, they use a lot of PureScript, but then Elm came up now and then as well.

Um, and so that was like my first exposure to it. I spent maybe like a couple of months like toying around with it. Made my, made my personal website in it. That was not the current iteration. It was maybe like two iterations ago. A, a healthy software developer, of course, rebuilds their website once a year.

Um, I don't know what it says that I haven't changed mine in three, I think. But, uh, but I, I had been messing around with it for a couple of months. I had a lot of fun with it. It, you know, I, I can yap about that later. But, uh, basically what happened then was I was telling a friend of mine, like, "I'm, I'm writing this language.

I, I really love it. I would love it if I could come up with a way to use it at work. Um, um, and if not, you know, that- that's okay, but like I'm having a lot of fun with this language." And then he said, "Okay, good luck on your job hunt, LOL." And he sent me a link to a Stack Overflow jobs board search, which I don't know if that even exists anymore, but for a little while it was there, and some people advertise on it for some reason.

Uh, but there was, uh, he, he sent a link to that job search, uh, filtering for Elm jobs, and there was one result on it, which was Deepgram. Uh, which is how I learned about Deepgram, uh, and then, uh, eventually how I also ended up getting a job at Deepgram. Uh, uh, and that's, that's what landed me there, basically.

Jared: So it was sent a- as like a joke.

Joe: Yeah, yeah. He was like, "Look, there's one company." And I was like, "Well, one is more than zero, so let's make it happen."

Jared: Yeah. I mean, that's obviously a different mentality than a lot of folks would have. They would see that and be like, "Oh, well then I guess that's not viable." But you saw it as an opportunity. Yeah, I

Joe: Yeah, I mean, you know, I, uh, and I, I say this to people when we interview them, right? 'Cause the, they, they have the same question about like, "Well, I get that Decred uses Elm, but like I won't work there for 40 years." And from my perspective, uh, once you're at a, at a certain level of software engineering, and if you're really like learning it, then I don't-- I think that people are not really gonna be that picky about the languages that you came from, um, as long as you're not picky about the languages that you go on to write.

Do you know what I mean?

Jared: Yeah. Yeah, for sure. That makes sense. Okay.

[00:12:01] Question from the Deepgram team: Pitching Elm

Jared: And so this leads me to a question from Brian Hillis, a co-worker, a colleague at Deepgram. Um, and actually he sent me a whole bunch of questions, and I'm not even sure. He said like, you know, it was like him and the team, and so he didn't take credit for this one specifically.

So, um, I'll just say that, you know, he gave it to me. Anyway, it is, quote, "Classic Elm community experience, pitching Elm to leadership, getting buy-in, and using it in production. Are you still happy with that decision? Any advice or stories about making it successful?" End quote.

Joe: Um, I am. I, you know... I think... So to talk about how I ended up having at Deepgram, uh, Deepgram was already writing Elm when I showed up. There were existing Elm projects, but, uh, I came on to kind of work on our like, uh, product-led growth or self-serve motion, um, meaning like, uh, you know, a website where you sign up yourself, get some free credit, uh, make an API key, and then, you know, use our services.

Uh, when I came in, uh, I met with Scott, CEO, and Natalie, the now VP of product, uh, and we just talked about, uh... They wanted to hear from me, like what technology I wanted to pick. And I had sort of actually quietly to myself interpreted that as like, "Oh, they want me to like, make a more conservative choice."

Um, like, like maybe they want me to do React because I've already written it before, or like Vue because there were some Vue projects at the company too. Um, uh, so I came in and I talked through like, you know, what I thought would be, um, the advantages of picking one or the other. Uh, I guess my advice on like pitching Elm or pitching any kind of technology that you wanna use is like, be honest about it.

Um, part of why we ended up using Elm was I enumerated a bunch of cases where I think that Elm is not really a great fit. Um, I think there are a couple of technical arguments in certain cases, and I think there are culture arguments for sure. Um, uh, but all of the reasons that I described for not picking Elm were not reasons that applied to us, and so we ended up going with it, and that was, that was about it.

Um, and then I think as far as like, you know, pitching a thing and not regretting it, you know, you, you find yourself not regretting it by constantly reconsidering it, basically, right? Like if I had said at the beginning, like, "I think we should use Elm," and then we just never thought about that choice again for the rest of time, then obviously somebody's gonna come in, new hire three years later, and say, "Well, why'd you do this?"

And you're gonna go, "Well, we're just kinda here," right? Um, so you constantly have to reassess it, I think. And, uh, I, I think that's kind of the, the nature of it.

[00:14:50] Web components

Joe: Um, I will also say that part of... I think that there's a different history where I was less happy picking Elm, and that's a history where web components don't exist.

Uh, it wasn't something that, that I was totally aware of when I joined, how much I would like really rely on web components. They're a really minor part of our applications, but the part that they like serve is so critical for us, and I think that Elm would be, uh, substantially more painful if we didn't have them.

Jared: Interesting. Yeah. So let's get into that a little bit. So what are the specific cases where you use web components

Joe: Sure. There, there-- I kind of like, I think of them as, like, two different, like, classes of, um, of web components that we need to use at Deegram. One of them is, like, a, a super general case that I think applies to everybody, which is, um, that you just have, like, leaf elements that you want to zhuzh up a little bit.

Um, and to, like, move into the sort of pseudo component territory that Elm offers is kind of a pain or maybe just, like, more pattern than you want. So, like, a, a really easy example is, um, we have, uh, like an expando, right? You know, a little button, you click it, it expands, collapses. We want to animate that.

Animating that smoothly when the content of it is dynamic means that you have to measure it in JavaScript. You can measure it in Elm too, but you are moving out into either, uh, you know, subscription territory or import territory. Um, and then to do that in a sort of, like, modularized, componentized way, you are putting in a lot of machinery where if you just used a custom element, you're, you're writing, like, eight lines of novel code maybe.

Um, so that's class one, which is, uh, zhuzhed up leaf elements. And then class two, and this is a Deegram-specific problem, although not unique to Deegram, is, uh, we have, like, a lot of stateful JavaScripty things to deal with. Mostly, uh, WebSockets, microphones, uh, audio contexts maybe more generally than microphones.

But, uh, obviously as an, as an audio-focused company, Deegram has a lot of these, uh, features that it needs to build. Uh, and, you know, if you're gonna use a WebSocket, well, you're bouncing out to JavaScript no matter what. And, and we found that web components are really, um, probably the... I, um, okay, personal opinion, but I think the best way to manage that rather than ports and then having a socket manager that kind of live as, like, freestanding code

Jared: Yeah. Yeah, I mean, that makes sense. So you have these two different cases where you really get a lot of benefit from using them. Um, are you doing anything fancy with them? Are they just basic, like custom elements or

Joe: Super simple. We've talked a bit about like, um, pulling in a framework or something, but right now we're just sort of, I guess, vanilla web components. That sounds kind of silly to say. Um, but, uh, yeah, we just make them ourselves. You know, generally speaking, they are, once you get a handle on them, uh, not so hard to work with.

I think the first time you get to it, you, you, you might get tricked into thinking that it looks like, uh, a React component or an Angular component, uh, and start thinking of them that way, and they're not quite that way. They're pretty close. There's, there's obviously a relationship in, in the origin of thought that led to those technologies.

But, uh, once you get used to them, I think that they're, they're pretty straightforward as a way of, uh, I guess you could call it shelling out to JavaScript

Jared: Yeah. Yeah, totally. And there's one use case I thought of with this, with web components that we use that I don't know that I've talked about before, but might be kind of unique, is, um, we have this little date range picker thing that we wanted, and it's in Elm, I found it. But it uses a li- a mo- a package that has a module name that conflicts with another one that we already have in our system.

Joe: Yep.

Jared: and

Joe: I've lived that life. Mm-hmm.

Jared: yeah. And so I was like, "Well, if I want to use it, how do I use it?" And so that was my thing. I was like, "Well, I'll just wrap a thing around it," you know. Like, I'll make this Elm thing a web component and use it still in Elm.

Joe: Hmm. So you have Elm, Elm in Elm. Elm hidden behind the Elm

Jared: Yeah. Yeah. It's, you know, disconnected in that way. And I think that's also a way to get those...

Like, if you want to do those leaf things, but you want them to be Elm, sure, no problem. You know, you can still animate them, do all that stuff in Elm. But then you sort of disconnect that wiring, and my rubric for doing that is, a rule of thumb, I guess, more, it's just,

Joe: Sure

Jared: how often do I need to do this? If I'm only going to do this, like, a couple of times, then just do the wiring, right?

Like you said, the machinery. Not, not a big deal. But yeah, if it's like a leaf thing, like a, you know, a select is something that I think about, um, could, could benefit from just, like, disconnect that completely. Let it do all of its things that are, to me, something that the browser really should be do- You know, it's sort of like this is something I want to be native.

It's something I use over and over again. I use it multiple times, every page. Just, you know, put... I mean, just, you know, just, just do this, you know. I mean, there, there's, there's definitely work, um, involved with it, and you have to sort of keep those things in sync. Uh, there could be some neat tooling, I think, to, to maybe generate some of those edges where you want, like, that, that API to be nice, um, like what Dillon's done with, um, with Elm and, and TypeScript.

But, um, anyway, yeah, I j- I just, you know, we're thinking about web components and, and cases where they should be used and, yeah, I think that there's definitely... Why not, you know? Like, why not make the, the job easier? Sorry, go ahead.

Joe: No, 100%. I mean, I think the Elm and Elm, uh, trick that you've pulled is really interesting because I've been thinking about that in the abstract. Like, the level of thinking about in terms of like, you know, you like wake up in the middle of the night and you realize you've been like thinking about programming and like nothing is actually coherent.

That level of coherence I've been thinking about, like how do you get code splitting in Elm? Like if I have like a second quote unquote application that I want to run in my bigger application that's fully discreet, is a web component like a technique that I can use to do kind of like an iframe in, uh...

For those just listening and not watching, I'm doing some scare quotes there. Um, uh, uh, I, I think that web components are a, a very, uh, transformative technology for Elm design. I think without them, Elm code today looks different than it does now. I think that applies generally. I think that like, uh, the projects that I work on are, are maybe more impacted by that on average than other projects, but, but, but I do, I'm a, I'm a, I'm, I'm a big believer in them.

We also use them for, uh, you know... And this is back to the like picking Elm and like, are you going to be happy with it forever? One of its risks obviously is like the ecosystem's smaller. There might be something that is not exactly what you want. Um, uh, we also use them for that. So like there's like a JSON viewer in one of our applications or two maybe.

Um, there are JSON viewers in Elm. Uh, for what our designers wanted, they weren't good fits. They just didn't really make sense for us. Uh, but there was a web component, so I'm just using that. Problem solved. I don't have to think about it anymore.

Jared: Yeah, totally. That's a

Joe: and then to keep rambling about this... Oh, you do? Yeah, yeah, yeah.

Perfect. Exactly, right? Um, we have a case where like Elm Charts doesn't fit either, right? We use Elm Charts, but, and we love Elm Charts, but there's a case where it doesn't work for us either. That's also, you know, we use a web component. Now, this is a little different because we're using that to pull in just like some JavaScript rather than a web component library per se.

Um, like that's just like Chart.js that we're pulling in for this like one use case basically. Um, but there's just like it, it's, it's both new functionality and it's also really great glue for sticking things that are not Elm into Elm in a safe way, in a really easy to encapsulate way, right? Um, and I think that's kind of the, the key of why it works.

I think if it required you to make your Elm less safe, it would... I, I mean, I wouldn't be using it honestly.

Jared: Yeah. Right. Sure. And then this, I mean, maybe we shouldn't go any deeper. I, I... What I think this is, is like, this is an, uh, an Elm Radio episode is what, is what this-- They're just talking about web components and how they can be used and, and benefits and all the different ways. Um, so yeah, Dillon, Jeroen, come on now.

Let's, let's do this. Yeah, yeah. Nudge, nudge. Um, but okay,

[00:24:08] Question from Deepgram: Fun stories with animation

Jared: so you mentioned Elm charts and, and how that works. There's a question from Brian Hillis here, quote, "You've done a lot of work with Elm charts and data visualization like orb animation and magic borders. Any fun stories or memorable hurdles from those projects?"

Joe: Um, those are little in-jokes for some, some animations that still exist and, and one animation that doesn't anymore. Um, uh, do I have any fun stories from that? Um, I don't know. I had fun doing them. I don't know if they're fun to talk about. I think, um, I think probably the most fun that I had making an animation is actually the one that's on my personal site.

Um, this is just like w- like the landing page of it. Uh, you can see it on your own, but basically what happens is, uh, page loads, uh, it says, "Hey," in, like a, what, you know, is, is rendered as like a series of independent dots that are like animated in. Um, oh, I'm so sorry, this is actually turning back into a web component thing, but that uses the wonderful Elm Canvas, which uses web components.

Um, uh, but that, that was a lot of fun for me because I had to figure out how to, how to do it. It, it ends up being fairly straightforward in the end, which is that I like render some text off screen. Um, I bounce that image to get like the pixels and their like positions in that image, and then I use that to like draw a bigger canvas and then, you know, each, quote-unquote, pixel is like a dot in this thing.

Um, that's probably the most fun that I've had. Uh, I think that like... I think animation is a great way to challenge yourself to be really, really precise in like the visual realm as a programmer. Um, like my-- This is not animation, but like one of the first things I had to do with this boot camp that I attended was I had to take the Google landing page, and I had to like make my own website that was like a pixel perfect duplication of the Google landing page, um, at any screen size.

Uh, that's not phenomenally hard, but it-- Like having to go into that level of detail and that level of precision, which I think animation de-demands of you kind of automatically off the bat, makes you think about, uh, how much of good front-end programming is, uh, math. Not super hard math, but like, uh, really, really rigorous algebra, I guess I would say.

Um, uh, and I, I think that those are really great... For me, I've always found those like really satisfying challenges to like look at something or hear something that a designer describes and saying like, "How do I come up with like a, uh, a way of making that real that, uh, is performant and still looks good?"

Um, 'cause those are-- those can often be at odds with each other, of course. Um, that was a rambly answer, but

Jared: Yeah. No, that's good. I love it. And you're able to bring web components back in. That, that's, yeah, that's

Joe: Any day I can make it happen

Jared: And so you... I mean, your history, you talk about being, have this, you know, music. You were studying music and then getting into this, and you're saying like... I mean, a part of it makes a lot of sense where it's like you're, you're trying to emote something, you know, to the world with maybe a visualization or a, an animation.

But you talk about the math and how enjoyable that is. Did you have that for, like, throughout life, or is this something that started when you started programming?

Joe: Um, I really, really liked math when I was a kid. Um, I also, uh, didn't do my homework. And so, uh, for me, it was like something where I eventually kind of felt like I've done enough math, and then I stopped for a decade, and now I just do, like, a little math for fun. I don't do any of the, the, the hard stuff.

Um, I guess I do some trig. That's probably about as bad as animation gets, is trigonometry, I'd say, w- which there can be a lot of it. Um, but I also think it ties into music too, because I think, especially with, like, animation and not visualization in general, but, like, animation is about rhythm. Like, most animations are repeating.

They certainly have timings. Uh, there's like a-- there's a physicality to them, underneath them, uh, that, that I think j- you know, for me, it kind of makes sense that I would, that I would find those, like, engaging. And also, I'm essentially, in so many ways, a child, and so when the pretty lights are on the screen, I have more fun

Jared: Yeah. Well, me too. I mean, I, I think if you're not, that-- I don't know. That's just not a very fun way to live if you... Yeah.

Joe: Grow up. Grow up and look at the pretty lights

Jared: Grow up and be a child again. Come on now. Um, okay. So bringing this on, we've talked about some things sort of tangentially related.

[00:29:29] Novelty budget

Jared: You mentioned using React early on. There's another question from Brian and the crew. Um, it is, quote, "At Deepgram, you've worked on some non-Elm projects. How do you decide when to use Elm versus something else, and what stands out when switching back and forth?"

Joe: I'll start with the second question. One thing that stands out when switching back and forth is that the React I've come back to is not the React that I knew. Um, I, I, I would've said, you know, at the, at the height of the, uh, class base React era that I, I really had a handle on everything. I think when I come back, I'm always really surprised by what Hooks has done to the framework.

Um, it's... I used to just, like, knit at it 'cause I was like, "Oh, now all your components are functional, but they're not pure functions, and, like, what's the point of a function if it's not pure?" And I do believe in that, but, like, uh, it, it's more for me, I'm always surprised by how much I'm doing, like, effects management.

Um, you know, effect X triggers effect Y, triggers effect Z, and it's just sort of like it, it is happening in an order, but it may not actually happen in a, like, literal order in your file, and that's okay. I mean, Elm is like that too, right? It's like message A may trigger message B. Um, I think that's inevitable.

But somehow in React, I think because of the whole, like, dependency array thing in, in Hooks, it's just... it's something that I've always really struggled to believe in, even if I, like, kind of understand it. Um, but to back out of that to, like, how do I pick, um, I think one thing that's always so important to remind yourself when picking a technology is that no matter what you pick, probably no one's using it in 10 years. Um, and that's true at, like, a, um, a code level. Like most patterns cease to exist after 10 years. But it's also true at, like, a, just a product level, right? Like most things get, you know, rewritten, companies go away, uh, things change, and I think it's important to keep in mind that, like, uh, th- it's not life or death what you pick.

Uh, because if you decide that it's life or death, you will always pick the thing that you don't like because you think that that's more responsible. Um, and it's probably not actually more responsible, but you're, you know, it's, it's just like how the instincts go. You know what I mean? Um, and then the other... Yeah, yeah, yeah. It's like, I mean, it's the, it's the classic like nobody got fired for choosing IBM. I'm the one millionth person to say that on a podcast, so I think I get something for that. But, um, it-- And then the, the actual like thing that I, I try to keep in mind is there's this great article about, um, ooh, how does he phrase it?

Like novelty tokens, I wanna say, or novelty budget. Um, but the idea is that like when you are starting a new company, a new project, um, that you have, you should allot yourself three novelty tokens. Um, uh, each time you choose a novel technology, that's going to cost you a novelty token. And so that novelty token might be Elm, it might be a graph database, it might be microservices, like just as an architecture.

Um, and then once you're out of novelty tokens or if you want to save your novelty tokens, you should be making a bunch of boring choices outside of your novelty. Um, you know, to, to take the exact same things, picking React, picking Postgres, uh, having a monolith. Uh, now there's a great response article to that, that actually, uh, the, the original article about novelty tokens I think links to, um, which is about like how that ends up actually looking in enterprise.

And this is my real belief now, um, is that n-novelty tokens or like choosing a novel technology is a, an immediate cost, but it is also an investment in increasing your novelty budget in the future

Jared: Hmm.

Joe: more you invest in unusual technologies, the more ready you are to experiment with additional ones. You might not stick with them, but it's, it becomes cheaper to do so

Jared: Yeah, that reminds me of a talk from elm-conf 2018 Grant Maki. He's an engineer at Ford, and he was talking about how you facilitate technology change through cultural change and, and how having a sort of culture that is open to having some novelty of, you know, trying things, making experiments, then you, then you can sort of do that, right?

It's like you can only do it if you create that culture and if you cultivate and maintain that culture. So yeah, that

Joe: 100%. Um, and that, that, that is resonant for me. I, I said offhand earlier something about, like, there are technical reasons not to choose Elm, and there are cultural reasons not to choose Elm. And I think some companies exist that do not want that culture, right? And it, it's very easy to be moralistic about that and say that, like, everybody should just have, you know, a fun, good culture.

But, like, sometimes you're a company that, like, needs a programmer every, like, two months out of the year, right? Should it be that every new programmer that, like, comes onto this job is, like, going to spend, you know, two or three weeks on-ramping to this novel technology? I don't think that's really fair to them.

If they're interested, cool, but are you gonna find an interested person every year? It's a big constraint to put on yourself. And so I think it's important that you want that culture, and I think when you see people abandon novel technologies, it's because they figured out they didn't want that culture, right?

They saw the culture happening and said, "Actually, I don't really want this culture." Um, and again, I'm, I'm not trying to put any sort of like, uh, judgment onto that, but I think that's how you see people abandon a novel technology. As I think it's, it's, it's almost always a cultural reason

Jared: Yeah. Yeah, that makes sense. And then there's this other side that I was thinking as you were talking about boring technologies. Like for me now, that sort of is the boring choice, right? Like

Joe: Oh, Elm is my boring technology,

Jared: Yeah. Yeah. It's, it's funny. It- it's novel in like the general sense, but for me, I've been doing it long enough now that it's like, yeah, I mean, that's like just the choice, not because of anything other than like that's my experience, you know, my, my own experience.

And, um, and yeah, if I were to use React because I've never used w- React at work and only very lightly touched it, so like for that, for me, that would be very novel. Uh, and same with Vue. So yeah.

Joe: is quite true that you, like, you have to think of novelty as, like, what's novel around you. Um, like we, we took on a big project at Deepgram that was in React, um, that made sense to do. There were people available who were quite good at React, and we... The most important thing for us was, like, just deliver this early.

It doesn't have to be everything that we want because this is experimental. Um, we just wanna have something to, like, get out there and learn about people. Um, and it won't be a product that we're maintaining in three years, right? And so tho- those two things together for me, I was like, "Okay, that can be React," right?

'Cause it's like we have a much wider base of people who can work on it off the bat, and I don't have to worry about what it looks like in three years, which is a big reason why I pick Elm all the time is 'cause I do care about what the thing looks like in three years.

Jared: Yeah. Yeah. When you say what it looks like, I assume you don't just mean like the visual appearance to users.

Joe: looks like,

Jared: Yeah. Yeah. A- and the, the patterns like you're saying, like, um, if you're using React in, in three years, there may be libraries and things that have sort of moved on. They've, you know, migrated to a different thing.

And c- certainly with Elm, at least so far for several years, it's been the case that, you know, those upgrades, those things that like when you come back to a project after a year and it's like, "Oh my gosh, I can't upgrade this anymore because it's been too long."

Joe: Yeah.

Jared: It's not a problem, I guess, with Elm is what I'm getting at.

Joe: yeah, 100%.

Jared: Yeah.

[00:38:10] Artificial Intelligence

Jared: Okay. Um, and so this, um, makes me wanna talk a little bit about AI, and I say that of, of course, Deepgram as, as in a company, uh, is into doing those things, right? I mean, that's like the core thing is, is doing that. But I think about like if I'm having it, AI do some helps or some agentic editing or, you know, some cool kids are calling it vibe coding, but I mean more of like just, you know, assisted editing.

Joe: Sure

Jared: Have you done any of that? Is, have you had an experience with that?

Joe: I've done a little. I, um... When I, like, started learning to program, I learned from people who worked like it was 1980, and so I now work like it's 1985, I guess. Um, so like I'm, I'm in Vim. I'm not even in Neovim. Like, I, like I'm, I'm stuck in history in a certain way. Um, I do use AI. For me, I, I tend to use it as like, um, a pre-Google almost, uh, where it's like I'm, I'm not sure what I'm thinking about, I'm trying to formulate it, and I let, I let it help me formulate it, and then I spend the rest of my time on MDN.

Like it... That's most of what my AI, uh, use is, looks like these days. Um, I, I have experimented with it, like in, uh, in like, you know, code completion territory, um, mostly Copilot, and I have just was-- I found that kind of a waste of my time, to be honest. I, I think that like it's, it's helping me like complete case expressions, and it's usually right, but then also it's inserting Haskell code into my editor, and that's not what I...

I-- Listen, I love to see some Haskell code, but it's not real- I'm at work, and so it's not really what's supposed to be happening to me. Um, uh, I think that that'll keep getting better, obviously. Um, I, I, I know, you know, I have coworkers who actually have a lot more success with this than I do. Again, I'm like a caveman in this stuff.

Um, I mean, maybe not a caveman relative to like, uh, software in general, but certainly within my company, I think. Uh, uh, yeah, that's, that, that I think is like roughly a, a summary of my like, uh, use of it these days.

Jared: Sure. Okay. I mean, that makes sense. I've used Copilot, had varying degrees of, of success. But recently I've used some of Zed's, uh, AI agentic editing stuff, and, uh, what I found... Uh, I found that there are some things that it's really useful for, especially in Elm, and this is kind of why I brought it up, like we're talking about Elm versus other things.

And I find it especially good with Elm because unlike something like Copilot, where it's just like making a suggestion and then, like, you have to go review that suggestion before you insert it into your code, it's like you can tell it, "Hey, go do this thing," whatever this thing may be. I, I usually try and keep it fairly small thing that it's doing, but I have it go do it and I say, you know, "Check against the diagnostics, check the Elm compiler.

If you find an error, listen to the Elm compiler and fix it." And it, it... Sometimes I have to reiterate, you know, tell it, "And remember, did you go back to the Elm compiler?" And a- and but when it does, I feel like I have a much better result than saying like, "Hey, go write some Python code for me." And then it's like it, it doesn't know if it's got it right.

You know? Like I, I, I have to tell it to make tests, and then I have to verify the test before I can even get to the point that I want it to

Joe: Yes. Yeah,

Jared: because I don't trust it

Joe: yeah, and, and I mean, you can't trust it, right? I, I think that like... So I, I have done lots of like, like true vibe coding experiments where it's like, I don't look at the code, right? I just say like, "I'm gonna go get Windsurf and I'm gonna go tell it to do some stuff." And it is plenty of fun, and then there is like some point in time where it becomes unable to accomplish anything anymore.

And that's fine, but I don't wanna look at the code now, right? It's doomed. Um, I think something that Elm gives you is, well, of course, if it compiles, it's correct and there's nothing to change anymore. It is more seriously like it is a, uh, it, it, the compiler must be useful for an LLM, right?

Because it is useful for us. Um, and an LLM is not us, but it is something that's operating in natural language, and Elm's compiler is good because of the amount of natural language that it is outputting. Um,

Jared: Bingo

Joe: so, uh, I, I think that, like, uh, I've always been a big better on like AI being good for Elm even if the corpus is tiny, right?

Like, we say that it's good in Python, and it is good in Python 'cause the corpus is huge, but it is not good at maintaining Python. Um, I don't think it's gonna be good at maintaining Elm, but I think Elm is good at maintaining itself

Jared: Yeah, and that's where I find it to be useful. It's like if I have it change some existing code, well, I mean, for one, with Elm, yeah, if it compiles, it works. I mean, it may not make sense like you said , I mean, as you alluded to, but like it, at least I, I have something that I can test against. You know, like I can do it in the browser.

I can, you know, actually do some, uh, write some tests. But,

Joe: Yes

Jared: like with Python, I mean, it, you know... Yeah, I mean, it has such a, a large group, but the Python that it writes may be a completely different style 'cause the Python's been around a long time. It's got a lot of different ways to do the same thing.

You know, like I don't want it pulling in new libraries to do things that these existing libraries already do. And so my ability then to like recognize, "Hey, this is the tools we already have. This is how we do it." The same applies with Elm too. It's like, "I, I want you to do it this way. Like, here's an example.

I want you to do this just over here." You know, I want it to do some rote work that I just, you know, I, I don't necessarily wanna do myself because it's just, you know, it's mind-numbing work. Which sometimes I do wanna do that, you know, that's, that can be cathartic. But a lot of times it's like that's kind of, it's not novel, you know, in the sense of like what I'm, I'm writing, um, and the pattern's there, so.

Joe: and like how, setting AI aside, how many times have people said that, like, "The thing that I like about Elm is that there's one way of doing something," right? Like there, there are good patterns and it is hard not to end up on them, right? And so that, you know, it seems like what most people want from their vibe coding experiences these days is to constrain the LLMs in whatever ways they can.

Um, and so I, I think that Elm is perhaps not uniquely suited, but exceptionally well-suited to accomplishing that. Um,

Jared: Yeah.

Joe: that, that's my feeling on it.

Jared: Yeah. Yeah. I mean, that's, that, that was what I was trying to get across, I guess,

Joe: Yeah. And you, and you did, I think

Jared: yeah, and, and that like the natural language, and you said that so well, the way that the compiler error messages are written, it's so easy for the LLM to understand just in the way that it's easy for me to understand as a human being, you know?

Like that it has that same type of quality. Um, but yeah. So then you all are doing AI related to text-to-speech, speech-to-text, and voice agents. How much of that n- is like, how much do you actually work in that kind of thing? Like how much of that knowledge do you have to n- have to do your job?

Joe: Mm-hmm. Sure. Um, little. Relative at least, right? Like, uh, obviously, like I, I have like more than like lay expertise in these things, but, um, ultimately, I'm a guy who makes websites, and so, uh, I have to learn a lot about our APIs, and I have to, you know, know fundamentally what our research team's up to. But there's a research team.

There's-- There are engineering teams about productionizing research. Um, what, you know, what I do and what my team does is we try to disseminate that, right? So in some sense, there's like an educational capacity, and that's why it's important for us to understand how these like different kinds of, uh, let's call them...

Like as a, as a, as a unit, let's call them like perception models work. Um, uh, but our, our job is mostly to get those in people's hands, let them see what happens when they have them, um, and let them understand what, what they're good at, what makes them good, where to put them. Um, uh, yeah, that's how I'd put it.

Jared: Okay. Yeah. And then you all, I mean, the, the way that Deepgram works, I don't know if folks understand this, and I don't understand it, so that's why I'm asking, is uh, I believe that you train your own models, right? You're not relying on any existing...

Joe: Yeah, no, we-- all, all of our models are our models. Um, uh, we have like an archaic endpoint that supports Whisper for people who really, really like Whisper, but it's not really a product of ours per se. Um, uh, we train speech-to-text models, text-to-speech models. The voice agent API is a little different because, like, that's not a model per se.

Um, that's like an API gateway, if you will, but for sort of, uh, sonifying agent relationships. Uh, like we, we think that, you know, okay, chat's nice or whatever, but we think voice is the interface that is going to like matter a lot for this. And so that's what that API is about. Um, we do build specific models, uh, like Flux, which we just released.

I'm not pitching, uh, but, but Flux is specifically about like turn-taking detection, finding out when people are done talking, and that's a-- that's about improving the humanness and the latency of agent interactions, right? Um, but yeah, like at, at its core, what Decrim is selling is models that it develops itself.

Jared: Yeah. Yeah, that's what I thought. So yeah, that-- I just wanted to bring that up as to understand a bit about the context of the company and understand that like, you know, it's not like a company that's using Anthropic and using, you know, OpenAI tools. You, you're, you're doing your own thing, um, specific to these and, and I think that's, that's really interesting.

And I think then you are-- your company, I don't know about you specifically, so this doesn't necessarily apply to, to your position, but I guess as a company, we talked about this a little bit, and so you may remember my concern is, is always with like, what's the sort of energy use, right, of, of these things.

And, and we got a little bit into that and, you know, from a high level, I thought it was interesting, um, just thinking about like, okay, what, you know, like, where are we going? Like, how, how are we doing in terms of making these things more efficient? And, and again, I know this isn't like your specialty area, but we talked about it a little bit before.

You had some knowledge, and I thought

Joe: Yeah. I, I'm happy to, to, uh, bring my low competence on this onto the record so that people can keep hearing it forever. But like, um, I think-- So one is like a more general statement. Uh, there, there's a perennial problem of talking about AI as in LLMs and talking about AI as in generative models, right? Um, so if you look at Deepgram today, for instance, Deepgram does not sell an LLM.

That is not a product that we have. All of our models-- Almost all of our models are generative transformer models. They are fundamentally the same technology, um, just applied in, in dramatically different spaces and for different purposes

Obviously, when we talk about AI and we're talking about I-- LLMs, we're mostly talking about, um, their development over the past few years, which has strictly been about increasing their size. Um, and that's been a really interesting conversation because as we increase their size, they take on new capabilities that were hard to predict they would be able to take on in the first place.

That's cool, but with that, you have to also talk about the fact that these things are continuously using more energy because increasing the size is essentially always increasing their energy consumption. Um, I think if you aren't looking at LLM specifically, uh, the wider space of generative models, a big thing that people are talking about is making these things faster and cheaper.

Um, you know, the, the holy grail of a lot of this is like edge computing, right? Like running this on people's devices. And for that to happen, it necessarily must be cheap. Um, and so that's a thing where it's like, you know, a lot of what Deepgram does, and I don't think we're alone in doing this, is we are trying to develop models that, um, are always better than the last generation, but then also faster.

And if it's faster, it's sort of inherently using less energy because, I mean, ultimately, like flops are what take time and also energy. And so, uh, I think in, in like the wider space of generative models, you actually see a lot of investment in, in reducing energy use because there's like an, an incentive to do so because you, you wanna get people the results faster ultimately.

Um, I think once you take LLMs into account, and of course, those are the biggest models out there, uh, that narrative's totally different, right? Um, but that, that's sort of like my, my view of the field.

Jared: Yeah, sure. And definitely from my perspective, the ability to convert text to speech and then speech to text, it affects me both as a podcast person because, um, I use a lot of those technologies to transcribe and then do my editing through that. And, and then with my software development, if I'm, uh, doing some kind of, you know, putting something into a text box for, uh, an agent to go and work on, a lot of times I like to use voice to, to do that, to, you know, put those in there.

Or even into Slack, like if I wanna send a Slack message, I will, you know, use voice to do that. And the reason is that, uh, I've been coding a long time. I'm getting some gray hair here. Um,

Joe: Your pink, your pinkies are getting weird, right?

Jared: yeah, yeah. I mean, I, I, I've had some things. It's like, it's been a while since I've really been in, in like the depths of that pre-Elm days.

Um, but, uh, I still have to kind of sort of maintain and like take breaks and all those things in order to keep myself out of the, the crypt there. Um, and so yeah, for me, from an accessibility standpoint, I, I definitely see the specific technology that Deepgram uses has a, a, a fundamental,

Joe: percent

Jared: yeah, um, use case that I think of a lot of other ones like, you know, I, I don't necessarily like need to go ask a question and then have it summarize, you know, a bunch of AI-generated slop, um, that when I go and review it, it's not, it's not, um, not even, you know, real, the things that I'm getting summarized.

Anyway.

Joe: Yeah. And it's like, I mean, that's the thing, right? Is that like, there's, there's clearly like people are trying to generate a market too, right? I think what drew me to Deepgram originally was that, you know, I, I almost looked at it as like, oh, I can work at a utility company. Like that's how I thought of it was like, um, like speech-to-text and text-to-speech, like these are like two technologies that like we have been working on for a very long time, very obvious use cases.

Um, and I... Well, I just-- Boy, I love delivering value, but, uh, th-those were things that I saw had value, you know? And so it's like, oh, I, I love the idea of just like I'm working at a place that is, um, in-investing in making those things better and faster and cheaper all the time. Um, yeah, ramble there

Jared: Yeah, that, that's fair. Um, okay, so let's see. Uh, is there anything else you wanna talk about?

[00:55:17] elm-codegen: Rediscovering the feels of "compile-time", active vs. passive

Jared: What, like, what are you excited about right now?

Joe: Hmm. What am I excited about? I feel like I told you there were two things that I was excited about, and one of them was web components. Oh, elm-codegen. Well, we don't have enough time to get into that.

Jared: CodeGen. We- sure we do. Why not? Yeah, elm-codegen's great

Joe: Fair, fair. Um, yeah, I've been screwing with it. I've, uh... This is like I'm-- I have to constantly reel myself back when I wanna, like, say that there's, like, something I wish Elm had, because a lot of the time when I want Elm to have something, it's just because some other language I have has that thing.

Doesn't mean it fits, right, in the ecosystem. And what I'm in the middle of with that right now is all of our backends at Deepgram are in Rust. Uh, you know, would I say that Deepgram is an Elm company? Mm, I don't know. My team is an Elm team for sure, uh, but Deepgram is definitely a Rust company. Uh, there is a, a ton of Rust code out there, and, uh, for, for those not familiar with Rust, there is a, uh, library that pretty much everyone uses, although they all pronounce it differently from each other, Serde or Serde or, uh...

Well, I'll, I'll go with just those two. But it's a serialization/deserialization library, and it uses, uh, what else? The macro to generate the serialization and deserialization code for structs and enums that you define in Rust, which roughly correlate to records and some types or custom types in Elm. Uh, I have a lot of problems with Serde because I look at the macro and I say, "I've got no idea what kind of JSON is gonna get generated from this," or, "I have no idea how I need to format my query string such that this thing will understand it." Um, but it certainly saves people time writing code. And so despite my qualms, I have been screwing with elm-codegen to do something kind of like that, um, for, for some of our Elm code. Uh, and I've only been doing it with primitive types, uh, and I'm, I'm constraining it to, like, a very specific area, which is, like, our feature flagging module because those are primitive types and you don't really want to make those custom.

I guess that's a conversation in and of itself, but I, I feel like you don't want to. Um, and I've been having a lot of fun with elm-codegen, so shout out to elm-codegen. Uh, thank you. Uh, I'm perennially confused using it, but I'm having a lot of fun.

Jared: Yeah, that's fair. I'd say that's familiar in the-- that I enjoy using it, but at the same time I'm always like trying to wrap my head around like what I just did and

Joe: I think it, it's fun 'cause it's like, I think that y-you and I have both been in this space for a long time, right? And it's like y-when you think about teaching, one of the big problems with it, or challenges I should say with it, is that like it's hard to remember how you felt on the other side, and it's hard to remember which things were hard for you to grasp and which things were trivial.

Um, the fun that I'm having with elm-codegen is I'm remembering the experience I had when I discovered compile time.

Jared: Mm-hmm. Okay.

Joe: when I was early in programming, I, uh, as I said before, I came from like scripting languages, right? And so at some point I started... I, I think probably my first compiled language that I had screwed around in was Haskell.

Um, but, uh, I was learning about like this is happening at runtime versus this is hap- quote unquote, "happening at compile time," which m-made no sense to me. I didn't understand what that could have meant. Um, now with elm-codegen, I have a third layer, right? Some-something's happening at runtime, at compile time, and at gen time.

And so I'm back into remembering what it felt like to say something happened at compile time, 'cause I'm like, "Wait, is this happening at gen time or compile time when I, when I use call instead of the like native thing?" Um, uh, so I've been having a lot of fun with that. Uh, I think if I like look at the code that I've refactored to be generated instead, it's net green, which is not a great sign, but I'm improving it.

Uh, I, I think I'll, I'll have something that I, I like better soon.

Jared: Okay. Cool. And so what is it exactly that you're trying to generate again? A little bit more

Joe: Sure, yeah. So it's like, ultimately you could say that what I'm making is just like, uh, like a derive system for some primitives in Elm on records. But like the real point of it is that like we have a feature flags object in, in both of our like big Elm repos. Um, and it's just, you know, classic feature flags.

It's just like different things that you want to make available to users or not make available to users, um, based on like their, uh, like the query string that you link them. Um, but then you also want to like persist their setting, and so you wanna write that to local storage. Um, and so then what that means is that every time you want a new flag, you are updating, uh, a URL parser, a URL builder, a JSON decoder, and a JSON encoder.

And you've gotta remember to go to all these places, and some of them are easier than others, right? The decoder is trivial because you just extend the record and suddenly it's not compiling anymore. The encoder, a little tougher to remember. Um, and what I... We, we had set up a system whereby we could, we could get the compiler to guide us through all of those steps, and it worked perfectly well.

But, uh, I am always trying to write software such that I can forget it, and the problem that I had with that system was if I shut my brain off for one second, I would copy-paste something I shouldn't have been copy-pasting, and then suddenly I had the wrong flag name. And so, uh, for me, I think for like very primitive types, it's probably safe to have some magic behind the scenes and have some generated code behind the scenes that's like, well, Booleans are only getting parsed in and out of the URL in one way.

They're only going in and out of JSON one way. I just need the field name, and then I'm good to go. Um, and so that's what I'm sort of trying to build is like a codegen module that like takes a list of flag names, the type that they should represent, which right now is just Booleans or strings, um, and then generates a module that gives you that, that record.

It gives you your... all of your serialization/deserialization code, gives you some utility functions, 'cause like when we have our feature flags, it's nice to have like a, a little pop-up saying like, "You have these flags active. Would you like to dismiss any of them?" Right? Um, just kind of like various little functionalities over that.

And I've been finding that, um, what I'm able to produce with elm-codegen is, uh, working really well. It's scary, but it's working really well. Um, and at, at build time, it doesn't matter if something's scary, so.

Jared: Yeah, that's right. You'll find out if you did something wrong if it doesn't compile. In this case, I think that's definitely true. Um, okay, so I, I think I understand it better. What is the single source of truth for the-- Or is there a single source of truth for these, um, future toggles?

Joe: Uh, like in the code gen mode, you mean? Like

Jared: Just like,

Joe: I'm working on or?

Jared: what goes into codegen? Like what tells it like these are the features

Joe: It, it, it's literally just a, a list of, um... So, like, the API that I'm, that I'm currently circling around, uh, is just a, a list of, um, function calls, and the function is either just called bool or string. Um, and then its single argument is a string, which is the feature flag.

Jared: Okay

Joe: that I have, you know, like, uh, blu- like, I want the sign-up button to be blue or whatever, that's my feature.

It's not the most exciting feature, but maybe it happens. Um, then, like, the, the entire call is just bool blue button. That's it. And you pass that into, like, a, into a builder, and then, you know, it spits out everything for you. That's the goal, is that I, I, I want to specify as little as possible, because the more I specify, the more attention I have to pay, and I love not paying attention.

Jared: Yeah. Yeah. I, I think it was Ryan Haskell who said something like, you know, "I just wanna do the, like, stupid work," you know? Like, "I just want to just, like, be told and then just..." Yeah. "... go." Um, yeah,

Joe: Punch the keyboard

Jared: I, I see what you're saying there. Yeah, maybe we should talk, uh, more after, but yeah, I think there's, there's an opportunity, um, if, if I understand, uh, maybe you get a little more details, but, like, we use code gen a lot, and we use active code gen, so, um, I find that to be super, super powerful.

Like, it's not... So there's passive code gen and there's active code gen. Um, and I'm-- There's probably an... You can name some other type, but, like, the difference for me is passive code gen is like you generate it once and then, like, you can go modify it yourself.

Joe: Oh, you like commit it eventually

Jared: Yeah, active code gen for me is like this is always going to be regenerated, and it's coming from a single source of truth that lies somewhere else.

In

Joe: Yes, that's what I'm trying to do. I'm, I... That's what I want. I, I, I like passive codegen too, but this is what I, I'm trying to do is, is have the source of truth be... At first I thought about it being just like a YAML file, and I was like, "Why do that to myself?" Um,

Jared: Yeah. Well, I mean, sometimes I'll have JSON, but o- oftentimes what the case for me is I, I want that system integrity, right? And, and you're talking about encoders and decoders. Um, but also for me it's like endpoints, like, you know, what is the endpoint that I'm calling? Mhm but we have Python on the back end, and what I've done is I've cr- generate this, um, uh, something's landing there it sounds like

Joe: Oh, uh, I live near a children's hospital, and so helicopters come through a lot

Jared: Yeah. Okay

Joe: It'll be about 15 more seconds probably

Jared: All right. No worries. We- we'll chill and just send some good vibes. Um,

Joe: any better?

Jared: yeah. Yeah, we're great. Okay. So yeah, so there's these encoders and decoders and, uh, uh, that I, I want to generate, right? Like, I, I do all that as codegen because not that I want... Like, like you said, like a lot of that work isn't terribly difficult to do, but what I want is I want- I don't want to make a mistake that I don't see until I, like, actually run the application.

Like, I, I just want that integrity out. So, um, because we define on the back end this Marshmallow schema, it doesn't really matter what Marshmallow is other than it's like, it- it's, it's taking a... something that is in Python code, and then we'll convert it into, like, JSON and then

Joe: Mhm

Jared: it, um, back into Python, so you can go either way.

Joe: Okay, sure

Jared: a- and so, um, with that schema, I can then have in- the information plus, like, the routes, how they're defined in Python. I gather up all that information, and then now I can generate, um, modules in Elm. We have like a whole bunch of them. There's like 137 now that we generate that are, that are all, like, different APIs.

So you... Like in Python, there's a class, and then in that class, there may be multiple endpoints. But then in Elm, it's like API.endpoint., and then it's like account class view. Uh, and it's like...

Joe: Right

Jared: account view. And then it's like API.endpoint.accountview.getusers or something. Okay? And, and then with that, it's like, so now I know what endpoint it is.

I know that it's a GET endpoint. And if I wanna call that, then I will have any arguments will be passed in. It'll generate, you know, whatever data it needs to be. Like if it's a post, for example, you would generate something to be

Joe: I see. Mm-hmm.

Jared: it also generates the decoder that comes back. And I think all that stuff is, is fine.

It's not like especially, um, unique what we're doing there. But I think maybe what is a little more unique is that I then require you to do something to map that. Like, because I, I still want you to think about, like... I don't want you to use all those primitives from the Python side as the ultimate model in Elm, right?

Joe: This is what I was thinking about as you were talking about it, is that, like, one of the things that I'm ambivalent about in all of this is that, like, I, I understand that decoders are, are hard for people coming into Elm. They're one of my most, like, favorite features. I, I love that there is no notion of, like, the JSON object that moves through your application.

Like, what Elm says is, "That's nice that you sent JSON to me. It's over now. You're going to make, like, a meaningful type that's expressive to your business needs," or whatever, um, business logic, I should say. Um, I... For me, it's like some of the most exciting and valuable computations that I do are in my decoders.

Um, and so I never wanna lose track of that. So, so I love you saying that, like, that's a thing that you sort of require people to do, is like, "Yeah, we generated stuff for you, but you still have to think about how this turns into your, like, application entities," if you will.

Jared: Yeah. Yep, exactly. And, and it's for that reason because y- if you only do those, those trivial, you know, the, um, the types that are like a, a Boolean and you get into that like whole Boolean identity crisis thing, you know. Shout out to Jeremy Fairbank there. Um, that's like Elm Conf 2017 maybe. But I mean, the um, those like, those ideas of like, um...

And then of course it's like, you know, um, making possible states impossible. Like all those ideas that, of like how you can use the, the powerful type system of Elm, um, to understand your business logic. I, I definitely want you to be thinking about and like converting into that. That doesn't go away. The only thing that-- I mean, not the only thing, but like the main thing that I want is that integrity.

I want there to be one source of truth. I wanna know like if I change the type on the back end, the schema, and like it's no longer returning a Boolean, it's returning a, a enumeration, right? It's, it's, it's a list of things. Like I want that to be a compiler error in Elm, and now it is. And, and so I have this like what I feel like is a lot more power, not only over my Elm code, but also over my Python code.

Joe: Huge

Jared: I, didn't expect there. And I did this just the other day and I was like, "Oh wow, this is a new way I can like have control over my Python code." I wrote some tests on the generated code that like verified the decoder worked

Joe: Yeah, I was just gonna say, right? It's like you could, like, like now one of your integration tests in Python is does the Elm compile

Jared: Yeah. Yep, 100%. Um, so like I'm, yeah, I'm like writing Elm code that like tests my Python code and I'm like, "Okay, now, now I feel like this is like definitely a thing that I, I'm happy that I'd done." And it was one of those like... A- and

[01:10:24] Question from Deepgram: Early design decisions

Jared: this is actually a question that, um, Brian had brought up, um, was like what are the, are the things that you did early on that, that you're happy with those decisions still today?

Joe: Design decisions that I made early on. There's a lot that are funny to me now, for sure. I think, um... What do I like? Well, my original approach to feature flagging, uh, is similar to... Oh, I'll talk about our, our A/B testing framework, 'cause I'm, I'm really proud of this one. This was a creative one. But, uh, uh, so, uh, we don't really run that many A/B tests these days, but we used to run a lot of them.

And, um, we had talked about getting, like, LaunchDarkly or whatever it's called. You know, some, some, like, service for it. Um, but then my feeling was like, "Mm, do I actually need a third-party dependency for this?" Um, it's on a website where everybody is logged in, right? And that was kind of the critical thing for me, was like, um, people have account IDs.

And so... And this is the nice thing about functional programming, although this is true of everything, but in functional programming, it's quite, uh, readily available to you to, like, seed your random number generator, because you have to seed it, right? Like, there needs to be a seed in it. And so, um, we set up this system of, like, taking people's account IDs, using, you know, account IDs or UUIDs, which are just numbers, uh, taking, like, the first number out of the UUID Don't quote me on that.

A number out of the UUID, uh, and then, like, a, a canonical name for the test, and then using, uh, using that canonical name as basically, like, your input into an, a random number generator seeded off of their UUID to, like, produce a consistent output, uh, that would, like, land them in bucket A or bucket B. Um, that's a design that, uh, was really fun to come up with and also actually worked really well because it meant that we, we knew, uh, A/B tests instantaneously and also did not have to pay anybody to, you know, tell us how to run them.

Um, I'm very happy with that design. Um, I think another design choice that I made really early on that I'm happy with is, like, you know, our, our biggest application is, like, 100,000-ish lines of Elm code, and it, it's a single-page app, and it is, like, very much a, you know, Richard Feldman Elm SPA example application.

Like, that, that is... That was the reference material for, for making it. Um, it's evolved a little bit, um, but we ha- we sort of, like... I sort of think of the application as, like, having different shells to it, um, and you have to, like- Uh, break through each shell to, like, land into an actual, like, user experience.

And so shell number one is, like, logging in. Are you logged in or out? Um, if you don't break through the shell, you land over here, and if you do break through the shell, you've made it through to, like, the next area. Once you're logged in, um, you know, we have, like, a project basis for everything, kind of, uh, GitHub-ish a little bit.

Um, uh, do you have any projects? Can we put you in one or not? That's shell number two. And so then that design, it, it's hard to express this verbally, but, like, what that means is that, like, we ha-- there's, like, main obviously for our application, but then there's, like, a smaller main that makes a bunch of assumptions about the presence of data that it couldn't have made if it was a top-level app, right?

When we check your login status or we check your list of projects, those are API endpoints that we have to hit. That means they're remote. That means you have to have error handling. All of that, like, error handling is now pushed out to the margins of the application and in your sort of, like, core app where you need all of this stuff and you don't really care to think about it without it, all that information is present for you.

It's just there already. Um, I think what that does is it simplifies a whole ton of stuff for us. Um, I'm quite happy with that design. It's a lot of, like, plumbing to... You know, when you have an update function, it has to make it all the way back up to main, right? Um, the ef-- shout out the effect pattern. Use the effect pattern.

If you're ever thinking, "What is that thing?" Google it and go use it. It is, like, uh, it, it is crucial for how our applications work, and I also think it's just the kind of the right way to go about stuff. Um, but the effect pattern makes all of this, uh, really feasible, I would say.

Jared: Nice. Yeah. And I like that the shells, it's like an onion has layers and

Joe: Mm-hmm.

Jared: you know.

Joe: Where in the onion do you go?

Jared: Yeah. It's a nice visual there. Okay. Cool. Well, um, we've talked for a while now. Um, I guess we should probably move to picks unless there's anything else that you really wanted to talk about. Okay.

Joe: I don't know. Let's go picks

Jared: yeah.

[01:15:32] Picks

Jared: What picks do you have for us today?

Joe: Okay, I have a few picks. Um, one, Learning Parser Combinators with Rust. Uh, this is an article, uh, that teaches you about parser combinators. It's in Rust. I actually think it's great to learn about that kind of thing in a language that you're less familiar with because you won't, at least for me, you won't get bogged down in the details of, like, exactly how certain things are happening.

It keeps you at a higher level, I think. It's also a very just fun article, I think. Um, I've done plenty of things that are about parser combinators for fun, uh, and this is the most fun that I've had. Um, uh,

Jared: Nice

Joe: it, it's also fun because it's like, because the type complexity of it is so dramatic in Rust, you actually have to, like, change a couple compiler flags to get it to compile in a human timescale.

Uh, and anything that makes you do that to a compiler, I think means that you're having fun programming. Uh, so that's, that's pick number one. Uh, pick number two is Crafting Interpreters. Uh, if you're not familiar with this book, um, it takes you-- it, it, it comes up with a language implementat-- or like a language definition, and it talks through how you would come up with a language definition.

Uh, and then you build, uh, a bytecode interpreter for it in Java, oddly. Uh, and then, or, uh, sorry, sorry. You, you make a normal interpreter for it in Java, and then you make a bytecode interpreter for it in C. And again, it's the sort of thing where I don't know how to write either of these languages. I think it's more fun to do this stuff in a language that you don't know 'cause again, it keeps you on that, like, high level.

So shout out to Crafting Interpreters. Um, and then pick number three is 'cause I was talking about, uh, bad pinkies. It's the Xbows. I don't know how I'm getting on the screen here, but the Xbows keyboard, that's X-B-O-W-S, uh, it puts all the bad pinky stuff into a thumb cluster, but it's still like a single unit keyboard, which I've, I, I tried splits and they weren't for me.

So shout out to this keyboard. It kept me programming for at least another five years of my life.

Jared: Yeah. Good choice. Yeah. I have, uh, the Kinesis Advantage Pro.

Joe: Okay. That's ... You're serious, yeah

Jared: Uh, yeah. Um, I went, like, all in. I'm like, "Hey, if I'm gonna do this, we're gonna go all the way there." Um, I do love it. I- it's, it's great. I've had it for, yeah, probably 10 years or so now. Um, okay. Yeah. So, um, three picks. Any other picks?

That's it, right?

Joe: Um, that'll be my picks

Jared: Okay. All right. Thank you. And then, so I have this record player that has been, like, not in use. Like, it's just been sitting there. It was actually behind me for a while, just like, just hanging out. It's not here now. Like, I don't have it behind me. But it, um, it was just sitting there, and then eventually my partner, she was like: "Oh, um, I found this thing and I think the, you know, the record player could go on it."

This was a couple weeks ago. "Okay, yeah." We go get it, an old piece of furniture, and like, we put it in, and then I'm like: "Oh, I'm gonna, like, actually get this thing to where I can use it again."

Joe: Nice

Jared: and, and so I did that, and, um, I've just been excited about it. And one of the things that, um, I like is listening to entire albums.

Um, and one, like, an older album that just for some reason popped into my head, um, that I thought-- wanted to share, it is "Zenyatta Mondatta," um, "Zenyatta Mondatta" by The Police. Um, lots of good songs on here. "Driven To Tears," "When the World Is Running Down, you Make the Best of What's Still Around," "Canary in a Coal Mine."

It's good stuff. Um, that's definitely a, a pick. You don't have to listen to it on a record player, a vinyl player, but if you do, um, I, I also recommend that just, like, specifically, like, vinyls in general. Um, because, uh, I like the idea of, like, sitting down and, like, just focusing on this one thing a- and having that experience, tactile experience of, like, going and like: "This is what we're doing.

We're just, like, we're listening to music." As opposed to, like: "I'm listening to music as I go from here, as I go from there, as I'm coding." Yeah. Yeah. Um, a- as like, that's the experience and, um, it's been a while since I've done that, since this thing has been, you know, broken and I didn't have it set up where I wanted it and anyway, um, having that back in my life I feel like is a really enriching,

Joe: Shout out to that. Me and my partner are also getting into vinyl right now,

Jared: Oh, cool. Okay

Joe: uh, just by coincidence. I feel like I should have an album recommendation, but I don't think I do.

Jared: Okej

Joe: but it, but it is really nice. It's like it, uh, it, it, it's really hard to get yourself to like listen to a thing, and the nice thing about an album is both that it's long and also that it ends.

Um, I think that like, you know, you can decide to listen to an album on like a streaming platform, but then, you know, your streaming platform will inevitably keep going on to something else.

Jared: Yeah. Good point

Joe: I think the structure of, of vinyl is, is really fun, and it's nice to have something to like go shopping for, you know?

Jared: Yeah.

Joe: Uh-

Jared: Yeah, it, it's good. It's like, it's art. I mean, it really is. Like, you know, it's something like when we're playing a record like that, it's out and, like, you would look at it. And I used to do that with CDs back in the day 'cause I was, you know, during that era when I was growing up and, you know, look at the lyrics and everything.

But, like, going back to this, like, I mean, it's, you know, it's large and it's like... I, I'm not, I'm not getting everything, of course. Like, I, I have to spend some money specifically on each one and yeah, and it's like an adventure and a search and all that. So I can't just go, like, try everything. It's like I have to really be either inspired by the artwork or something that I've...

Joe: Or roll the dice on something

Jared: Yeah. Yeah, for sure

Joe: it's, it's funny 'cause it's... I was talking to a friend about this because even if you were, like, into physical media, vinyl is objectively not the best physical media for audio. But it is, uh, really big and pretty, and so those are two points in favor of vinyl, I think.

Um-

Jared: Yeah, for sure. And like, you know, you get to the point where like CD players, then like you can put five CDs in and it'll, you know, switch between the different CDs and it's like, I don't know. There, there is something just this... It's analog and so like, you know, you have this signal. It just, I don't know, it just has a

Joe: hard to convince yourself that it works as a technology too. I think that's a big thing in point, like in its favor

Jared: Yeah. Yeah, for sure. You look at it and you're like, "That makes sound?" Yeah.

Joe: "No, no way."

Jared: Yeah. My word of the day, uh, at the company at Logistically was je ne sais quoi. Um, it is like, you know, like this indescribable, um, feeling like, it's like what you don't know, um, like how to explain it, but like it's... There's something there that's sort of intangible.

But the fact, I think one of the things, again, coming back to like just having a physical thing, like that is tangible. Um, a- and that is a big part of it for

Joe: And we spend so much of our time doing intangible stuff, right? Um

Jared: Yeah, for sure. I like it. Cool. Um, anything else?

Joe: Hmm. I'm gonna look around the room and see if I'm inspired

Jared: Any Rondo for strings and pegs? Someone, if they no,

Joe: Oh, my webs- I was like, "How do you know about that?" Yeah, that's on

Jared: yeah, it's on your website, um, for folks

Joe: mortified when you said that. I was like, "What do you, how did you..." Okay, yeah, I actually advertised that. That's fine.

Jared: Yeah, I know. Uh, folks who don't know what we're talking about, um, there's this video on Joe's website, um, where he does a performance. Um, and like, uh, the first couple minutes I didn't read the whole blurb that he had before that would've told me what it was. I just started, you know, clicked it, and I was like, "All right," like, "He's tuning.

He's tuning. All right, he's gonna tune up." I'm like, "Man, a lot of this video is him tuning this

Joe: tuning for a

Jared: Yeah, and I was like, "Oh." I go back and I read and I, and then I get to the end. I, "Oh, okay." Like this is the whole... Yeah, there's a, a lot of tension there

Joe: It's, it's hard to tell in the video, or at least like, I guess it's not hard to tell in the video, but like in, in human experience, it was absolutely terrifying when that string broke. Even though, even though that's the point, right? Like, the whole point is to do that. I was like, I was still-- In practicing it, I like was not so scared by it, but in performance, I was just like so in the zone that I had forgotten that I was doing this to myself.

Jared: Yeah.

Joe: but that was

Jared: And what, and it kind of made me worried because your head was down so close that I'm like, "Oh man, I'm

Joe: That's-- I was in the zone, yeah. I think I had glasses on though, so it's like, like how bad could it be, right?

Jared: bad could it be? Yeah, that's fair. Sure. All

Joe: would be a different vibe if I came in with goggles, I think

Jared: Yeah. Like people know something's up. That would've given it definitely a certain feel.

Joe: Yeah

Jared: but okay, cool.

Well, I appreciate your time, Joe. I won't take up any more. Um, thanks to all the folks that are listening out there. Please rate and share if you're enjoying the show. Thanks, Joe, for coming to Elm Town.

Joe: Thank you, Jared