Future of Coding - Mary Rose Cook: Isla & Code Lauren

Episode Date: June 4, 2021

Mary Rose Cook is a programmer with.. just.. so many side projects, oh my — and, she works at Airtable. Mary created Gitlet, a version of Git in 1000 lines of JavaScript with extensive annotation. That might be her most well-known project, but of particular interest to our community are her programming environments Isla and Code Lauren. These projects explore syntax, learnability, execution visualization, and other surfaces of the development experience that I think we all would love to see reinvented. Mary and I talk about the design decisions behind these projects, naturally. But more importantly, we look at the ways they failed to achieve the goals Mary had for them, and what we should all be mindful of on our investigations into the future of computing. The discussion also touches on the theme of "escape hatches", picks up a few lessons in UI design from the video games Into The Breach and The Witness, and reflects on what people think programming is like before they actually learn what it really is. Lighthearted but full of wisdom. We have a new sponsor for today's episode: Glide. If you're excited about making end-user software development a reality, go to glideapps.com/jobs and apply to join their team. As ever, the transcript for this episode is sponsored by Replit. The show notes and transcript are available right here: https://futureofcoding.org/episodes/050Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Welcome to the Future of Coding. I have a very fun interview today with Mary Rose Cook, who is a programmer currently working at Airtable, though I know her from her thousand and one side projects, including Gitlet, which is an implementation of Git in about 1,000 lines of JavaScript. She's done a very interesting couple of interactive code editors called Code Lauren and Isla, which we will talk about at quite a bit of length in this episode. She's made a number of interesting excursions into giving people insights into the workings of compilers and interpreters and systems that are opaque in their operation, but that through interactivity and through visualization and through play, especially, you can develop an intuition for how they work. So we're going to get into all that stuff in the interview. It was quite a lot of fun to put this episode together, and I think you will enjoy it.

We have two sponsors today. I'm going to put one of them in the middle of the episode. Am I actually going to do that? Let me just zoom out here and check. Oh yeah, I'm going to put both of them in the middle of the episode. So I'll come back and give you more details about them, both when the time comes. But just right off the top, I want to thank Replit, as usual, for sponsoring the transcript, and our new sponsor, Glide, doing some very interesting stuff with spreadsheet-backed app generation. And so we're going to talk about that a little more at the break. For now, let's get right into it. So here is my interview with Mary Rose Cook.

I was reading some of the links from your website and playing with the projects and all that sort of thing. And in one of the articles you linked to, you mentioned that as a 14-year-old, you picked up the 700-page book, Foundations of Mac Programming. And that that was perhaps your introduction to programming. Is that true, that that was your first sort of encounter with it?

Yeah, yeah, pretty close. It was a difficult book that I picked up that was called something like Mac Programming Starter Kit that you could buy in my local bookshop. But it was the same idea. It would kind of take you through programming from the beginning, both in C on the Mac. And I, in fact, bought Foundations of Mac Programming because I'd found the prior book too hard to understand what was going on. And Foundations was easier. And so that's the one that I ended up working through in full. And what was it that sort of drew you to want to do that sort of programming to go from, I assume, not having much exposure to programming to then picking up quite a large tome about it?

I played around with a tool called ResEdit that came with the Mac back in the day, the system seven days of Mac OS. And back then, Mac programs were sort of composed of two chunks, some code, some binary code, and then some what they called resources. And those were things like sounds and images and text. And with ResEdit, you could edit those parts of any Mac program. And so you could like change the icon, for example,

or change the images if it was, let's say, a game or something like that, or change the sounds. And so I'd kind of been messing around with my parents' computer using that tool. And then I somehow found my way to the programming section of the local bookshop and saw there were programming books. And I think I bought the kind of couple of easiest looking ones that promise to take you from the beginning. And a crucial component was that they came with an IDE that you could install, which would kind of at least get you going really with those with an environment where you can actually write and run code. That makes so much sense. I also was a was a Mac user my entire life. I remember quite fondly ResEdit and as I talk to people and learn

about their histories and how they got into programming, if they were on the Mac, it seems like HyperCard or ResEdit were sort of the two doorways into programming. It's neat in that both of them start you off playing with the tangible parts of the software, the GUI parts of it, rather than the command line, say, that you would run into if you were on the DOS side of things. That would be your first sort of encounter with a programmer interface. But on the Mac, it was, you know, ResEdit for, like you said, editing sound assets or icons and that sort of thing. And in HyperCard, of course, it's very visual. Exactly. And when I think back about my own early days of programming, one of the things that I often,

one of the things that I reflect on fondly is the difference between what I imagined programming was before I learned for real what programming was like. And I'm wondering, I want to start asking this question. You're the first person I've asked this question to, but I think it's going to be one of my common things going forward. Do you remember anything about what you imagined programming was going to be like before you learned? And do you remember how that changed or what it was like as you sort of came into really understanding what programming is? Yeah, I do. I remember my dad said that computers are all just ones and zeros.

And I asked him, I mean, how do they show numbers higher than one, if that's the case? And he said, I don't know. And so I had some vague notion that code would somehow get turned into ones and zeros. But that seemed, I almost didn't believe that because it seemed far fetched that you could encode everything in as long numbers. So that was my initial idea. But I think actually once I started building programs, essentially tutorials that were in these books, then I think a new mental model just probably completely eclipsed whatever had been there before

because I could almost figure it out empirically. It's like, oh, when you type in this bit of code, then this window appears on the screen or something like that. So I don't think I've kind of built my new mental model on the ashes of any previous ones. My favourite pre-programming mental model that I've heard, that I wish I'd had, is that somebody really liked Super Nintendo games

and so they'd think, well, the images are quite big on my TV but the cartridge is only like you know four inches long by maybe three inches high so how do they sort of fold up the pictures inside it because they you know if the images are bigger than they could possibly fit inside the cartridge so how does that work and I think that's like a lot more I really like that because it's so physical and in many ways makes more sense than whatever crazy ones and zeros I had in my head. Yeah, whatever poisoned sand and all of that literally is. Yeah, that's fantastic.

You were 14 when you first picked up those books or thereabouts and sort of, I imagine, continued playing with programming. What was it about programming that hooked you and how did that kind of nurture and develop as you went forward? Yeah, I wrote a series of small desktop applications for the Mac, starting out from tutorials and then kind of making my own things. So I remember I wrote a thing that would you could type in an error code that the Mac showed you and it would tell you what it meant

um and I wrote a kind of very very simple word processor um where you could it was just like a notes app but you could type into it and save stuff uh so I kind of wrote little programs like that and then I I'd never really liked maths very much um though I was okay at it but I just didn't really like it that much and I thought that serious programming would require lots of maths which um so I sort of assumed that I would not want to do computer science at university and so I was thinking about doing something else. And then just through luck, my uncle, my uncle David, he put me in touch with, he was a professor at Oxford. And he put me in touch with a professor of computer science who was also Oxford to kind of just have a talk about, you know, what my aspirations were and this professor um uh said oh you know maths it can be part of computer science but um it's not you don't need to spend your whole time doing maths in order to enjoy programming and enjoy computer science and so genuinely because of that conversation i decided

to do computer science which so i'm so very grateful to that person um because i i really don't think i would have done it unless i'd kind of been disabused of of that of that um uh notion about maths being integral to to programming i love moments like that where you can and they tend to be frequent at around that age where you're sort of you know forced to decide perhaps for the first time in a big way what you want to do with your life. You know, it was this conversation with this person that put me on the path that I'm on. There's something kind of special about that. And I'm curious because you mentioned it just very briefly in passing.

Do you know what you would have done if you hadn't studied computer science, what you would have studied instead? Yeah, I think I would have done English, most likely. That would have been a bit weird because by that point I would have been doing A-levels and I did maths and physics and geography. So that would have been a bit of a jump to get over to English. But I think maybe possible, just because I really like artsy stuff as well. I mean, there's some outside chance that I would have done structural engineering instead.

But again, I think that was probably just a kid's thing that I was interested in. Those two feel like the salient ones, the arts and programming, basically. And of course, structural engineering, you're going to have a lot of math in that one. At my my impression as an outsider mine too yeah yeah i'm gonna uh jump ahead a few years and ask about this mostly for my own personal curiosity so i'm gonna try to resist the urge to sort of uh jump up and down too much with fanboyish excitement. But you eventually went to work at

Ableton. And I'm personally really excited about Ableton because I will be using Ableton Live to edit this podcast. I think that the things that they have in their user interface, especially for some of the sound processing plugins that you can use, devicesices, that's what they're called. The little sound editing devices, like their equalizer, the parametric equalizer and that sort of thing. I think some of the UI work that is in there is just absolutely phenomenal.

And so I'm curious to hear what it was like to work at Ableton, what you worked on while you were there, what that whole chapter of your life was about? When I was there, we were about 100 people. So it was in 2010, 2011. And I worked on the, they essentially had an internal team that built their website and their shop. And so I was on that team writing Python mostly um and so we built a bunch of the shop basically that that you used to buy Ableton and then a fair amount of the sort of stuff that built documentation and things like that they've since changed their website and obviously it's

been like 10 years so it's there's been a lot of changes. So we built that kind of stuff. And to work there was very special because I think pretty much everyone who was there really loved Ableton Live and either used it or cared about it in some way. And so it felt great to work at a place where everyone's excited about it. And there were also lots of people who were essentially professional musicians who maybe had a kind of part-time or second job at Ableton, you know, maybe to make some extra cash or whatever. And so there was just tons of music people around as well. And that was really exciting too. So it just felt like there was a real culture of caring

about what the company was making. And the other thing that stayed with me was how, so I kind of only observed the development of the product itself, kind of sort of one step removed because I didn't work on it directly but it felt like the people who worked on live itself were so careful about adding things to the product and thinking very carefully about how it should work and making sure it was extremely robust because obviously it it's a live music tool, and so you don't want it to crash. And just this sense of carefulness

that I think married with what felt to me, I think is still kind of next level, like you say, UI design, sort of really put into me kind of some deep core of like, you can be careful and also innovative at the same time um which i think is something that is not those two ideas don't often go together um and i think

ableton proved that it's that it's possible i mean they've i think we live eight was the most recent version that had come out so that was in 2010 when i joined and then um it's, you know, there have not been too many more versions since then, which I think is in many ways a good thing because it just kind of is very careful taking, making sure what they're building is the right thing, I think is really cool. That's good to hear because that kind of lines up with my experience as somebody who has used live both in a sort of a hobbyist capacity for things like editing this is built with a great attention to stability and performance and robustness, but also on the design side, like you sort of identified like it.

I've been using it since version five, which I think would have been in 2004, 2005, somewhere in there. I started using it. And since then things still work in the same way that they did back then and they've added a tremendous amount of capability and power and and new features to the program but they've done it in a way that to me never really broke my workflows never really

broke my expectations or if they did change something that required me to slightly adjust how I work, it was something that made sense. It was something that was not a complete departure from what I was used to. It was sort of like a slight augmentation or an additional thing just to cope with the greatly expanded scope that the product has had in that time. And that's very interesting to me, like you said, in that it sort of proves that it's possible to do this. And I think that that's a really important thing to reflect on in the face of, and I'll just pick on one example, companies like Apple, who are beloved for their design prowess but are also notorious for breaking people's workflows or for doing a complete reinvention of something

when perhaps that's not necessary. And so it's nice to have these counter examples of things that are exquisitely designed but that are also very respectful of the of the expectations of their of their longtime users and do a very, very good job of leveraging familiarity against the need to kind of the need to I guess one one reason why perhaps Apple does what they do or other companies do what they do in that sort of reinvention when it's bad kind of way is because there's that pressure to constantly be adding new capabilities so that you can justify charging for upgrades and i think um yeah ableton are a great example of a company that's found a way to keep working on their product and keep growing and and building something without having

to force people into an upgrade cycle that is not beneficial. One example that comes to mind is, I've not used this feature, but I believe it came in Live 9 where you can essentially turn an audio or some audio into MIDI, so kind of a wave back into MIDI. And I believe that came in Live 9. And when I was at the company, that feature was being talked about. And I think that was, to me, emblematic that they said, yeah, this is going to be Live 9, so probably in like three years' time.

And that's just like, it's very cool, I think. It's like, okay, we've got this cool feature. It's going to take a while. We're looking that far ahead. And it's no, it's not like, you know, they're sort of just saying, oh, it's out when it's out. But it's like, there's no rush. It's just going to make some things better in certain ways. And it takes however long it takes to add and so exactly like you say i think it's an example of just we only add things when they make it better not to not for some release cycle or to justify charging for an upgrade i think it's super powerful so now i'm going to start getting into some of the projects that you've made um and you have made a lot of projects so there's you's a real banquet of choices here for things we could talk about. And I want to start by talking about ILA, which is a programming language that you made specifically for young kids. And it's something that you intended to be a good first language. So somebody's first encounter with programming would be this language. And in one of the talks that you gave about it, I think it was in one of the talks,

you mentioned that it would be a language that kids would very likely outgrow as they continued learning to program. That if they stuck with programming, that Isla would sort of fade in relevance and they might move on to something else. And I was wondering if there were aspects of this language that you specifically designed with that in mind, that you specifically designed to encourage kids to outgrow it. Because that's a really interesting design constraint, if that was something that was that you made intentional in any way. And so I'm wondering if that's what you might have done to accomplish that. Yeah, absolutely. The explicit thing that I did to aim for that

was to not try and make it something that a child or anyone could grow with. And so I think of ILO as essentially a data definition language in the sense that you write code that defines data structures, really. So you can say something like, effectively, you can create an object, you can add attributes with values to that object, you can create lists of objects and so on, and that's about it. So you're just sort of defining data when you write the code. And so by definition, it's not going to be a language that you can do that much with. And I think the discipline I put on myself was to say, that's OK.

I want simplicity and accessibility to be the most important thing. And so essentially not forcing myself to make it a powerful language lets me double down on the simplicity and make things as easy as possible. And the idea behind Isla in the end was that the kid would write some code which defined some data so let's say they would create an object called with a like a I don't know had the name Saturn and it had an x attribute and a y attribute that was set to some numbers and then it had like a color attribute or something like that so just an object with those four attributes and then they might define another

object along similar lines called Mars or something and another one called venus let's say um and they put them in a list and then that that would be where things ended for the kid in terms of their input but um one would be able to layer on uh environments that would use that data to do something interesting. So in that case, it was to create a little planetary simulation where it would use maybe the size of the planet that you could also define to define the mass of the planet. And then the starting positions would be the X and the Y of each of those objects.

And then it would just kind of make them orbit a sun that they could add as well and stuff. And so the idea is that the kid would define some cool pieces of data and then a more advanced programmer would be able to set up the environment that would use that data to do something that was hopefully interesting. And so to try and get hopefully a somewhat interesting result out of not too much difficult code. So that was sort of the goal.

I think there were a lot of problems with all of that that I'm happy to talk about if that's interesting. Yeah, that's very interesting. I would love to hear what you see as the problems with this approach. Yeah, the first problem i think is that uh with a number of kind of you know i don't know you could call them like dynamic medium projects or future of programming projects or anything that's trying to change the way that people program computers basically a number of those projects that I've done

have a sort of split focus between the tool that you're building and your objectives for what that does, and then another objective around what you want to do for yourself as the creator. So, for example, Ila was the first programming language that I'd ever implemented a compiler for. And so part of my goal was just to implement a compiler for the first time.

So that kind of split focus meant that I think I did not pay as much attention to the quality of the language, and if even having a language was the right move as I could have done so for example you know a few people that I know used Isla with their kids and tried it out but you know as far as I know beyond that it's got zero kid users basically and stuff and so and I partly I think that's because the design of the language and the environments themselves were compromised by my own kind of separate goals for writing a compiler, if that makes sense. Yeah, that makes perfect sense. that if you kind of flip the way of thinking of it on its head, instead of thinking of it as this is going to be a transformative programming environment and I need to learn some things in order to build that,

if you instead think of it as I want to build transformative programming environments, but to do that, one requires practice just like they do with anything, then it seems sort of inevitable that uh that you're going to end up with that split focus um and so was was the problem then that you went into it thinking that it wasn't like a like a primarily a learning project that it was instead primarily something that was meant to sort of have a life of its own? Yeah, I think I was a bit blind to it, that I had this split focus between my own goals of building a writing compiler and the goals of creating a language that would actually be fun or educational or useful for children to use.

And I think I've noticed that as a common failure mode inside the projects that I've built along those lines. So I did another one called Code Lauren that I think suffered the same fate. I think you're absolutely right that it's like, okay, in order to do something, you know, like build a language for children, then you may need to learn some stuff. And that's, that's just part of part of what you need to do. And that's fine. And I think that's absolutely right. I think the what of what you're building, so that kind of secondary goal of, oh, I want to write a compiler, constrains one to that as the solution for helping children

get into programming or whatever. It's like, oh, there could be other ways that are better for helping children write their first code. But the solution has now been presupposed as a compiler. And so I think that kind of thinking inside the box is sometimes a dangerous consequence

of this kind of split focus. That's 100% something that I think that I have to deal with because I'm building my own futuristic programming projects and they are visual languages because that's the area that is my obsession. And would I write a futuristic programming project that is a compiler?

Heck no. Because I'm, well, for one, I'm scared of compilers and of that sort of whole can of worms as I see it. But it's just not something that's interesting to me. And so what I'm curious is now that you've done these projects, Isla and CodeLorin, which we will talk about in a bit, and you've sort of discovered that that's an affliction that you have where you are constrained to inside the box thinking based on what your presupposed solution to the broader problem is. What advice do you have for surely the many people out there who will hear this, who are also perhaps trapped in that box and may not yet have realized that that is something

that is constraining their thinking? What have you come to having gone through that reflection? I think the first thing is that all of that, Isla would have been absolutely fine if I was a kid too, which obviously is hard to imagine, but because I would be my own user and so i think exactly what you're talking about with hest my understanding is that you are building this to use yourself and to use as part of your work and so i think that is a really good way to avoid this

this failure mode that i've talked about um because then, you know, you can't kind of fool yourself by saying like, oh, some other people who, you know, who are not me, but some other people will get value out of this. Because you can tell yourself, obviously, if you're not getting value out of it, if you've built it for yourself. The second piece that I think I've found helpful more recently is, it took me a long, I don't know if I've totally shaken it yet, actually, but it's taking me a long time to shake off this idea that building software requires writing code. And so I think I in the past, I've ignored ways of building software that aren't primarily writing code because they seem like oh that's

never going to be powerful enough or that's always just going to be a toy um and i feel like i'm more open in my mind to tools like that that maybe in the past i would have looked down on as not powerful enough and so uh the other thing i've taken away from this, I think, is trying to not dismiss things just because they're not going after a particular goal in the same way that I am. So to give a concrete example, something like Game Maker, which I've been completely obsessed with recently. kind of an IDE for making 2D games. And it's been used to make some very cool commercial games like Nuclear Throne is one, or the first version of Spelunky. Our Hyper Light Drifter is a favorite of mine. Right, exactly. Yeah, fantastic. And so it's definitely serious and not just a toy.

And it also requires some code for things, for sure, but it also does a lot of work to avoid requiring code for many things. And so I think I've just tried to make myself more and more open to, if you like, to put it in sort of Stuart Brand terms, like low-road tools like that, that maybe would have been seen as inconsequential in the past, to me at any rate. And actually one of my later questions, I think it's going to dovetail really nicely with what you've just said, because I'm going to ask a little bit about your thoughts on text code and other more visual systems because there's some other things that you've said that I think hint that you might have some thoughts about that or some

thoughts that might have changed over time. So that's something that I'm going to actually come back to in a bit. But still on the topic of ILA, you gave a talk at JSConf in 2012 and you said the following, and I'm just going to read it verbatim just because I found it really charming. You said, there's this notion of indirection, which is the reason that I think programming is so fun. I type in something to the computer here, and then something happens over there. And in between, there's this magic and that magic is fun. And later you expand on that by saying it's like setting up a long line of dominoes and then you flick one and you watch the rest of them fall.

And depending on how you interpret or how one were to interpret that, it might be seen as going against the conventional wisdom that indirection, especially in user interfaces, is a bad thing. And that's sort of where, you know, Victor made a lot of great points about direct manipulation being good for some things in some cases because of that removal of indirection. And so I'm wondering what are your thoughts on indirection and maybe those have changed in the time since 2012, granted a long time ago. Um, but that, that sort of indirection being one of the places where fun can come in. Do you see the, the issue there with that, that it might cause for some people or how do you, how do you wrestle

with indirection? What do you think about indirection? I think I still, I still think that's true. Um, it's a really interesting idea about how I actually direct control and mastery of, of, and directness, um,

of, of things is, is, is a fun feeling too. I think that's absolutely right. Um, of things is is a fun feeling too i think that's absolutely right um if there's any kind of delay on when you do an input to seeing the result that can be very disempowering and and sort of energy sapping i think um i think i i would add on to the idea of indirection that that maybe now I would think about it as power or leverage where you do

a thing over here and you see an effect over there which gives you a sense of like I say kind of power or control or mastery or leverage kind of something around those words, where you can have an effect that's at a distance. And so I think I can imagine this being a similar thing to if you ran a company, and kind of the feeling that you might get of knowing that there were people who were working on stuff and building it, and you weren't even aware of it. And then they show and it's like, wow, that just happened because of the system that I set in place or whatever. That's really cool. And I think that might be a similar sense of fun. And so I think to boil it down, you know, writing a line of code

and then seeing a window pop up on screen feels similar where it's like, oh, I did this thing that felt reasonably small to do and then this big thing comes out of it it's like a sense a strong sense of leverage coming out of it um and so i still think that's why i find programming fun um and i think emergence factors in here as well where you know i've heard game designers talk about seeing players do things in their games that they never would have anticipated and how cool that is and it's like yeah i created a system or a smaller thing and this these these extra consequences came out of it that's so cool because again it's like that sense of um indirection plus power um and I think also

possibly magic you know thinking of a magic trick feels related as well where it's like if you can see that the person kind of you know had the ball in their other hand the whole time or whatever it's like that's not magic that's just you just see there's a directness there whereas if somehow the the ball appears to have flown between from one hand to the other or the or the man appears to have jumped from one box to another or something that's like wow there's something literally supernatural about that that feels powerful and and and sort of almost awe-inspiring, I guess. So, listening through that thinking, I was holding in my mind the whole time

that this might be one of those cases where we're using one word in two different notions and that it's probably worth disentangling them somewhat. The point you made very early on about, you know, latency not being good and about certain kinds of indirection where it's sort of this artificial limitation being imposed on your expressivity, that's no good. But there's this other way of seeing indirection where it's that leverage that that is good. And maybe those are two separate notions that are sort of unfortunately tied together with one word. But then right at the end, you start

talking about this magic of, um, you know, not wanting to see the ball go from, you know, one hand to the other and of the magician. Um, and, and, and so that to me, that's weird because that is one of the things that people like you and me who or behind the evaluation of the language and trying to surface that and show it to the programmer as a way of giving them leverage. And it's sort of like all of a sudden there's a cost to doing that. And I completely agree with you. I think that especially when you're first encountering programming, that feeling of I typed something into the command line. I'll tell a story here. When I was first learning to make websites with Rails and JavaScript and that sort of thing, I was coming out of a world of Flash because I started with HyperCard and then I graduated into Flash and that sort of thing, I was coming out of a world of Flash. Because I started with HyperCard, and then I graduated into Flash, and that was sort of my main programming environment for many, many, many years.

And so then when Flash started dying, and I switched over to programming on the web, this was sort of in the beginning of the node modules as the mass of a black hole era. And so there was this new tool at the time called Yeoman, and you'd install it with Brew, and that's cool. I'm good with that. And you'd type yo new Angular or whatever it is to invoke it, and it has this recipe where it's like, oh, okay, I'm going to bootstrap a new little Angular project and download all the node dependencies.

And so I type this command in, and it prints out something like 10,000 lines of output in my console saying, installing this, installing this, installing this. And I have this panic attack and I'm ripping my hair out thinking, what the hell have I just done to my computer? I'm installing tens of thousands of things. This can't be right. Where are they all going? Are they being scattered all over my hard drive? Am I going to have to go dig into my library folder and find where they all went and clean them up? Thinking that all of those things were each like their own traditional Mac application where they have the application lives in one folder and its data lives in another folder and it's got some secret data over here and there's some cache there. And I'm thinking, I've just made this colossal mess.

How does anybody work with this? How is this seen as a, you know, hey, we make it easy to get started with your first project kind of tool that all these people are encouraging. And so it's that same feeling of I just do this little tiny thing and there's this huge, this flurry of activity that happens as a result. And that's something where, you know, I totally see the way that that can be a positive thing when you are first learning, if it's not, you know, something unexpected and bad, as it was in my case.

I've had the opposite experience too where it's very delightful. But it's something that our tools that we're building are trying to lessen. And so I wonder if that's one of those things where we might have to put that as one of our benchmarks that we hold dear when we're designing these tools. Thinking about, you know, if we do get to the point where a lot of the magic is dispelled and a lot of the inner workings are surfaced in a way that doesn't make them seem intimidating in their complexity, maybe that loss of magic will be something that is felt by people. Yeah, I love that. I really like the kind of teasing apart of these two ideas of indirection and leverage. And I think you're absolutely right that the more one understands something that one is possible that that would lead to a kind of mundaneness, a feeling of mundaneness about it. I think it's exactly what you said that there's

something about leverage which is which is putting in a small amount of something and getting a a an impressive result as a that comes out of it so um and i think that's about just maybe it's about one's preconceptions of what's impressive and what's not so for example if you're you know when I was a kid and I could write a few lines of code to create a window on my mac that was just like the windows that you know real cool official programs could create then I think that's it's an impressive result from from from something that I knew how to do and so I think that gives a sense of leverage or power or fun or whatever um on the other hand I think I really love this idea there's almost a diametric opposite which is that you know that

sometimes I find if I've dived into a complex system or what seems like a complex system and learnt how it works in detail. So, for example, I did this with Git and learnt how it works in detail. That actually also brings a similar sense of kind of, I don't know, power and ability and sort of competence or whatever, even though you actually now know all the details of how it works. And so I think

it's maybe it's sort of it's not so much about the method that you used to get there. It's just more about, wow, I can do this thing that seemed very impressive before I knew how to do it. And that, you know, makes me feel like a sense of fun or a sense of ownership or whatever over my over my thing and and that might just be just a few lines of code that produces a window or it might be you know a deep dive into i don't know kind of you know learning how git works in in detail um but a similar feeling comes out of it um and because i think with the magic trick analogy, it's actually you don't know how it works. And that's sort of the point. But that's someone else who's doing that magic trick.

It's not you. And so I think if we limit it to just, okay, well, what can, if we're focusing on the things that one can do oneself, this sense of power can come from, like exactly like you say both those things a sense of leverage or a sense of deep connection and understanding this reminds me a bit of um ted nelson's zine computer lib slash dream machines where he sort of talks about this this like priesthood of programmers who sort of guard their secret spells that they can invoke upon the computer and how that sort of that's detrimental to progress as society and incorporating computers into our lives. And that, you know, the magician keeping the magic secret works when the relationship is between the magician and an audience but when you are

a magician yourself and you want to learn a new trick i think that the learning how the trick is done in that context still brings with it that sense of fun rather than the sense of disappointment that might come from an audience member knowing that the trick is actually mundane, that the different objectives in each case help you have a positive relationship instead of a negative one when it comes to dispelling how the magic is done. Yeah, absolutely. So the other thing that made me think of

is perhaps if dispelling the magic that is going on inside the computer is something that were to take the fun away, to make it mundane, maybe that could be addressed. And this is where we get into like, I think that this is the case, and I know that other people do not think that this is the case. You could probably address that by changing the aesthetics of your programming interface or the aesthetics of your relationship with the computer in that if there's some mundanity there,

maybe that mundanity just comes as a result of you running into like a barrier where now your experience is mitigated by things that are frustrations rather than things that are joyful. So for example, if you take away some of that magic of, you know, I type in one command and, um, let's say in my case, you know, I ran yo, whatever to install in it, it installed thousands of things. If you, if you take away that, that, that magical nature of it and perhaps replace it with, and this is a totally contrived example,

but if I had to install those things manually one at a time, or if I had to go and, you know, populate my package.json and then, you know, run npm to install it or something like that, like if it becomes a little bit more manual and that dispels it then my my

experience with it is mediated by the fact that i'm now just waiting on the computer to do some work like there's some latency here and that's the part that governs my experience where if it was you know instantaneous or effortless or if it were more tactically interesting, that's kind of the bent I'm on, or if it were more visually interesting, then that might still keep the element of fun even after the magic has been taken away. Because the thing that's mundane probably isn't the absence of magic. It's probably just whatever is behind the surface of the magic.

Like a ball going from one hand to the other, is mundane until you're juggling. And then it's, you know, exciting. And much the same way, a lot of the, maybe the plumbing of data that we do in programming is mundane until you dress it up with graphics and sound effects and challenges, and then it's a video game. And so it's the sort of thing that I feel like, like this idea that the magic is fun and that behind the magic is mundanity. I really like that. I think that that's a really fruitful line of thinking and exploring this space. I think that's super cool. this episode like all the previous episodes you've enjoyed so far has a transcript which

you can find at futureofcoding.org slash episodes slash 50 we've made it to 50 episodes everybody how about that that's uh that's pretty cool, of course, huge kudos, as always, to Steve Krause for starting the community and starting this podcast off and sort of taking it right up to the goal line. I don't know. I'm not a sports person. Yeah, 50 episodes. That's awesome. Here's to 500,000 more.

And for all of those 500,000 episodes, hopefully, fingers crossed, there will be a transcript. And that transcript is brought to you by Replit, an online repl that you can pull up in your browser and pick from a huge list of languages and now frameworks for making games and tools for launching websites and apps, and they are just absolutely crushing it. I'm subscribed to their newsletter, and it seems like every week or two, they're bringing out some new innovative thing that they're doing, really building up this very comprehensive, very robust platform for doing software development in a very broad sense. And so I, uh, I always do this, but if you're tuning in for the first time, I encourage you to go take a look at Repl.it.

When they first started sponsoring the transcript, they were hiring. I'm sure they're probably still hiring. bringing the tools that we all use to do our software development to everyone, regardless of whether they have the expertise to get into the trenches and set up all the stuff on the terminal and all their dependencies and manage all that hell, or whether they want to just go straight to something like Repl.it and having all of that taken care of and just firing up instantly a REPL for whatever tool set they want to be working with. Check them out and see what they can do for whatever tool set they want to be working with, check them out, see what they can do for whatever you're working on for your investigations into the future of programming.

So thank you to REPLIT for sponsoring the transcript and helping bring us the future of coding. I kind of like that tagline. I'm going to do that on all the sponsor reads. It's not something that's in the ad copy or anything like that. I just like to try and find these little memetic things I can work in. So if you find it infuriating, just know, direct all hostile feelings towards me and not towards Replit or anybody else. They're not making me say this stuff. I'm the one doing that.

All right. And now back to the interview. So after Isla, you later made a project called CodeLorin, which we've mentioned a couple of times so far. And CodeLorin is a game programming environment for beginners. And if I get this explanation wrong, feel free to jump in and say, no, no, no, that's not right. But it's a text editor and you can type in some code, the code that you're typing in, maybe it does some graphics like making shapes or that sort of thing. And the graphics will be rendered right into the background of the text editor. And so you've got your text code and your graphics right there in the same space. And am I correct that the language that is in CodeLorn,

is that a language you also created? It is, yeah. Cool. Yeah, I didn't recognize the syntax and I wasn't sure if it was something obscure or something that I just haven't seen. And did you build the language and the environment together at the same time? Yeah, I did.

Yeah, they kind of co-evolved. And that's kind of what I'm curious about. And that's what I'm hoping you'll talk about is sort of what was the thinking behind the project? What was it like creating a language and its editor or the other way around, an editor and its language at the same time? How did that all go? Yeah, the background is that this is another example of somewhat confused goals where it's supposed to be definitely a considerably more powerful environment than ILA was,

but also supposed to be more accessible than something just like plain JavaScript or even JavaScript with like a graphics library like Processing.js JavaScript with like a graphics library like processing JS or something like that. So that was the kind of the goal on the one side was more accessible language and environment. The goal on the other side that I think ended up dominating was that I wanted to write a virtual machine to kind of be the foundation of the compiler that took the code and then

the way that the code should be run. And so that was a sort of somewhat auxiliary confused goal. So those two things competed with each other a bit. So to take an example, I wanted to have a language that sort of got rid of as much of the incidental complexity as possible. So examples of that are you could, because I knew that it would be essentially used for writing code that would produce animations or games, then I knew there was going to be an event loop whizzing around for the whole life of the program. And so I made that very easy. So you could just type forever, and then some braces, and then whatever was inside the braces would be the tick of that event loop.

And so that was, you know, something that was pretty simple to do for the users. So that was cool. On the other hand, I wanted to write a VM that would let you run your code in reverse. Basically, it's like a technical flex, to be honest with you, because it would seem impressive, I suppose. And so those two things don't go very well together because, so I hit the goal of, yes, you can run your code step by step,

kind of like a step debugger forward, and you can also do it backwards. But a reverse debugger actually doesn't make that much sense for something that is an event loop that's going around, you know, maybe 60 times a second at full speed. Because you're just constantly clicking back, back, back, back, back, back, back, like that. And so, you know, you would click back 20 times and you would be just, you know, a of a second back in in this run of the program so it was very difficult to find the bit that you were interested in getting back to and so these two goals like I say kind of competed with each other a bit and I think if I was taking a more honest run at this sort of thing I would have made something that was closer, or at least I wouldn't have been able to make something nearly as good, I don't think,

but I would have been aiming at something that was focused on this person wants to make a game or they want to make an animation. What does that tell me about how the tool should work? Whereas, like I say, the focus was more like, I want to create a VM that runs a programming language in the browser. And so let me let that mostly dictate things. I think the things that I did discover that seemed helpful were I started to kind of graft on a debugging help for the user.

So some things along the lines of what Brett Victor has worked on for a while, you know, around learnable programming. So, for example, you know, there would be help on what arguments, functions that you were going to call took, for example. There would be reasonably helpful error messages when you got syntax errors sort of things like that and and another thing that I found I think was helpful was having one way to do everything rather than multiple ways kind of reduced complexity for users and so just having one way to call a function, for example, or having the whole thing be, oh, what was another example?

Having one way to instantiate variables. So just kind of simple stuff like that. It's like, why put the extra complexity on the user? And I'm sure on the VM and the language as well, like there's sort of a win-win there, I think. Yeah, yeah, for sure. Exactly, yeah. That's absolutely right. I have a direction that I want there, I think. Yeah, yeah, for sure. Exactly. Yeah, that's absolutely right.

I have a direction that I want to go with looking at Code Lauren. But before we go in that direction, I just wanted to see if there was anything else about it that you wanted to reflect on, just because the direction I'm going to take it is in quite a different direction. Hmm. different direction yeah i think um i think this this could have been something that if i'd focused it more on what i needed to make a game which i started to do towards the end of it it would have had been more successful because it could have been something that i would find useful, which would at least put me on a useful track. Um, and, uh, so I, I kind of wish I'd doubled down more on making it something that was, that was useful

for me to, to make games. And so I definitely took that away. That's interesting to me because of your most recent obsession, Game Maker. It seems like you, um, and you've also made games that's something I haven't incorporated into any of these questions but you you also make games in addition to making tools for making games and so before I take this in a different direction I'm just curious if now that you've played with game maker and now that you've had that experience with code lauren where you sort of realized okay the focus needs to perhaps be on um dedicating the tool to a specific kind of of project that a person wants to make or a certain kind of problem that they want to solve um code lauren is a far more interesting tool than game maker in in the way that it offers very unconventional user interface capabilities, like the ability to step forward and backward through the execution,

the fact that the code editor and the graphics are right in the same window in the same space. Is there anything that you're currently chewing on that you think might be like if if you could go into game maker and and augment it in some way to to leverage some of these more interesting interface ideas what might you do with something like game maker to give it more of that capability or what might you do with code laurenin to bring it closer to the sort of the domain specific utility that you get out of a tool like GameMaker? Yeah, I think CodeLorin would be served well by getting a bunch of things out of code and into a GUI. And so I think that's one of the huge strengths of GameMaker is that a bunch of things you can just do in a GUI.

And I think it goes down to even the most simple things that are just so beautiful. It's like in GameMaker, when you create a sprite, then the creators of GameMaker know that a sprite tends to have multiple frames. And so they give you a nice little painting editor that's 100% GUI to create your image. And then they let you add more frames to your sprite and reorder them and things like that. And then there's an implicit assumption that when a sprite

is displayed on screen, that it will have a current frame. And the default behavior is for it to just cycle through those frames at top speed, which is all stuff that the user does not have to program. There's an algorithm there, clearly, but it's just been created with a combination of using a GUI to define the algorithm and also using some conventions to define the algorithm. And I think that's so powerful. So I think CodeLaw, if I went back to it, which I don't think I will, but if I did, I would try and lean as much as possible away from code and say, how much can the user do without writing any code?

I think areas where GameMaker would be, where I would love to see this version of GameMaker, and I think it sort of exists there's because in game maker you you you are always manipulating an artifact you know whether that's code or images or or whatever um you know essentially boxes and arrows kind of connected with wires you're always manipulating an artifact that is not the final output and i would love to see a version of Game Maker where you manipulate the game itself to create the game and I believe there is a tool called click and play that is from like 25 years ago or something that takes this this approach so you essentially arrange some objects on a canvas and then to define how they work you you kind of can literally click and drag to define the motion of of a particular sprite or something so it's like oh i want this

to move from here over to here and then you you that drag defines that movement so you don't have to type write any code to do that or another example is you can like run your game and then when an event happens like one object runs into another then a little modal will pop up saying define what should happen in response to this collision and there's a number of events like that that it's sensitive to and so again you're doing it by manipulating the actual the actual output which i think is would be a really exciting idea i feel sure that they ran into big limitations on how powerful that that can get but i think it would be very cool and it's it's something where one of the objections that people might surface when they encounter that idea is if you look at an environment like HyperCard, it sort of worked in this way.

Flash even worked in this way a little bit at one time with a feature called Behaviors. running game or system that you're building or playing with right there and you can work directly with it and and specify the behaviors that things should have right in that running environment um but the environment is still it's not forcing you to only do things in terms of what exists in that running environment you're still able to you know when two things collide bring up a modal and in that modal, there's a nice dedicated interface for resolving that one particular circumstance. So it's not, it's not necessarily like you have to give up on the, uh, the sort of the indirect tools that we have available to us in, in a, in a system like game maker in order to get that world

where you are working with the actual running interface. I think that there, that those two ways of working are very compatible and that you could probably see an environment where you have, um, both rather than just one or the other, which would be nice. Yeah, I, I completely agree. I think you're absolutely right. It's sort of, I almost see it as, um, kind of popping up the right UI, the right editor at the right time. And if that can stick within the direct manipulation metaphor or the output metaphor, then that's great. But exactly like you say, it doesn't have to. And users can still totally understand what's going on um i think that's something that working on air table has has taught me that the philosophy there is i mean i don't want to speak for everyone but but certainly the philosophy that that is is part people talk about you know not somewhat frequently inside the company is this idea that of escape hatches where air table is a database that you can essentially directly manipulate

and most of the time, 99% of the time, you're not writing any code. You're just manipulating data in a database and defining schema relationships between pieces of that data. But then sometimes you need to do something a bit more sophisticated. And so you can create something called an automation, which if you've ever used Zapier,

it's somewhat similar where it's like forms-based programming. So you say, oh, when a record is created, then I want to update that record with these values or something like that. And you can do various other things like send email and so on. And so the automations interface is a little escape hatch that lets you either automate repetitive processes or it lets you do things automatically where you don't have to supervise them. So you could imagine that, you know, a process would run every night at midnight or something like that. So it's a little bit of extra complexity, but you're certainly not programming.

And actually, you do that bit, and then you get back to just doing normal Airtable, which is basically manipulating data. And then you can take those, you can imagine those escape hatches in a hierarchy where above that you have writing a little script, which you write in JavaScript, just to do that little thing that Airtable can't do,

that doesn't have that feature built in, whatever that is, whether it's updating a set of records all at once or something like that. And again, it's a little escape hatch where if you can cope with writing that much code, or you can just find someone in kind of the small matter of programming style

in your office who knows how to write code, then they can write that someone in, you know, kind of the small matter of programming style in your office who knows how to write code, then they can write that bit of code for you and then you can get back into Airtable. And I think that is a super powerful idea that, to me, I think that the opposite of it pervades work on future programming stuff where sometimes I get the sense that there's this implicit assumption that's like, oh, well, if you can't do everything in whatever the new UI or programming

paradigm is, then it's never going to be good enough. So you may as well just stop and just do it all in code. I just think that's exactly the wrong way around. It's more like, okay, let's do 99% in this cool, much more accessible UI, and then let's have a little escape hatch way where somebody can take on the extra bit of complexity, solve their little problem, and then get back into the much nicer, much easier to use environment.

And that's a lesson that I think, I mean, I'm going to imagine here, maybe, you know, if Andy Hertzfeld or somebody is in the audience, they can reach out and fill me in. But I imagine that that's something that people often learn

or that they arrive at. And I'm just going to imagine a debate between people who are against escape hatches and are in favor of escape hatches and sort of hopefully arrive at the point in the middle that it seems like Airtable is at. And the argument against escape hatches that I hear, and I often am guilty of making this argument, is that they will give people a way to fall back on familiar habits or fall back on the way that they've always done it before. So they will sort of bring forward whatever traditional experience they have with a programming environment into your new novel way of creating some kind of dynamic software system. And they'll just do the old thing

if you give them an escape hatch into a world that looks more traditional. And so the example, the reason I mentioned Andy Hertzfeld is the original Macintosh when it first shipped had a mouse, but it had no arrow keys because they, on the Macintosh team, I don't know if this was specifically Steve Jobs

or if it was somebody else there, but they decided not to include arrow keys because that would encourage people to use the mouse as much as they could. That if you need to move the cursor, the right way to do it in the GUI paradigm is to grab your mouse and to find the spot where you want the cursor to go and to click. And so by taking away the arrow keys, they were forcing people to learn and become comfortable with the new paradigm. And not too many years later, they added arrow keys back to the keyboard because there's so many ways that arrow keys are useful beyond just the ability to move a cursor. If you want to make a game or something like that and

have directional movement, arrow keys are very natural for that. If you only want to move the cursor one or two spaces, arrow keys are really nice for that. And that, you know, even with the arrow keys, people still manage to get used to using the mouse and get used to using the GUI. And so it's neat to hear that at Airtable, something like the automations system, which am I correct, that's what you worked on something like the automations system, which am I correct, that's what you worked on, yes? That's right, yeah. Cool, we're going to come back to that. The automation system is seen as an escape hatch from what is otherwise more like a database

sort of spreadsheet-y style interface. And it's cool because when people in the future of coding world talk about escape hatches, I think what they pretty much universally are referring to is, and this is a little window that pops up a text editor where you can write JavaScript. And I love that idea of there being a hierarchy where it doesn't just have to be either the new thing or an escape hatch to the old thing, where there can be intermediate escape hatches, where you can sort of blur the line a little bit between the new world and the old world in a way that I think, because some part of me does really

believe in the idea that if you give people a visual programming environment and give them a textual environment and they give them a textual environment and they're used to textual programming, they're going to just jump into that textual environment as soon as they can, even if there's a way to do something better in the visual environment because they won't want to pay the cost of having to learn the new way to do it. Of course, counter argument to that is often there isn't a way to do it in the new environment or the way to do it in the new environment is very clunky and that's a whole other issue. But this idea of having gradations of escape hatches, I think, is a really elegant way

to solve that problem and to find a really nice middle ground in that sort of contentious space. Yeah, that totally makes sense. The not-so-good side of escape patches. I think the distinction is that, exactly like you say, with the original Macintosh, they were imagining that most of their users would be people who'd only used command line computers before, and so those old habits would be it would be tough to break but i think sort of like the um uh when when things kind of break out and become popular it's not because a bunch of people have it's a massive over generalization but in an example like this I

think this is probably true but it's not because all of the people who used an old thing now are going to move over to this new thing though some of them of course will it's more that the gates have been opened to a whole new group of people and so I think that the the people who use Airtable, for example, are probably not going to have those old habits necessarily always to fall back on. And so there's no danger of them just doing it in the less efficient way with the script when they could be doing it in a more quick way without a script.

And I think that the same is true for something like Game Maker, which just opens up the ability to make games to just so many more people that those escape patches are, I think, about enabling someone to stay in the environment rather than having someone be able to just bring in a bunch of preconceptions and let them use this environment if that makes sense so because I think again taking Airtable as an example the danger is is that we provide a really nice database but then they're like this is great but after you know a few days there's just a bunch of stuff that I cannot do in like vanilla Airtable. And so I'm

very sadly have to go back to my internally written tool that's all written in code by the internal programming team or whatever it is, because Airtable just will not grow with me. And these escape hatches give that ability to grow. And that is something that absolutely, I think, it rings true specifically because you made a context around this, which is that you are looking at things like the Macintosh or like Airtable, which are reaching out to people who previously were not using a computer or previously were not using this sort of dynamic software, that they are new people coming into the tent. And the thing that I, my own personal blindness

is that I'm paying way more attention to the problem of taking existing expert computer users and trying to advance the tooling that they have. And that's sort of where my own biases creep into this, where I'm thinking about people bringing their own experiences forward. It's because there's that other side of, you know, there's the one side of let's get more people into the tent there's a lot of um startups out there right now that are thinking about the next billion programmers and i think power to them um but then there's the other side of it which is uh once once we have people in the tent or once we have the people who have been in the tent for a long time what do we do with them because it's you know i think there's no argument here that the uh that the existing tools that we have are just you know ripe for improvement in countless ways and i think that sort of like what

you identified with air table and having the the escape hatches in a kind of a graduated fashion it it's sort of the onus is on us to make sure that no matter what experience people have and no matter what they're bringing into this that we give them the the capability to do whatever it is that they need to do and so in the case of a beginner user if they run into a limitation with Airtable and they need some programmability because entering things manually isn't cutting it anymore, you know, you have an automation feature for that. And if it is, you know, an expert programmer who's, you know, they're familiar with command lines and text languages and compilers and all of that, and you give them some kind of visual tool or some kind of you know

novel debugger or something like that that if you are worried about giving them the escape hatch to for them to fall back on which is it's not just an argument that i made i hear a lot of people make that you know objection to escape hatches that just puts the pressure on you as the author of the tool to make whatever new contribution you're making very very good and to make it you know you have to sort of do that objection handling and that i think it might it might almost be a like a good benchmark to give yourself i love benchmarks for this kind of stuff to say i am going to put escape hatches in my thing and that's going to force me to make my thing good enough so that people won't need to or won't want to use those escape hatches if

they're bringing in existing familiarity with whatever world that escape hatch opens into that the new thing is so much better or so much more compelling that they won't necessarily need to fall back on old habits and they only do fall back on old habits. And they only do fall back on old habits, perhaps, you know, in the case of an expert user for the sake of something like a foreign function interface or for the sake of, you know, using an existing library or something like that. I think Clojure did this really well. You're a current former Clojurist? Yeah, I haven't written any for a while, but written a reasonable amount.

Yeah. Yeah, I haven't written any for a while, but written a reasonable amount, yeah. Yeah, same boat. And yeah, I think that philosophy that Clojure had of, you know, we're going to make a novel language. It's Lisp, so it's very familiar in that sense. It has these really nice new data structures that are very powerful, but it's going to be a hosted language. It's going to sit on top of Java. It's going to sit on top of Java. It's going to sit on top of JavaScript. But it's so good that you're not going to find yourself

wanting to drop down to write stuff in raw Java or raw JavaScript when you could use Clojure. And I think that that approach to escape hatches is probably really, really powerful. Yeah, I think you're absolutely right. And I really love the idea of the thing just has to be way better. And then that is why people will switch to it. Because that often seems to be the challenge with, as you say, the people in the tent, in that if they're switching, then

they've definitely got some ingrained habits that need to be battled with. And is that something when you're designing a feature like automations or when other people at Airtable are working on the product, what's the balance of consideration between the people who are going to be coming to sort of reconfigurable software like Airtable for the first time versus people who are already familiar with programming or very, maybe very advanced users of something like Excel? How do you kind

of split the design space for those different people coming to it? Yeah, it's a really interesting question. It's something that we think about a lot. I think, first of all, this is an oversimplification, but there tend to be users that set up Airtable bases who will need to design the schema. Maybe they'll be the ones who are more likely to create automations that run automated processes on the data in the base. And then there are the people who essentially use the base as a tool to get their work done. So you could imagine that, let's say we're in, like it's somebody who runs a hair salon,

they've created an Airtable base to keep track of their customers and their hairstylists they employ and you know their let's say their appointments and all of that stuff probably their hair salon owner might be the one who set up the base and maintains it as a piece of software and then the stylists would be the ones who would who would actually use it to do their work, to say that they've completed an appointment, for example, or maybe that they have some availability coming up in a couple of days and would be open to appointments or whatever. And so there's that kind of separation between making it accessible for both groups of people. And we do that in a number of ways. So for example, you can create views that

are focused on, so you've got a table of data, and then a view will show you only a subset of that data. So only a certain set of records or a certain set of fields or whatever. So that's sort of just one example of the way that a view might be something that a user of the base uses, which is a much simpler thing that they can interact with. At the same time, there's also exactly, I say people who have different levels of sophistication with building applications. And I would say that I don't know in detail, but we are certainly targeting more people who are not programmers or who maybe only do a bit of programming and who are more sort of, but still need to build software, basically. So I think it's a different, not entirely different for sure,

but mostly different group. So it might be, it's quite often people who've used spreadsheets to run their work in the past, and so there's a transition there. But I think because Airtable is better suited to the things that people are using spreadsheets for in these cases, which is basically to kind of keep track of data that has a schema, then that transition, there's a little bit of stuff to do there, but basically that's not the tough problem. I think the toughest problem is helping people learn to create schemas that are powerful

for them and helping people learn to maintain those schemas and I think the other problem that certainly I think about a lot as a someone who works at Airtable is how you help someone understand what their processes actually are. So let's say, again, to take the example of a hairstylist, let's say they're keeping an appointment book at the moment, and that's how they've been running their salon so far. And that's been working fine. But if they started to build a base, then there's a big question of how do they translate their processes and which processes should they translate is there a burden on air table to help them build better processes for running things so for example let's say that so far um if they've had some let's say they decide

to open the salon on saturday or something like that to um see which of their stylists are going to be available to take appointments that day maybe they just ring round um which of their stylists are going to be available to take appointments that day. Maybe they just ring round each of their stylists and say, oh, hey, can you do Saturday? And then they figure out what the hours are and so on. And let's say that happens pretty frequently, then would they even recognize that as a process that could be made better in Airtable? I don't know. It depends.

Some would, some wouldn't. And maybe Airtable? I don't know. It depends. Some would, some wouldn't. And maybe Airtable could help them recognize that and help them build a better, more efficient process that doesn't involve them ringing everyone up. So I think we're sort of trying to push on all of these different fronts at the same time, being accessible for people who want to build the base, accessible for people who want to use the base, and also helping people build better processes for their work. That is fascinating, because that is an institutional example of what you ran into with Isla and CodeLorin. You know, you have this thing that you want to build, and in going through

it, you discover there's actually this problem outside of the scope of that thing that solving that problem out there would be helpful for the thing that i'm trying to build or that the the problem is broader than what i've scoped my focus on yeah that that's exactly it and and we have a number of tools for solving that problem. So one example is that for our larger customers, we have implementation specialists who are, you know, super-duper Airtable experts, and they will help the customer design the processes that they want to put into their base.

And so that's like, you can imagine, they're almost like a consultant who is helping someone produce better processes for their work. Then within the tool itself, then we can help customers with things like having templates, for example, that target certain niches. So, for example, there's like a sales management template or there's like a I don't know you know film shoot management template and things like that that obviously are ways for us to tacitly convey these sort of hopefully useful approaches to running this type of work but it's I mean it really like it's so I find it so fascinating because these problems kind of run all the way up and down the stack that we need to help customers with so all the way up to something quite high level like that like modeling a 10-step process that involves a bunch of complex steps in air

table kind of right at the top level all the way down to helping a customer understand that if they've created a table for January, like their January sales or something like that, it's probably not the right move to create another table for their February sales, that actually it's a better move to create a view that will filter down a single table of sales to show only January or only February or whatever. And so right down to that sort of just kind of data modeling problems that we need, that we also try to help customers with.

That's fun. Like I can imagine that, that building a product like Airtable and running into those kinds of challenges are just really invigorating for the people whose job it is to try and, you know, design their way out of them. It's great. Yeah, I think that's very cool. We have a second sponsor, which is fantastic because there are costs associated with doing this show. And so having companies willing to come forward and say, hey, if you read a thing

or two about what we're doing, we'll give you a little bit of money. That is so helpful for me. So if you are with a company out there that wants to get your product or your idea or your job listing or whatever it is that you want to get out there in front of our audience, and our audience is comprised of researchers and people in industry and people in academia, teachers and students, just a really, really big cross section of people, all of them sharing that common interest in exploring what we can do to really get ahead of where we are with our current state of programming and with our current culture and our current tools and all of that, reach out and let me know and we'll put something together. One such company that came to me and said, hey, we're hiring. Can you share that message with

your audience? It's a company called Glide. Glide's mission is to create a billion software developers by 2030 by making software dramatically easier to build. We all marvel at how successful spreadsheets have been at letting non-programmers build complex software, but spreadsheets are a terrible way to distribute software. They are an IDE, and the software built in it rolled into one, and you can't separate the two. So one way to think of Glide is as a spreadsheet-y programming model, but with a separable front-end and distribution mechanism. The way it works right now is that you pick a Google sheet and Glide builds a basic mobile

app from the data in the spreadsheet. You can then go in and reconfigure it in many ways, including adding computations and building some pretty complex interactions. Then you click a button and you get a link or a QR code to distribute the app. The data in the app and in the spreadsheet will automatically keep in sync. So they've taken the data that backs the app that you're going to build and, and have just used Google spreadsheets as that database interface, which is really neat because you'll, you know, I'm going totally off script now at this point, but, um, you'll see these, you know, tools for

working with SQL databases or, or no SQL databases that, that give it a kind of a spreadsheet interface. And it's sort of like, you know, having to gradually build back up from having no interface to having an interface, whereas what Glide are doing, or they're just saying, let's take an existing interface that is already really nice for working with database like storage that being, you know, the Google Sheets spreadsheet editor, which is quite robust. And let's just make that the database, which is so cool to me. For the Glide team, that's just the beginning. Glide needs to become much more powerful. Its declarative computation system has to support many more use cases without becoming yet another formula language. Its imperative actions don't even have a concept of loops yet or of transactions.

Glide needs to integrate with tons of data sources and scale up to handle much more data. To do all that, Glide needs your help. If you're excited about making end-user software development a reality, go to glideapps.com slash jobs and apply to join the team. Thank you to Glide for sponsoring this episode of the podcast and helping bring us the future of coding. We talked a little bit about CodeLorin having a virtual machine that you built in addition to the language, in addition to the editor interface addition to the the editor interface

there's you know a lot to this project and that lets you have this little feature up at the top that you talked about a little bit where there are little buttons for sort of rewind step back step forward and play that let you know, incrementally move through the execution of the code that you've written. And at each step, when you step back or step forward, it highlights in a little box the fragment of the code that is currently being evaluated, say. And so you can sort of step through, like if you're calling a function and doing something with the return value

and you are stepping forward through that, it would first highlight each argument to the function, and then it would highlight the function's name to represent that the function's being looked up. And then it would highlight, does it highlight the whole, the name and the arguments or just the parentheses for invocation? I can't remember. It will highlight the

function name itself to look up the definition of the function and then it will finally highlight the parens when it actually gets invoked. Okay, so it's just the parens. Yeah. And then after that it will highlight whatever the return value is being assigned to,

it will go through assignment and that sort of thing. And then after, I think more recently than that, you made a game called Step. It's sort of similar. It's a little snippet of JavaScript. And I will remind people that this is a game. So if I start swearing a whole bunch and cursing and all of that, just remember this is games are things people do for fun. It's a game. So if I start swearing a whole bunch and cursing and all of that, just remember, this is games are things people do for fun. It's a game that challenges you to click each little piece of syntax in JavaScript in the order that it is going to be evaluated, which I found absolutely agonizing because the script is a little little for loop and so it's got a you know var i equals zero i less than three i plus plus and then a little bit that's evaluated in the for loop like a console.log sort of thing and so you have to click each one of those in the right

order and it is not like you know i i did some computer science at university i will say that um i do i did at one point know the order that all of these things were supposed to be evaluated in and playing this game revealed to me that uh i don't know shit like i i did so badly at this and it that's interesting because you know you don't necessarily need to know that to be a programmer who goes through their programming life building programs but it's it's one of those little things that's going on behind the scenes that that at least I found very surprising and and going a little further back in your JSConf talk about I, you had a little section of that talk where you talk about syntax. And sort of going into that section and coming out of this experience with the game Step,

my sort of, you know, if you cornered me in an alley and said, hey, you know, held a gun up and said define syntax in in the context of programming i would sort of blurt out something about it being you know in a text-based language it's just the little bits of you know it's it's the punctuation basically or it's the you know the fact that you know var is a statement and so it doesn't have a return value it's not an expression that kind of thing like that syntax is just basically like it's not decorative it's very functional but it's it's not an expression that kind of thing like that syntax is just basically like it's not decorative it's very functional but it's it's um separate from the actual meaning of your code that it's sort of like maybe conveniences for the sake of the compiler is how i might look at it but in

fact in your talk you you describe syntax as being the order that things happen that that's that's what it is and so i went and i looked up the etymology of syntax and it literally means uh to put in order the the sin part of syntax means together and the tax part comes from the same root as the word tactics and so the syntax of a language is literally talking about the way in which it helps you put things together in a specific order. And I found that really interesting and surprising, especially in light of how bad I was at understanding the syntax of JavaScript, a language which I am forced to suffer through quite regularly. And so through all of these projects, through CodeLorin, through this so-called game, through Isla, all of them, it seems to me like you have this really strong affinity for the text of programming, like as a medium in a way that to me feels, I don't know if it's literary or if it's, it's not linguistic because it's not about speech per se. But to me, it feels like there's something about the text part of programming that you are really interested in.

And I wrote this question out in advance before you saying that you might have studied English if you didn't study computer science. And so I was kind of in my head going, oh, interesting. Is that fair to say that you are very, very fond of the textiness of programming? And is that something that you've thought much about? Or is that something that you've just kind of happened upon sort of naturally? Yeah, this is something that I've thought about before. It's interesting you bring it up. I think the parts of programming that I'm good at are often linguistic. And I guess I distinguish the linguistic parts from maybe things like, you might say, the graphical parts or the, you know, graphical, by which I mean the graphical, you know a graph for example or like

data structures or whatever because it feels like writing prose to me writing writing code so I really enjoy that part of it because it's like just cool stuff like creating a closure or something like that let's say with's say with a function that then lets you, say you create a function that returns a function, and then you can access the closed over state later when you run the inner returned function. That feels kind of very like reading a novel or something like that to me, where you can kind of, you know know create a structural link in the text from something that happened earlier to to the current moment that the person is reading that like i said it feels very linguistic to me and so i really enjoy those parts a lot yeah and it's something that

catches me by surprise just because i've uh i've not uh i've not done a very good job of hiding the fact that I loathe the text of programming. And so to immerse myself in your work the way that I did to prepare for this interview and to discover so many ways in which it feels to me like there's a fondness there that you have for it that kind of seeps through in your work you know perhaps that's the thing that is just needed to compel one to create a programming language because you've how so i don't know this offhand how many programming languages do you think you've made so far how many different ones i think only two are just the one for code lauren and then isla i really enjoy that that textual part of it i think where step came from um and where i would say quite a lot of my other projects have come from

is it is from a desire to understand deeply what's going on um when a program runs and so when i built steps and so it's all it's all just hard coded basically it's not it's not like a um the environment that you click on when you when you when you look at step is is i've literally like i think just made a list of what what the right order of things to click on is um because it seemed just much faster that way the projects like that or like you know the implementing git in javascript um or uh i wrote this essay about um kind of an intro to functional programming they're all about trying to get at this core of how stuff works so step when you click on it i still get it wrong sometimes so i actually went back to it a few weeks ago, coincidentally, and I messed up in several places.

I could figure out why I'd messed up. Oh, yeah, of course, you do that bit first. But I think I really enjoy how precise one needs to be to get it absolutely right. All of these projects, like I say, are born out of a desire to not be confused by things which is comes from basically from a place of fear that things that i don't understand make me fearful that you know i won't be able to i don't know might make good stuff using code or you know that there'll be a bug that i can't fix or something like that. And so this, like, going very deep is a way to feel, it's probably like a self-soothing type thing, where it's like,

this is a way to feel like, yes, I understand this in detail. And it's also, I think, super fun to just understand how stuff works, like put stuff together. So's like for example just one example when I built git in javascript then learning that by doing git add to a file that I've effectively created you know I've I've I've saved that content of that file at that moment forever now you know sort of you know modulo any any git clean or whatever but um I've saved that that content forever now and so I don't need to worry that I'll lose it then when you read that in an article it's like oh if you want to keep something then just get at it there's there's a sort of certain sense of unease that certainly comes over me it's like oh why that's weird why

I thought that you only save stuff when you commit it that that's weird why i thought it only saved stuff when you committed that that's weird and so you don't really trust it and you don't really remember it that well whereas by understanding what's going on in the objects directory uh inside the dot git directory then i was able to understand why that was true that git add would save a file for sort of notionally forever and that is like gives you a feeling of like i say understanding and it's also sort of cool so oh that's how that works that's pretty neat through all of these projects including uh gitlet code lauren and and step curse um and isla they sort of they all kind of they play on this idea that when you're working

with a language like C in a very traditional, you know, editor environment, you kind of have to play compiler in your head. Like you sort of have to be familiar enough with the syntax of the language, which means the order that things go in. You have to know about, you know, any quirks of the language, which means the order that things go in. You have to know about, you know, any quirks of the execution environment. You have to know things about if you're writing across multiple files, the way that they're going to be brought together and what order they're going to run in. And that's something you can hose yourself with. There's all of these details that go beyond

just the behavior that you're specifying that you need to understand comprehensively in order to confidently build a project and it feels like a lot of your a lot of the tools and games and things that you've built over the years are trying to take some of the mechanical aspects of compilation and either play with them or surface them or bring them out of obscurity and out of mechanization and make them intuitive or make them interactive in a certain way. And I find that really delightful as a sort of an overarching theme of your work. And I was wondering sort of now, and this is a little bit like what we talked about earlier with GameMaker, but if you were to keep going with that theme of getting

people out of having to play compiler in their head or surfacing what the compiler is doing, where do you think you would go with that idea in future projects? It's all about trying to make it more accessible, trying to make it easier for people to build stuff or not be afraid of computers. And the place I'm at now and have been for the last, more recently I guess, is sort of like I've touched on before, getting away from writing textual code and towards a place that you still need to define programs,

which is to say to define algorithms, I guess is how I think of it, but you don't necessarily need to write code to define those algorithms. Trying to move towards a place where that's not necessary, which I think hopefully makes it even more accessible because taking code mostly out of the equation, that's not necessary which I think is would hopefully makes it even more accessible because taking code mostly out of the equation I think lowers the barrier quite a lot certainly in terms of perceive you know people's perception and the fear that comes from that and also from the actual challenge of it and so I think it gets I think there's a way to get completely away from code forever for everyone.

But I found a useful North Star more recently to be no programming ever. And it's like, you know, obviously you're probably going to fail at that, but it's a useful mental discipline. So how can I do this without programming? Because it seems highly likely. If we're still still writing code most of software is being created by people writing code in 100 years then I will be very surprised and so it seems helpful to try and run towards in that direction as quickly as possible now rather than sort of waiting for it to come in the future and I think that part of that is about helping,

hopefully making things that are more accessible for other people. So that's like working on Airtable, for example. And partly it's about actually moving myself away from writing code. I mean, obviously I write code for my living at the moment, but I think that, you know, I put whatever it is, I don't know, 20 years into learning to be a good programmer. Still learning tons, still tons to learn. But, you know, I think I'm a solid programmer now.

But I find myself just wanting to get away from writing code more and more. So GameMaker is one example of that. Another example is trying to build and prototype interfaces without writing any code. So by using both drawing on paper or by using UI prototyping tools like Origami is pretty cool or Axia is amazing. I have no idea why. So I feel like the last six months has been me discovering tools

that are 20 years old that are totally amazing and that I wish I'd discovered a really long time ago. I know that feeling. Because they're just so much faster. It's just like, oh, God. And so essentially just, you know, I don't want to say that programming sucks because it obviously doesn't. Obviously, I love programming. But I do kind of find programming

very slow, even though I'm quite good at it and sort of very frustrating. And there's just so much more joy that comes from not needing to write everything in code and being able to just move whatever it is that you're making forwards so much faster than if you have to write code to do it. There are some people probably in the audience who are going to get a little bit hung up on your use of the word programming. And I just wanted to give you the opportunity to sort of define what you see as the difference between coding and programming and maybe something like you know using hypercard or maybe something like using a drawing app or something like that because there's some people out there for whom you know drawing a picture in

photoshop is programming like they're they have that broad of a definition of what it means to be programming you know and then there's some people where the line is HTML or there's some people where the line, there's some people where if you are writing in a dynamic language, you're not programming, you're scripting. So I'm just, in that you have made a very universal statement, no programming ever,

I think it would be interesting to hear where you put the boundary around what it means to do programming in light of that yeah no thanks for letting me clarify that that's that's super that's super absolutely right um i think that the rough definition that i'm using here is textual programming as a kind of a rough rule of thumb definition um i think there are some things that aren't textual but are still very close to it. So like Scratch, for example,

it's like, you know, you're not writing much text, but it still feels very textual. It's pretty close, really, and so I would include things like that. I think if one defines programming as creating something that defines an algorithm, then I think that could be helpful. And so in that lens, then like writing a Word document is programming because you have types and characters in that dictate how the computer should render some text on the screen. And so that feels like technically correct, but not very useful.

And so I wouldn't go that far myself. I think what's useful is to have a useful definition. And so I think of it as being able to define the behavior of software without writing textual code is a rough rule of thumb, you know, with a bunch of caveats, basically. And so that's like a good example of that, I think is the example I gave of GameMaker

of defining the sprite where you don't have to write any code to decide to show, oh, this set of images go together into a sprite that's the first part of the algorithm the second part is that they should be shown in this order that I've dictated by dragging them around and the third part is that the image should change at this speed which you could also define graphically and so on and so that's definitely an algorithm that you've created. And so I'm not trying to get away from that type of programming.

I think that type of programming is really great. And even if it's not necessarily an algorithm that you've created like a new kind of search or something like that, it's still an algorithm that you are, like you're still doing algorithmic thinking when you're doing it much in the same way you're doing algorithmic thinking when you write a recipe or something like that exactly right it still seems to use the same parts of the brain but i i think that you know rearranging those images inside game maker to put them in the order that you want them to be displayed yeah it's creating an

algorithm and it requires algorithmic thinking but i think sometimes people get confused and say oh well if you're doing algorithmic thinking then you must be capable of programming and it's like yes that's true but it's so much easier to not do it in code. Both for the most amazing program, both for John Carmack and for somebody who's just writing their first line of code. I think there are easier and harder ways of creating

algorithms, and I guess I'm trying to push towards the easier ones. And just because it popped in my head, I bet an even harder interface than many of the programming languages that have survived to this day would be something like very complicated legal contracts. Because those are algorithms that have algorithmic thinking behind them, and the interface for them is just horrendous. So it's not as bad as it could be, but it certainly could be a lot better. Yeah, exactly.

So my kind of my last question, I thought would be a nice lighthearted kind of thing. And that is something we've talked a little bit about this already, but I want to go a little deeper into this because I'm that kind of nerd. We're both gamers. And I personally think that games have a really big role to play in both the future of programming directly but also just in the space of thinking about what the future of programming might look like there's a lot that the people making these sort of programming tools like you and i are working on and then people listening to this show are working on, things that we could learn from looking at video games. Both video games as works of art that inside them contain interesting ideas that we could borrow for programming, but also video games as a culture and an industry that produces software and is

wrestling with a lot of the same problems that we are wrestling with. And so I wanted to just take a moment to ask you if there are any favorite games that you have that are fun to look at through the lens of futuristic programming or through the lens of people working on this kind of dynamic software. What do you see as interesting things that we could point to over in the games world that it might be worth us paying more attention to? Part of my answer is around the non-interface, non-expression related parts of games. So, for example, the way a community can form around something like Minecraft, for example. I think future programming people, including me for sure, can learn a lot from that.

So it's like, my understanding is super supportive community, very exploratory, lots of different people with different objectives, kind of all working in the same area, kind of, you know, amazing community of practice around youtube and and friendship groups sharing ideas and sharing techniques and so on and so i think there's a ton of like just community related stuff that that that we can all learn from from from specific video games so that that's one part of it. Another part of it I think we can learn from is that games are extremely good at conveying complex systems to people in a very short amount of time in a very clear way. And so it's just kind of some of the stuff

is like next level. So for example, a game like the witness by jonathan blow which is if you're not familiar is kind of a puzzle games 3d you walk around solving sort of puzzles on that are on panels placed around the world um it gets more interesting and sophisticated than that but it's a hundred percent like non-linguistic like i think there's there's maybe like an x shown on the screen to say press the x button on your playstation controller but beyond that it teaches you an extremely complex you know i almost want to say language that you need to solve these puzzles without any words and it does it in this like amazingly ramped way it's so cool and so i think there's a lot of stuff about communication and about designing some systems that can be learned and so on that we can learn from various games too

i think there's also things to be learned from really great uis so the example that springs to mind, when you play Mario, you know, like the original Mario 1 on the Nintendo, the way jumping feels as Mario is just so precisely tuned that, like, you hold down the button for longer and you go higher. You hold it down and you just, for, you know, the maximum amount of time and you'll float just a little bit, but not that much. There's this kind of beautiful kind of exponential ramp up to how you move when you run and all sorts of things. So much complexity in just a few buttons that I think it's an incredibly expressive interface that they've created. And it's just for jumping. And so I think we can all learn a lot from there um and one of my favorite genres of YouTube videos is is is people explaining how games are designed so there's a really cool one um I think it might be with Miyamoto I'm not sure um where no it can't be with him um is somebody explaining how the first level of mario works where it teaches

you that that for example it almost forces you to trigger the first mushroom to jump out of the block when you when you jump into it um and then the mushroom is sent straight at you so you're like oh no it's it must be bad it's gonna hurt me and it's tough to avoid and so more likely you hit it and then you end up growing and you discover, oh no, mushrooms in this context are good. And just like all of these non-verbal ways of communicating things I think we can learn a lot about because essentially games are learning systems and they're just so much better than programming systems are. It's amazing. So I think we can learn so much better than programming systems are. It's amazing. So I think it's that we, yeah,

we can learn so much. I love those examples. And yeah, like just to fill in a bit of color on the last two, like in The Witness, an example of the language that the game teaches you non-verbally is that the panels that have the puzzles on them that are scattered around the world they challenge you to draw a line sort of through a maze from one corner to another corner or one side to another side and you can draw a line that can't intersect itself and so you can figure that out very easily because you start tracing the line around the panel and the and the game's interface sort of like laser focuses you on this activity it's it's the sort of thing where um the game does a tremendously good job of getting you into this space where the only control that you have is i'm moving my my mouse or i'm moving my joystick and and this line is being drawn and you can play with it and explore it and discover

okay it can't intersect itself there's this little pulsing thing that if I draw the line up to, it lets me complete the puzzle, and then that's the most basic thing. And then it builds on top of that, you know, in some of the puzzles, there might be three little dots in a little square of the grid that is the maze that you're drawing through. And you'll figure it out through playing with it that if you draw a line that goes past those three little dots, it won't let you complete the puzzle. And based on the arrangement of the maze, it might kind of force you to draw a line around those three dots in a certain way. And it will do that again and again and show you that every time you are drawing a line around those three dots in a certain way and it will do that again and again and show you that every time you

are drawing a line around those three dots and the puzzle is accepting your solution it's because the line that you've drawn goes around those three dots on three sides and then it will show you you know two dots and you have to figure out okay if i surround those two dots on two sides then it lets me complete the puzzle. And so it introduces this mechanic of, you know, this symbol will have a variable number to it that is the number of sides around which that square of the grid needs to have your line go around it. And then there'll be another symbol, and some of the symbols in the game look like Tetris pieces. They're these little Tetris

piece symbols like a like a little T or a little L shape or that sort of thing and the game will teach you non-verbally that to complete a puzzle that contains one of those symbols you have to enclose that symbol in a path that has the same shape as that Tetris-like piece that, and they're not tetronomos, they might have five segments or three segments or whatever, but it introduces something like 10 or 12 of these different mechanics and then puts them in all sorts of different combinations whereby the end of the game,

you are like this master at this language of drawing lines that are constrained by all of these weird symbols. And the symbols are sort of forcing you have something like a minute and a half to solve this whole series of these puzzles that are incredibly complex and that are randomized every time you do them. Because most of the puzzles in the game are the same every time you do them. And these puzzles at the end game are randomized and time limited. And there's a very juicy reward for completing that. But it's just this masterful way of showing that the presence of an interactive system

that you can have a dialogue with will let you have a learning experience that can be radically different from what we're used to when that learning experience is going through a medium that is human language where it's a direct you know teacher student kind of relationship and they're talking about some subject or when it's you know like a textbook or something like that here is an environment where through a little bit of trial and error but mostly just very carefully focused design you can have a learning experience that teaches you something very complex and of course that complex thing was designed with the fact that it needed to be taught

in mind and so it's not necessarily like you could apply this to teach an arbitrary thing but there are um i think there's a there's a really good spectrum there where from games we can see that there are so many different things that can be taught in ways that are nonverbal and in ways that are playful that if you are looking for features to design into your futuristic programming environment, there's a great big menu of choices you can choose from for interactions or for behaviors or for dynamic relationships between things that we can see and we've proven are very easy to teach intuitively or that there exists a way to do a really good job of teaching it intuitively and through play rather than didactically where you have to explain it with a pop-up or a manual or

something like that. So I loved that example. Yeah. I always find it interesting what games choose to essentially give you, you know, to, to, to, to just explain to you or to give you for free and what they want you to figure out on your own. Because clearly that if they just left you with nothing, then there would be a lot of frustration, which would be not that much fun.

But at the same time, making everything really easy, that's not that fun either. And I think a really strong example of that that comes to mind is a game called Into the Breach, which I also loved, which is essentially like you've got a few little tanks that you control and you have to fight off some other tanks in a little sort of eight by eight grid,

sort of isometric view. And they spent apparently a couple of years, they kind of got the game pretty much nailed down, but they spent a couple of years working on the UI, working out how to explain the concepts to the player in a way that wouldn't be frustrating. And I sort of find, so for example, they'll make it very clear that when you have one of your tanks fire, so you sort of, you essentially say, oh, I want my tank to fire over here, and they will show you the immediate consequences of that.

So the shell will hit the enemy thing and then that enemy will get flung back by two squares, let's say. And then that will they'll get flung into a building which will destroy that building. And so they've obviously given you quite a lot for free there. They're showing it to you in advance of it happening. Exactly. So you get to you get to have a preview of what is about showing it to you in advance of it happening. So you get to have a preview of what is about to happen if you decide to take that action. And what I find interesting there is like, okay, they're kind of giving you that for free. So they're certainly

saving you from some mistakes that you could be making. But clearly what they think is interesting is the slightly longer term ramifications that you do have to figure out for yourself so there's this notion of what should be told to the player or the user or whatever that that would be an omission if not told and then what shouldn't be told that would be like giving the game away or maybe taking the fun out of it or like taking away that fun of exploration you know whatever it is and i do not know how they decided what to put in the we'll tell you this and what to put in the you have to figure this one out for yourself categories and i think about it quite a lot i find it fascinating that's another game that i loved and another great example and i like um

specifically that you talked about that they they made the game and they made the That's another game that I loved and another great example. And I like, um, specifically that you talked about that they, they made the game and they made the, you know, the, the engine and the graphics and all that sort of thing and had this game playable and then spent a tremendously long time tuning the UI of it. And I think that that's a valuable lesson because it's not like games are different from the kind of software tools we're building in terms of the economics of it necessarily or in terms of the the process that you have to go through to create a thing like game developers want to make their game and they want to ship it and they want to get it out there into the world it's not like all games have developers

who spend that long working on the interface. That's very unusual. A lot of games, they'll spend the most time working on the graphics and the world and on populating it and fleshing out the story and on, if it's a big AAA game, recording all the dialogue and doing actual logic for what characters will do and all the things that happen as you progress through the game. There's a ton of things that take a ton of work and designing the UI is often not one of them. And so what makes Into the Breach such a wonderful example

is that they did take that extra time that it took to just polish the ui of this thing into something very very special and very unique and that that aspect of it is what made this game remarkable and is what made it i i think personally at least i think it's what made it into such a big success and such a big hit commercially, uh, was that by, by taking that much time to really tune the UI for one, they took a game style, a genre that is normally very niche and they made it approachable to a broader audience, but they also exposed a lot of the, the beauty of that beauty of that genre to people who previously wouldn't know that they would be interested in that kind of a game. And they did have the luxury of getting to take that time because their previous game was sort of a surprise hit. and you are working on your Isla or you're an Ivan and you're working on, you know, my past

projects that nobody's heard about or cares about, it's absolutely worth it to live with something for a long time and to invest that energy and that effort in polish and especially polish on the side of the user interface and on making it like you said mary you know deciding what to expose and what to obscure or or in the case that they did like very specifically they show so many things that other games hide and other games hide them because they think that the fun will come from seeing the dominoes all fall down as a surprise. And what these developers of Into the Breach found is, no, you can show, you can preview pretty much everything that's going to happen.

And at that point, from somebody who hasn't played it, you'll get the objection, well, at that point, why even play the game? Like if I sit down and I immediately see, oh, this is everything that's going to happen, where's the fun in that? And they show that it can be more fun when you give people more information because that lets you constrain the actions that the player can take in more interesting ways more severely than you could constrain them if you didn't show them everything. And another example of that that I love very much is a game by Zach Gage called Good Sudoku, which is a game that Zach made. And Zach does this for a lot of games.

He did this with Solitaire, with a lot of things where he will make a game that is based on a very, very standard game that everybody knows and everybody's bored to death of, like Solitaire or like Sudoku or something like that, where you think, well, really, you know, this space has been pretty well explored. What more is there to do with it? And what Zach's approach to the game is, is to build a very powerful user interface that lets you play the game at a higher level

than the normal interfaces for that game would allow. So most Sudoku apps will replicate the experience of playing a Sudoku on paper and good Sudoku will do things like it will automate all your annotations that say like, well, this cell can't be a three and that cell has to be a five or a seven or whatever. And it fills in all of those, those notes for you and saves you a whole ton of manual work. And you'd think, well well doesn't that just take the joy out of it and it's no because what that enables you to do is to a very quickly and through a very very good user interface that he developed for this learn more advanced techniques for sudoku

that you might not have even known existed if you were just playing sudokus casually. Like if a row which has to contain all the digits from one to nine has two cells that are empty, you know exactly what those two cells are. They're the only two numbers that are missing from the digits one to nine. And that's a technique that most people might not realize unless they play Sudoku very, very seriously and get to a high level that his interface exposes immediately. And so he can let you play Sudokus that are way, way, way harder than you'd normally ever be able to play because the interface is so good. And in so doing, learn all these new, more advanced techniques and see some of the beauty that that game has behind it that is normally obscured by that interface. And so, yeah, I think programming, we could do a

ton of that in so many different areas. I think, you know, maybe Elm's error messages are an easy thing to point to as a programming project where they put in a tremendous amount of effort to say, you know, what are some things that we can expose to the user that would normally be somewhat hidden that they'd have to do a lot of work to learn for themselves but there's probably many many many more things that we could do like that if we were each individually or collectively able to take that time and and really spend it living with our interfaces and and really honing the heck out of them yeah i i completely agree and I think that often hand in hand with the attitude of oh you're taking the you know the work out of it or you're taking the the fun out of it or something like that is this attitude that comes up in programming quite a lot of like oh if you can't simulate what the

computer's doing in your mind then you're not a proper programmer or something like that. And it's this kind of silly, I don't know, it's almost sort of like a moralistic viewpoint to take that you should be doing the grunt work, you should be doing, you should understand everything all the way down to the ones and zeros or whatever, in order to be able to do anything. And I think it's just, it's ridiculous. Agreed. Well, Mary, thank you very much for coming on the podcast and for taking this tour through the history of your projects and through my torment in playing with one of them and my delight in playing with all the other ones and sharing all the interesting thoughts that you've built up along the way.

Yeah, thanks so much for having me, Ivan. It's genuinely a huge honor to be able to talk to you. So thanks so much. So that brings us to the end of the interview. Thank you once again, Mary Rose Cook, for coming on the show. And I am just, you know, delighting in being able to have the position of power that I have as the person who is recording the end of the episode separate from the interview when Mary's not here to say, you know, oh, thank you.

No, thank you. No, I get the last word. So I get to say thank you, Mary. It was super fun to talk to you. And I'm thrilled that as part of doing this show, I get to interview so many Mary it was super fun to talk to you and I'm thrilled that as part of doing this show I get to interview so many people who are doing such interesting work and I've had Mary on my list of people to get on the show forever and ever and ever and it is a joy to finally have had this conversation um some closing thoughts before I wrap this up and turn you over to whatever podcast is next in your feed, I have, speaking

of podcasts, a new podcast that I've started. And I think I'd be remiss to not, you know, give it a plug here at the end when I'm doing a little bit of fourth wall messing around and saying, hey, I'm the editor. I get to, you know, have my own little soapbox, blah, blah, blah. This new podcast that I've started is about my own future of coding project called HEST, which I have talked about, I think, in passing once or twice on this show, but not in very much depth. If you would like to hear more about that, or if maybe you've seen it, if, you know, in some of the videos I've shared on the future of coding Slack, or some things on Twitter or various places, if you're curious what this is, I've shared on the future of coding slack, or some things on Twitter or various places.

If you're curious what this is, I've started a podcast where the whole point of the podcast is that I'm just going to do very short episodes once a week. And by very short, I mean like 10 minutes, 15 minutes, like super, super short, focused episodes on just a single piece of the design of this project. And I just talk about, you know, one or two little ideas. And it's a very lighthearted show. It's very free form. It's very daydreamy. And it's kind of inspired by some of the early episodes of this Future of Coding podcast

where Steve Krause, he would do these research reflection episodes where he would talk about his own thinking about what his project for the future of coding might look like. And I really, really loved those episodes. I'll peel the curtain back a little more here. Those episodes were by far less popular than the interview episodes. And that's probably a combination of factors. The biggest one is probably that when you do an interview, you are sharing that interview with the audience that is built in for the show, plus the audience that the guest is bringing to the show, the people who were already fond of the work of that guest. So you get this kind of magnification effect. And in the case of the research reflections, those episodes only go

out to the built-in audience for the show. So they weren't very popular. And so I think they aren't worth doing in an ongoing way in this feed. Like they're not the kind of thing that I would want to start doing for any number of reasons. So I decided to start a new show. And that new show is where I'll talk about my own work. So if you are interested in that, and I will warn you, it has a very different vibe from the vibe of this show. So you might find that very appealing, you might love it, and it might make you not want to listen to this show anymore or the exact opposite. Go check that out. And the way to find it is in your podcast player of choice. Just search for my name, Ivan Reese. That seems to be the most reliable way to find

the show. Otherwise, there'll be a link in the show notes and on the episode page. That episode page, once again, is futureofcoding.org slash episodes slash 50. There will be a full transcript of the interview up there as well as links to various things that Mary and I talked about and our two sponsors, once again, Replit and Glide. Thank you both for sponsoring the transcript and the show. And hopefully you'll hear from me again before the season changes. And on that note, oh, how do I normally end these things? Thanks for listening and I'll see you again in the future. I used to have an ending. That's the problem with not doing these episodes, except for once every season, is I forget what the ending is.

Oh well.