Further tweaks and grammar

058-wasm.txt

@@ -6,7 +6,7 @@ M: So we've recorded an extra little bit at the end to explain what those things
 
 C: It's really exciting. Stick around.
 
-[Music]
+[MUSIC PLAYING]
 
 C: Hello, and welcome to FOSS AND CRAFTS.
 
@@ -34,11 +34,11 @@ C: Mhm.
 
 M: So what is it?
 
-C: WebAssembly, it's an abstract-- what's called a virtual machine. You might be familiar with the term 'virtual machine' if you've ever booted emulators of various, computer architectures. But 'virtual machine' is a bit more general than that. It just means an abstracted machine. So that can be for an emulator, but it can also be for some sort of-- a lot of programming languages have a virtual machine in them that they use on the compiler that they compile to and that actually runs a program. So WebAssembly is designed to be kind of this general purpose architecture. If you have been doing this stuff for long enough, this might sound a little bit familiar. Java kind of sold this dream of having this universal virtual machine that you compile once and it runs anywhere. It kind of didn't really happen as that dream. It would like look like maybe it was happening for a while, but for various reasons that we will not get into this episode, it kind of didn't. In some ways, WebAssembly is kind of that dream done much more correctly, I think. And it's very well built for being very minimal and being something you can compile to and etc.
+C: WebAssembly, it's an abstract-- what's called a virtual machine. You might be familiar with the term 'virtual machine' if you've ever booted emulators of various, computer architectures. But 'virtual machine' is a bit more general than that. It just means an abstracted machine. So that can be for an emulator, but it can also be for some sort of-- a lot of programming languages have a virtual machine in them that they use on the compiler that they compile to and that actually runs a program. So WebAssembly is designed to be kind of this general purpose architecture. If you have been doing this stuff for long enough, this might sound a little bit familiar. Java kind of sold this dream of having this universal virtual machine that you compile once and it runs anywhere. It kind of didn't really happen as that dream. It would look like maybe it was happening for a while, but for various reasons that we will not get into this episode, it kind of didn't. In some ways, WebAssembly is kind of that dream done much more correctly, I think. And it's very well-built for being very minimal and being something you can compile to etc.
 
 M: Yeah. And this is built on Lisp, right?
 
-C: Sort of. So, the textual syntax looks a lot like Lisp. And if you program in it, it feels a little bit like kind of a combination of Lisp and Forth and assembly all together. So you can program in it by hand in this Lisp-y syntax and it compiles down to a binary syntax, but it's basically a stack machine with a lot of very serious discipline, which means that you are pushing values onto the stack and then running operations that eat those values and then put other things on it. It's kind of like a stack of cards that it keeps like kind of putting things on and then like eating the cards off of the stack and it kind of grows and goes up and down.
+C: Sort of. So, the textual syntax looks a lot like Lisp. And if you program in it, it feels a little bit like kind of a combination of Lisp and Forth and assembly all together. So you can program in it by hand in this Lisp-y syntax, and it compiles down to a binary syntax, but it's basically a stack machine with a lot of very serious discipline, which means that you are pushing values onto the stack and then running operations that eat those values and then put other things on it. It's kind of like a stack of cards that it keeps like kind of putting things on and then like eating the cards off of the stack and it kind of grows and goes up and down.
 
 M: And this makes it so that basically you can get like all of the languages in the browser, right?
 
@@ -46,39 +46,39 @@ C: Yes, that is the reason that the name 'Web' is in WebAssembly. It's not neces
 
 M: Yeah. And it's also a general deployment target, right?
 
-C: That's right. There's a project called WASI, which is a WebAssembly interface system. It's interesting because it's kind of capabilities oriented and it's also kind of POSIX-y. So like POSIX is like the kind of standard for Unix stuff. It's basically like, okay, you have this virtual machine. You can do all sorts of operations on it, but how do you simulate all the things that you might want to do in a program, reading and writing from files and getting input from the keyboard and all sorts of things like that. And so WASI is built for that purpose. And it also so provides some capability protection architecture in the design. So yeah, there's been a lot of excitement about WebAssembly also being just this general purpose target that you can compile to. And then you can, you know, run these programs anywhere, basically.
+C: That's right. There's a project called WASI, which is a WebAssembly interface system. It's interesting because it's kind of capabilities oriented, and it's also kind of POSIX-y. So like POSIX is like the kind of standard for Unix stuff. It's basically like, okay, you have this virtual machine. You can do all sorts of operations on it, but how do you simulate all the things that you might want to do in a program, reading and writing from files and getting input from the keyboard and all sorts of things like that. And so WASI is built for that purpose. And it also so provides some capability protection architecture in the design. So yeah, there's been a lot of excitement about WebAssembly also being just this general purpose target that you can compile to. And then you can, you know, run these programs anywhere, basically.
 
 M: Yeah. And a few years ago, you and a friend started a kind of small group called "It WASM Me", right?
 
-C: Yeah. So Tristan, a friend of the show, has appeared on it before. And we ran this little user group. We called "It WASM Me". We both wanted to understand WebAssembly. So we were hand writing WebAssembly in its WAT syntax, the WebAssembly text syntax, which is again very lispy. And we were just writing very tiny programs just so that we would understand it. You know, when we ended it, we were working on implementing Conway's Game of Life in handwritten WebAssembly. What I wish that had existed at the time, but didn't-- There's a project that exists now called WASM-4. And it's basically like a tiny fantasy console. So you know, we gave a whole episode about the tinyNES, right? And that's a real video game console that existed that people could play games on. And fantasy consoles are basically this idea of like this imaginary, imagine if you made this old retro computer. And so there WASM-4 is like this extremely restricted fantasy console. And so if we had done it today, I would have said, we would try to have written our programs to write out to WASM-4. But when we were doing it, we were just manually hooking in the interfaces we needed to the browser so that we could like, print things out and also write to a canvas and stuff like that.
+C: Yeah. So Tristan, a friend of the show, has appeared on it before. And we ran this little user group. We called "It WASM Me". We both wanted to understand WebAssembly. So we were hand-writing WebAssembly in its WAT syntax, the WebAssembly text syntax, which is again very lispy. And we were just writing very tiny programs just so that we would understand it. You know, when we ended it, we were working on implementing Conway's Game of Life in handwritten WebAssembly. What I wish that had existed at the time, but didn't-- There's a project that exists now called WASM-4. And it's basically like a tiny fantasy console. So you know, we gave a whole episode about the tinyNES, right? And that's a real video game console that existed that people could play games on. And fantasy consoles are basically this idea of like this imaginary, imagine if you made this old retro computer. And so there WASM-4 is like this extremely restricted fantasy console. And so if we had done it today, I would have said, we would try to have written our programs to write out to WASM-4. But when we were doing it, we were just manually hooking in the interfaces we needed to the browser so that we could like, print things out and also write to a canvas and stuff like that.
 
 M: Yeah. Every time we've brought "It WASM Me" up in public, people have asked if this was a user group that they could join. Is this something that you would be interested in expanding or making more public?
 
-C: Maybe. I would be. The main problem is that I don't know when I will have time. But it was a really fun project. Maybe if somebody else is really excited about this, we could get somebody else to organize it and then I could just start showing up. But it was pretty fun. It was just a user group of two.
+C: Maybe. I would be. The main problem is that I don't know when I will have time. But it was a really fun project. Maybe if somebody else is really excited about this, we could get somebody else to organize it, and then I could just start showing up. But it was pretty fun. It was just a user group of two.
 
-M: Mhm
+M: Mhm.
 
 C: But yes, when every time we've mentioned it, various people have gotten excited and said, "oh, whoa, whoa, I wish I could have participated in that one".
 
 M: Yeah. Let's talk about the extensions to WASM.
 
-C: Yeah. So I mentioned that it's a stack machine and it's very minimalist. Like the base, core, what's called the MVP, the minimum viable product version of WebAssembly is very basic in some ways. And you can do nearly anything, but it's so minimalist that it's usually-- like the main thing is that very few people end up handwriting WebAssembly programs, the way that Tristan and I did. Most people are using something like Emcscripten, which compiles C programs to WebAssembly, or they use something like C or C++ or they use something like Rust to compile things. So they're going to be using a language that's not one of these low level languages. They would probably compile the whole interpreter or whatever for that language and then run the program, but that's very expensive. So part of what we're doing at the Spritely Institute is we're trying to advance the usage of these proposals in terms of WebAssembly being a first class language platform. So for example, if you're writing these low level programs, then you're probably doing manual memory management or just using the stack. But if you're using a dynamic language, you might be using something like a garbage collector, right? JavaScript, Scheme, other languages like that, have a garbage collector-- Python. The problem is, the garbage collector goes and removes things that aren't needed anymore, goes and picks up the garbage, right? But if you are running this on top of something like, you're running it with the browser and with the host JavaScript, how do you end up, saying, okay, JavaScript doesn't need this anymore and your program doesn't need this anymore. You kind of have to kind of synchronize those things. And so the garbage collection proposal allows you to use the host garbage collector and you don't have to port over a garbage collector. And there are all sorts of other extensions that are kind of in-progress, like multiple-value return and the delimited continuations proposal and other things like that. We're not going to go into those in this episode, but let's just say that there are some interesting extensions that are being worked on to WebAssembly. And I think part of the value of Spritely pushing forward the Guile WASM stuff is hopefully we will help push forward and advance the ones that are really necessary to get a lot of different kinds of these dynamic languages to be first class citizens in the browser.
+C: Yeah. So I mentioned that it's a stack machine, and it's very minimalist. Like the base, core, what's called the MVP, the minimum viable product version of WebAssembly is very basic in some ways. And you can do nearly anything, but it's so minimalist that it's usually-- like the main thing is that very few people end up handwriting WebAssembly programs, the way that Tristan and I did. Most people are using something like Emscripten, which compiles C programs to WebAssembly, or they use something like C or C++ or they use something like Rust to compile things. So they're going to be using a language that's not one of these low level languages. They would probably compile the whole interpreter or whatever for that language and then run the program, but that's very expensive. So part of what we're doing at the Spritely Institute is we're trying to advance the usage of these proposals in terms of WebAssembly being a first class language platform. So for example, if you're writing these low level programs, then you're probably doing manual memory management or just using the stack. But if you're using a dynamic language, you might be using something like a garbage collector, right? JavaScript, Scheme, other languages like that, have a garbage collector-- Python. The problem is, the garbage collector goes and removes things that aren't needed anymore, goes and picks up the garbage, right? But if you are running this on top of something like, you're running it with the browser and with the host JavaScript, how do you end up, saying, okay, JavaScript doesn't need this anymore and your program doesn't need this anymore. You kind of have to kind of synchronize those things. And so the garbage collection proposal allows you to use the host garbage collector, and you don't have to port over a garbage collector. And there are all sorts of other extensions that are kind of in-progress, like multiple-value return and the delimited continuations proposal and other things like that. We're not going to go into those in this episode, but let's just say that there are some interesting extensions that are being worked on to WebAssembly. And I think part of the value of Spritely pushing forward the Guile WASM stuff is hopefully we will help push forward and advance the ones that are really necessary to get a lot of different kinds of these dynamic languages to be first class citizens in the browser.
 
 M: Yeah. So that is what WASM is and how it can be extended. But why should we care?
 
-C: Well, Andy Wingo, who is the main person that we're actually bringing on to work on Spritely's Guile-to-WebAssembly project, (we're contracting with him through Igalia). We were reading an interesting blog post where he's like, "oh, WebAssembly is a new Kubernetes", which really means WebAssembly is kind of going to be the environment that everyone targets for compiling and running programs. And if you are an enthusiast of other programming languages that aren't JavaScript, then you might care, right? But I think that we're going to see more and more computing be kind of built around WebAssembly partly because it is kind of the version of the JVM dream done right. It's not being controlled by this one big corporation. It's being kind of driven forward by this set of people collaborating.
+C: Well, Andy Wingo is the main person that we're actually bringing on to work on Spritely's Guile-to-WebAssembly project. We're contracting with him through Igalia. We were reading an interesting blog post where he's like, "oh, WebAssembly is a new Kubernetes", which really means WebAssembly is kind of going to be the environment that everyone targets for compiling and running programs. And if you are an enthusiast of other programming languages that aren't JavaScript, then you might care, right? But I think that we're going to see more and more computing be kind of built around WebAssembly partly because it is kind of the version of the JVM dream done right. It's not being controlled by this one big corporation. It's being kind of driven forward by this set of people collaborating.
 
 M: And recently you were showing off WebAssembly.sh, right?
 
-C: Well, I was showing it off at the Hack & Craft. Yeah, WebAssembly.sh, it's an environment that lets you play around with programs that have been compiled to WebAssembly and it kind of looks like a Unix shell. And it will download the WebAssembly versions of commands as you type them in and then you can play with them. And so it's just kind of an interesting example to see that with, [as] I mentioned earlier, the WebAssembly system interface, the WASI, it uses that to allow for these different programs to compile and run. And so you can get a sense of how that's going to work and get a sense of this being a compiler target that people are going to be able to go after.
+C: Well, I was showing it off at the Hack & Craft. Yeah, WebAssembly.sh, it's an environment that lets you play around with programs that have been compiled to WebAssembly and it kind of looks like a Unix shell. And it will download the WebAssembly versions of commands as you type them in, and then you can play with them. And so it's just kind of an interesting example to see that with, [as] I mentioned earlier, the WebAssembly system interface, the WASI, it uses that to allow for these different programs to compile and run. And so you can get a sense of how that's going to work and get a sense of this being a compiler target that people are going to be able to go after.
 
 M: Yeah, your interest in WebAssembly started with some encounters at T-PAC several years ago, right?
 
-C: Yeah, so T-PAC is W3C's, the World Wide Web Consortium's big annual conference for standardization stuff. And a few years ago, I had the good fortune to attend live and I had some extra time and I could go to basically anything I wanted. And I'm like, "well, I'm really interested in finding out what this WebAssembly stuff is and like, are they actually doing things legitimately? Like, is this something that we should follow with earnestness?" And so I went into this room and kind of watched them talking about things and I was just really floored by the quality of people that they had brought into the room, the quality of the conversations they were having. And we've had Mark Miller on the show, Mark Miller was part of those conversations and Mark and I spent a bunch of time talking about how the GC proposal would work afterwards. And I was also surprised to find out that--if you listen to this show, you know, we talk about capability security and why it's important a lot--That capability security was being very seriously considered for WebAssembly. I was like, wow, this is like, this could really bring these ideas like quite broadly to the rest of the world. And there were two very memorable things that happened at that event, as in terms of just kind of funny side stories. So one of the things was that there was this one person who I was sitting next to and they were like, oh, yeah, I'm just working on this little toy project. They're like, it's a scheme that compiles to WebAssembly. Now, of course, that's funny because you know, Spritely Institute is now doing a scheme that compiles to WebAssembly. And they're like, "and then, I'm going to make it so that it can compile itself. And I've just been fooling around with it during the middle of the meeting". And I was really excited to talk with them. And I'm like, "well, I actually think that the kind of Lisp-y syntax is one of the things that got me most excited". And they said, "you know, we didn't initially start out with Lisp-y syntaxes in terms of what we were planning on using. We were saying, 'well, we can't agree on a syntax right now. And we'll just use this Lisp syntax for the moment until we come up with something better'. And then I guess like what always happens with Lisp is we ended up coming to like it."
+C: Yeah, so T-PAC is W3C's--the World Wide Web Consortium's--big annual conference for standardization stuff. And a few years ago, I had the good fortune to attend live, and I had some extra time and I could go to basically anything I wanted. And I'm like, "well, I'm really interested in finding out what this WebAssembly stuff is and like, are they actually doing things legitimately? Like, is this something that we should follow with earnestness?" And so I went into this room and kind of watched them talking about things, and I was just really floored by the quality of people that they had brought into the room, the quality of the conversations they were having. And we've had Mark Miller on the show, Mark Miller was part of those conversations and Mark and I spent a bunch of time talking about how the GC proposal would work afterwards. And I was also surprised to find out that--if you listen to this show, you know, we talk about capability security and why it's important a lot--That capability security was being very seriously considered for WebAssembly. I was like, wow, this is like, this could really bring these ideas like quite broadly to the rest of the world. And there were two very memorable things that happened at that event, as in terms of just kind of funny side stories. So one of the things was that there was this one person who I was sitting next to, and they were like, "oh, yeah, I'm just working on this little toy project". They're like, "it's a Scheme that compiles to WebAssembly". Now, of course, that's funny because Spritely Institute is now doing a scheme that compiles to WebAssembly. And they're like, "and then, I'm going to make it so that it can compile itself. And I've just been fooling around with it during the middle of the meeting". And I was really excited to talk with them. And I'm like, "well, I actually think that the kind of Lisp-y syntax is one of the things that got me most excited". And they said, "you know, we didn't initially start out with Lisp-y syntaxes in terms of what we were planning on using. We were saying, 'well, we can't agree on a syntax right now. And we'll just use this Lisp syntax for the moment until we come up with something better'. And then I guess like what always happens with Lisp is we ended up coming to like it."
 
-M: We'll use Lisp until we find something better.
+M: "We'll use Lisp until we find something better."
 
-C: And then they don't. Nothing better emerges. So there's that. And then the other thing that happened was I was just overhearing these people talking and they're like, "well, the amazing thing about WebAssembly is the way that it ended up coming from ASM.js". So there was a few years ago, there was a person named Kripkin who Mozilla had hired. He was working on a project that I was really excited about, which was this open source game engine that nobody else cared about I felt like, except for like me and like 10 other people and it was called Syntensity. And it was game engine that was designed for you to extend it live and it was based on JavaScript and stuff. And then he was like, "well, these things need to compile to the Web. So he started working on how do we get C programs to compile to the Web? And that basically became Empscripten and he started working at Mozilla. And so in order to have those browser games run on the Web and have them run using, you know, kind of "standard technology", you could compile to JavaScript but it was too slow to run like 3D graphics programs in the browser using JavaScript. So they introduced this hack called ASM.js. And ASM.js did the ugliest things imaginable. You would basically insert these little things that-- if you said "include ASM.js" in a string that would just be ignored. Like a compiler that didn't know about it would ignore all these things, but you could put all these really ugly annotations. And if the compiler knew to look for them, then it would do the smart fast paths for each one of the things that it found. And it was ugly as sin. But one of the people said, "but the brilliant part of it was it forced everyone to have to adopt it". The other browsers didn't want to adopt it. But since you technically could run the programs slowly and other browsers, if you didn't have the ASM.js support, you just made it look like these like fancy games that were being compiled from 3D, like these other browsers somehow had gotten fast enough they could run these 3D games and stuff. And then the other ones just didn't know how to catch up. So they were forced to adopt this and everyone hated it because ASM.js was terrible. And so it forced everyone to come to the table and say, "okay, how do we design the thing that we actually want to support?" And that became WebAssembly.
+C: And then they don't. Nothing better emerges. So there's that. And then the other thing that happened was I was just overhearing these people talking, and they're like, "well, the amazing thing about WebAssembly is the way that it ended up coming from ASM.js". So there was a few years ago, there was a person named Kripkin who Mozilla had hired. He was working on a project that I was really excited about, which was this open source game engine that nobody else cared about I felt like, except for like me and like 10 other people, and it was called Syntensity. And it was game engine that was designed for you to extend it live and it was based on JavaScript and stuff. And then he was like, "Well, these things need to compile to the Web". So he started working on how do we get C programs to compile to the Web? And that basically became Emscripten, and he started working at Mozilla. And so in order to have those browser games run on the Web and have them run using a kind of "standard technology", you could compile to JavaScript, but it was too slow to run 3D graphics programs in the browser using JavaScript. So they introduced this hack called ASM.js. And ASM.js did the ugliest things imaginable. You would basically insert these little things that-- if you said "include ASM.js" in a string that would just be ignored. Like a compiler that didn't know about it would ignore all these things, but you could put all these really ugly annotations. And if the compiler knew to look for them, then it would do the smart fast paths for each one of the things that it found. And it was ugly as sin. But one of the people said, "But the brilliant part of it was it forced everyone to have to adopt it". The other browsers didn't want to adopt it. But since you technically could run the programs slowly and other browsers, if you didn't have the ASM.js support, you just made it look like these like fancy games that were being compiled from 3D, like these other browsers somehow had gotten fast enough they could run these 3D games and stuff. And then the other ones just didn't know how to catch up. So they were forced to adopt this and everyone hated it because ASM.js was terrible. And so it forced everyone to come to the table and say, "okay, how do we design the thing that we actually want to support?" And that became WebAssembly.
 
 M: That's how we create things.
 
@@ -106,7 +106,7 @@ C: "Making things together with the shared trauma of compiler experiences"? Oh,
 
 M: Yeah, that's not--
 
-C: --a good ending. Okay. Wait, wait, wait. Let's end it on a positive note. So I am sure, I'm hoping, over the next year that we can show really exciting things with Spritely's tech with compiling to WebAssembly. One way or another, what I do know is that I think this is going to push things forward in fun and exciting ways. Andy Wingo, who is leading the project, is not only a compiler engineer on V8 and SpiderMonkey, like the two top JavaScript engines in the world and also contributes to WebAssembly. He's also the Guile lead maintainer. And by the time this episode is out, we will have announced the new engineer, Robin Templeton, who is a person that we were hiring in-house to continue this work. Robin is awesome. They worked on the Guile Emacs project, which allowed you to actually run Emacs on top of Guile. And it was like a really cool project. They're so incredibly well positioned to be able to make this project happen also. So I'm excited to have them and Andy working together and for them to kind of carry forward that knowledge internally and within Spritely also. And yeah, it's just exciting times ahead. I'm sure, you're listening to this episode now. You have this impression that web assembly is just this thing so that people can have C and Rust programs in the browser. You're wrong. Get ready. WebAssembly everything. It's happening.
+C: --a good ending. Okay. Wait, wait, wait. Let's end it on a positive note. So I am sure, I'm hoping, over the next year that we can show really exciting things with Spritely's tech with compiling to WebAssembly. One way or another, what I do know is that I think this is going to push things forward in fun and exciting ways. Andy Wingo, who is leading the project, is not only a compiler engineer on V8 and SpiderMonkey, the two top JavaScript engines in the world and also contributes to WebAssembly. He's also the Guile lead maintainer. And by the time this episode is out, we will have announced the new engineer, Robin Templeton, who is a person that we were hiring in-house to continue this work. Robin is awesome. They worked on the Guile Emacs project, which allowed you to actually run Emacs on top of Guile. And it was like a really cool project. They're so incredibly well positioned to be able to make this project happen also. So I'm excited to have them and Andy working together and for them to kind of carry forward that knowledge internally and within Spritely also. And yeah, it's just exciting times ahead. I'm sure, you're listening to this episode now. You have this impression that web assembly is just this thing so that people can have C and Rust programs in the browser. You're wrong. Get ready. WebAssembly everything. It's happening.
 
 M: Excellent. All right. Thanks everybody.
 
@@ -126,7 +126,7 @@ C: The Sprightly Institute team. That's right. And I'm not one of the primary pe
 
 M: Yeah. And the Spritely team recently participated in a game jam using Hoot, right?
 
-C: Yeah. We participated in the Lisp game jam. We actually did two different things. One was Fantasary. It was like a virtual worlds mini system. And the other one was a implementation of Wireworld, which is a kind of cellular automata. So actually the funny thing is if you remember earlier in this episode when we were talking about how Tristan and I had done the "It WASM Me" kind of "user group of two" doing implementation of WebAssembly by hand, we were working on an implementation of Conway's Game of Life and we were like, "Oh, well, the main thing that held it up was it was really difficult to translate all these APIs into the browser. And if only we had used this fantasy console called the WASM-4". Well, one of the things about the game jam is we actually used that fantasy console called WASM-4 and we used it to implement Wireworld, which is a different kind of cellular automata than the Conway's Game of Life. But it's kind of neat because it gives these like circuits. It looks like little computer programs. And it's fun. You can try it right in your browser. We'll have a link in the show notes to the blog post about it. And that was primarily Robin Templeton doing the implementation of that. And I helped with like some of the graphics and stuff. But the exciting part about it from a technical level was that it was showing off how Hoot has some low level WebAssembly tools. So it has this assembler and disassembler and things like that, which are used by the compiler. They're not normally what we advertise Hoot as being for, right, normally we advertise Hoot as being compiling a scheme program into WebAssembly. This one was like you're writing low level WebAssembly immersed in scheme, which probably to some members in the audience should be very clear and to some, maybe not so clear. You should read the blog post. It's fun. Anyway, but the cool thing is that you can actually try something that is written in Hoot actually live in your browser and it's kind of fun and interactive.
+C: Yeah. We participated in the Lisp Game Jam. We actually did two different things. One was Fantasary. It was like a virtual worlds mini system. And the other one was an implementation of Wireworld, which is a kind of cellular automata. So actually the funny thing is if you remember earlier in this episode when we were talking about how Tristan and I had done the "It WASM Me" kind of "user group of two" doing implementation of WebAssembly by hand, we were working on an implementation of Conway's Game of Life, and we were like, "Oh, well, the main thing that held it up was it was really difficult to translate all these APIs into the browser. And if only we had used this fantasy console called the WASM-4". Well, one of the things about the game jam is we actually used that fantasy console called WASM-4, and we used it to implement Wireworld, which is a different kind of cellular automata than the Conway's Game of Life. But it's kind of neat because it gives these like circuits. It looks like little computer programs. And it's fun. You can try it right in your browser. We'll have a link in the show notes to the blog post about it. And that was primarily Robin Templeton doing the implementation of that. And I helped with some of the graphics and stuff. But the exciting part about it from a technical level was that it was showing off how Hoot has some low level WebAssembly tools. So it has this assembler and disassembler and things like that, which are used by the compiler. They're not normally what we advertise Hoot as being for, right, normally we advertise Hoot as being compiling a scheme program into WebAssembly. This one was like you're writing low level WebAssembly immersed in scheme, which probably to some members in the audience should be very clear and to some, maybe not so clear. You should read the blog post. It's fun. Anyway, but the cool thing is that you can actually try something that is written in Hoot actually live in your browser, and it's kind of fun and interactive.
 
 M: And it looks pretty.
 
@@ -190,8 +190,8 @@ M: Should I move this closer to me?
 
 C: Yes, you should.
 
-M: The usual status of things. Morgan has the microphone right in front of her face. Christine, has some space.
+M: The usual status of things. Morgan has the microphone right in front of her face. Christine has some space.
 
-C: Christine's over here. I think we got a mastodon bloop in there.
+C: Christine's over here. I think we got a Mastodon bloop in there.
 
 M: That happens.