[00:00:00] Andrey: I found this JavaScript library and I thought, well, how hard could it be to port just the necessary bits, to Elm? You kind of, you have to become an interpreter of the codebase yourself

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

[00:00:19] Sponsored by Logistically

[00:00:19] 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. We build the front end for all new features in Elm.

[00:00:33] If you're interested in our mission and enjoy writing Elm, please drop us a line elmtown at logisticallyinc. com. I'll put a link in the show notes.

[00:00:42] Introducing Andrey

[00:00:42] Jared: Now, let me introduce Andrey Kuzmin. Andrey is a software engineer who loves concerts, yoga, and functional programming. He currently works at Framer. He is a long time Elm aficionado and game maker.

[00:00:58] Some of his Elm contributions include organized the Elm Berlin meetup and Elm Bridge from 2017 to 2020. He created several games in Elm and led several game jams, notably Mogee, a WebGL platformer that fits into a 64 by 64 pixel screen, which he presented at ElmConf 2017, and the collaboration with me on elm-pool.

[00:01:26] He maintains the Elm Explorations WebGL project. He's published Elm Physics, Elm OBJ file, contributed to the Elm Language Server, including recently adding Elm Language Server support to Zed, a high performance multiplayer code editor from the creators of Atom and TreeSitter. Andrey, welcome to Elm Town.

[00:01:48] Andrey: Hi Jared, how's it going?

[00:01:50] Jared: Good, good, I'm glad to have you on. So, one of the things I wanted to do to get started here, I usually start with asking about how you got it started in computing and programming, and we're gonna get to that. But first,

[00:02:04] Favorite concert

[00:02:04] Jared: because you have this on your Github that you love concerts, I wanted to ask you, do you have a favorite concert or band that you like to see in concert?

[00:02:17] Andrey: I can talk about the concerts I went to recently. so one of them, is a band called Deerhoof. they play like very, very interesting and peculiar music, uh, like using guitars. And, uh, I really liked their last album because they, uh, they started to sing in Japanese. Their singer, she is Japanese, uh, and before they never sang in Japanese, but then all of a sudden, uh, they started singing in Japanese, and I learned Japanese, uh, So it was like, it's really fun, a really fun concert to go to.

[00:02:52] Jared: So, you've learned some, some Japanese, and so, yeah, you had this connection with that, for sure, and you like this interesting guitar stuff that they do, right? Then, actually, I did have a question to ask you about natural languages. So, how many natural languages do you know?

[00:03:12] Andrey: like my, my home language, Russian and English, uh, I can, uh, speak fluently and, uh, and I've been learning German because I live in Germany, uh, I've been living in Berlin for about nine years. I've been learning Japanese on and off, like maybe 15 years ago. I learned it for a couple of years.

[00:03:32] And then most recently, because I got to travel there. A few times I picked it back up and now I'm still actively learning Japanese twice a week I'm attending online classes.

[00:03:44] Jared: Japanese is the one that you're focused most heavily on, but of course, yeah, you have the English and Russian fluency and then German as well. So do you think that English being a second language has affected how you program in general or because you're fluent, has it not been a big deal?

[00:04:08] Do you have any insight into that?

[00:04:10] Andrey: I'm not sure exactly about this. I cannot connect my, like, my language to the code that I write. I think English has a lot of flexibility in it. So it's, I think it's more interesting to talk about German or Japanese where the, I don't know. Uh, the grammatical sentence, uh, like kind of makes sense in the, in the programming way, like, uh, I think that, that makes, probably makes you be a bit better at, uh, at like logic and, and, and writing code because you write code, uh, like you write down logic.

[00:04:50] Jared: I guess to help me understand that you are saying that because German is more logical in the syntax and more strict and Japanese, then those languages are better suited for training your brain to, to program. Is that kind of what you're saying?

[00:05:11] Andrey: I think so. I think so. Yeah. Uh, both, uh, both languages have this, uh, kind of frame based structure where you have like a grammatical structure with placeholders where you can put words, but only in the places where they can be put and it kind of trains you to program in a way.

[00:05:34] Jared: Yeah. Okay. That's pretty cool. Yeah, that's really interesting to think about. Okay. Well,

[00:05:41] Getting started in programming

[00:05:41] Jared: let's get into this standard starter question then, about how you got started in computing and program, kind of your, how you began and what motivated you to get into it.

[00:05:56] Andrey: Oh, I've started programming a very long time ago. I think I was still in the secondary school and I was, uh, I think the first thing that I was programming was, uh, was using either QuickBasic or Pascal or both. I was I was actually trying to make some games and I was, uh, I was writing a game in, uh, you know, the shoot them up kind of style where you have a spaceship and you shoot up and then there are enemy ships coming at you.

[00:06:28] And I only, I only managed to have like one enemy ship there moving on the screen. And then I thought about like, what should I do to add the second one? And you know what I did? I just copied the whole code for the first one and I changed the, the variable names to have, like, two at the end of them. Uh, and I got two two enemy ships on the screen.

[00:06:54] That was amazing.

[00:06:56] Jared: Nice.

[00:06:58] Andrey: on I learned about arrays and how you can have many things on the screen.

[00:07:04] Jared: Cool. Well, you were able to take the knowledge that you already had and extend it, right? So yeah, that probably also reinforced the power of arrays in that respect. You're like, Oh, wow, this is much easier.

[00:07:21] Andrey: Yeah, and, and after that, um, I continued using BASIC. I think I used, uh, so I used Visual BASIC. I had a friend who implemented like a small kind of 2D library using Visual Basic, using DirectDraw. And I used that and I made like more complex games. So there was, uh A platformer game I made with, together with the map editor. There was also, like, a kind of a shooting game, like, look from the top and there was, like, a person in the center of the screen and you could, like, move the mouse and the person would rotate and shoot in different, uh, directions.

[00:08:12] Jared: Okay. And you said this was in Basic?

[00:08:16] Andrey: Uh, yes, this was, using, uh, Visual Basic.

[00:08:20] after that I studied at the uni, I studied computer science. , and then I started working as a, kind of a full stack engineer, so I was doing a bit of backend. some of that was in PHP and like early days of Ruby on Rails, then I learned Python. Then I dove deeper into front end, um, like Node. js was, uh, starting. And, then I learned front end frameworks. My first one was Backbone. js. Uh, then was React. And yeah, this is how it all started.

[00:08:52] Jared: sure.

[00:08:53] Discovering Elm through Dan Abramov

[00:08:53] Jared: So you went to the university and studied computer science and then you were becoming a full stack engineer, learning all these different languages, moving from languages that, yeah, were full stack to front end specific things like React, Backbone, and then I'm guessing this is leading us to Elm.

[00:09:16] Do you want to tell us a little bit about how that came about?

[00:09:18] Andrey: yeah, actually I got into Elm through React. Uh, I went to, uh, one of the React Europe, uh, conferences in Paris. And, and at that one. Dan Abramov presented his time traveling debugger in Redux. And, uh, yeah, he mentioned, uh, he mentioned Elm, and it got me curious. And, uh, and I wanted to try it, so, and, and I wanted to try it for something fun, because, uh, I mean, free time is for doing something fun, so I, implemented a game.

[00:09:52] It was, uh, it was like a copy of the, of the Tetris game. it was a clone of the existing, game. it was fun to think out in the, in the functional way. it was quite difficult for me to, to get started, even though I, I studied some Lisp at the uni. Uh, it was still, I think I forgot all this knowledge and I had to break something in my head to, In order to start thinking in terms of of immutable functions.

[00:10:23] Jared: Right, okay, so you, I like that phrase, break something in your head to just start thinking in that way. But yeah,

[00:10:32] Andrey: there was some step, there were some established connections, like in order to program in object oriented style or in procedural style. And like, in order to start thinking differently, you have to forget about the other ways of, like, how you used to do things.

[00:10:57] Jared: I think about it as, I can put that stuff into one box and then over here in this other box is all the, the functional concepts. But then, sometimes I will think about certain concepts that, that pull over. I'm like, okay, these things, I guess then kind of becomes more of a Venn diagram where these parts overlap, but there are these two sections on each side, which are independent.

[00:11:23] So, yeah, that's really interesting. Okay. And this time traveling debugger was something that motivated you to start this initially, right. Building this, I believe it's called Flatris, the Tetris clone. Uh, yep.

[00:11:40] Andrey: The original Flatris was implemented in React, so it was already sort of functional, but not exactly.

[00:11:49] Jared: So You were making this Flatris game and you, how did it go? What did you think of Elm after you sort of broke your brain to learn functional programming?

[00:12:04] Andrey: this was my very first approach to making a game. I first started with very big let blocks, and I have like, this equals this, and then that equals that. So it still looked a bit procedural, because one thing, I thought about them as one thing happening after another thing. then another thing I saw is that some logic that would be very easy to do in imperative programming in Elm, for me, costed me a lot of lines of code. and then seeing this in Elm, I started thinking like, does it have to be this way? And as I learned more, I was able to change the data structures in order for the operations on them to become shorter, like more concise. Uh, so for example, uh, like when modeling, uh, uh, Tetris pieces, you would think of, like, yeah, I probably need, like, uh, a two dimensional array to represent them. But then, like, how do you implement, like, other, like, iterating on all the pieces? So you would have to iterate on, over the blank spaces too, uh, and, and the logic gets, uh, like pretty complicated. Uh, so what I did instead, I represented all the pieces as a, as a list of coordinates for each of the, uh, each of the squares that, that it occupies. And that like really helped me down, uh, to shorten down the, the code and the operations on them. 'cause I could easily map over like all the occupied, uh, blocks, uh, all, all, all the occupied, uh. Squares for each piece.

[00:13:55] Jared: Right, yeah, so you changed the data structure and it made the code much nicer for this FP style, Functional Programming style, I think there's a lot of power in how you model the data, and I've noticed that I can sometimes tell when I don't have it right. For that reason, because the code's a little clunky, or I have to write a lot of extra stuff, some helper functions.

[00:14:24] And then I notice when I've made an improvement, because all this stuff goes away, right? Like, I'm like, Oh yeah, all right, this is, this makes sense now. I, you know, I've kind of remembered or learned some, some way to, to model the data or just try changing it. Because Elm is so good at telling you what you need to change.

[00:14:53] Of course, you can make that change fearlessly, right? And then, uh, and then go fix all the compiler errors and, and then it works again. So that's, yeah, that's pretty beautiful.

[00:15:04] Applying knowledge from Elm in React

[00:15:04] Jared: So you have at this point broken your brain. You've, you've learned Elm. What comes next?

[00:15:14] Andrey: I really liked it and, um, I like using it in my free time, like after work, uh, on the weekends. And I think that the reason why I kept coming back to it for, like, trying it for other games, too, is because I didn't have to think about, you know, setting up Webpack, configuring all the front end packages because Elm gave me everything out of box.

[00:15:46] Like, I could create something just using Elm. And that kind of brought me back the joy of programming for fun.

[00:15:57] Jared: I feel like for me, because I had a similar transition from trying to do functional style JavaScript to then learning Elm. And I was using JavaScript on the front end and back end. I had some Node. js experience and one of the things that I found was I hadn't had to deal with Webpack.

[00:16:20] I think this was Grunt and Gulp JS days. So that ages me, but yeah, so, but the, the point there being that there were these other tools that were churning over that I had to keep relearning. And then even the libraries, even if I was going to use the same library, if it stuck around that long, then I had to figure out, Oh, do I need to upgrade?

[00:16:46] There might be some changes. How does this work? If it works differently, what's the documentation like, you know, how do I use it? I can't rely on consistent documentation and a nice compiler error message if I, if I don't understand something. So yeah, that, that's certainly something that, um, I think for me, I thought about it as like this just overwhelming kind of overload of all the things that I had to, to pack in, but with Elm it's more freeing and I can kind of focus on the thing I'm trying to build. So, yeah, that makes sense.

[00:17:23] Andrey: And then the second thing that I noticed was that me, like, toying with Elm and making some things for fun actually made me a better programmer in JavaScript or TypeScript. And as you said, like you were using this functional libraries. I don't think that I, I saw like any big value in them.

[00:17:47] I was just a front end engineer before trying Elm. Uh, but then I saw like, then things, uh, clicked in my head. So I, I could write React that looked really nice. And, uh, I took a lot of things from Elm. Like, for example, like if you. If you have a function, like, why, like, you should only pass the arguments that are actually used in that function.

[00:18:14] And sometimes, folks in the React ecosystem, they don't, uh, pay too much attention to this. So you have, uh, You have components that get, a lot of properties and use only a few of that, of them, That, uh, was, uh, one of the things that I learned. Another thing was, uh, actually using, like, using Redux, uh, probably the way it was meant to be used. I worked at SoundCloud, we worked on an Xbox app. And we had one big store that represented the whole UI state, plus the state of the things that it fetched from the backend. And then all the things were, were passed down to, uh, React components.

[00:18:59] And, uh, yeah, a lot of that was like really influenced by the way I would write Elm code. It was really like nicely structured. Like I, sometimes I don't feel very proud about my front end code, my JavaScript code. But. But the application was structured very well, and some of the pieces of this application were then later on taken into some other codebases.

[00:19:24] Like, I think the mobile website has some pieces of the audio integration. Uh,

[00:19:30] Jared: Oh, cool. Nice. And where were you working when you built this?

[00:19:37] Andrey: it was at SoundCloud. SoundCloud for Xbox and Windows. Like, uh, kind of Electron like, but, uh, using Microsoft, uh, alternative.

[00:19:47] Jared: So you were at SoundCloud using Elm in your free time, but then using the knowledge that you gained from that experience and then applying it to your work code in React. Okay, cool. Excellent.

[00:20:03] Andrey: Um, so heavy reliance on, uh, union types, they're called tagged unions. Uh, what we call custom types in Elm. Uh, because TypeScript lets you do this. And when I learned about it, I just started using this extensively to represent, uh, different states. there was, uh, One really complex landing page that I worked on and it was it had so much logic and so many different possibilities Depending on you if you are already a subscriber or not Or there is a promotion or you are in the process of applying for a student discount and like all the different prices. So you have another type of subscription and, uh, you're getting a discount because of that.

[00:20:52] So, it was an explosion of different possible states, and, uh, Yeah, the approach was to start with a spreadsheet and have all the inputs, and then fill in the spreadsheet and figure out what states could be unified, and then distill them into, uh, like, uh, different constructors. Different cases, and I've combined all these cases into one big union type.

[00:21:22] Jared: Very cool.

[00:21:24] Andrey: That could be really, that logic could be really tested without requiring testing any, you know, any, BrowserDOM could be just like one function that took all the inputs and produced this result. So you could be pretty sure about what you're going to show to the user, depending on all the different, uh, all the values of the different arguments.

[00:21:51] Jared: That sounds pretty nice. So Yeah, you've been able to extend this knowledge, this experience with Elm into other places.

[00:22:03] Elm at work (Arrival)

[00:22:03] Jared: I know at some point you worked at Arrival and you got to use Elm. Is that what comes next in this journey or where are we at now?

[00:22:15] Andrey: Yes, so, I worked at Arrival last, uh, three years. And, I was specifically hired for my Elm skills, uh, especially doing 3D in Elm. Ian Mackenzie was my colleague at Arrival. Uh, so we used our libraries there, like we used Elm3D Scene, of course, WebGL because it uses, uh, WebGL under the hood. Uh, and it was, it was a lot of fun.

[00:22:43] I didn't spend all my time programming in Elm, uh, at Arrival. Uh, I also picked up some Python, well, I used to do Python in the past, but not Python 3. And I also, , programmed in Rust there. Uh, but as for Elm, I think one of the, one of the cool things, I've like implemented some camera controls, like where you could, like, you kind of, you see, there was like an app with a 3D view of, uh, of a part, and you could, uh, like zoom in, zoom out, pan, uh, you know, zoom in, zoom out, pan, uh, And rotate, uh, that, and that was like really intuitive. And, uh, and I contributed, uh, translucent colors to elm-3d-scene. So you could, you can have, uh, like, uh, see through, uh, polygons in there.

[00:23:36] Jared: Wow. So your work at Arrival also contributed back to the libraries that you had made. And so they were improving through that process. And so let me ask you this, if you wouldn't mind to describe a little bit about how this product worked in relation to what Arrival does. Maybe explain to folks a little bit about that.

[00:24:05] Andrey: I worked on a team that was, uh, building tools for design engineers. And, uh, I used the term design engineer, I know it means, it has a different meaning now in frontend, but these were actual design engineers. So, people who, uh, design parts, uh, for, like, product, like, for industrial designers, and, uh, they use CAD software, uh, to design parts, uh, for the vehicle. The idea was to do some assessment on the parts so they could upload their design and get, uh, some feedback about how it could be improved. And of course there was like a very big bulky pipeline in the backend that was doing all the heavy machinery for this and the Elm app was used just to present the results.

[00:24:56] Jared: Right.

[00:24:57] Andrey: And, uh, in the results, you could see the part and some information about it and some suggestions about the design.

[00:25:05] Jared: Very cool. And so these parts would be going on to vehicles, correct?

[00:25:10] Andrey: Uh, yeah,

[00:25:12] Jared: Okay. Nice. So you got to, after being in the Elm community for a few years, Just on your own free time, right? You got to apply this to your day job.

[00:25:31] Consuming-facing work and opening up to other languages

[00:25:31] Jared: Do you want to talk a little bit about what you're up to these days?

[00:25:37] Andrey: I've just joined, uh, Framer, and I've been with Framer for about, uh, three weeks now, I think, or this is my fourth week there. And I joined Framer as a product engineer. So even like before, uh, Arrival and SoundCloud, I was not only doing front end, but I was also doing back end. And I'm kind of working in both, uh, at Framer too.

[00:26:02] what I think I like is, uh, like I enjoy in general delivering some things that, uh, the users, uh, are using, so the things that the users can interact with. Uh I think I was missing some of that when I was working at Arrival because the user base was only internal, uh, internal customers, not the whole world, but, but Framer has like such a, such a big exposure. And then another thing that is cool about Framer is like, unlike other, uh, similar products, uh, Framer, like, really fosters creativity, like, all the Framer websites, they have, like, lots, uh, lots of heavy animations and some effects on scroll, and all of that, and the general, like, mission to make the internet more creative, I'm, like, really down for that. Um,

[00:27:01] Jared: That's really cool. And so, This time you're not using Elm, but certainly I think the, as you mentioned before, the experience of having used these concepts, you can take those into the, the work that you do today. And who knows, maybe you'll find a place where Elm makes sense there as well. But, but certainly you have the opportunity to have a large impact because of the, the, the user base there.

[00:27:31] So. Yeah, that's exciting. Cool.

[00:27:34] Andrey: So I think that at my work at Arrival made me open for. Trying out other languages in general, uh, because, I worked with, uh, with folks, who programmed in Python, but without, uh, a lot of, experience in software engineering and not even knowing about the type system. So, trying to figure out how that code works and that types to it. Getting back to the, comfortable state of, of, of, of things, trying to make them like, it, it's not like the, the, the things are not like super strict on types like Elm, but, To have, like, certain, certain structure in the code and, uh, and certain, certain guarantees.

[00:28:21] It's good enough, uh, for me. Uh, I used to be like a purist. I used to like be, you know, really strict on things. I think you have to draw the line somewhere and like being productive or like spending a lot of time tinkering and, and, and polishing your, your code base. And, uh, I think Elm still stays with me, Elm is still in my heart, and I'm still using it in my free time. But, uh, I think other languages are also fine.

[00:29:01] And I like when there are many different programming languages in general. I like, you know, trying, trying out one language and trying out another language, then, then thinking about, Oh, there are some similarities, but then, uh, in, in they're also different in some way. And you could borrow lots of, uh, ideas, uh, from them.

[00:29:24] Like, uh, I find Rust very interesting because, uh, it. It has a lot of, like it has a very strict type system that is very similar to Elm, but then it adds the concept of the borrow checker and it makes you think about the memory. And, for example, you don't have a problem in JavaScript to choose what to use to store a number because you only have a number. Like, even if it's a float or an integer, you get a number. Well, Elm adds, uh, types on top of it and can make it like a float or an integer.

[00:30:04] But in Rust, you have to think about integers, unsigned integers, like floats, and then, uh, they can have different sizes too, uh. And that's, uh, that's kind of fun, like you are, you feel like you're closer to the machine when, you know, you have to make these decisions.

[00:30:26] Jared: Right.

[00:30:28] Andrey: And actually, like, when we just started, we were talking about integrating Zed with Elm.

[00:30:34] And one of the bugs there was because Elm's language server is written in TypeScript, and it uses the package from Microsoft that helps you implement a language server. And in that package, I think there was like, uh, Like, one part of the API was reporting a progress of an ongoing operation, like indexing your files. And, uh, in the, in the specification, it is declared as it being an integer. And, uh, it's like, uh, yeah, an integer percentage, like going from 0 to 100. And, uh, in JavaScript, they forgot to round it, and it was sending floats. But Rust was very strict about it. Rust was like, let me try and parse this as an integer because the specifications say so, and it cannot parse it. So, uh, yeah, that, that, that bit was broken. I had to contribute to, uh, like to, to the Microsoft, uh, library in order to get this bug fixed.

[00:31:44] Jared: Yeah, that's really interesting. I like this this idea of, again, you've sort of broken your brain. You went from being really, you know, you started out, you were this object oriented programmer, and then you broke your brain to learn functional programming. You were a purist though, in that, uh, you wanted things to be exactly as they should be, and then you kind of went back and had to get into a Python code base where things weren't as strict. And this sort of broke your brain again, and then you're learning Rust. And so now you've, you've migrated into thinking more about how the machine operates at a closer to the machine level anyway.

[00:32:31] OK, very

[00:32:33] Andrey: I've been trying out some, uh, embedded Rust. Uh, so trying to program on a Raspberry Pi Pico, and trying to display pixels on a tiny screen.

[00:32:46] Jared: migrated the Mogee font to that, right?

[00:32:50] Andrey: Yep. Uh, yeah, that's a pixel font that Nadya, uh, my wife has designed for that, for the game, and I thought it would be cool to see it on the actual pixel display. That was quite a fun project. I also tried, I also played with TreeSitter because, so I wanted to use the Elm package as the source, as the configuration for the Rust crate.

[00:33:18] So I added it as a, as a GitHub module, and I used all the images for all the glyphs. But then I also parsed the Elm source code and I got like, some values from there. And I brought them into the code gen that I wrote in Rust.

[00:33:36] Jared: Whoa. That's really cool. You parse the Elm to pull it into Rust using Rust. Okay.

[00:33:44] Andrey: like, like the kerning tables, uh, the distances between the clips. So that was the first crate that I published in Rust. That was my first Rust crate.

[00:33:59] Jared: Okay. Cool. We'll add links to your social media. I know you post that stuff on there sometimes, so yeah, sounds good.

[00:34:09] Interpreting code via the brain

[00:34:09] Jared: I want to switch it up here a little bit. I got a question here from Erkal Selman. He says, quote, About Andrey, what captivates me is his remarkable knack for code comprehension. There was a time when I questioned how he managed to translate a physics engine from an imperative language to Elm.

[00:34:28] His answer was quite extraordinary. He claimed to be able to run code in his brain without fully comprehending it. I'm inclined to believe in this rare capability of his. During the interview, it could be insightful to delve into what the experience is like for him. Does it resemble some form of synesthesia or a different cognitive phenomenon? So synesthesia here being, Is it something where you go from a How you think about it to a different sense, like a sense of smell, or a sense of taste, or color. Is it something like that, or is it, do you have any idea of how this works in your brain?

[00:35:11] Or maybe you could just kind of describe what it's like, and then we can go from there and see how it goes.

[00:35:18] Andrey: yeah, that's a very, that's a very interesting, uh, question. I was, and it was indeed like that. So, I, I ported, uh, cannon.js into Elm physics, and now Elm physics has diverged. As I, as I learned more about the actual things in the code, what, what they meant. So how I got to do it in the first place, I, um, I made some games in Elm and I got into WebGL and then I thought maybe it would be cool to do some 3D things in WebGL and then I made a Rubik's Cube game and then I thought, uh, okay, maybe I can make something else. And, uh, there was a game jam where the topic was, uh, randomness. And I thought that, can I.

[00:36:02] Can I make like a physically simulated dice? And in order to make the dice, I had to do some physics. And then I found this JavaScript library and I thought, well, how hard could it be to port just the necessary bits, uh, to Elm? Just to make sure, to make it possible to like, uh, drop, uh, drop a dice and then See bouncing and, uh, and blending on one side. and I can read JavaScript. This is one thing that I'm really, really good at. I can read like the worst ever possible JavaScript. I can figure out where, like, where the data is coming from, what kind of, uh, transitions, what, what kind of, where it is mutated. And then another thing is. I kind of, in order to do this, uh, in order to port, uh, like a highly imperative code base to, uh, like a purely functional code, uh, to, into a purely functional style, you have to see what, like, what are the dependencies, where the things can be, where the things are mutated, where they are not mutated, and, uh, Establish some sort of boundaries, like, if you see that from this part of the code, like, only this is mutated, then you can have a second, you can implement a pure function for that.

[00:37:31] For some, like, highly imperative algorithms, uh, what you do is, uh, you implement a recursion and, uh, Uh, and you, uh, take all the local variables that are changing and you make them into arguments of your function and then, uh, every time they change, you call your function with, uh, new values and, uh, and this is how it can, update them. But yes, like, I think this has like, I think in order to be able to do this, you need to have like years of experience of writing code and seeing any possible code. And, uh, You kind of, you have to become an interpreter of the codebase yourself in order to see what, like, how it works. Uh, so you have to, you have to be evaluating things in your brain and you have to have, like, uh, Rust's, uh, borrow, borrow checker in your brain.

[00:38:33] Maybe that's why Rust, uh, I found Rust very interesting, because, uh, like, a part of, of my brain was, has been doing this already. Um, yeah. I'm,

[00:38:46] Jared: Nice. Very cool. Okay. So you, you have a capability of understanding code when you're reading it and, and being a sort of interpreter, like you said, is there, do you have a visual way that you think about this in your head? Do you, you know, do you kind of see this or is this just kind of standard thought or?

[00:39:17] Andrey: I don't think that I see it. I think what I see is the code in the editor and, uh, And the variable names. It's not that I have like a visualization, like a graph of some dependencies in my head. Like, I mean, it probably exists, but I don't see it as a visual thing.

[00:39:42] Jared: Well, this kind of relates, I think, to another question that I had.

[00:39:48] Designing APIs

[00:39:48] Jared: So what have you learned while designing the API and writing docs for your Elm packages? One example I want to reference is your API design sessions with Evan on WebGL. Are there any specific things Things that you've learned from that.

[00:40:02] It sounds like maybe this one where you talk about finding all the mutations and establishing boundaries, that seems like that could be something related there, but is there anything else or maybe dive a little deeper into that?

[00:40:14] Andrey: How I got into, uh, WebGL in the first place. I made a game and then, uh. the new version of Elm came to be and Elm WebGL stopped working and I realized that there was no one behind the package anymore. And it happened to be at the Elm Meetup in Berlin where I met Noah, who was also highly active in the Elm community back in the days. And he helped me, uh, to migrate the WebGL library to the newer version of Elm. I think it was this version where Elm stopped being a functional reactive programming where when Elm dropped signals, it was like a fairly big change in how the underlying JavaScript code worked. So with the help of Noah, I managed to migrate it and then, uh, I wanted to release a newer version of this, and in order to do that, I had to go through the review process with Evan. And this is how our sessions came to be. And I think they are recorded, and it's still available. I do not remember what we discussed there. Most of the things, as far as I remember, most of the things were about making certain states irrepresentable. It was about seeing what is possible to do in WebGL, what are the possible combinations of values, and coming up with the best Elm types to represent these. So it wasn't about immutability per se, it was, I think it was already, like, the main API didn't change too much, the way you input data, the way you tell WebGL what to render on the screen, that was mostly the same, but, uh, with the newer version, there were less possibilities for you To run into the white screen when something is broken and is not working. Because, like, the combinations were made impossible with types.

[00:42:38] Jared: Well, I think that's certainly a core concept there that, that is good to understand. There were some, I noticed at the end, I just watched part one yesterday. So I have a little bit of that in my brain, but toward the end of it, and I'll add a link to, to these videos, but toward the end of it, there were some general tips on how to document things that I thought were pretty valuable too.

[00:43:04] So I'll add a link to that specific part of the video, but yeah. Okay. So, so you learned some, some tips or maybe, you know, we're kind of guided and into using some, maybe you already had this knowledge, but at least worked with Evan on making these impossible states impossible, sort of changing the API to work a little bit nicer and cleaner.

[00:43:31] I think there were some cases where. Well, there were some places where you could pattern match on cases on, uh, on custom types. So the, uh, it was exporting all of the values instead of making it opaque. And so I think that was, that was changed as well. So, yeah, that, that's a good one.

[00:43:56] Andrey: And I think, like, after that, I took some of that knowledge and I worked on Another package of mine, that like came to be later, uh, elm-obj-file. And I think I'm really proud of that one, uh, how the API turned out to be. Uh, because, uh, so the Elm obj file, it lets you load a 3d geometry from an obj file, a wavefront obj format that you can export from Blender 3D software. But what's interesting about this OBJ format is that it can contain sections, it can contain multiple objects defined in the same file, it can contain multiple groups, and they may have different geometry in them, or the same geometry but with different parameters.

[00:44:54] Uh, the parameters may be a position and normal to the surface, or, uh, a texture coordinate like that tells where this vertex is on, on the texture. You can find it. and what I wanted to have is a package that, that you get all that information from the file and then easily use it with elm-3d-scene. In elm-3d-scene, it defines its own, uh representations for materials, for different materials. Like, for some of them you need texture coordinates, for some of them you need normals, and so on. and the way this was implemented, uh, that was, by the way, highly influenced by my collaboration with Ian Mackenzie. And I got lots of tips from him, too, in working on this project.

[00:45:40] How it came to be is, what if this loader was a decoder, like a JSON decoder? So you could kind of parse this representation, but then you could decode things that you need from it. And it worked really well, and it allowed, for example, to store multiple parts of the same thing in the same file.

[00:46:07] So, for example, if you have a car you could store, like, the car, the wheel for the car, and maybe a convex shape for the physics to represent the collider. So you have the collider shape that usually has to be coarser than the visual representation, because for a collision, it's nicer to work with simpler geometry.

[00:46:37] So that it will be a performant. And you could store this whole, like, everything in the same file, and then you could write a loader by combining the decoding primitives, and you could decode the model of the wheel, the model of the car, the collider, and then put them in your own representation for the car.

[00:46:59] Like, uh, elm-3d-scene mesh, and uh, Elm physics, uh, body, and then you could like both render and then simulate that. Um, and I think this is a very powerful concept and it made like a really dumb OBJ format into something that can, uh, maybe even compete with, uh, with like, more complex formats that, uh, other people use. You could think of different hacks. Like, for example, you cannot represent local access. you cannot have a scene graph in the obj file. Everything is in the same coordinate system. But what you can do, you can place, uh line segments to represent, uh, the coordinates, uh, the basis, the coordinates basis X, Y, and Z. As like three, uh, line segments that represent the vectors like this. And then you decode it into elm-3d-scene's Frame3D. And then you can use it to represent like where you want to place a part of the geometry.

[00:48:11] Jared: Wow. Cool. So you worked with Ian Mackenzie and with that, and it, it seems to me like you probably were able to gather a lot of the knowledge from building other packages and, and in the past and, and use those as well and experience with, I think you mentioned JSON decoders and so using those concepts and then applying them to this.

[00:48:38] So you have done a lot of work with 3D. You've done a lot of work with games.

[00:48:48] Presenting at an Elm Japan meetup in Japanese

[00:48:48] Jared: We're about to get close to the end here, but one question or one thing I wanted to mention was you presented at Elm Japan Meetup earlier this year, and kind of going back to what we were talking about at the beginning, you're interested in learning Japanese.

[00:49:07] Do you want to talk a little bit about that presentation?

[00:49:10] Andrey: this was actually my third or the fourth presentation. one of them was remotely, but the, the three of them were actually in Tokyo. And, uh, because I was learning Japanese, I was, I was thinking like, how, how hard would it be to actually do that presentation in Japanese? Uh, so in the, in the first three presentations I made, I wrote down things I had to say, and then I asked my Japanese friends to fix all the mistakes.

[00:49:42] Then I read this over maybe three times. And then the last one was, I started preparing for the talk very late. So, uh, I was, uh, working on the slides whilst already traveling, and I didn't have much time to go through the same process. as I was working on the slides, uh, I came up with, uh, uh, my friend, Yoshi, who was, uh, organizing the, uh, meetup. And I just tried, to present this in Japanese to him.

[00:50:12] And he said, if you do it this way, then it's going to be fine. Uh, I, I thought, okay, maybe I'll, I'll just YOLO it this time. And I did. And I think it was, I think it was good. Uh, uh, I didn't use a lot of, uh, difficult words, uh, this time because. I just forgot all of them instantly when I started talking, so I used very, very simple words.

[00:50:39] Like, mostly it's, uh, you know, to use and to make are the two verbs that you really need to know if you want to show something. Because you can say, like, in order To make this, you gotta use this, or like, using this, you can make this. And, uh, and you can point at things and, uh, that will work fine. Um, uh, but I think it also turned out like really fun.

[00:51:06] And, uh, and it seemed that the folks enjoyed, uh, my presentation. I was actually presenting, uh, our, uh, Elm Pool, the, the pool game that we worked on together with you, Jared.

[00:51:18] Jared: Right. Yeah, that's really cool. So I like this that you, I guess maybe accidentally, but you were forced to be a little more on the spot with how you spoke. And so this created a bit of a limitation in the words that you use. But I think that's, that's good to set those, uh, those limits and then, and then make that possible.

[00:51:46] It seems like that's sort of breaking through another, another barrier in your brain to, to be able to be that conversational, if you will. I guess, even though you were giving a presentation, but. that's really neat, and so that, you think, went pretty well. You presented it in Japanese, in Tokyo, um, and yeah, so that's, that's a lot of fun.

[00:52:11] Elm Town 3D logo animation

[00:52:11] Jared: before we get to picks, is there anything you're excited about now?

[00:52:15] Andrey: Yeah, I think that there was one really fun project that I worked on recently. It was the animation that I made for this podcast. And, with all the knowledge about 3D, uh, when I saw the logo, I thought that would be really cool to, to animate it. And, uh, and as we learned, the logo wasn't really designed in 3D so the logo, uh, was designed in 2D uh, but because of the, some prior knowledge of, uh, of Blender, I could, uh, trace it into, into 3D, save it in, in the OBJ format, and then load into Elm. As for animation, usually using Matthew's package, Elm Animator, and that worked really well. Like, even without knowing all the 3D geometry stuff, when you read that code, just have a custom type representing all the possible animation states, and changing from one state to another is just changing that one value, and then everything else just happens. And all you need to store in the model is, uh, that, timeline of that state. And, uh, and constantly have to be updating it with the requestAnimationFrame. I think I will try and, and write a little bit about it, because, uh, There were a few things that I learned myself, actually, uh, uh, about this, uh, when, when doing this, uh, so, um, yeah, yeah.

[00:53:49] Jared: Yeah, that was so cool. So just to give a little bit more, I was working on this Elm Town website rewrite and it was originally some template with the publishing provider that I use, Simplecast. But I wanted to write it in Elm, of course, and I was using elm-pages, and I showed it to Andrey, and it was like he was inside my head, because I was thinking, I was like, I wonder, I wonder what it would be like if we animated this. And before I even could suggest it to him, he already wrote back and like, this would be cool if we animated it.

[00:54:31] So I was so excited. And when I actually saw him make it in action, you make it in action, I was like, yeah, just blown away. Especially the subscribe animation. I think, I mean, the whole thing is, is incredible, but like, I don't know. It just. It's really cool. I recommend going to elm. town and checking it out.

[00:54:53] You can subscribe with an example email address. That's fine. You don't have to put it in if you don't want to, but if you do, that's great. But checking that out is, is really cool. And yeah, so shout out to Matthew Griffith for Elm, uh, for the Elm Animator package. Yep. And I did use Elm UI as well by Matthew Griffith.

[00:55:13] Let's see. Dillon Kearns' elm-pages used. Oh, there's, there's so much there. Of course, uh, your, uh, used Elm OBJ file, right? On that. Yeah. Yeah. And

[00:55:27] Andrey: packages

[00:55:29] Jared: yes, of course. Yeah. Those are, they're huge. They, they make the, uh, the code just so nice and readable, even for someone like me who is very naïve in an understanding of 3D.

[00:55:43] So yeah, that's a lot of cool stuff in there. I need to get that code out there linked up. And yeah, maybe if you talk about it before I get this published, I'll put a link to that. And Otherwise, yeah. Are you ready to move on to picks? Do you have anything else?

[00:56:06] Andrey: mmm nothing that I can think of, let's, uh, let's move to picks.

[00:56:09] Jared: Okay. Actually, there is one thing I wanted to say. I just wanted to shout out to Maggie Appleton, who created the original logo. You mentioned it wasn't actually written in 3D, but yeah, that is a really cool Elm Town logo. If you know the Elm Town logo, you're familiar with what it looks like. But it's just a really cool way of taking the tangram and then kind of rotating things and making it sort of look three dimensional there.

[00:56:38] So that was cool. She said it was fine for us to render that in 3D and show it. So yeah, shout out to her as well.

[00:56:48] Picks

[00:56:48] Jared: All right, so what picks do you have for us today, Andrey?

[00:56:53] Andrey: One of the interesting things that I find about Elm is that through using Elm, you can learn about other things. by modeling them, because, Elm, like really, really makes it nice to, to describe, uh, certain things, uh, and put them in types. So you, you end up thinking a bit more about the domain that you are working on and it makes it in such a nice and playful, uh, way.

[00:57:24] For example, I. Once, uh, I learned about how to render text with WebGL and, , I did it in Elm. It was like a very, very fun, uh, and eye opening experience for me. And the second thing that, I want to say as a takeaway is, try to make, uh, games with Elm, and, and see where it goes. Try not to overcomplicate things and, like, work on your game engine. Just try to make a game and, uh, you will have a very fun and rewarding experience.

[00:57:59] Jared: Yeah, I think that's good advice. Certainly I haven't made, I've only made one game in Elm, but working with you, collaborating on Elm Pool was a lot of fun. And I, I think that because we were able to structure the code in such a way that there was really no like confusion in, in which parts of the code that each of us had to do.

[00:58:26] And so that was just a, An awesome experience. And it, like, at least for my part, it didn't seem like it was a lot to do. Of course, I wasn't rendering 3D objects or anything, uh, but, and doing physics. But, um, but it was, it was a really cool, um, experience. So, yeah, I think that's good. And it was the only time that I've participated in a game jam.

[00:58:48] And so that was, that was a lot of fun too, having a deadline that, that we had to get to. So, um, yeah. Yeah, those are good picks. I want to go back to the other one that you said, rendering text in Elm, because I think that sort of reminds me of what you're talking about, getting closer to the metal with Rust, that's kind of what you're doing here, where instead of just giving a string and having it render it in some, predefined font, you're actually rendering that.

[00:59:19] So, that is an interesting way to learn more about how that works as well. So, you've maybe broken your brain in another way to understand that. So, very cool. Uh, my picks, I have two of them. The first one is unrelated to programming at all. It is a band, Flaming Lips, and I mention that band particularly because you like concerts, and I've been to a lot of different concerts.

[00:59:56] I like a lot of jam bands particularly, but I saw the Flaming Lips live a couple of times. And under no influence of anything, it was a very trippy experience. And I, I think that it, it's a pretty cool show. I don't even know if they still tour or not, but maybe check it out on YouTube video, but, uh, it's a pretty cool thing to see.

[01:00:29] And then the,

[01:00:29] Andrey: I've seen them once, uh,

[01:00:32] Jared: yeah.

[01:00:33] Andrey: it was really, really good. Uh, and also performance wise, like, when he, Uh, gets into, like, a ball and then goes over the crowd, that is, like, wow. Or riding a unicorn through the crowd, that was quite fun.

[01:00:52] Jared: Yeah, he got into the ball when I saw them too and that was, yeah, that was pretty crazy. It was, it was a pretty neat experience, I definitely recommend it. So yeah, that's fun. But yeah, so my second pick is the Zed editor. We talked about it a little bit earlier. We've added mostly Andrey with me there as moral support.

[01:01:18] Uh, added the, uh, Elm language server integration or the Elm integration, including Elm language server. And I use it as my daily driver today. So, I had mentioned when Mario Rogic had interviewed me on Elm Town 74, that it was not yet my daily driver. That was because the things that we'd worked on were not released yet.

[01:01:46] But since then they are. And I'm using it for Python and Elm every day. It's basically the only editor that I need. So yeah, check it out. And I guess that's it. Thanks to all the folks listening out there and. Rate and share if you're enjoying the podcast. And I want to say a big thanks to Andrey for coming on this show.

[01:02:11] My projects are so much better for, for, uh, having you collaborate with me on them. So, uh, thank you for that. And thanks for coming to Elm Town. Bye.

[01:02:26] Andrey: thank you too, Jared, for having me. bye bye.

[01:02:29]