[00:00:00] Nduati: Elm, even though I was just picking it up, I was able to walk myself through the, the whole process. Like, The mental model for me was much easier. And so, like I would say, it actually fits in my brain.

[00:00:13] Jared: Hey folks, welcome back to Elm Town. I'm your host, Jared M. Smith. We'll be visiting with Nduati Kuria today.

[00:00:20] Sponsored by Logistically

[00:00:20] 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. Logistically pays me to record Elm Town episodes, as well as pays for our production and hosting costs.

[00:00:39] 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 dot com. I'll put a link in the show notes.

[00:00:52] Introducing Nduati

[00:00:52] Jared: Now, let me introduce Nduati Kuria. Nduati is a software engineer who recently graduated with a Master's of Engineering Artificial Intelligence from Carnegie Mellon University, Africa. He works at Qoda with folks such as Dhruv Dang, who was on Elm Town 36 – The Risk of Elm, and Dwayne Crooks, who was on Elm Town 55 – From algorithms and animation to building a decentralized finance app. Nduati's built several site prototypes in Elm, including Art Culture, a Haruki Murakami website UI, and a WebGL sculpture animation site about Marcus Aurelius. He's excited to talk about functional programming in Elm. Nduati, welcome to Elm Town.

[00:01:40] Nduati: Thanks for having me, Jared.

[00:01:42] Getting started

[00:01:42] Jared: So, I wanted to get started by asking you what was your original motivation for getting into computing and programming?

[00:01:53] Nduati: in high school, um, I studied computer science. And this was, like, it was very kind of basic. We go high level through things like internet and email, uh, very high level through networks. But at our school, I had the great opportunity to have two teachers who snuck in programming, uh, lessons.

[00:02:14] Which was a part of our syllabus. Um, so, My first year of high school I did a bit of Pascal. Then, between second year and Ah, sorry, yes, the second year of high school and the final year we did sprinklings of, like, C that was a really interesting experience. Very simple things, like drawing a triangle.

[00:02:34] Like, you draw a three sided triangle with, um A length of side 3 or something like that. Um, but it was really interesting learning the, like the really basic things of how you think about programming. So, input, processing output, solving problems, loops and things like that. And then two things which actually turned out to be, uh, really beneficial to me, kind of getting into computing and specifically into programming.

[00:03:03] In Our third year part of the syllabus is to go through the Microsoft suite of software. So Word, Excel Publisher, and Access. And I remember, I think it was my third year our teacher had this idea that we're going to build It was during the World Cup, so we're going to build the World Cup table in Excel.

[00:03:23] Um, so basically you have the group stages. As much as I played, you fill in the scores, it should tell you who won the group stage. And then the winners of the group stage should show up into like some tournament, uh, table and like throughout the semester we should be able to fill out the scores and, um, like get the winner of the World Cup.

[00:03:44] And, like there's that old joke that the, like the world's most famous programming language, um, is actually Excel, because it's being used by like all the financial guys. Um, and we ended up doing a lot of like, if conditions, things about sorting hierarchies kind of like how like in, let's say the, not the World Cup, the Olympics, when you have a country with many goals.

[00:04:11] Uh, in another country with many silver, uh, with some silvers and bronze, like you need to figure out how to do some sort of like sorting so that gold matters most, uh, silver matters slightly less than bronze. So like doing simple scaling.

[00:04:25] So if a country has six golds multiplied by a million, it gets six million golds. Anyway, so just really interesting tricks, uh, in programming and finally, later on, my final year, did a bit of Visual Basic, uh, inside Access, which is like, Microsoft's it's not very common these days, but it's like, they're a database product that they had.

[00:04:46] So you could build forms and things like that, so, uh, we started injecting Visual Basic for click interactions, um, Like some validations which weren't out of the box. Anyway, so, after all of that, I really got into computing, Loved the, like, that thing you get after you build something and decided to, uh, study computer science in, uh, in college.

[00:05:10] Jared: Okay, neat. Yeah, and so, I wanted to kind of go back here because you mentioned Excel as kind of being the world's most famous programming language and I think that's, you know, that's true. I was at Strangeloop this, uh, conference that Felienne Hermans had presented. And one of the things she said was that, basically the same thing, you know, that Excel really is a programming language and it sounds like you were really using it in that way.

[00:05:41] So, And this is nice. So you were able to kind of sneak in this through your high school studies. And that is what inspired you to go study computer science.

[00:05:54] Nduati: Yeah, yeah, that's right.

[00:05:57] Jared: Okay. All right.

[00:05:58] Nduati's College Journey: Swift, Internships, and Elm Discovery

[00:05:58] Jared: So then you go to college and you study computer science. How was that?

[00:06:03] Nduati: I think many people say the same thing that, um, The programming they learned wasn't mostly in, like, high school proper. For me, a huge part of this, of my programming journey was, I had a friend who ran a, like, a small startup. Uh, they needed a Swift, uh, developer, because they needed to, like, build some iOS apps.

[00:06:24] So I said, okay, fine, I guess I'm learning Swift now. So, I picked up Swift, and, um, the programming side of things I was okay at, but, uh, like, the UI bit of things, like, I wasn't the best. But, like, that feedback, where I would build something or design something, some UI design somewhere using maybe Sketch and I'll give it to my boss and he'll say like that's okay But like it's it's actually not okay This could be better like using too many colors.

[00:06:56] This is complicated. This is This isn't clear. So Over Actually since my first year of college I Somewhere around my third year, um, I interned with them, uh, even during the semester, during my free time. I would go into the office, uh, do some programming. Um, when I would fall behind because of school, it would mean that, like, when school was over, I would have to come and catch up with the work that was being done on the Android side.

[00:07:27] So, , it gave me a place where I could learn, where I was getting feedback by someone who actually cared, because it's their product. And then I would also have to learn to program pretty fast because whenever school kind of got in the way, uh, you got that, I would fall behind the Android development and I would have to come in like in a week trying to catch up to a month's worth of exploration and, uh, programming.

[00:07:51] So, that really gave me, uh, an opportunity to, to learn to write production code.

[00:07:58] Jared: Cool. Okay. And so you're kind of getting this feedback process, this loop of trying out things and especially with the UI and, and then getting some feedback and learning and adapting from that. And then also you have this additional challenge that you're trying to do this while also going to school and be productive at work.

[00:08:22] So yeah, that sounds like, uh, a challenge that, that would be interesting to face.

[00:08:27] Learning Elm: It actually fits in my brain

[00:08:27] Jared: And so you're kind of doing this internship, right. While you're in school in Swift. And then what happens next?

[00:08:36] Nduati: So, around my third year, I had, I decided to take an internship at a cyber security firm, which was interesting, got to do a bunch of Python, some ML things, which was fun. But once that internship finished, I was now entering my final year, and like, you know, final year of undergrad, you expected to do, over the course of, uh, two semesters, you're supposed to come up with, like a system project where you come up with some fake problem you want to solve, you do a lot of design documentation, you build out the thing, then finally there's a presentation at the end of the, um, at the end of the year.

[00:09:15] And I had, just in my free time, I had been playing around trying to build something in React. I had really been struggling with that, and for whatever reason, I have always kind of struggled with HTML, um, like flex, flexbox, all those things, they, they don't sit in my head, if you can use that phrase, um, so, after a while, I had been watching a few Elm videos, so, um, I said, okay, let me try out this thing, did Elm.

[00:09:49] Like combined Elm and a bit of Elm UI and something I've been struggling with for like a few weeks I did it in a couple of days which like for me was huge because I had tried Vue before, I had tried React before and Like the fact that the Like I would always struggle, but now the fact that especially with Elm UI I didn't actually have to think about HTML.

[00:10:13] I would use the same

[00:10:15] Language, uh, to describe what I want and to implement it. So, you want something to be above something, I just, like, I use above. Instead of some complicated, uh, combination of, I don't know, Relative positioning, and then top, all that, all that, uh, stuff. And, um, so then I realized there's something really nice here.

[00:10:38] I can now start programming almost like Like I say at the speed of thought. So if I, if you want something on top, I just type on top, then I put it there. If you want a certain color on something, I just type color. And then, um, let's say I want blue. I just put blue. And so after that experience, I decide, like I'm going to gamble with my fourth year project, and kind of use Elm and uh.

[00:11:02] Nduati: At that point I was also looking into Elixir, using Elm and Elixir, and see what happens there.

[00:11:09] Jared: Okay. So you'd tried out React and Vue and you were struggling with accomplishing things. Mostly you think because it was a combination of the HTML and layout that you were trying to accomplish.

[00:11:24] Nduati: HTML was one thing, and the other was, uh, First of all, like, with React, there's so many things, so many ways of doing things, so, um, Components, you end up with, like, very many files, Props, it's not obvious. Even now, like, I have helped people with React code, and they still don't understand everything, so, How props work, it wasn't clear how to get data to go back up, um, wasn't clear to me, And I hated having to discover bugs at runtime, so, You type something, you type something.

[00:12:02] You refresh the page, it looks good, you click somewhere, then there's this undefined not found error, or something blows up. So I hated that. Elm, even though I was just picking it up, uh, I was able to walk myself through the, the whole process. There's, there's a clear structure, model, update, view, any updates to the pages, any changes to a state, all happening in one function.

[00:12:27] All the possible changes that can happen in that page are all listed in one place. Like, the mental model for me was much easier. And so, like I would say, it actually fits in my brain. So, HTML was one thing, but also, like, the actual, the language itself.

[00:12:43] Jared: Sure. Yeah, and so you have taken this opportunity to try out Elm, right? And you're, and you're finding that, yeah, it's easier to debug and There's typically one way to do things, right? As opposed to in other frameworks. And so, yeah, that sounds interesting.

[00:13:03] Uber for school buses

[00:13:03] Jared: What was this final or fourth year project?

[00:13:06] Nduati: Ah, okay. So, For whatever reason, I decided to do like, so, uh, let me preface this by saying it was like during COVID. So, um, while the school was trying to figure out how to get back to like online learning and things like that. I got like this huge chunk of time when no one was disturbing me. Like there were no expectations of anything else other than work on your project.

[00:13:31] So what I was doing was I had My idea was to have, like, real time tracking of buses. And so the idea was, uh, and it's kind of silly now, but, it's like Uber for school buses. And, so it, and the idea just being that, like if you think, if I take, uh, the example of, like, let's say it's snowing or raining, and you don't know where the school bus is, you don't know when it's going to arrive, Wouldn't it just be nice if you could take out your phone, you could see the bus arrive in 5 minutes, you could see where it is.

[00:14:06] And so it was a collection of things, so there was an IoT part, which was like some GPS sensor and a GSM sensor to talk like over networks. That would keep track of the location of the bus, that would talk to the Elixir backend. And I would know the location of all buses in a city or, um, like in some area.

[00:14:31] Then all this information would be shared in real time, uh, both through a mobile app and a website. So their website was in Elm and, so there I was doing things like, setting up WebSockets so that, like, you can, from the website you can just see as the bus moves. So the GPS sensor reports a new location, that's pushed over WebSockets to the Elm front end.

[00:14:55] Uh, where I had like Google Maps with a pin over like an SVG bus moving around and all that. Uh, but it was really interesting because, now with all that free time you start doing like things like, uh, If you want to, let's say record repairs happening to the vehicle. Like, there's a page which you see, like, the skeleton of a bus, so you can just see the tires, the axis, and all that.

[00:15:20] And you want to say that the tire had a repair, so you click on the tire, you drag and drop it into, like, some form, and then now you have, uh, Like, you have a form with, like, the tire reward, where you're saying, I fixed this tire, it cost this much. Um, so because it had a lot of free time, it got the chance to, like, push Like, the things I could learn about Elm.

[00:15:43] So, drag and drop, um, real time You know, that's the idea of the project. So it was real time tracking of school buses, like a lot of crowd applicable features, plus a lot of special things to put in. Um, just for the sake of learning.

[00:15:58] Jared: Yeah, that really sounds like an ambitious project.

[00:16:03] Nduati: Yes, um, my philosophy is learning, uh, is like promise you'll do it and then go and figure out how, uh, cause like half way into the semester I can't just wake up and say like all this Elm stuff isn't working, I'll try React. I force myself to learn by making it ambitious, so, at the end of it, like even now I look back at some of my code.

[00:16:28] I don't love all of it. Like the way I'm using ports and all of that, but the structure of the code, like it feels fine to me. The components, the way you use views, styling, things like that, they all feel fine. Um, and I think that was because if you write enough code, like you'll, you'll be forced to learn the like, the proper patterns of doing things, especially in Elm, where the language drives you towards, like, realizing certain things are correct and other things would make your life painful.

[00:16:59] Yeah.

[00:16:59] How Elm drives you toward best practices

[00:16:59] Jared: Yeah, I've heard that before that the Elm kind of drives you toward best practices. Could you, do you have a particular thing in mind and how Elm does that for you?

[00:17:10] So, an excellent one which I've seen also at work is how you end up, like, coming up with components. So If everything, at the end of the day, ends up being that kind of, uh, the Elm architecture. So you have a model, which renders out a view, and that view can generate updates. And like that's, that's how the language is structured.

[00:17:34] Nduati: That's, that's how the runtime works. The moment you now start building up a lot of complexity and you start realizing this one component is carrying Like, let's say half of your update function is, um, half of your update function is related to one, like, single component on your page. So this, like, the obvious thing to do is, okay, let's just put this inside, uh, like another union.

[00:18:01] So we'll have, um, I don't know, user clicks this, user clicks this, and then user updated this component. And then inside there, you'll have all your options for that one component. And then maybe you'll come up with another function that handles the update for that one component. And, like, slowly you'll start pushing things away.

[00:18:21] So, like, because every, like, views are just functions, it's very easy to just pull that view into a different file. It's also very easy to pull out all the updates related to one, one component into the same file. And then eventually The same model. So you can basically pull out the TEA architecture just for a single component into its own file.

[00:18:44] And someone who's, who knows how a page works, can go and look at the, uh, component and it like, it makes perfect sense. And so you, you can end up kind of replicating this, uh, the tt I was funny say TEA architecture, but the, the TEA architecture. Like, and keep on building abstractions on top of that, because, uh, first, refactoring is painless, you know exactly when you've pulled something out, and, so let's say you, you, you have a message that you, uh, that's in a component, but it's not listed in that component, the compiler will tell you immediately.

[00:19:24] So refactoring is easy, but then because we already have like this TEA architecture. It's obvious when a component, like, it feels good when a component is, like, really well encapsulated. So, I don't know, those are some of the things. It's easy to kind of stumble into a good architecture. At least that's from my experience.

[00:19:46] Jared: Yeah, so you're describing the process of scaling Elm apps out, you know, as it gets bigger and you're finding these things are related, you kind of, like you said, push those things into their own functions and view function, update function, message variants, and then at some point you may decide to pull those into their own module and then encapsulate that because you say, okay, we're going to do this maybe in other places or we want to Separate this code because we want to focus only on the logic of that code

[00:20:18] Nduati: yes.

[00:20:19] Jared: in this place.

[00:20:20] Yeah. Okay. And because it's Elm, you know that when you make that refactor, it's fearless, right? As they say, it's okay. Excellent. And so at this point we're talking about Still, I mean, you've mentioned work and, you know, some of the problems you've solved there, but kind of in your story, we're at this point where you have discovered Elm, you used it on your fourth year project, this ambitious Uber for buses project,

[00:20:53] Nduati: Yeah. I don't

[00:20:55] Jared: And at this point, you, you're starting to learn Elm. And had you Learned any functional programming before that?

[00:21:08] Nduati: Nah, no. Um, I was just getting into it and that's why, like, I picked up Elm and Elixir. Again, I'll go back to that phrase, it all fit into my head. So, these, like, when the moment you start dealing with references in object oriented, um, programming, there's, there's this little overhead that comes along where like, you know things but you also, you don't know. Um, you pass data into a function, you have no clue what's happened. It might have, like if it's really low level languages, it might have been deleted.

[00:21:44] In like Swift, Java, um, Python. It might have, uh, like values might have changed inside, uh, like a rich data structure. If it's Python, the The whole thing actually might have disappeared. And there was this simplicity that came with functional programming, where kind of the same way you've been like learning in school about, here's a function, you give it data, it gives you back some other data.

[00:22:11] Like that promise was, was being fulfilled. It's the thing we were told, the way programs are supposed to work is how they were working in, in functional programming. So I don't know. I fell in love with functional programming. So, um, yeah, I started using them then.

[00:22:28] Jared: Okay, yeah, and I've heard this experience before the most recent description that this reminds me of is an episode I did with Adriano Ferrari and kind of talking about the same thing with the mental overload or the you know, the overhead that you have with programming in, in other languages that don't have the same guarantees that Elm does, right?

[00:22:53] That don't treat functions as functions, as pure functions. So, yeah, you have this, what seems like, I guess, more working memory for your brain to focus on the problem at hand, instead of focusing on other things that may come at you and you're going to have to guard against.

[00:23:15] Nduati: Yeah, yeah.

[00:23:16] Jared: So you're getting into functional programming. You've written, made this ambitious project using Elm and Elixir. What happens next?

[00:23:25] Nduati: Um, let's see.

[00:23:28] Introducing Elm at work

[00:23:28] Nduati: So, I joined a small fintech, uh, here in Nairobi. They were using Spring, so it was Kotlin. And I would try and sneak in Elm, but the tricky thing with sneaking in Elm is sometimes it feels it doesn't feel like the responsible thing to do unless like everyone is bought in. So like, you can always introduce it, you can always prove that it's that if you work with Elm, you'll be so much more productive.

[00:24:01] The tricky thing is Well, just to go off topic, there's this interesting idea I've heard that it's like, The only thing worse than an overbearing leader is an absent one. So, I was finding that in some situations, like, I would suggest an idea and there wouldn't be pushback. So I'd suggest Elm and, like, it would be okay.

[00:24:28] Which, like is a scary thing. Because you shouldn't be able to introduce a new programming language without like some pushback or some thoughts or something. Because otherwise, like a decision isn't being made. It's like things are just going. So, for while I was there, I kind of stayed away from using Elm.

[00:24:49] Well, at least in, at work. Um, I still use it a lot in my free time. But like And I guess that ends up being one of the tricky things about Elm, that, You can have people who are really bought into it, But there's a huge group of people who will use the simplest, Or let me use the word, the most common programming languages, so React is chosen not because it's the best.

[00:25:13] In fact, usually there's no decision, it's just, Everyone else is using it. There's no discussion about trade offs. Is it this versus this? What do we lose? It's always the hiring. What is everyone else using? It's a Facebook language. , So for like around 8 months, I was working mostly with Kotlin and, um, helping out a team that was working with a bit of React.

[00:25:36] Master's & self-directed learning

[00:25:36] Nduati: Then, soon after, I went to do my Master's, which was full time. And there, I got back a bit of my freedom. In that, uh, school projects, like our school assignments, it's like how it looks rather than what it's built with. So no professor is actually going to go and read your code. So again, I got back into this paradigm where there'll be a problem or a project where, It's very easy for smaller teams to like other teams or other, uh, like individual group works specifically for other groups or, um, other individuals in, uh, individual assignments to like, to do something very bare bones.

[00:26:16] But I would be there on the side with Elm and because I had gotten used to it, um, and like it's so expressive, like I would build like proper dashboards and UIs for a class or an assignment where it has nothing to do with software engineering. So like I remember a good example of this is, I was working on a, it was a class having to do with like data analytics, and like some machine learning things.

[00:26:46] So we were doing, uh, like we were working with, I think it was predicting fraudulence, not fraudulence. Which loans are likely to be, sorry, which loan applicants are likely to default. And so you're supposed to use an API. And like, it's supposed to be very simple. Just use an API, uh, in Python, like using Flask, that's supposed to sit on top of the ML.

[00:27:09] And the ML was supposed to be the main thing. But like in a few days, I built this entire dashboard where you could. Like actually put in the, the, someone's records, it would do predictions, it would tell you what's the likelihood of this, some nice visualizations on precision and accuracy. So even though I wasn't working on Elm full time, I was like in school, uh, I still found that it would make me extremely productive and like it would make assignments, which at times I found a bit boring, a lot more exciting,

[00:27:42] because, like, I could go and build an entire application in, like, in a weekend. Anyway, which, which would really, because it was a stressful time, it would really, like, make my day. Um, Because, it's like, I don't know, I think it's a programmer thing to, Side projects are a lot more fun than work. Even if Like, they have some overlap, but that self directed, um, learning and, creation, is really amazing.

[00:28:09] From elm-charts to Qoda

[00:28:09] Nduati: So while at school, I managed to link up with, uh, Dhruv from Qoda. Actually, I, I was, uh, working on something in elm-charts and, So, an issue he had raised, so I picked that up and, uh, gave some ideas, we linked up on, LinkedIn, and then, uh, started working with them, uh, while I was finishing my Master's.

[00:28:32] Jared: Yeah, I'm glad you brought that up, because I had sent a question to Dwayne Crooks about, to give me a story about you, and this is kind of the story that he gave. So it's kind of a bit of a paragraph here. So I'll just quickly run through this, and it describes kind of what you're saying from his perspective. Quote, I first heard about Nduati through Dhruv. At the time, we were busy working on releasing our first version of Qoda. And one of the many features we wanted to add to the decentralized application was charting. We knew about elm-charts by Tereza Sokol, but I had never used it, and we didn't know if we would be able to use it to build the type of chart we needed.

[00:29:18] I didn't have the time to experiment and find out. So Dhruv decided to reach out to Tereza via Terezka slash Elm Charts issues to find out if it was possible to do candlestick charting with the library. The request remained there for a while, until Nduati responded with a gist that prescribed exactly how it could be done.

[00:29:37] Dhruv was happy with the proposed solution, and he messaged me to tell me all about it. I think they had a few conversations after that, and Dhruv was really impressed with his work enough to come and talk to me about his decision to pursue hiring him.

[00:29:53] That's how I came to know about Nduati, and eventually working with him. End quote. So is that basically the same way that you, yeah.

[00:30:03] Nduati: yeah, it's, I've never heard it from that side.

[00:30:06] Jared: yeah. So then what was your interest in Tereza's elm-charts? Was this related to the visualization you were talking about?

[00:30:13] Nduati: Yeah, yeah, um, well, kind of well, first I have to say I love the elm-charts, library. , the library itself is wonderful, but, like, on top of that, Tereza has put together, like, some really, really nice documentation, like, which walk you through all the charts you could build, how they could be combined. It's really wonderful.

[00:30:34] So, again, going back to Canvas, uh, or, let's say, my master's, I was doing ML, but, Apparently, it turns out, I like ML, like, inside software, but not as its own thing. So like, I would have, uh, classes which would be a bit stressful for me. And not stressful like in the good way of programming usually is where you're struggling with something, you struggle with something and then you solve it and like, you feel this high.

[00:31:04] Like, um, where you feel great. ML, it's, it's a little less, um, deterministic. So, you'd work, you can work on something for hours and like nothing falls out, which is like a really strange sensation, especially when you're used to like cause in programming you have this thing where if I work long enough on this, maybe I get some help.

[00:31:25] It'll work. Like, and usually it, it almost always works. Um, anyway, so what would happen is when I'm having like a really slow week at school. I'll go and start doing some things on the side. So, for whatever reason, I was really interested in, like UI's related to stock markets. So, at that point I was looking, okay, can Tereza's library let me draw the candlestick charts?

[00:31:49] The ones which show, like the opening price, closing price. And, so I Google, uh, candlestick, I see nothing on Tereza's. Application, uh, sorry, library. But like, there's an issue which is open. So it's like, okay, this is useful. And since there's someone else who needs this, let me give it a shot. It was really interesting to do.

[00:32:13] Had to play around with a few things. And, well, eventually, kind of, because of avoiding schoolwork, I found myself talking to Dhruv, sorting out Like, giving me a few suggestions on how they could sort out the issue. And yeah, so that's how we met. And he was very kind enough to reach out. Uh, yeah, so now we get to work together.

[00:32:39] Jared: Did you start working at Qoda before you had finished your Master's?

[00:32:44] Nduati: Uh, yes, yes. This, this was So, my master's was three years, so I joined with Qoda at the beginning of my summer holiday, um, and the idea was that I'll work with them for three months, try and finish my schoolwork, and then, if they're still interested, we can work later. But I, like, I had a really amazing time, and again, going back to this idea of getting feedback, like I found, like, it's One of the best ways to learn is you do something and then someone tells you, That's not exactly how you should do it.

[00:33:20] If you can change it in this way, then it will be perfect. And, like, go back and think about it again. So, the experience of working with Dhruv and Dwayne, like, he gave me this opportunity to do things in Elm and be told, no, you need to tweak this, you need to tweak this, um, you need to think about components this way. And, so, finished working this, like, working with them over the summer holiday, For whatever reason, I decided, let's just continue this thing, and, like, by that time, I had said to myself, Like, if I can spread out my, like, my remaining school workload so that, Like, I can continue working part time, I think that would be in my interest, because, Like, ML is interesting, and I'm sure it's the future, but, uh, there's a wonderful, this wonderful feeling you get out of programming, Um, which can't be replicated, uh, That immediate feedback of, you try something and it succeeds.

[00:34:21] You try something, it fails, it fails, and then it succeeds. So already I could tell, even if I finish this Master's, most likely I'll, like, I'll want not to go into machine learning, but to, go into software. And if somewhere down the road, machine learning and I cross paths again, I'll know a few things.

[00:34:41] Uh, so, uh, continued working with them. And still working with them to this day. Um,

[00:34:53] The rigour of programming with Elm at Qoda

[00:34:53] Jared: What is it that you enjoy about using Elm at Qoda?

[00:34:59] Nduati: There's a rigour, which, and I don't know if this is because of their, this is also a Haskell team, but there's a rigour which will, comes from, which I've come to learn from, like, Dwayne and Dhruv. I wasn't very strict before with how I would, like, deal with types. So, I would kind of come up with anonymous records all over the place.

[00:35:18] Like they were just types for a really long time were just vehicles for dealing with data. Like, it's like a record or just a really long tuple. Where a container I could pack a piece of data into. And something like I've really come to enjoy with Elm is how easy it is to model types really well.

[00:35:40] Like, one of the things which I love most about Elm is the fact that there are boundaries around the language. JavaScript coming from outside, oh sorry, not JavaScript, JSON coming from outside, um, unless you, like, you really insist on breaking the rules, it has to be sanitized. It has to go through a decoder, which means that, like, There's a wild, wild west out there, but inside our little circle of Elm, everything is perfect, everything is typed.

[00:36:07] And so we can try and decode things, if data doesn't match what we expect, we have to handle it. So, there's a very nice way of being able to express types hiding, like, what's inside a type.

[00:36:21] so in, at Qoda we were, uh, we're building a decentralized app. Um, so it's basically like a financial product that lives, um, on the blockchain. And one of the interesting things about, like, values on the blockchain is like they're usually really, really long.

[00:36:40] Like if Bitcoin is now something like 20, 000 dollars it's like there's a lot of decimals. So, like dollars are usually like two decimals. Uh, something like Bitcoin, you'd have 18 decimal places. So it's like we have to have special types which are big integers that are coupled together with like a decimal value.

[00:37:02] Nduati: So you have 1 to the power 18 as your value and then 18 decimal places. And then, yeah, sorry. So if you have an 18 decimal place number whose value is 1 to the power 18, that's like equal to 1 Bitcoin. And you have this thing where adding, you have to add big numbers and, um, be able to subtract them, some lists of them.

[00:37:29] And if you're just dealing with the big numbers, instead of like dealing with an actual amount type, um, you lose some type safety where you don't want to be able to add, let's say a Bitcoin and USD. So Elm makes it really easy to, like, represent things at the compiler level that make it impossible to like, to make certain errors.

[00:37:53] And then also because you can always encapsulate the type inside a module and only expose like a few functions from that, um, module. Like, it's really easy to have a type that is safe. Not just in terms of, like, the type safety, but also the usage. You can, at the compiler level, prevent like, prevent your team from making certain mistakes.

[00:38:18] So that, plus the fact that, like, whenever you're dealing with a team of people compiler safety, like, the type system, like, makes it so much harder to make mistakes than, like, a lot of other JavaScript languages. So that, like, if If, uh, someone in my team has gone and changed something in a, in a, in a module, and I don't know about it because maybe I wasn't, like, really reading through all the git changes, um, if I go and I start treating a type, like, with the assumption that it's still exactly the same, um, the compiler will tell me, no, you can't use it in that way.

[00:38:55] So, Elm, I think, has made it really easy for us to work as a team and, like, build out features and make changes. Because you can be sure that other members of your team can't assume that, Like they can't make certain assumptions that are no longer true of your code.

[00:39:11] Jared: Right. Yeah, I like that too. You can use the compiler to communicate when things change, right? Yeah, you can't make assumptions and then Merge some code in and then if those assumptions change, you will know it as soon as you run

[00:39:32] Nduati: Exactly, exactly. Yeah. Yeah,

[00:39:35] Jared: like you're saying, having these clear boundaries at the edges of Elm is really nice because that provides the opportunity for you to make nice types and make sure that things make sense inside of Elm, even if the outside world is, you know, Is not so nice.

[00:39:54] So,

[00:39:55] Ports

[00:39:55] Nduati: yeah. And actually that's, that's one of those things which, um, Especially from our experience, um, at Qoda, It kind of throws away this idea of, like, Elm won't be enough. So we have a really large code base inside JavaScript. The reason for that is like a lot of the front end, um, blockchain libraries are in JavaScript.

[00:40:19] Um, so whenever we have some user interactions, so let's say someone wants to make a transaction. So maybe they want to create a loan or to, to lend to someone else some, some of their, their, their cryptocurrency. All of that has to be piped through, like the JavaScript side of things. And so it's really easy to actually build a very, like, complete application.

[00:40:45] Um, even if huge parts of your, uh, Huge parts of the application code are in JavaScript. And, like, the ports, um, make it really easy to communicate back and forth. And there's a bit of boilerplate that's there. But, like, I think it's the boilerplate in Elm, because of the types in the compiler, ends up being all you have to do is implement it well once.

[00:41:11] And then from that point forward, you just copy paste that module and make the changes. And you forget something, the compiler will tell you, like, this isn't what you expect. So, um, I don't know, I'm really happy with Elm and our experience at Qoda. It's made it, like, really easy to, like, keep on iterating on a product.

[00:41:35] Like, every few weeks you might find a page turns out that needs to be changed completely. It's really easy to just delete code without worrying that it's being used somewhere else. It's really easy to change things, um, because of the type system. And then it turns out to be really, really easy to talk to, um, JavaScript over ports.

[00:41:56] Jared: okay. And I know some people have struggled with using ports. And so, yeah, it'd be interesting if y'all had some insights to share. I don't know if you followed kind of the pattern that, I don't know if you remember, there was a talk that Murphy Randle gave back at elm-conf 20 16, 2017, something like that. The importance of ports and, you know, kind of described one of these patterns of having a port in and a port out and then encoding and decoding the values across those. Um, which I thought was a nice pattern that I've used myself and kind of to that point of like, you know, when you're adding something new you can kind of copy that.

[00:42:45] That process, and then, because the Elm type system makes it easy to model things, if your thing is unique, then you can easily, you know, define that model, that type, and then figure out how you need to encode or decode based around that. But, um, but yeah, I'm, I'm curious because you're doing a lot of this interaction, if there is some unique situations or, uh, techniques that you found that, uh, might be interesting.

[00:43:13] I don't know, maybe you should, uh the, the team there at Qoda talk with the Elm Radio folks about some of the, the tools and techniques around using ports, because, um, that might be interesting.

[00:43:25] Nduati: Yeah, I, I think Dwayne did a, like a post on Elm Discourse a while back, um, kind of describing this. But essentially it's kind of what, um, uh, Randle talked about. So but we like a few layers on top. So the way we structure it is we have like a, a port in and a port out but we don't talk directly to the ports.

[00:43:48] So, um, a page never talks to the port directly. Um, in between the port page and the port, there's something which we call, um, messages. . So a message is, it's like a request for specific things. So maybe on your load page you have get homepage data, and that module for, I don't know, application dot port dot message, dot get home page data.

[00:44:16] It knows everything about how to encode data. So maybe for let's say it's a logged in user. So when you request the data, and you need the user's ID. So you pass in the user ID to like a message function. And that knows exactly how to wrap, that user ID into some JSON value.

[00:44:36] And it knows exactly which port, um, where to send it. So whenever we're sending out data, we send , like a json with a tag, which is like a name of which piece of data we're talking about and a value. Once it gets to the JavaScript side, we have like a long, uh, case or switch statement that matches on every possible message that can come out of the Elm side. That calls a function in its own, uh, JavaScript file that knows how to like pull in all that data. So if there are HTTP requests that have to be made, maybe talking to local storage, it does all of that. And it can either succeed. In each case, it returns almost a namespaced version of the request. So if the request was something like get homepage data, it can return get homepage data dot error, with like a, as a tag and a value with some error.

[00:45:31] Or it can return get homepage dates. Get homepage data dot data and then a value of the actual data. That's returned by that function. And then it gets sent back to Elm. And then the ELM side, the same module that knew how to encode the the request to get the homepage data, also knows how to decode a success.

[00:45:54] response or an error response. It knows everything about how to, like, it knows everything about how to, like, unmarshal this into the, like, a proper rich type, uh, inside Elm, and then it now pushes it to the page through, like, a subscription. So, like, it's It sounds like a lot, but once you've done it the first time, uh, from that, like, if I want to know I had to get a settings page data, I'll just copy the home page data file, copy paste it, change, like, the tag name, and maybe the data and marshaling, and then go to the JavaScript side and add an extra case statement, or, like, an extra branch handle getting the data So it turns out to be like, really, once you've done it the first time, it's really easy to do.

[00:46:45] And it's very easy to reason about, there are very nice ways of being able to log, so you know, Like when you're developing data came out here, it went here, then it disappeared here. And now you can reason through all of that. So, I don't think I've ever had any real problems with JavaScript interop.

[00:47:04] Jared: Yeah, nice. Okay.

[00:47:06] And I forgot that Dwayne wrote that post on Discourse. I'll add that link in the show notes so folks can take a look at that

[00:47:14] Haruki Murakami site animation

[00:47:14] Jared: One thing that I wanted to go back to was you had built these, a couple of sites, kinda learning different things, one of them being, the Haruki Murakami example site, and were there any challenges that you faced?

[00:47:31] I know that has a lot of animations in it.

[00:47:34] Nduati: I think the one, so, okay, so just to describe it to anyone who's listening, um, it's like a simple site. The idea is that there's a list of books. you click on one of the books, it animates as if, uh, like, okay, so you have like a a horizontal list of books. If you click on one of the books, it kind of lifts off the surface of the, of the, of the main page.

[00:48:01] The other books kind of slide away and you end up on this, uh, new page. And if now click on that book, on the new page, it like, it animates as if the pages are, are stacking. So yeah, I think that the, it was like a really interesting project and like a lot of the things I do on the side with the Elm, it's more.

[00:48:20] I want to prove to myself that I can do this. The idea being that at any point in the future, whenever there is, like a designer suggests something, it's not like this fear that that'll kill us if we try and do that. But the one thing I did kind of struggle with there is that, like, animating between pages.

[00:48:41] is almost impossible. So some, I think, like, uh, Astro 3 has been, like, really showing off inter page animations. And there have been some proposals, I think, for Chrome for like, hero animations between two pages. But at that time in Elm, what I would have to do is, like, inside one file, I would have A view function that kind of mixes the state of two pages.

[00:49:06] And when I'm animating between two pages, I'm kind of hiding some pieces of the page, one page and showing other pieces of the other page. And, I don't know. It was a lot of work, but I don't think it's something that should be all that much easier in other programming languages. Because you still have to, at some point, describe.

[00:49:26] How things are going to move, the speed of animations , and things like that. Yeah. I don't know. I think it's a software project and I think it's definitely doable to do like really complex UIs and animations in Elm. Um, yeah. I don't know. I'm not sure I've answered your question.

[00:49:48] Jared: Yeah, yeah, I think so. So, yeah, there's some kind of mixing of models that you have to consider here because it does animate between these two pages and different parts of that page are showing or hiding, if I recall correctly, as it's as it's going between them. So, yeah, that makes sense.

[00:50:07] Not having to pay the cost of constant change

[00:50:07] Jared: What are you excited about now?

[00:50:10] Nduati: So it, it's tricky to talk about being excited with Elm. Kinda because like, one of its greatest strengths is what everyone seems to be complaining about, the, the fact that it's so unchanging. So the, one of the things I really like about Elm is and I've had people complain like about the, uh, 0.18 to zero, uh, 0.19, uh, transition.

[00:50:36] But in my experience code I wrote like three, something like three or four years ago. I can walk back into it, it's exactly the same, it reads, like there's, there's no huge changes. And like some of the things which I'm happiest most about Elm end up coming out of libraries. So like, Tereza's, elm-charts library.

[00:50:59] Came out, not of some huge change to the language, but someone spending time to build something, um, something beautiful. So the thing which I'm excited about Elm is, it's a boring thing, but it's the stability. It's the fact that, uh, I can always come back to code bases that I wrote a while back. Even team projects that you build something and then you walk away from it.

[00:51:24] So maybe, an admin dashboard, and for months, there's no real reason to change things. And then a feature request comes in, you walk into the codebase, and everything feels like all the other code you're writing all over the place. Well, I'm excited about Elm staying the same. Which isn't a popular opinion, but there's a power to, To be able to always understand what's been written in a codebase.

[00:51:51] Being able to steal code from other people online, because you don't need to worry about which version of React or Vue are they using. Or if it's the functional style or components. Like, there's a lot of decisions which I don't have to make because Elm is pretty much stable and Like, it's no longer a cost I have to pay, when I'm working with Elm, uh, knowing about types and versions and all that.

[00:52:19] Jared: Yeah, I like that. That's well put. Not a cost that you have to pay. I, I feel that for sure and, you know, not having that mental overhead, that load of thinking about, yeah, will this work with the version that I have? Because, yeah, the, the change hasn't been since, yeah, what was it? 2019. So, the language is very stable.

[00:52:47] It allows us to continue to keep our projects going, introduce code from an old project into a new project, and yeah, make it just seamless because there's no significant change. There's not a difference in the style. It's funny that we were talking about that pattern of using ports, right? And this was something that was talked about, what, six years ago.

[00:53:19] In terms of JavaScript world, that is an eternity. You know, generally, that, the amount of change that could happen in that time period, you'd think, well, that code is just trash. But Elm doesn't suffer from that. So, yeah, the stability means that you can leave something and not worry that when you come back to it, you're going to have to make a whole bunch of changes just to get back to where you were when you left.

[00:53:50] Nduati: actually, this is like a huge thing, even outside, like, JavaScript itself, even the The bundlers, um, so there was Webpack, then Parcel, then ESbuild, then Bun, um, And, like, for us, forever, it's been elm make. And, like, it all just works, And there's, there's a lot of simplicity to that, Cause there are no decisions to be made, And the ones which were made, at some point, by Evan, A lot of them turn out to be really good.

[00:54:22] So, yeah.

[00:54:24] Jared: Yeah, yeah, for sure. I mean, they're good because they continue to work and

[00:54:28] Nduati: Yes,

[00:54:28] Jared: haven't had to have changes in such a long time. So,

[00:54:33] Picks

[00:54:33] What PIX do you have for us today, Nduati?

[00:54:36] Nduati: So I'm sure these are well known in Elm, but I'll still share them. The first is an old article from 2019 called Parse, Don't Validate by Alexis King. And it has this It discusses this idea, that's really common in Haskell and applicable to pretty much every programming language of converting types. So, if you have data coming from outside, maybe the user, instead of confirming that the data matches some requirement, the idea is that you, instead of doing that validation, making sure that certain conditions are true, You do that and then convert it into a new type.

[00:55:18] So instead of having an email as a string, you could wrap it into an email type. So that from that point forward, you know that within the language , and this is especially useful in Elm, everywhere that you have, like, that email type, you know this is a valid email, uh, string.

[00:55:36] So that's something I really like, and, it makes it much easier to, like, reason about your code, because it's not a bunch of strings everywhere, you have an email type here, you have an amount type there , and I love that. The second is an article called, Drag and Drop Without Draggables, but it's from around four years ago from NoRedInk.

[00:55:57] And this is one of the articles which I love because it, it kind of shows... My, my experience with Elm is that with a lot of other programming languages, it feels like, you don't actually get to touch your system, if I can put it that way. So whenever you're dealing with JavaScript, with drag and drop libraries, it's all, you're always touching something which actually touches the system.

[00:56:21] Um, so this article kind of describes how you can build drag and drop systems where you keep track of the, like, the click down event, move events, and then the mouse up event. And what I really love about that is, like, it's really easy to build really complex UIs because instead of you handing off to, like, some HTML drag and drop, tooling, you're the one who, you can implement the whole thing, so you have special behavior that you want to build into the application. So maybe, something that's picked up on this side of the page can't be dropped on this other side of the page. It's very easy to build that yourself. That's my second pick.

[00:57:00] And my last pick is just to encourage people who like myself, don't like HTML or aren't comfortable with all the Flexbox and all that to look into Elm UI. It's It's probably well known in Elm already, but I found, for a developer who's not ready to go all the way into CSS, still learning things, it's a very good way to learn the web without having to learn, uh, CSS and all the all the 20, 50 ways of doing the same exact thing.

[00:57:31] Um, yeah, so that's, that'll be my third pick.

[00:57:34] Jared: Excellent. Yeah, all great picks. The Parse, Don't Validate. I just want to make a comment about that. That makes me think back to our conversation about boundaries, right? Because that's a lot of what that's doing is not just, not just letting those values in. You're making some guarantees based on how you let those values yes. And that goes a lot to what Dillon and Jeroen say on Elm Radio where they talk about opaque types. And the same idea of Parse, Don't Validate. So, yeah, that's uh, that's great. And this, I had a question about this drag and drop one because You mentioned earlier that you were working on this fourth year project, and one of the features was to be able to drag the tire, for example, and move it over to another part of the form.

[00:58:28] Was this an article that you used to implement that,

[00:58:31] Nduati: Yes. Yeah, it was. The thing that I love about it is how straightforward it is to, to implement. And maybe this is something you should have mentioned earlier, but I've also had experience with, , I had a small application I was working with where, we had data coming in, in XML and you needed it to be, like parsed into some JSON structure, and it turned out to be like a very nice, uh, user experience, uh, yeah, user experience to be able to just paste in the XML on this side, paste in the target JSON on this side, and then just drag and drop the values from the XML to the JSON, and like, then have the backend figure out how to do the JSON, uh, the XML parsing, the JSON parsing, and out how to.

[00:59:19] So I think drag and drop can be a really intuitive way of letting people , like connect different parts of the app. Yeah, and in Elm, there are a few, like, watchouts about making sure you're not, like, if someone lets go or their mouse goes out of the screen, you're aware of that. But it's like Surprisingly easy, even for like a novice, programmer to implement like really complex UIs with Drag'n'Drop.

[00:59:49] Jared: Excellent. Yeah, and then I guess I should probably comment on Elm UI. It's just so nice to be able to use that if you can. So, yeah, a great way to learn. If you can use that instead, it's intuitive to think about and not be thinking about weirdness with layout and weirdness with styles.

[01:00:14] Nduati: Yeah.

[01:00:15] Jared: Yeah, all great picks.

[01:00:17] I just have one pick today. I don't think I've picked it before. It's elm-doc-preview. use it at work for our internal application documentation. So a lot of the modules that we have We reuse in different parts of the app and so I want to be able to share that, make those things easily discoverable for folks who are new to the program or to the system or even for myself if I haven't used a particular module in a while I want to go check it out and remember what's, what's available here and how do I use it? So,

[01:00:56] Nduati: Hearing about Elm Doc Preview kind of reminds me of an issue I've heard a few times about how Elm doesn't let you, kind of set up private, uh, private libraries. And I think, so there's a combination of things which, like, makes that not an issue. So, uh, in Elm, using, like, relative path directory.

[01:01:20] You can say, if this is your main application and in a nearby directory, like your library exists, you can go into your download. json and say the sources, you can list that directory as, like, one of the sources. So it's very easy to bring in if you have private libraries, just set up a git repository for it, and You clone that repository near your current project, and then you can import in pretty much all the modules for that existing library.

[01:01:51] But now with elm-doc-preview, it's very easy to additionally pro uh, provide kind of private documentation for your private libraries. You still end up getting that full experience which you get from Elm. So good documentation and an easy way to import in your private libraries.

[01:02:12] Jared: Yeah, that's a great point. We'll definitely add a link to the ElmDoc preview side. And so if folks want to use that for their private libraries in addition to their application documentation, then they can do that. Excellent. thanks to all the folks listening out there, please rate and share if you're enjoying the podcast and thanks Nduati for coming to Elm Town.

[01:02:40] Nduati: Yeah. Thanks for having me, Jared.

[01:02:41]