Future of Coding - Technical Dimensions of Feedback in Live Programming Systems by Josh Horowitz

Episode Date: May 10, 2026

This episode is about the paper Technical Dimensions of Feedback in Live Programming Systems by Josh Horowitz. [THIS SPACE INTENTIONALLY LEFT BLANK] [SERIOUSLY, IF YOU WANT SOMETHING HERE, WRITE IT YOURSELF] [NO PROMISES. MAKE IT GOOD] It's a solid episode — that's my take. You should listen to it instead of reading about it. And then give us your take. Links $ Gang, I'm sorry this episode is months late. It was a real doozy! But also, the bonus episodes over on our Patreon have been getting wildly ambitious. I did an insanely edited 54-minute video about The Browser Company. We had William Taysom over to share a deep critical analysis of The Witness. Jimmy and I shared what we'd do with our lives if we weren't doing computer stuff. And most recently, we spilled the design tea on two recent projects we've been working on — Jimmy's Whiteboard visual programming system, and Tenfold from Ink & Switch. If you like the FoC podcast, you'll get so much more of it for $5/month at feelingoff.com. Audio Hijack — this is the program we use to record the podcast. It has "Canadian Juice", which is a joke only Lu will get, but Lu isn't going to read this. But you all know what "juice" is, right? It's what Andrew Blinn does better than anyone, and he IS reading this. He fucking better be. Am I narrowcasting? Jimmy mentioned Notes from the Underground. I haven't read it, so I can't add snark. Sorry. We're making backend changes! Stay tuned. The new website for this podcast will be feelingof.com. You should check out that website, cool stuff there, and they have a podcast. The Hest podcast, which Ivan has always self-hosted (so to speak), is, basically, 38 episodes of Ivan describing what he's devoting his life to, one episode about the combat loop of the video game Death Stranding, and one episode about getting smaller and smaller forever, but make it music and about Ivan's misspent youth. If you're reading this and you haven't listened to it, what the hell are you doing! You'll love it so much! PlayBook is the project that the Programmable Ink folks at Ink & Switch have been working on since January 2024. Ivan is one of those folks. I'm one of those Ivans. Specifically, this is "the show notes writing Ivan". Have you met? He writes the show notes. I commentate on his work. This… paper(!)… was originally presented as a talk at LIVE PROG — which is almost a FOUR FOUR — in 2024 as a talk called Definitions & Dimensions of Liveness. Jimmy and Lu and I were in the room! Maybe that's the last time we'll ever be in the room. (Did you listen to the free 2025 holiday spectacular?) You sat along the fire… you saw the light… you saw. You're Sigur Rós, you're so. Why am I crying? Inventing on Principle — do we need to link to this? If you're reading these show notes and you haven't watched this talk, email [e-mail] and I'll give you a virtual hug because you're listening to our podcast without getting, like, any of the jokes? Observable — same snark as previous Projection Boxes — now this one, I hadn't heard of, but if you have heard of it reach out and tell me about it so that I can be in on our jokes. The Ostrogoths are not rats, but I'm ready for either of them to invade Alberta. (Aside for any Alberta-curious listeners: there's interesting political history / class warfare here) Quokka is an editor extension that gives you live evaluated values right in the context of your JS code. Seems super neat on paper, but Ivan didn't have much luck using it. (skill issue) Glamorous Toolkit is the shining example of a "moldable" development environment. PANE is an interesting node-wire programming environment by Josh Horowitz, which flips the usual format by making the nodes hold state and the wires represent transformations. Node? Wire? Junk? Pipe? Baby Died, one of the uncountably infinite classic bits from My Brother, My Brother, and Me. Sketch-n-Sketch is one of the all-time great bidirectional editing environments. There's even an FoC episode about it. Sculpin is an environment that lets you use the mouse to interact with JSON data and incrementally enrich it into a GUI. It's sick! Wisp is a whitespace-based Lisp. This is one of the coolest websites I've seen in a hot sec. The 2019 Mac Pro had a Xeon, and sucked, like a room full of alien eggs, really, any room full of alien eggs. The 2019 MacBook Pro did not have a Xeon, but ran stupidly hot and also sucked, but not in a way that involves alien eggs AFAIK. Imagine a material FPGA (Field-programmable gate array). NOT field-programmable gatorade. NOT FPGA stop making jokes everyone that's not why we're here. We're here to discuss two things: computers, and feelings, and I'm all out of feelings. Stop Drawing Dead Fish… I need like an autocomplete for stuff we reference in every second episode. Can you imagine if I linked to Clojure every time we talked about it? Here's a nice demo of Boxer, if you've never seen it. The title of Josh's paper was inspired by Technical Dimensions of Programming Systems, a work by longtime friends of FoC Joel Jakubovic, Jonathan Edwards and Tomas Petricek. There's a link I can't include because it would be a spoiler for… not the next episode (Grice), not the one after that (Papert), but the one after that (Plant). She'll be out eventually; sea—por favor—paciente; see you in July; Tiny Huge; the sort of looking back in hindsight you've come to expect at 40. The Chorus: Daniel Tempkin chee rabbits Eli Mellen Brooklyn Zelenka Jack Rusher Arcade Wise Joshua Horowitz Taylor Troesh zuggamasta? Stuart Presnell Sam McDonald n Tobias babel (they/them) (oi oi, what's all this about, then?) Eric Paul C chris shank Scott McKinley Evans Corey Moran Lim Oliver Mahmoud H Samuel Durkin Harold Martin Duane ma3ke Ara Hacopian Cfiggers Siva Mahadevan Arcade but different and cooler asd Arlo Han (if you see yourself in this list and would like a link to your website, let me know) Music featured in this episode: Untitled #1 (Vaka) by Sigur Rós Phenomena by Akron/Family ! If you figure out all the secret clues lemme know, join the Feeling Of community, and here are the Means-to-Find I, and also J: I: 🐘 🦋 🌐 J: 🐘 🦋 🌐 https://feelingof.com/episodes/080/Support us on Patreon: https://www.patreon.com/feelingofcomputingSee omnystudio.com/listener for privacy information.

All right. Is that working? Do we hear any echoes? No, no echoes. Any doubles? No echoes. No echoes. Okay, great. That's good. Now I can just now I can just dock audio jack out of the way. Cool. Okay, so I guess first, right off the bat, what windows do you have open on your computer? A lot. A lot. Okay. Always. I end up closing out of them because I'm like, wait, I need to stop being distracted by all of these.

He's being distracted. We'll do that and then tell me which ones you have opened. I've got a terminal window, audio hijack, zoom, and then I have PDF markup. Is this your new? PDF markup is my vibe-coded app that I used. Oh, nice. It was fantastic until this morning when I realized I hadn't actually had it properly implement sync between my iPad and the Mac.

So I had to do some more vibe coding to get it to work. But yeah, I have my own vibe coded app that I use to highlight this. And it's so much nicer because it does only the things I want. I'm also using my own. And we're going now, by the way. This is the same show. I am also using my own app that I slash we wrote. I'm using Playbook once again for highlighting, which might come up later.

Because I have it. I have it ready to screen share. Yeah, yeah. I was saying, he's currently screen sharing. I am screen sharing. Oh, I'm already screen sharing? Son of a bit. Yeah, you've been screen sharing since I joined.

I was testing to make sure it would work because screen sharing an iPad is a... My level of highlighting was way more thorough than his... He didn't highlight anywhere near enough. Ah, yes. Well, well. All right, all right. But he has writing that I can't read. Yeah, you don't need to read.

It's just like it's labeling each of the parapher. Which is a new thing I'm trying this time. I tried like what if I label what each paragraph means and then if we start talking about something I can like quickly find the like oh where did we talk where is that paragraph. So we'll see if that works. Fancy. Yep, yep, yep, yep, yep. Okay, so one point of order before we get into the, the disorder. I keep wanting to say that the listicle, the article, the no, what's it called? We're reading a paper. We're reading a real paper this time. It's a real paper. The last paper was fictional. Yes. The last paper was not a paper. This time we were reading a paper. But before we get into that, I have one thing to say, which is that now that this podcast is called The Feeling of Computing, I need to make a bunch of backend changes.

And this is really boring stuff that is normally, wait, swipe the page, it's normally like underground. Like you don't normally know about Jimmy's laughing already. You don't normally know about what is, um, going on underground in the podcast, but in the spirit of today's paper, I'm going to be surfacing some things from underground in the podcast so that that people listening to this can enjoy those things that are normally. Do we really want to do all of this without at all explaining why I laugh and what this, what is going on here? They'll know. They'll know soon enough. Don't worry. Don't worry about that. This is not a video podcast. Yeah, they don't need to see that they don't need to see anything on the video. for this theme to make sense.

Okay. This is going to make sense with audio, I hope. Okay. I guess one thing I could do is I could start recording video if you wanted. That would be... No, you don't need to. Okay. That's fine.

I just, you know, I feel the need to explain that there's drawings of things underground in this paper. Yes, and we'll get there. Because a big part of the paper is describing their visual notation system. So we'll definitely talk about that when we get to that. Of course, of course. But right now, you know, I'm letting people in on the joke of Ivan trying to be underground, and exposing things. So this is notes from the underground, got it.

Yeah. So because the podcast is now called The Feeling of Computing, I want to make a bunch of changes. And one of the changes that I want to make is I want to get off of our old podcast host who are fine, but increasingly bad. And if you've ever looked at our show notes, at the very bottom of the show notes, you would have noticed a little link that gets auto-injected to some privacy policy

because the platform we use does not have great respect for people's data. And I just want to switch to hand-rolling an RSS feed, hosting some MP3 files, and slinging them over the wire, because that's the origin of podcasting. And I think that's the proper way to do a podcast if you have the technical means and know-how,

which I do. I've always done that for the HEST podcast. I've done that for other podcasts. It works great. So I want to get off this proprietary platform and self-host. But that means doing a feed redirect. So I've done this before. It probably will go seamlessly for everybody.

But just in case it doesn't, if you are listening to this, you may want to just make a little mental note that maybe a day or two after this goes out, I'm going to switch the feed over. And so you might want to, like I'll probably drop a little thing in both feeds just letting people know, hey, we did the switchover. If you're listening to this, you made it. And then in the other feed, I'll say, hey, if you're listening to this, you haven't made it.

So go update your subscription. So that's going to happen. We're going to do a new hosting setup. It's going to be feeling of computing. It's going to be completely privacy respectful because we'll have the choice to do that. And that's what I like to do. So I just wanted to put that out there as a like heads up. We're making it happen.

So that's a little bit of behind the scenes for the show. So on that note, Today's paper is called Technical Dimensions of Live Feedback in Programming Systems authored by Joshua Horowitz, who I should disclaim is a friend of the show. He's active in Incan Switch. We talk regularly.

He's a wonderful, wonderful person, and so I'm coming into this already predisposed to be a little bit friendly towards this. So if I'm too friendly, or maybe if I overreact and I'm too harsh, just know that, yes, I know Josh. Josh, it's great. And we saw a different version, but fairly similar version of this paper, Live. Yeah, yeah, when we were at Live in 2024, I think it was, maybe 2023.

Yeah, Josh presented this work. I think, you know, it's changed some since then. I'm not saying it's not different, and I don't think this is the published version of that. Yeah, no. This has been updated. Yeah, but we still, yeah, he presented it. So it's something that I was very familiar with going in, having heard the presentation. Yeah, he did this as a talk, and so now it's a paper.

And I asked him if we could do this. I don't think it's actually published yet, but he's been sharing the preprint, and he's said, yeah, go ahead. So we're doing it. We're doing technical dimensions of live. Live back programming systems. Yeah, I think this paper is quite a bit different from papers we've done in the past. It's not a summary of an existing system. It's not a position paper of, like, arguing how you should do programming or anything.

It's really kind of a breakdown and analysis of a bunch of different ways in which live programming systems do things and trying to, like, categorize. them. I don't know that there's much to, I don't think there's going to be a bunch of disagreement on this paper, right? Maybe. We'll see. Maybe we'll see about that. We'll see about that. You know, I think there's different ways in which you could divide things up. It's a fairly straightforward, interesting way to look at systems. When I say straightforward, I don't mean, oh, it's so obvious anyone should have thought of these. I mean, as presented, it does a very good job showing the different aspects of a live system, a live system. It doesn't claim to be exhaustive. I think that's important if it did, then maybe we get all the disagreement. But it's a

pretty nice, it's a very well-organized paper, very clear. I think this is the clearest, most well-organized paper we've ever read, for sure. Ever. I mean, I certainly would rank it really highly in that regard, definitely. And that's one of the reasons why I picked it is like, you know, we have lots of friends who publish papers. Josh has published papers in the past that I've considered bringing to the show. But this one is just such a, for my money, at least, it's such a clean slam dunk. Taking a lens on our field and presenting that lens, I think it makes it really easy to discuss. So yeah, definitely agree on that point that it's cogent. Is that the word? I've heard that word a lot lately.

And it also like while it is a contemporary computer science paper, it just doesn't have some of the things I find obnoxious about those. Find abnoxious, find obnoxious, just really like lays it out very clearly, very simply. I enjoy it quite a bit for that reason. So yeah, just to just to kind of pull a couple of highlights from the first paragraph here to clarify some terminology, because the the title of the paper. Man, I have to get used to saying paper again. The title of the paper is technical dimensions of live feedback in programming systems. So what does live mean?

This was presented originally as a talk at that live programming conference. Live programming is a term that a lot of people are using these days, also live coding. And there's some people who are not present on the podcast today. who have strong opinions about the use of the term live. And so here's Josh's definition of live, the very first sentence of the introduction. He says, programming systems are called live when they provide feedback on the dynamic behavior of programs as they are edited. And then six citations.

So that's the definition of live that Josh is going with for the purposes of this paper. Programming systems are called live when they provide feedback on the dynamic behavior of programs as they are edited. I think that that's perfectly reasonable. I kind of like that. Like, there's a lot of stuff that falls under that umbrella. It's a pretty, you know, all-encompassing thing. You could even say, like, depending on how you want to stretch the definition of programming, that all running programs are live because you're, you know, as you use the program, if it has some GUI or something like that, you're manipulating the state space of the running program and it's giving you feedback on that state space. But that's like, that's wanky. But that's not as they're edited.

You're editing the state space of the program. You're not editing the program. The state space is part of the program. No, it's not. Well, okay. You're editing the inputs and outputs. That's not editing the program. Is state part of the... You said the state space, not the state. What's the difference? And I'm actually seriously, not sure. Yeah, like, well, it depends. Like, if I meant, oh, I'm editing what things are recorded, right? I'm editing the state.

Like, before, I wasn't recording every single user's click. And now in my little state struct, I say clicks, and I have a list of them, and I'm adding to them. Ah. That would be one way of talking about editing state. I see what you're saying. Yeah, like editing what state is even captured, how is it structured, how is it used, yes. And, of course, if you could edit that. that would be editing the program.

Well, okay, this is a rabbit hole that has nothing to do with the paper. But, okay, I want to say why I like this definition. Yeah, go for it, yeah. The reason I like it is because it says the programs as they are edited, I think that the editing the programs is very important aspect. But the one that I really like is that it's about feedback on the dynamic behavior of programs. One of the, like, I don't think intentionally, because I just think that they don't have experience with these systems.

But one of the bait and switch kind of things that you'll hear from people in the like statically typed world is like, well, all that live programming stuff, we have that too. Look, I'm in my editor and I immediately get feedback of I have a type error. And that's live programming. And the fact that we call out the dynamic behavior of the programs that we get feedback on that is I think one of the keys here. And like really makes a big, a huge difference. I think, Both can be valuable. Getting static feedback is very useful. But actually getting feedback on the dynamic behavior is to me what makes something live as opposed to just nice to work with. Right. I think feedback, frequent feedback, which we'll talk about, you know, granularity, et cetera, is really nice to have.

But of the dynamic behavior is kind of the key here to me. That makes it live programming. Yep. That makes sense. Sorry. Okay. He's sitting over here. Okay, so I will tell a story here because I have to because it's more fun.

So I went to a Sigurose concert when I was like right out of high school. I'm not a huge Sigurose fan. I think they're okay. But like I'm not like, yep. But my friends really were. And so we drove 12 hours to Philadelphia for a Sigeroz concert. And are you still there? Are you still there?

What the fuck? Hi. Hi. Hi. You're back. Zoom crashed. Like actually crashed. All right. Nice. Hasn't happened before.

Yeah, you froze and I caught it pretty quick. Yeah. You should reboot the Sigurose story. You want me to start over? I know that I was saying, we drove 12 hours to Sygaros concert. That's the last word I said. Yeah, yeah, yeah.

We drove like 12 hours to Philadelphia for Sigeroz. We stay the night in this crappy hotel. We get there at like 7 a.m. The Sigurose concert is definitely not at, 7 a.m. It was way late in the evening, but my friends wanted to be the very first to stand in line because it was general admission and wanted to run all the way up to the front and make sure that they were right in the front at the stage. So we're there for like 12 hours. It is like 98 degrees out. It is just blazing heat. I'm not like I'm not having a good time. We don't even have food or

anything, like maybe some snacks. Finally, it opens up and it turns out I was given. a ticket for the wrong day and wasn't allowed to go in. And luckily, one of the security guards who had been there since the beginning saw that I had been there all day long, took my ticket, let me go in and was like, it doesn't matter, you just go. So I get all the way up to the front. And then we have an hour and a half of them messing with the projector. The concert is supposed to start, but instead of starting the concert, they spend an hour and a half moving the projector back and forth and back and forth by the tiniest, tiniest amounts in complete silence as they're just adjusting the projector.

And that is what Ivan has been doing this whole entire time, except for his little adjustments of all of his screen are so silly and minute that he's crashing Zoom. and I wish they had crashed that concert because by the time it happened I was just the most frustrated I've ever been at any event ever. I think I know why it's crashing Zoom. I can't tell if this is going to be in the show

or not this bit about Zoom crashing because this is not part of the theme of the episode today which is surfacing as the show as we do the show. That was Zoom surfacing feedback about you. doing things. I guess so. So I'm trying to set up some screenshy. Oh, fuck. This is going to crash.

This is going to crash. Totally going to crash. Are you sharing from your iPad? I am sharing from my iPad, yes. Ah. I think if I don't move the windows that Zoom is sharing, it won't crash. It only crashed when I started moving those windows around. All those windows are in their final. You're not doing like an OBS and then... No, I'm not doing an OBS. I'm just doing... If I had some complicated setup like this, that's what I would do. Also, though, I don't. I just made my app work on Mac. Yeah, I had five minutes to set this up. I just made my app work on Mac.

I don't know what your problem is. My problem is that I like the iPad. Yeah, mine works on both. Fine. Also, my OBS setup is like wickedly complicated right now because it's set up for this Halloween character that I do for one day a year. Yeah, you'll find out about it someday. Okay.

All right. So, all right. The other bit that I wanted to call out from this first paragraph is the question is like, well, maybe somebody, I wouldn't ask this question because I'm pilled, but maybe somebody would ask, why do we want live feedback as you're editing the program? Why do you want the tool that you're using to give you feedback on the dynamic behavior of the program? And the examples that they give are increasing accessibility for less experienced programmers. easing comprehension while reading code and opening up new exploratory workflows. Which all of that makes sense. I'm sure there's other reasons as well, but I think those are three solid reasons,

especially the third one. Opening up new exploratory workflows. That's how you get me. That's my catnip is like, wait, new forms of visual feedback that let you explore new ways of working. I think that's pretty amazing. Yeah, I'll just say like as well, like, live, like, it changes the way you code. This is one of the things that I think is the most important aspect of it.

It is like if you have something that you're able to get live feedback, it is kind of a forcing function to, like, you get so much benefit out of it that you end up wanting to make sure your system can work in a live way. and so you augment the code to be able to fit with that system. And it has a lot of interesting nice properties because of that. I think if you look at closure codebases and you see some of these old school closure programmers who hate their in-reple and only want to copy and paste stuff into their repel, man, are those codebases awful? New school closure people who actually use all the nice tools.

There's so much better. Hello, welcome to the Feeling of Computing Podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Wait, wait, wait, oh, no, no, no, no. Hello, welcome to the feeling of computing podcast. This is a recording.

Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role as surprised guest is to give Jimmy and I feedback on the podcast as we we record it. You may do this at any time as much as you want. Don't be shy. Thank you. And now, back to the episode. Yeah, so you were talking about curses and rebel. I can't tell if there's somebody else. Is it how could I? No, there's nobody else on the call. So, or no, there are. There's four participants. Ah, okay, got it. Hello, people. Daniel and Chi are you able to see each other? Great.

You are our first two surprise guests. Please feel free to unmute yourself at any time and give us feedback on the episode as we record it as much as you want in any form that you want. Feel free to interrupt. Feel free to raise a hand, whatever it is that you want to do. And because I wasn't prepared for this, I'm going to just look at Ivan and pretend you're not here

or also I'm just going to get distracted. Ivan loves to surprise me with things. I was not told. I was told there was something happening today. That was it. I'm also going to look at Ivan and pretend I'm not here. Oh, great. Yeah, when you all speak, I have it on speaker view, so when you all speak, I'll see you.

But for right now, I'm going to try to be a normal podcaster. Nice, nice. Yeah, yeah. So I think it's worth getting into the heart of this paper. So the heart of this paper is this system of visualizations that Josh came up with that qualify and make a sort of a spectrum. of these different facets of live programming systems. And so we can look at a bunch of different systems that have some live feedback and score them in different ways or like evaluate the dimensions, the technical dimensions along which they give their feedback. And those six different dimensions are, first, granularity, which is how detailed is the feedback in a live system, specifically how deeply into the internals of,

of the program, does the system provide visibility? Then there's reactivity, which is how often are changes to a program reacted to with feedback. There's velocity, which is how quickly after an edit is made is feedback available to the programmer. There's moldability, how can feedback be shaped to reflect the domain-specific meaning, bidirectionality, which means can programs be edited by acting on feedback? and materiality is feedback a side effect or part of the critical path of computation. So my question so far, Hello, welcome to the feeling of computing podcast.

This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role as surprised guest is to give Jimmy and I feedback on the podcast as we record it. You may do this at any time, as much as you, you want. Don't be shy. Thank you. And now back to the episode. So I think it would make sense to kind of go through these one at a time and talk about Josh's examples and what we think of them. But before we do that, Jimmy, do you have any thoughts on the overall system or the visualization

design or anything like that? I think, yeah, no, I think the visualization design is nice in some ways, confusing in others. I think it gives this paper a good flavor. The paper feels much more lively, but I don't know that it actually like adds a whole lot personally. Hello, welcome to the feeling of computing podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role is surprise guest is to give Jimmy and I feedback on the podcast as we record it. You may do this at any time as much as you want. Don't be shy. Thank you. And now back to the episode. If I leave and come back, do you have to say it again? Oh, I haven't thought of that. Okay. I'm going to

since this is our first piece of feedback, I'm going to add a rule which says additional rules. If you leave and come back, what do you think, Daniel? Should I have to say it again or should I not say it again? I think you should not say it again because otherwise we're going to be tempted to leave and come back over and over. Well, I wouldn't want to do anything to tempt you to mess with the show. So there we go. All right. That is the first additional rule.

Yes. Any other feedback while we're here? Did I miss my two? of these a scored odd? Yeah, so that's great feedback, Chi. So I'm screen sharing my iPad, which has all my notes in it for this paper. And I've crossed out the, there's a nice figure on the second page, which shows this visual language, this visual system that Josh came up with to illustrate these different

dimensions of live feedback. And we'll talk about the design of those visuals in a sec, because that's a really big part of what makes this paper interesting. And there's little descriptions next to each of them, and I've crossed some of those descriptions out because I didn't like those descriptions on this figure as much as the first sentence introducing each of these dimensions that appears later. So I have some notation here to let me know, okay, I don't like the description of granularity here.

I'm going to read the description of granularity on this other page. I will just say I agree on granularity for sure. I thought this was a little misleading of a description. The description that's in the figure says, how deeply into the structure of a program is feedback provided? And then the description from the actual section on granularity says, how detailed is the feedback in a live system, which makes more sense.

And then it says specifically, how deeply into the internals of the program does the system provide visibility. And I think this is interesting. Okay, so if you look at this little flower picture, so these, I know we'll describe them, I'm sure in more detail later or whatever, but there's this little flower picture, and there's like the ground and a flower sprouting up.

And almost all of these pictures differ by how there's these little blocks with flowers sprouting out of them and how they relate to each other. So this one has three empty blocks with no flowers and then one flower versus four blocks each with their own flower. And there's this, you know, dividing line of above ground and underground. We can talk about that. But granularity here is like, oh, there's lots of flowers. all spaced together and there's not like some missing flower right there's not something happening that you're not getting a flower for I find this interesting because I actually asked I can't remember in the talk how this one was but I talked I asked specifically a question of Josh about like do you have one about the internals of the system and like exposing things like performance like like if you had a garbage collector like seeing when the garbage collector's running all

all of those kinds of things, which is what I think of as internals. And he said, eh, not really. And he didn't know if that was valuable. But then this one talks about the internals of the system, but then when we see it,

I don't think. Chi has in the chat posted, or indeed three garbage collectors, a callback to a recent episode. Yeah, to my thing where I have three garbage collectors. So, yeah,

I don't think this is actually about the internals of the system, especially in the examples here. I think this is about, how much you visualize. But yeah. Yeah. Yeah. Like it's certainly,

it could have used this visual language. And just to nail down the visual, it's like you're a side view where you're seeing above ground, there's some flowers and below ground. There's some programming. And the programming below ground

is this like horizontal row of boxes. And the boxes don't have like depth. But the description here is like how deeply into the structure of the program is feedback. provided. I almost wonder if it would have made sense to do a more layered visual notation. Like there's like some higher parts of the program that are maybe like the parts that integrate all the smaller units down below and, you know, give them their overall program behavior. And then deeper down, there's like, ah, here's the little, you know, micro functions that do all

the little tiny bits of work. And maybe there's the dimension of granularity would be about like, which of those things are you seeing? Are you just seeing like broadstores or. strokes, like, what state is the program in right now? Zoom is recording. Zoom is on a call. Zoom does have the chat window open, or does it go more deeply down and say, like, you know, here's how we actually position each of the little. Jack is raising his hand. Yes, Jack. granularity in lot of code systems. One of the things that comes to mind is that in some systems, you can reevaluate the state of the entire program. You know, you make a change and it reruns the whole program. In some, you can manually decide, you want to be able to.

to reevaluate a single function within the program, assuming we're sort of a functional paradigm. Some you can go in and you can evaluate a single form, as we would say in the list world, or component of a function at a time. And then some you might want to assign a control to some single tweakable constant so that you can change how many bunnies there are running across the field with the slider. And so for me, granularity in this context is really about how much you can zoom into the smallest artifacts of your program, interact with them directly, rather than only whether you can see or visualize them from the outside. thought. So in the framework that Josh set up, the question of when you make changes, how often are those changes visualized? Like how quickly are you getting feedback? I thought of that as a separate dimension

ultimately. Like how, yeah. That's reactivity. That's the little hands underneath. And Brooke in the chat also said, as far as I know, it's trying to squeeze space and adjacency and time into the same horizontal dimension. And yes, that's correct. Like reactivity, the next dimension has these little arrows from one underground box to the next with a little hand on each arrow. And that represents sort of time goes left to right. And each time you make an edit and get a new state of your program back, that's a new box. And only some of those boxes may have flowers or all of them might. It depends how reactive the system is to your feedback. And the granularity one here seems to be like a static snapshot, right? We're not getting across time because we don't have these little like edit things.

So I think what Jack mentioned makes perfect sense in, you know, doing a bunch of closure. You find this ability to, you know, edit a small amount. But I think granularity here is not about what you can edit, but what you can get feedback on. So the examples that we get are stuff like, you know, in Brett Victor's Inverting on Principle Talk, the user edits code on the right hand side of the screen. and as they do, the left instantly updates. But like all of the internals of the program, it says intermediate values, control flow, et cetera, remain a black box.

So even if you could like edit at the most granular possible level, you might not be able to get feedback at that level. I'm definitely not talking about editing to me. So I'm talking about being able to evaluate those subcomponents, which is how you get feedback on them, right? You can inspect what values they have in them. You can run their computations again. And you can potentially put skin them with different visualizations on top.

This is a mechanism of feedback and not merely a way to change the code. Well, I get what you're saying, and I'm not disagreeing. I guess what I was thinking that you're talking about is being able to evaluate an expression. And you could imagine evaluate an expression and you get no feedback on it, even though the live running program now has your changes. This would be surprising, right, if you didn't get something back. Even in fairly primitive rebels, you get something back when you evaluate it. You could just be re-evaluating the function, right?

So you're re-evaluating a function, and now there's some tight loop calling your function. And, you know, you might not realize whether it's calling the new version or not because you didn't get feedback on the fact that it is. And also the feedback, when you evaluate a function of knowing that it was able to evaluate the whole function without error is helpful,

because you might be editing the function, you want to know that you'd make some sort of semantic mistake or syntactical mistake in the function that you just edited. And just seeing that it worked in that sense is already a kind of feedback. Yeah, absolutely. I was just trying to make that distinction that you could imagine,

it would be a very poorly designed system, but a system that lets you do those granular evals, but doesn't tell you whether it succeeds or not. And then that would be one that has... This would be terrible. Yes. You would have a system that has very granular of editing the live dynamic state of the program

without getting feedback on. Only side effects. Just side effects. No. no actually useful information. And I think just earlier, Jimmy, you made the point that there's a difference between the dynamic behavior of the program and the static version of the program. And I have, speaking of like, you know, being able to run the program to even know if you have an error in the program, I had an experience writing Swift, or I frequently, I should say, have an experience writing Swift where I go to make some little change just to, you know, maybe comment out some code. or something like that. Maybe I put a return in. Yeah, let's go with the example of a return. I put in an early return because I just want to see the first half of a function and what it does and ignore the later stuff. And Swift goes, well, hey, there's dead code down here. So we're not going to actually let you run the program. Like, we're going to block you from running the program until you fix this error that has no influence on the dynamic behavior of the system. It's just about what have you done statically. It is like too much of the handcuffs of the static world.

view, as I'll call it. Yeah, Go does this too. If you have an include, you don't use, you can't run your program. And maybe the include isn't used because you commented out some debug that requires the include, and you're going to have it right back in a moment, but you still have to edit your program to run it again and find out what happened. It's a terrible. Yep, yep, yep, yep, yep. So the examples that Josh gives of granularity are three examples. There's Brett Victor's talk inventing on principle, where it's a, as I call them,

Lisp on the left, but in this case, I think it's JavaScript and it's on the right, unfortunately, of this little canvas, like 2D canvas drawing of a cherry blossom tree with the pink flowers. And so there's these sort of fractal branches coming up with these pink flowers at the tips of the branches. And in the talk, Brett shows that you can make edits to the code and the drawing updates immediately. And so that is an example of feedback that is not very granular because the only feedback you're getting is what is the full result of the drawing. You're not getting feedback about anything else in the code. And then the next sort of more granular example is an observable notebook where the notebook is split up into a bunch of different code cells. And you can get some information about the code in each cell, sort of like maybe a spreadsheet or something like that where you can get a value from each of the cells.

But in observable, the cells are much bigger, right? There's many lines of code in that cell. And you can get some feedback about what goes on when that cell runs, but nothing, you know, about. what's within the cell. And then the third example is something called projection boxes, where you're getting feedback about the values that appear on each line of code as it's evaluated. And I don't, I'm not familiar with projection boxes. This one, this one's new to me. I feel like I should go dig into this. You also see this in, you know, Brett Victor has an example of this kind of thing as well in one of his things, right? But it's really just showing you the control flow of the program,

showing you what values have been and what variables. And I think this is why I have trouble with this, like saying it's about, I get where he's coming from, saying it's about the internals of the system. But I guess part of what I think of as the internals of the system are also the very thing giving you the feedback mechanism. And that's not at all what you get. And so maybe it is the internals, but I don't know. It's more like seeing the values in your code seems to be the granular.

thing here. But like I also think about like the Brett Victor one. Like he has it where you can, you know, highlight on the left what pixel you're on and you could see the code. And that seems like a clear example of granularity as well, even though it's not. It's kind of about the internals, but not exactly. So chorus, by unmuting yourself and shouting either yes or no, are you familiar with projection boxes? Is this something you've seen before? Three, two, one.

No. Nope. Brooke, why do I hear water in the background of your... That's my cat's water bowl. Oh, cool. It's a very nice, pleasant little babbling brook as it comes over to Zoom. It's a thematic with my name, indeed. Uh-huh.

Yeah. Nice. Nice, nice. So that's granularity. Jimmy, any other thoughts on granularity before we move on? Besides, you know, talking about the actual thing here, right? Like what is said in the text, like the actual idea of granularity, I think is a very important aspect of live feedback. I've worked with systems that have some sort of live feedback mechanism, but like the thing I want to see is hidden, right? Even if it has these other dimensions, it's like, well, I can't see this bit. And so, yeah, I think I think this is actually one that like that's one of the reasons I was a little sad on how it's described because I feel like it's kind of,

kind of super important. And it's something where there's this interaction in my mind between the code that you're writing and the system's ability that actually comes into a lot of play here. This is what I was talking about, like the way people can write closure code. Some people write it without these kinds of nice live systems. And when they do, their code doesn't have a structure where you can get this granularity of feedback. It has these big, huge chunks of code that can't be evaled in and of themselves. They're not self-contained.

And so I think this granularity can actually really, like, change the way you structure your code. And that's why I think it's probably one of the most important aspects of life feedback to me. Yeah, Jimmy is, I agree with you 100% there. And also, there are some things that fall out of it naturally that if you build your program so that you can evaluate little chunks to verify they do, or at least to find out if they do what you think, they do. You also have tiny chunks that are very easy to test. and you tend to have a certain kind of bottom-up modularity that lets you switch pieces out when you need to, rather than locking important functionality inside of larger boxes, so that people have to then sort of reinvent them outside of the boxes in order to get variations of behavior from your code.

So, yeah, this kind of structure, this question of granularity is, I think, very important, with or without interaction. And I would say, I'm going to give some feedback on the course. I would say that the course is doing a good job of being granular in their feedback so far. So round of applause for the course. Thank you. Next section is reactivity, which is how often are changes to a program responded to with feedback in a live system. This is the dimension of reactivity.

And this is something where I'll say the chorus is maybe not doing a great job of being reactive. We're almost never being interrupted mid-sentence. You're all being very respectful and kind. And directly flying against the don't be shy directive. in the instructions. So I wonder if we need to make a rule change here. I'm going to come down and I'm going to add an additional rule which says interrupt us mid-sentence. And the rules may change it anytime. We'll see how this goes. Yeah, Jimmy, thoughts on, or do you want to tee up reactivity and kind of explain a little bit more about what it is and some of the examples? I mean, I don't know.

I think this one is, the visual here is quite easy to see, right, if you are looking at it, which you're not a podcast listening. See, this is why we'll never switch, we'll never switch to video just so I can continue to say these kinds of things. Yeah, this joke will never get tired. Uh-huh, yeah, so, so what we get is these,

in the first thing, we got two flowers. On either end, we got four boxes. And those boxes were created by punching each of the boxes with a little hand, a little karate chop punch. And that's our edits. And so we're trying to like edit things. But like sometimes we're editing things and not getting any feedback on our edits. So this is reactivity here.

That would be low reactivity as you get. Yeah, yeah. You do some edits and you don't get any new feedback. And then the other option is you get lots of flowers. Because you're doing lots of edits and you get lots of flowers, which are your feedback. Right. So that's, you know, the more flowers you get in life, the more reactive your live programming system is. That's what I learned from this little section.

There's a sentence that I underlined and wrote, yes, and put a very messy asterisk next to, which is, With reactive feedback, programming begins to feel more like aiming a water hose than aiming a bow and arrow. Which I love that image. I love that mental image. That's great. Like continuous versus discrete. It's got that in there. It's got a, it's like you can remember the feeling of doing either of those things, shooting an arrow.

And I guess the arrow has the additional advantage where if you're not naturally gifted at it the way I am, you miss all the time and you aren't able to defend your home from invading. Are you a naturally gifted archer? Yes. When the Ostrogoths come and raid Alberta, I'm going to be ready for that. I'm going to fight them back. You mean when the rats come and invade Alberta? No. They're already here.

It's my prediction already coming true. Yes. Yeah. So, yeah, I think this one, you know, it's about like how often I edit do I get feedback. So you could do it like on every single keystroke. You immediately get feedback. That, of course, comes with problems. And this whole section talks about like kind of this various range of ways and choices that you might have for how often you give feedback.

The thing that I find interesting about this one is that. it's, the reactivity does have an interplay with like your actual language runtime. And I guess with how you write your code, but way less than granularity. Hello, welcome to the feeling of computing podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role a surprise guest is to give, bleh, your role as surprise guest is to give Jimmy and I feedback on the podcast as we record it. You may do this at any time as much as you want. Don't be shy. Thank you. And now, back to the episode, except there are two additional rules that previous feedback has produced. One of them is that if you leave and come back,

I'm not going to reread this spiel. And the other one is that you must interrupt us mid-sentence. The chorus are being too kind. Okay, I will do that. Thank you. They're not being reactive enough. We're going for whole spans of 30 seconds or longer without anybody making any noise and derailing the show. This is not very reactive feedback, and it is not proving Josh's point correct when he says, however overreactive feedback can be dangerous. Code usually moves through invalid states on the way from one valid state to another. I was looking at that exact section, and something I was thinking about with reactivity is like reaction distance. When I make a change, what do I expect the reaction to be and how far do I expect that reaction to propagate? And I think this is very much a me problem,

but I think it's like a, I've touched a lot of things where it's like, oh, that went, I was expecting that to go further or, wow, that went so much further than I anticipated. And I'm like 67 dominoes deep when I thought I was going to be three. So there's like the little like karate chop that Jimmy was talking about. This diagram makes it look like there's a chap and then there's a change. There's a chop and there's a change. And there's never like a chop and like there's 30 changes down the road. and that's what I'm like, how does distance or depth relate to reactivity? Yeah, there's never like a big flower and a small flower, right? Very much unlike guitar, where if you play a guitar, you know, away from your amp, it's not very reactive.

And then if you go closer to the amp, oh, it starts to get a little reactive. And you get right up to the amp and it's like, whoa, we've just invented like 10 new genres of music. And I think to your swift example, I often have the experience of like, I change. changed a prop. Oh, wow. The whole application has failed in like remarkable ways as opposed to like this one change failing. And it's like, it tends to be a documentation error. You know, it's not like a value is in the wrong order, even though it's named. Why has this hugely exploded my iOS application? Hello. Welcome to the feeling of computing podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role as

surprise guest is to give Jimmy and I feedback on the podcast as we record it. You may do this at any time as much as you want. Don't be shy. Thank you. And now back to the episode. But there are actually additional rules that feedback has produced. One of them is that if you'll even come back, I'm not going to reread the spiel. And the other one is that you must interrupt us mid-sentence. All right. Yeah, I think this like a blast radius of reactivity is really interesting. I think also you can see how systems that are overly reactive not only have some of the dangers or whatever that there's invalid programs indiscriminately executing. But if you accidentally have a lot of granularity, you make a change. And then it turns out like, oh yeah, that granular change made it so I

create, I don't know, five gigs of data that I'm now trying to visualize. The reactivity all of a sudden drops drastically because, you know, everything's frozen. Or you're computer crashes, the number of times I've evaluated a form and a REPL, and then my computer crashed was, it has, is more than zero. So I've done some very dumb things that, you know, you don't think about the fact that your, your thing's going to have a big change. And I also think about like, you know, even though this is type systems and not dynamic, you know, you make one change that now breaks like types across, you know, 50 different files. And sometimes it would be really not, to have, like, yeah, sometimes it would be really nice to have a limit on the blast radius of what reacts.

And you could think of that system as being dynamic because it's running the type checker or something. Anyways, I think that's an interesting dimension. I don't think, do you think, Ivan, that the blast radius here has any, do any of these dimensions talk about that? I feel like they don't. Yeah, one of them, where is it? There's one of them later on that talks about kind of like, you know, limiting side effects and that sort of thing. I can't remember where that comes in. Maybe that's under velocity.

Materiality. I thought about that one. At the same time, that's, that one I want to get back to in the chat. I saw materiality. It could be Blastratius, but it's kind of like in the opposite direction. I think it, materiality and bidirectionality are a little, I'm still questioning materiality. if it's real or not. Oh, well, we're going to have a fight

when we get to materiality. Oh, boy. I might be an idealist and just think that all the world are just impressions that we have. You know, there is no material world. Barclay really got it right. And that was...

Barkley. I thought you were doing a Plato's Cave thing. Plato's Cave, yeah. Yeah. Yeah. Yeah. Yeah. I was disappointed in this paper.

that it didn't sort of extend the DNA of materiality back to Sketchpad in 1963, because I feel that's really where it starts. All right, I'm interrupting. We're not talking about materiality until we get to materiality. I have to be the format cop. This part of the conversations remind me a little bit of, you know, if you're getting overwhelmed with the amount of feedback and information, it's a little bit like turning your log level too high.

Does the paper talk at all about like making that adjustable or basically setting flags and something like I want to know. know about this, I want to know about that, but like not other things, getting more of like a sketchy view versus a detailed view, you know, versus having something like, you know, a fully observable, you know, down to each, you know, running process view, you know, with dashboards, right? Like, you can, there's many different levels of, of detail that you can get here. And this, at least so far, I haven't read the paper, at least so far, has felt very sort of like, you know, you've got to hit the right balance.

And this is the, you know, where we're trying to find how much is too much. and sometimes the user will need to know more or less. Maybe it's this stuff, maybe it's the granularity up here. Yeah, but is it exactly that? I feel like... I would like to point out that the format of the podcast that you have invented, Ivan, does not really correspond to the idea of the paper

from what I've seen that well, because if you build a reactive system in code, the reactive system already knows what it's going to be reacting to, whereas I came into this podcast purely unknowing. And I think it would be interesting if you could build a software system where the reactive components have no idea or no understanding of what the system they're reacting to is.

But I am not a software component. I am a human. And so I have to build up the context of what I'm reading before I can react. Are you sure you're not a software component? We're starting to make software components that are people. Are we sure we're not making people that our software...

That would be the... Hello! Welcome to the feeling of computing podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role as surprised guest is to give Jimmy and I feedback on the podcast as we record it. You may do this at any time as much as you want.

Don't be shy. Thank you. And now back to the episode. There's one other person who's just sitting there with the joining dot dot, dot, dot, dot, dot. So there's one in the chamber. It's gonna, you know, might pop off at any moment. So if you got a thought,

Keep it popcorn sized. This would be way lamer if you had AI bots coming in interrupting us instead of actual human beings. Jimmy, you should know me better than that. I would never, ever, ever, ever do something like that. Jimmy, you should know me better than that. I would never, ever, ever do something like that. Jimmy, you should know me better than that. I would never, ever, ever do something like that.

But I will say, Arcade, I think the point that Ivan wants is not for you to react to the paper, but to react to us and say we're doing a bad job or a good job. That's his real goal. Which they did. Yeah, they said that I did a bad job setting up the bit, which is perfect feedback. Uh-huh, yeah. And, you know, it doesn't have to be on this paper or anything. It's on the podcast, right?

So the podcast could be taken more, you know, you all talk about whatever you want. But I do think that Brooks Bricks write about this In some ways it's granularity But couldn't you have something Where the system Gives you yes You could have it so you change configuration

For granularity But it also could be that like It starts a broad overview And as you zoom in You see more and more of that detail And that feels quite distinct From like what's talked about In this granularity being like

The internals of the system It's like the fidelity right of the feedback right like it's like something like oh well it might be you know right now I only see like a few pixels but like as I zoom in I get more and more detail and it kind of unspirls out and so like it was always there potential in the feedback I was getting I don't have to cause new feedback it's just that it you know it's a richness of the representation which I think would be an interesting one reactivity is the only one where Josh says that um that it's a matter of information design, right?

That like, but I think that that applies to everything in this paper. Like, everything in this paper is, and I, this is an area of deficiency, I think, in the paper is it doesn't go far enough into saying that like, so much of what makes live feedback valuable or frustrating, useful or unhelpful is down to the question of how that feedback is designed. And I think that these different dimensions give us some axes along which to vary. They give some suggestions as to things we should do. But it doesn't really look at, I think, in the sort of detail that I would like, how the design of different systems, maybe taking two systems that are similar in some sense, but different in some other sense in comparing their design decisions, like how that affects the quality of the feedback you get and the quality of the programming experience. I think the podcast is going very well. Hello. Hello, welcome to the feeling of computing podcast.

This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role of surprise guest is to give Jimmy and I feedback on the podcast as we record it. You may do this at any time as much as you want. Don't be shy. Thank you, and now back to the episode. Did you stutter the times you told people to show up?

Yes, I did. Okay. I have also released a, I'll just, I'll spoil the bit a little bit for everybody who's here. I have posted on social media, and I have released a special time-limited episode to the main feed that is one minute long telling people to join the Zoom. Hey, so this is a really unusual episode, as I'm sure you can tell from looking at the runtime of it. If you are listening to this, within, say, an hour of it being published, we are recording an episode right now, right, right, right now. And I am running a social experiment within that episode that Jimmy, of course, did not know that I was going to be doing in this episode. So if you want to participate in this social experiment, what you need to do is go to your computer or mobile device and open the URL, I-V-A-I-S-H-I-V-V-A-V-A-S-H-I-V-V-A-S-ZoM.

Go there right now, if you're within like an hour of this episode, going live, and you will get to participate in a live recording of the feeling of computing podcast. What do you think? Was that good, or should I do it again? Good. Good? Okay, great.

It's just really funny what you're doing. So we'll see how many people we end up getting. But yes, this was a delayed release capsule of a chorus of live. back, yes. Velocity. This is where the visual language goes off the rails for me. I don't get it at all.

I understand the joke of like the flower, wind is sending the flower, but I don't understand what it's actually supposed to mean. Oh, I don't see wind. Why is the flower bent? It's like how how long do you wait for the flower

to, yeah, okay, I guess me. I don't know. Why is the, why is the flower? flower bent growing towards the sun. You know what it should be? It should have a little edit action, and then you have like a little sprout, and then the sprook gets a little bit bigger, and the sprook gets a little bit bigger, and the sprook gets a little bit bigger, and a little bit bigger, and a little bit bigger, and eventually there's a flower. And it's like, God, we had to wait so long for the flower to bloom. That could make sense, but like there is no flower on the second part. There's just a,

it's like it, so, okay, for people who are not seeing this, there's two blocks and the ground and the flower, but on the left-hand block, there's a flower with a big, long curve. This is the slow. Stem, big long, parking stem. Yeah, but like going towards the other block. And then whenever you're faster velocity, it's less arched and the blocks are closer together. But like, why wouldn't you get another flower?

Why is one flower reaching? I think it may just be that they want to keep it in the same bounding box. Yeah, but look at all that empty white space to the right. But Jimmy, could you speak more through your favorite philosophical lens about the validity of the taxonomic differentiation between reactivity and philosophy? It's time for Jim's philosophy. A stinger just played. I think that we could make the flower more real. Yeah, I don't think any of this is real, right?

This is a weird dream I've been having. So, yeah, I don't get the picture at all. I get the idea. So how quickly after an edit is made is feedback available to the programmer? And then we get told that this is different from everything because it's always better. And that I just fundamentally disagree with. How so? Okay, so I won't come up with a good programming example.

But right now, off top of my head, but I will come up with a real-life example of like, sometimes you don't want feedback on something right away. you want to try things, you want to be able to think about things, and having that feedback immediately can actually stop some of your thinking process. Sort of like you want to go through several invalid states, get to a correct state and then get feedback on the correct state rather than like, you know, type in your email address and you type in your email address and then it's like, oh, you're missing the at sign. It's like, yeah, I know, I haven't gotten there yet. Slow down.

Here's a great example. I got a programming example. All right. I know this is not the dynamic thing, so it's not live programming, but it still works. Autocomplete. I don't always love my auto complete to instantly pop up. If I'm in the middle of typing things and auto complete starts typing up and it's wrong, it is just bad. It is worse. But that's not feedback on the dynamic state of the program. That's feedback on static text stuff that is like only disconnectedly related to the dynamic state of the program. Wouldn't a user be typing be dynamic state? The state is changing dynamically. But the dynamic state of the program you're making? Well, I would say that the user input is part of the program.

What if I'm making my own autocomplete? Now the episode is going to be hard to edit. Until we had to overtalk, the episode was going to be easy. Now it's going to be hard. Well, if they're allowed to interrupt mid-sittance, why am I not allowed to interrupt mid-sitance? Yeah, no, they're allowed to, in fact, the only nightmare will be if they start interrupting each other. Because Jimmy and I, I can disentangle our crosstalk because we're getting local recordings of each of us, but y'all in the chorus are one audio track.

But it's in the rules. Unfortunately, it is in the rules, yes. The rules. Ivan, maybe you should have had us create our own audio files. Yeah, that would have been simple. That would have been easy to set up at short notice. Yeah, everyone by audio hijack, which is what we use to do this. Everyone in the chorus join in.

I am Spartacus. I am Spartac. Come on, everybody. I am Spartacus. This will be great for Ivan. I am Spartacus. I am Sparta. I do have an opinion about the flower or a thought about the flower. I think that what's happening here, if I understand it, is that you type whatever causes the state of the left box. And now you're working on the state of the right box. And it takes a while for that flower, the feedback to appear, right? And now it's already cool. Oh my gosh. I finally get it. Thank you. But I do want the flower to not grow up. I guess. drawing out of the left box is like, yeah, it's the feedback in response to those. I think it would be more clear if they drew the flower over the second box, so it'd be more clear that the flower is talking about the first box, but the second box has already happened

and now it's out of date. Or like, wait a second, I just realized I can draw and you all can see this. If the box had the line coming out to the side and then the flower came up. So it's like working, working, working, okay, your feedback's ready. Something like that. Yeah. Yeah, I finally get it. That makes sense.

I didn't understand at all. but now, like, I get what it was trying to do. I still don't, yeah, maybe the paper needed to come. This feedback on the paper, it needed to come with Daniel to interpret it for me. The fact that I didn't have that out of the box is a problem. Yeah, I don't know. There's times where even like on dynamic, the state of a dynamic program, having that feedback immediately can be a distraction if I'm still in my head, right?

And sometimes I want, like, you could say that like, oh, it's not velocity, Because like... Would you say feedback like this is distracting? No, I would say that that feedback's fine because he was at a good point to stop. And that's why I underlined down near the bottom, how can a user comfortably control the execution of their program as they make edits?

Like, you want to be in control, right? You don't want out-of-date feedback. You don't want feedback to proactively. You want to be in control of when you're getting feedback on the program, which of course is what Hess is all about. You can say that I'm confusing reactivity with velocity here because maybe what I'm really saying

is like, oh, if I was, as I'm typing, but that's reactivity. But like, once I ask for feedback, whatever that granularity is, I might want it instantly. And I guess you could try to say that. I still think that this feels a little overzealous to say that it's always better to have faster feedback. I do think there's cases where a delay can actually help you understand something. And I, maybe I'm wrong. Maybe if I thought about it longer, I would disagree with that.

But I think in real life, I often don't want feedback on my things. And I often, even when I ask for feedback, I want a moment to think about it. And so I don't like things to go in so fast. Hello, welcome to the feeling of computing podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role a surprise guest is to give Jimmy and I feedback on the podcast as we record it.

You may do this at any time as much as you want. Don't be shy. Thank you. And now back to the episode. And for all you new chorus people, I was not in on this bit from the beginning. So this is all new for me too. But please feel free to. I do have feedback.

We're missing a critical amount of Lou here. Yeah, hey. I agree. Yeah. Lou exists. That's, I can say Lou exists. The list of things that do exist, Lou. Yeah, yeah.

Let's talk. Yeah, this section I think is, is disappointing to me because it's mostly just a section that talks about incremental computation as a way to make programs give faster feedback. That's really all it's about. It's like four paragraphs about incremental computation, which I don't know, at least 50% of the podcast doesn't give a hoot about incremental computation. I want to apologize for the velocity of this, but you have stopped reading the additional rules for some reason. I don't know if that was intentional or unintentional. Additional rules. If someone leaves and comes back, I will not say the,

welcome speech again, and the chorus must interrupt us mid-sentence. I think you need to read it twice more because of the three times that you didn't read. Additional rules, if someone leaves and comes back, I will not reread the introduction, and the chorus must interrupt us mid-sentence, and the additional rules are that if somebody leaves and comes back, I will not reread the introductory welcome speech, and you and the chorus must interrupt us mid-sentence. Yeah, I think incremental computation, though, is like a super-interesting topic. in and of itself.

And, you know, being able to give feedback faster, I don't think necessarily has to require the incremental computation or even that the computation is fast in order to give feedback. That's one of the things I found is a little disconnect here. You can give feedback even if the answer hasn't been computed yet. You know, I think about, like, when I was trying to analyze all those chess positions to make my own little opening book for the chess bot that I was making, like I didn't have, it's not going to be done.

I had, you know, hundreds of gigabytes to process through. But when I first wrote the program, it didn't give me any feedback at all about what it was doing. And I was like, how long before this is done? But having it frequently give me feedback was, you know, still valuable, even though it's not done with the computation yet. You're doing great. Look, even I can do it.

Hello, welcome to the feeling of computing podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role is a surprise guest is to give Jimmy and I feedback on the podcast as we record it. You may do this at any time as much as you want. Don't be shy. Thank you. And now back to the episode. Additional rules. If somebody leaves and comes back, I'm not going to reread this. The person who just joined has given themselves the slack name,

oy-oy, what's this about then? Ooi, what's all this about then? If I do it three times, maybe I'll get a good one. Ooi, what's all this about then? And I think that it might have been somebody who left and came back with a changed name just to throw me off, which is really turkey of them. And then the other additional rule. I would like to correct you there. You said that was a slack name, but clearly we're using Zoom. Okay. You're correct. It is a Zoom name.

I am in too many windows right now. That's nice. So I think we actually got a person that was not, yeah, that did not leave. They said, no, it's not a person that left and came back to try to trick you. That's nice. Wow, we're both speaking in such complete, comprehensible normal sentences right now. Uh-huh. All right.

Moldability. I didn't read the second additional rule, which is that when people join, they're supposed to interrupt us mid-sentence, or when they give their feedback. Yes, moldability. Yeah. The visual for this one is there's the ground plane. There's two little edit boxes above ground with flowers coming out, and there's kind of two versions of this graphic. One of them where the flowers are the same. They're both little purple flowers.

And then the other one where it's like, actually, one of the flowers is different in a special way. So here's where my custom software that I... built, well, you know, Claude built for me, but I built to highlight this stuff is bad. I have one color that I'm not happy with, which is my red, which happens to be the highlight I have here, which

made it look like this image has no differences. And the two things are exactly the same, because the red happened to tent out the fact that the colors are different enough, that it was just like, wait, what is this one again? Why are there just two flowers on both sides? So, yeah,

I'm gonna, I need to erase live, can I do it? That is actually one of the failure modes of malleable software, that you can make changes to your own software, and then somebody else can make changes to their software, and you can both be working on it together, but seeing different things, and then talking to each other and be like,

oh, just go click the thing that's purple, and the other person's like, wait, I don't have a purple thing. And then you go back and forth and back and forth and realize, oh, yeah, we both made changes to our software that render them incomparable. Well, yeah, so this is, the way they do moldability here is interesting because it's, how can feedback be shaped to reflect domain-specific meaning? I find that one strange as a definition. I don't know why it has to be, how can feedback be shaped to reflect domain-specific meaning? Because to me, moldability is about how can the end user change the software?

No, that's malleability. That's, that's, malleability is usually the term. for like the end user changing the software. I think that if they had wanted that meaning, they would have said malleability, because I'm pretty sure Josh knows that term. I mean, then we get the next sentence, though. But this is moldable in the like... It has to be presented in a way that is meaningful

to the programmer-specific context. Yeah. And then we're talking about a feedback is moldable when a programmer can change its appearance to reflect the needs of their particular use. So I think that's literally exactly what he's talking about here. Yeah, but I mean it's... I think you have some...

duties here. Yeah, I know, I know. I'm waiting for the other one to join. There were two who joined, and then I said, admit all, and now one of them joined and one of them's waiting. And then I will do my job. Okay. But so this does look like... All right, I'm good to do it one and then the other. Hello, welcome to the feeling of computing podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role is a surprise guest is to give Jimmy and I feedback on the podcast as we record it. You may do this at any time as much as you want. Don't be shy. Thank you. And now back to the episode. But there are some additional rules. If someone leaves and comes back, I will not reread this introduction, and you must interrupt us mid-sentence.

And I'm actually going to rearrange these rules because it makes more sense if that comes after that. There we go. That makes more sense. And now back to the episode. So it does mean malleability in the sense that you used it for moldability. Hmm. If you continue reading, right? So it's about being able to change it.

But like, it's about domain specific. And I just find those terms domain specific to be, uh, a strange choice rather than just like, how can the feedback be changed by the programmer, by the developer, by the end user, by, you know, the person making the software? Well, isn't it about like what kind of application you're working on at the time? You know, as one developer, you're working on different types of projects and you're going to want different feedback depending on that context. I mean, that's just how I understood it.

Yeah, I guess I just don't see that as domain specific rather than moment by moment, personal preference specific, right? That I guess was what I was objecting to. But wouldn't you want sort of a general thing like, okay, I'm working in JavaScript now. This is, because that's the example you have it's right here, right? The JavaScript data or whatever.

Like, okay, I'm working this kind of project. It knows that for this type of project. These are the pains that I want to have. This is the feedback that I want to get. And then I'm going to go into a different type of project. I'm working on something, a different kind of application. And I'm going to get different set of application,

like of feedback. Yeah, what I'm imagining, I guess, on that. Like, imagine, I have, I haven't a thing that anytime I do math, it gives me this domain-specific math view, right, that shows math in its nice little typeset format. I would call that cool. I wouldn't call that, and like, let's say I have multiple representations that are precanned, right? But they're all domain-specific for sums and for blah, blah, blah, blah.

That doesn't seem moldable to me, right? It seems like it's a nice property to add domain-specific. views, but moldable to me means like I'm able to edit the system itself. I'm able to change it in an arbitrary fashion. Obviously it's a spectrum here, right? But like the more moldable, the more I'm able to change it in an arbitrary fashion. Yeah. And that might not be domain specific. I might not want it to be domain. I might be like, you know what, today, I'm in a moody mood. And I want this to be like a gothic themed visualization rather than uh something useful right yeah well i think it's it's yeah the fact that it's domain specific is i disagree with but the general idea of like

yeah yeah i want to make changes not to my editing environment because we have that right we have the ability to theme vs code we have the ability to add you know uh quoka whatever it is that extension that like live evaluates your javascripts you as you're editing it, that kind of thing. We have those kind of things. What we don't tend to have is for tools that do provide feedback about the dynamic behavior of a system, the ability to go in and make changes to that feedback in some way.

And I think glamorous toolkit is like the one shining example of a system designed to let you do that. Yeah, I mean, their whole thing is moldability, right? Yeah. But I think you could also make arguments for, you know, I don't know, EMAX? Yeah, I suppose, yeah. Though, like, what glamorous toolkit has is it is, and EMAX has this a little bit.

Jack's no longer here, so I can say shit about LISP environments. Oh, yeah, but Brooke, you're here, so you could drop some EMAX science. But, like, EMAX is different from a small talk, I think, in that, like, small talk is very, very deeply meant to embed you inside the running environment that your program will eventually run inside of while you're developing it and that you're meant to... Well, what if you're developing Emacs?

Then you're a bad person? Then you're a monster. I mean, this is a obviously broader conversation, but like, yeah, I mean, in Emacs, you can live edit your environment, but then that also comes with other tradeoffs, right? Like, you can completely break your environmental

these other things, right? So having some constraints on it, you know, having a toolkit that says, like, this is feedback and here's kind of, you know, the degrees of freedom you have might not be the worst thing in the world. Yeah, this is one of the things that I find is a limitation of the podcast format is like I would think it would be really interesting to dive into the technical details of some of these small talk systems and the ways in which they allow you to edit the system. And then there's been some papers on like, uh, how do you do that safely? How do you edit a live

running small talk and give you full control ball also not breaking your environment? But I feel like that in a podcast format would be very dry. You know, like, if we're talking about all the technical details of like, how does this work in the, and trying to understand it all. That's why we have to have these papers that are a little bit more like overviewy, a little less technical. I just don't, maybe it could be done, but I just don't know how to do it. I want to, we have two people unmuted, so I'm worried that they might share some feedback mid-sentence, but I'm going to start talking and we'll see what happens.

Living dangerously. I want to take us on a short tangent here because there's an example. that Josh has in this section that is related to something that I care very deeply about. And so he has this example. Tobias, I'm going to mute you. If you want to be unmuted,

feel free to say something in the chat. I just hear some background noise. I don't know. That was some good feedback. All right, fine. We'll stay in the show. No, you can, you can, you can view. So there's this example

that Josh has here to show multiple feedback, which is from his program tool pane, which is a node wire programming environment where the nodes give you like live previews of the result of each operation. And then the wires, the edges, the what are they called? What are they called pipes and junk or whatever? Junk and pipes. The pipes. Actually, I'm going to interrupt myself. If you don't get that joke. If you don't know what that joke is, you need to go to feelingoff.com and sign up for our goddamn Patreon. We have bonus.

episodes over there. Like and subscribe. Leave us a comment in the chat. I have feedback and that's, I'm a broke student, so I'm sorry. Oh, no. Okay. If you're a broke student and you want to get free access to the bonus episodes, what you need to... Hello, welcome to the feeling of computing podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role a surprise guest is to give Jimmy and I feedback on the podcast as we record it. You may do this at any time as much as you want. Don't be shy. Additional rules.

If somebody leaves and comes back, I'm not going to reread this introduction. And you must, must interrupt us mid-sentence. Thank you. And then back to the episode. Yeah, if you, uh, this goes for anyone. If you can't afford a subscription or whatever to the Patreon and you want access to things, just messages and I'll send you a, I can make free codes. Can make up to a thousand.

So if I, if we get past that, there's a real problem. But other than that, I'm pretty sure that's my limitation. So sincerely, just message me and I'll send you one. That's the student discount. And we are all students of life on this beautiful planet that we share. So I want to take us on a short tangent, which is to talk about a thing, and I'm going to talk about pain first. I forgot how I was setting this up. So in this pain environment, you've got values in nodes, and then you've got these wires, edges, whatever you want to call them, lines going between these nodes.

And the lines are your code that's transforming the values. And so you might have a number and then a little arrow that's like plus and there's like two little arrows going into the plus and then a and then those go together into a third box that gives you the result of plusing together those two numbers. It's a nice little twist on the familiar node wire visual programming paradigm. And in Josh's example, he shows two screenshots from pain. One of them shows vectors represented as little structs or dicts or whatever where you have like X, 6, Y, 4 as your value. and it, you know, you can see the data, but you can't really see the data. And then there's another example where he has a custom visualizer, where for each of these little vectors, it's an arrow pointing in the direction with a certain length.

And that's cool. Questions I have are like, how did he make that custom visualizer? Did he make it inside of pain? Probably not. That's a dimension, like a design dimension here that I think is super, super important, is can you augment the tool from within itself? If not, is it really moldable or is it just like, you know, got a plug-in system, you know, plug-in systems, boo, editing stuff from within, yay. That's quality thought here on the feeling of computing podcast.

But the thing that I wanted to share, the tangent I wanted to take you on, is to talk about a little thing that I'm working on called Trappdoor, which is a little visual programming environment that I'm working on that is really interested in answering this question of like, what, what, what, could we do with things that are about vectors and points in space and programming those kind of things that does better than just show a little box with a number for X and a number for Y or even just show a little box with an arrow pointing in a certain direction? And the idea of Trapdoor is that you just, you have this canvas in space and you have points in space and you can take two points and say there's a vector between these two points. And all of your points and all of your vectors live in the same canvas and you have this nice big canvas environment to do that you know that working with points and vectors inside of you know what you need then is you need a way of saying like

how does the system evolve over time and what josh has in his example is like these little boxes of these little isolated vectors and what i want in my system is actually that time is the z-axis in this environment and so to go to the next step in time you don't have like a little separate box off to the side like a comic book panel. Instead, what you have is like a little, like a layer in Photoshop that comes in on top of what you are already seeing on the canvas and now lets you say, okay, we set up this configuration of points and arrows. Now let me set up another one based on that first one and then another one based on that second one. So this is, this is something that I'm just beginning to work on. I have a very bad running version of this code, but it's,

it's something that I wanted to share because I want to flag that this way of doing visual programming with vectors as node wire where they're kind of sprawled out in space, I want to flag that as like an enemy that I want to slay. Because I think that vectors in these little boxes isolated from each other are just as meaningless as the numbers labeled X, Y, and that sort of thing. Because you only get the lightest sense of comparison between these vectors, right? Like these vectors, vectors can be wildly different lengths. They can be very subtly different lengths. They can be going in wildly different directions.

They can be going in very subtle different directions. And you need a whole bunch of additional augmentation to make vectors meaningful in space. And so I've seen a couple of examples of systems where it's like, we're going to do the comic book style where they're separate. And I think that that is the wrong way to approach what I call programming stuff in space. What about the Brett Victory style? You have all the boxes, but when you hover over one of them, you see it displayed on the others. Then you would get the kinds of...

Right, yeah, the like in apparatus, right, with the spreads where it's like, oh, I can see a sort of a like split-out version that's showing like ghosted images of all the other values that this thing could have. Um, hello, welcome to the feeling of computing podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role of surprise guest is to give Jimmy and I feedback on the podcast as we record it. You may do this at any time as much as you want. Don't be shy. Additional rules. If you leave and come back, I'm not going to reread this spiel. And you may interrupt us, or must, I should say, interrupt us mid-sent. Hello, welcome to the feeling of computing podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role of surprise guest is to give Jimmy and I

feedback on the podcast as we record it. You may do this at any time as much as you want. don't be shy. The additional rules, if you leave and come back, I'm not going to reread this spiel, and you must interrupt us mid-sentence. Thank you. And now back to the episode. Yeah, that's one way of doing it, but I still think it has the problem of, like, not, like, it's cramming you into this little tiny space, which is a very text way of looking at the world. Like, text is a really compact way of representing something, right? Like, you know, baby shoes for sale never worn, right? That's a really compact thing you can put in a box that explodes out to a much bigger meaning

and spatial stuff doesn't work that way. So if we're going to get... What was that phrase? The real visual programming revolution. You can't do it by stuffing your stuff into little boxes. Death to boxes. Bate?

For sale, baby shoes never worn. Okay. What did I say? Did I say never opened? I don't even know what you said, but I don't know that phrase. You said, for sale baby shoes never worn. Yeah. And Jimmy said, what was the words? And then I put the words.

Yeah, for sale. I wasn't correct. I had it answering, Jimmy. Oh, okay, cool. Yeah, yeah. What is that? That's, I think Ernest Hemingway's famous attempt to write the shortest possible sentence that tells a story. Oh.

Yeah. Which, if you are an active listener of the Mbimban podcast, you would know that is, in fact, not the shortest sentence that tells the story. You could just say, you know, baby shoes never worn. Way to go, Travis to shave off some of the cruffed down to a tight four. I can do it too. baby died. You want a real sad story. His story was three times longer than it needed to be.

Good enough. He did it. But why was that relevant in the sentence you said? Ivan was talking about the compressibility of text and how efficient it is that story information. Ah. See, look, I get meta-commentary on Ivan. This is like, this is a genius setup for me. So I'm just, now on I'm just going to let other people explain what I've been saying.

to me. It's great. I should do that too. That would really help them. Uh-huh. All right. So, yeah, moldability. Moldability is this one little sentence at the bottom of page five, and then, like, two paragraphs on page six, and that's it. It is the most insubstantial sentence in this whole paper. And to me, it is the second most interesting section of this paper, the second most interesting dimension of feedback. You ranked them? Well, I mean, I care about one of them, and then I care about this one, and then the other one, who cares? The other ones are not. The other ones are... The one you care about doesn't even exist. I know.

It's so... But that's a joke that was in the chat. The audience doesn't know that that's a joke that's running. That's going to be a tough edit. This is an interesting issue that you can try and represent in the podcast. How do you also include the context of the chat as a separate channel? Oh, I'm going to hit and call in the chat. chat's going to disappear forever because I have Zoom set to not save chats and that's just

going to like flow out of my consciousness. And then when I go to edit, I'm going to go, oh, no, none of these jokes are working because they all depend on context from the chat. What am I going to do? And then I'm going to have regrets. People watch streamers. At least like, you know, 10% of our audience that's young enough watch the streamers. It's fine. I watch streams. A significant portion of the funness of a streamer is that generally they embed the chat itself. into the video so that even if you're watching a replay, you can see the context of the audience interaction. Yeah, but how many people are actually sitting and watching the stream with their full attention and how many are instead playing a game while having stream up while also

browsing on their phone, right? That's the real answer. I am in fact playing a video game while listening to this podcast. So you're correct. Sorry, what was Jimmy talking about? I was looking at this thing that Daniel linked to. I wasn't paying attention. I'll do better. Hello, welcome to the feeling of computing podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role as surprised guest is to give Jimmy and I feedback on the podcast as we record it.

You may do this at any time as much as you want. Don't be shy. Additional rules. If somebody leaves and comes back, I'm not going to reread this, and you must interrupt us mid-sentence. Thank you, and now back to the episode. So that's it for moldability. Moldability is just like a fart in the wind. It's probably the most generative section of this paper in terms of,

like things that I want to do with it at least. And it interacts with all of these other things, right? Like if you have moldability and you're trying to have velocity, that can be a problem, right? If you're having, like, you could augment granularity by having moldability. Like, there's just so much that I think is a potential there for moldability. And it changes the nature of your program if the moldability is part of your program.

I'm going to change the nature of the rules. don't use chat. This is an audio medium. I am changing the rules. No, they can chat. It is up to us to not... Well, okay, don't use chat for feedback. There we go.

Okay, yeah, yeah. If you want to give feedback to us, you've got to say it out loud. I think that's perfectly fine. If you're trying to just talk and chat, you can't be so draconian and not let people chat while they're watching their 12.

favorite podcast. Come on, we're not that good. I'd like to correct you. You're at least in my top three. Grossly overestimate how many podcasts I'm capable of listening to. Where is top point one podcast? Yeah, the first 15 minutes of every three-hour episode. Yeah, the thing that I don't think the chat realizes is just how long, there's like how

long the episodes are, and then there's how long the recording is. And so, yeah, I don't think there's an understanding that this, this is, you know, just beginning. This paper is short. It's a good one to do it on. Yeah, thank goodness this paper is short. That was a really pivotal part of me realizing that this format was possible. This might work, because otherwise it's like the five-hour recording session where we break in the middle to do a bonus episode. It doesn't quite work.

Yeah, I don't remember that being the most recent episode we recorded five hours. We went for five hours doing that. 16 hours of recording for six minutes of video is actually not a bad ratio That's pretty good By-directionality This one is maybe the third most interesting Dimension

Technical dimension of live back What's the tame of this labor? Technical dimension of live-vacabber By-directionality This is like sketch and sketch, right? We all know sketch and sketch. It's like you have a lisp on the left and this time it is actually on the left.

Yes, but it's not a Lisp. It's an ML, which, ugh, ugh. But you edit the code and it produces some output, but then you manipulate the output and it changes the code. That's bi-directionality. And it's almost based. And when we get to the next section, we'll get based. But it's almost based.

Which is like, can programs be edited by acting directly on feedback? And so there's sketch and sketch. And then the other example is a system that Josh made that probably nobody on this call other than maybe the folks who are from Incan Switch know about, which is this tool called Sculpin, which is like, what if you had a JSON doc and then you could use the mouse and like select some element of the JSON and then get some choices of like, hey, turn this into a card or turn this into a label or whatever.

And then you could select some other part of the JSON and be like, turn this into a list. And it lets you, like, build up a UI to present the data that the JSON represents and do a bunch of transformations like, hey, repivit this list using this other list or whatever, right? Like, do joins, that kind of things. Do filtering based on this key or whatever. And it's a way of, like, direct manipulating JSON into a UI. And it's only lightly bi-directional in that you're sort of able to make changes to the JSON to change the, to change the, data that's showing up or, you know, which things are showing up in your UI, and you're making changes to the UI to present the JSON. So, but that's, that's another one. I just want to say,

I thought for sure someone had inceptioned me because I could have sworn. I was there in 2016 in person watching sketch and sketch at Strange Loop. And I was like, it was a Lisp. How is this not a Lisp? And I pulled up the video, it was a Lisp. All right, I feel good now. So it was a Lisp and then they changed it. Uh-huh. I was like, there's no way this wasn't a Lisp. I know for a fact,

what I saw. Oh, that's heartbreaking. You cannot lie to me. Why would they do that? And I was like, maybe my memory is not as good as I think of it. My memory's awful. But I was like,

I know I, I have a good memory for when I've seen Lisp's. Lisp shoes for sale, never worn. Some people get tired of Parenz. Some people should interrupt us mid-sentence. There's, A really interesting thing called Wisp, which is white space-based Lisp.

And you can do all the fun things that you can do with S expressions, but just encoded as white space. It's really quite compelling. So bi-directionality is all about feedback also lets you edit the code. And there's pretty much nothing else to say about it. That's pretty much it. It's a dimension along which you can design feedback is to make it. And it does adhere to my dictum that if you make a visualization, that should be an editing interface.

That's one of my personal rules. Do you see Hess is bidirectional or material? Hello, welcome to the feeling of computing podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role is surprised guest is to give Jimmy and I feedback on the podcast as we record it. You may do this at any time as much as you want.

Don't be shy. Additional rules. If somebody leaves and comes back, I'm not going to reread this. You must interrupt us. Hello, welcome for feeling a competing podcast. This is recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now.

Your role of surprise guest is to give Jimmy and Ivan feedback on the podcast as they record it. You may do this at any time as much as you want. Don't be shy. There are additional rules. If someone leaves and comes back, not going to say the above again. And you must, must interrupt mid-sentence. Don't use chat for feedback. And finally, change and break these rules.

Thank you, and now. back to the episode. I do have feedback, and it's that other people aren't interrupting enough. I feel like there needs to be more interruptions. We have enough people here that we have more feedback. The velocity of the feedback is too low.

There's so much untapped computational power. We have an Intel Zeon processor roaring underneath Zoom, which thankfully hasn't crashed in over an hour and a half, so fingers crossed. Why? And yet, and yet, the feedback is not incremental enough. It's just chugging along.

Why an Intel Xion? Because that's the worst processor I could think of off the top of my head. Okay. I couldn't remember. Is Centron one of those? Is Inteleron? They have... Zon is the...

Isn't Zeon one of like the server CPUs? That's what we have... Yeah, that's what I was confused about. I was like, you're giving like a really high end? Yeah, I thought you were talking about the servers. Yeah, but I mean, they're also the ones that are in like Mac pros, circa 2019. Celeron, there we go. Are you saying the...

2019 Mac Pro is bad? Yes, I am saying that 2019 Mac Pro is... Having been an owner of such a laptop, it is not fun. Laptop? MacPro, laptop, MacBook Pro, I assumed. No, I'm talking... The MacBook Pro did not have a Zon in it. Oh, okay. It had an Intel. I was thinking of the Intel. Yes, it did have an Intel, yes. But then it had a server-grade chip.

Ivan's talking about the cheese grater-based, large desktop Mac Pro that no one buys. But those would probably be fine because the problem with Intel was the battery life. Yeah, because the processors were too power hungry and put out too much heat and gave people tripopophobia. Yeah, yeah, but they were fast because they were insecure.

How did the processor give people tripophobia? Oh, no, it's the actual Johnny Ives design of the front of the cheese grater, the new one, makes it look sort of like that scene in aliens where all the eggs are in the room and all the eggs kind of hatch open and also the scene in Mandalorian where there's all the eggs in the room and then all the

eggs hatch open and then all right. All right. So is hast bidirectional and material? Materiality. Is feedback a side effect or part of the critical path of computation? This is the mention of materiality of feedback. So basically, is the feedback an integral part of the thing itself? Or is it just this layer of ornamentation draped on top? Unfortunately, for this podcast, the feedback is material, is the most important to mention, because materiality is the way that bidirectional feedback actually transcends and becomes more than just, you know, an afterthought, more than just a little faky layer on top. It's why sketch and sketch and sculpting are fundamentally flawed.

It's not that they're not LISP anymore. It's that they're not, oh no, oh no, oh no, oh no, oh no, oh no, oh no, oh no, oh, no. Hello, welcome to the feeling of computing podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role as surprised author of the paper is to give Jimmy and I feedback on the podcast as we record it. You may do this at any time as much as you want.

Don't be shy. Additional rules. If somebody leaves and comes back, I'm not going to reread this. You must interrupt us. Mid-sentence, don't use chat for feedback. You may change or break the rules at any time, and I encourage you to do so. And thank you. And now back to the episode.

Okay. Was this... Materiality, it is the best. It is the most important dimension. It is the only thing that I think is worth working on. It's the thing that I would implore everybody to think very deeply about how can we make our systems more material. And the visual design of the little, you know, visual language that Josh Horowitz came up with for this dimension of feet. Hello, welcome to the feeling of computing podcast.

This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role is surprise guests, because there were two people this time, is to give Jimmy and I feedback on the podcast as we record it. You may do this at any time as much as you want. Don't be shy. If somebody leaves and comes back, I'm not going to reread this,

and please interrupt us mid-sentence. Don't use chat for feedback. You can change or break those rules as much as you want. Thank you and now back to the episode. So this visual, it shows... If I could interrupt, and part of my entrance in this field, I've subscribed to the podcast to kind of pick up from ground level.

But if this is supposed to be a meta-commentary on feedback in line with the paper, it doesn't matter that the feedback in this circumstance is almost forced or occurring in such a way that is outside of the maybe normal understanding of materiality as it's phrased in the paper there. That might be a deficiency in the phrasing of materiality in the paper because the materiality, yeah, it's like materiality doesn't go far enough in the paper, I would say. Like it doesn't get to the level of like, oh, actually, you're. going to go change your computing hardware as a result of your experience of building this program. Like materiality could go so much deeper, right? Like if you have an FPGA or something, like, imagine a material FPGA, field programmable Gatorade, which is like one of those reprogramable hardware units that you can like, it's fixed function when it's done, but you can

like reprogram what it does. Yeah, field programmable Gatorade. It's like materiality. I made a joke earlier that I was going to bring in some Marxism to the podcast. It's time for... Archivost philosophy corner. I think that you can take a view of materialism informed by dialectical materialism, and I will admit I am nowhere near as knowledgeable as many people could be, but you could see a piece of software as not just being material

in that it is a piece of software, but it is a product of both the software and the hardware that it is running on. forms the entirety that is the program because you can't have one without the other. You can't have a computer without a program. You can't have a program without a computer to run on, even if that computer is someone's mind or something more abstract than a physical piece of paper. So there's almost like a layer of ground above the above ground and a layer of ground below the below ground and where even is the ground.

Hello, welcome to the feeling of computing podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording right now. Your role is surprised guest just to give Jimmy and I feedback on the podcast as we're recording. You may do this at any time as much as you want. Don't be shy. Additional notes.

If somebody leaves and comes back, I'm not going to reread this. You must interrupt us mid-sentence. Don't use chat for feedback. You can change or break these rules. Thank you. Now back to the episode. So materiality here, right? Like the analogy...

Hello, welcome to the feeling of computing podcast. This is a recording. Well, it's not a recording in the sense that it's pre-recorded. We're recording. Your rule is surprise guest is to give Jimmy and I feedback on the podcast as we're recording. You may do this at any time as much as you want. Don't be shy. Additional rules.

If somebody leaves and comes back, I will not reread this whole thing. You must interrupt us mid-sentence. Don't use chat for feedback. You may change or break the rules at any time. Thank you. And now... Hello, welcome to the feeling of competing podcast. You are all in character as the system.

When Ivan says, what does the system think? Everybody who is the system must unmute and say the following words, and then remute. What does the system think? Okay, I understand. Okay, I understand. Cool. Now back to the episode, Jimmy.

So this feedback is material here because it affects the podcast that we're doing, right? Instead of like if we had them off in their own room giving feedback as a little, you know, focus group and we couldn't hear it, it would be immaterial. It wouldn't be materiality on the feedback. What does the system think? That is correct. So materiality, this is like, you know, I've been gushing about this section, but let's give the examples that Josh gives for this section of the paper. So his examples are, one of them is this circuit simulator in E Toys that Alex Worth made where, and this one I actually don't think is material. But let me explain what it is and then we can pick it apart.

So it's this circuit simulator. So there's like a little diode that controls the direction that electricity is allowed to flow through, and it's a light emitting diode. So when electricity flows to it, it lights up. And then there's a little power source. And so you can connect this power source and this diode with these little wire segments. And when you drag them together and connect them, because of the rules of this system, the wires turn yellow, and that makes the next wire turn yellow and the next wire turn yellow and then it flows through the diode and the diode lights up, and that forms a circuit. And then the you can pull those little pieces apart and it breaks the circuit. And I, I don't know. Jimmy, do you think that that's material? Did that example do anything for you? No, this example didn't sit right with me ever. I get what it's getting at, but the example fell off because, like, the visuals don't

actually matter for the computation, right? It's the, like, deep underlying state that actually matters. And if you turned off the screen, it would still keep doing it. which I know seems like a silly, arbitrary thing, which is why I never raise an objection to it. But that's my feeling. I'm just telling you my feeling. Like, if you took this and made it a physical system

where the, like, literally the light actually is the thing causing the stuff to happen, then I buy it 100 billion percent. But in software, it's like, uh, unless you're actually like getting at the pixels. Like, you know, some hardware used to do, like, I think Game Boy actually like, you know, has like pixel interruptors or whatever. You look for intersections of pixels. If you were doing it at the hardware level or something, I would more buy it. But I think it's an illustrative example, even if I'm not sure that it's material.

So I still like the example. What does the system think? I mean, everything in computing is in some ways an illusion. It's creating an artificial concept of a world. So materiality is that at least you flow through that artificial concept of the world. Is machine code abstract or concrete? This is what I was saying. It's both abstract and concrete at the same time, and that's what makes it a computer.

Jimmy, do you feel the same way about Boxer? I don't know. It's been a while for Boxer. I have to rethink about it. But I get your point, Josh, which is why I felt that my criticism is flimsy, right? Well, I mean, there's something deep here, which is that, like, the claim that's being made about the circuit simulator is that the execution, the dynamics of the system, they're not, it's not a superficial visualization of dynamics that are actually defined in terms of like real data behind the scenes. Like, it's not like each of these

gates actually asks for its input, like input dot Boolean value or anything like that. It's asking for, like, what's the color on the screen at this point? Is it yellow or is it black? So it's the color sees behavior of E-toys that makes it material? That's right. If it didn't have the color C's behavior, if instead it was doing the, just, you know, asking for a property of some objects, that wouldn't be as material. Yeah, I think the thing that throws me off on it is, you know, you maybe my philosophy brain's jogged here because you're, you call this, it's not epiphenomenal. And what you're describing in the E-Toy's demo doesn't seem, actually seems like a can't. occasionalism, which I will describe. So occasionalism is this belief that like we don't have, so you might have a dualistic mind. You might have a mind-body distinction. You might not.

The important part is that what happens is your mind doesn't cause your actions. God does. But he always makes sure that they line up. So when you're wanting, to move your arm. It's not that the want moved your arm. It's not that your mind moved your arm. God just so happened to orchestrate the world in such a way that when you want to move your arm, you will. Right. And that's what this like E-tois feels like to me is it's not actually materially causing the thing. It's that this thing behind the system is making sure that when you want to materially cause something, it will happen. That's the distinction that it feels like to me. But I think it's a great example. And so I, like, even if I think it might, like,

I'm quibbling on nothing. Because I think it's a great example that is very evocative and helps understand materialality in a way. I don't think any other software example would. I kind of feel like earlier you were saying it wasn't a good example, though. No, I, I, that's why I tried to, then there was lots of interruptions. I tried to say, I disagree with it and think it's a good example. Would a, would a system with a high degree of materiality be something like Baba is you where the rules of the system itself are embedded

inside of the system and you can physically change them and by physically changing them you can change other rules work too? I'd say yes. I'd say that's a great example. I think that's a fantastic example. I'm playing the game. I want to hear Josh's reaction to that. Well, this is all just

on the fly but one thing that's tricky about about Baba is you is I'm not sure in that case you're playing with the program itself, you're not playing with the live feedback. You're not playing with the things that are generated by the dynamics. I mean, I guess you are in the sense you're actually playing the game. But it's kind of like, I'm not even sure that that has live feedback in the sense that this paper is talking about. Yeah, that's a good question. Like, for instance, what was the moldability, right? The moldability angle on Baba is you. You can't actually change the kinds of feedback the game gives you, right?

Like, you could say Baba is on fire, but you can't change. what on fire means to something else. You can just change like which things are on fire. Yeah, Baba is you might be more just material but not reactive or like live granule, live moldable sort of thing. It's just material. Is it possible to have one without the other bits? So yeah, if you haven't gotten it, materiality is that, you know, the feedback feeds back

into the system and really affects how it runs. in a short answer here. And I don't think I actually finished explaining what the visual is, which is that you have some boxes underground, and then there's a flower above them, versus a visual where you have a box underground, and then the next box that it's connected to is above ground, and then the next box that it's connected to is below ground.

So in this one, this is the only one where one of the boxes representing some part of the program is above ground. So the feedback is part of the program. The program is made of feedback in some sense. made of feedback in some sense. Lemon's asking to go out. Lemon. All right, Jimmy, take a lemon break.

Well, you're gone. I'll keep going. Okay. You go ahead. Because we can do this next bit without him here. So this next bit is, I actually want to read a quite lengthy section of this page, of this dimension. What does the system think?

Yeah, go for it. This dimension. has strong resonances in the history of computational media. Boxer is based on a principle its creators call naive realism, which states that users should be able to pretend that what they see on the screen is their computational world in its entirety. No data should be hidden away from the visible world. The developers of self followed a similar principle

when building the UI for self. In a later reflection, they summarize this principle as, the thing on the screen is supposed to be the actual thing. Achieving liveliness through materiality is perhaps the most radical option available to a system designer. Traditional computer science tends to hold that data should be represented in mathematically elegant forms, like algebraic data types, and that views should be strictly separated from models. Following these precepts will lead to a low level of materiality. But by departing from these disciplinary norms, materiality opens up intriguing possibilities with a profoundly different feel than can be.

conventional programming systems. In a system with material feedback, a program sees and works with the same things that the programmer sees. And the programmer is no longer a second class observer. I love that passage. For me, that was the highlight of this paper. That's to me such a charming and at the same time motivating way of phrasing this dimension. It makes me want to explore this dimension further. And it ties back to that very introductory paragraph where it says one of the reasons to do live programming is to open up new exploratory workflows. It's not just made my heart saying when I read that. I quite liked that.

Yeah, I do think this is one of the most interesting dimensions. Because I feel like it kind of departs from some of the other ones, whereas I feel like they're kind of all most live systems you can find, you know, my directionality, I guess you don't see it always, but you can imagine kind of how it would play in. And this one, I think, really, like, fundamentally alters what the live system is in a way that I think ending on this one especially is a really nice ending to a paper because it, like, takes this system I kind of thought I understood, like, oh, yeah, we get live feedback and turns it into something where it's like, oh, actually we can change the programming paradigm altogether if we have this aspect of it. Like, you can't just, it seems at least very difficult to just like slap this on top of pie. or JavaScript or whatever, whereas the other ones you can imagine doing something like that. Yeah, that's a good way of putting it.

Like this one, the other ones are sort of like, here are different design dimensions along which you can make a programming system have more or less or different kinds of live feedback. This one hints at like you could change the fundamental way that programming works, not just your experience of it, but like something about the programming itself could be changed by exploring this dimension. And it seems very difficult. Like I can't, you know, we get these examples.

And the reason I still am saying sincerely, they are good examples. Like the thing that's hard for me to think about is other things that have this or like things that have this in a slight way, but don't fully realize it. Like it is hard to, there's not a whole lot of systems out there that I think have this materiality. Like I was trying to think of like stop drawing dead fish. Do we get something material there? A lot of analog computing systems. Even if you consider like an analog signal processing has this character to it. Like playing with an analog synthesizer, you're directly kind of controlling the thing

and getting the feedback immediately, right? I haven't played with them enough to say. Yeah, you mean like using an oscilloscope or something like that? Or in what sense? I mean the, I mean the you're directly controlling the, I mean, the, I mean, the, the feedback is is kind of immediate. And the thing you're playing with is the, that what you're programming is the same as the output in a sense.

Yeah, I think that the hard thing to divide up between this, like just not having played with those things enough, is like, is this materiality or is this bidirectionality? Right. I think that a lot of things I start thinking of as material at first, I realize, like, what I'm really saying is bi-directionality. Because like the system isn't, like it's kind of almost hard to talk about properly, right?

Because I think this idea of feedback and it coming back into the system is really interesting. But I, we need to do boxer for sure. I love that they call it naive realism. It's been a while since I've read it. I think that this would be really helpful for kind of understanding this concept deeper. The analog synth example is interesting because, you know, not to speak authoritatively about it, but like I think of analog synth. as a system with very little feedback.

With a synth setup, you probably have it plugged in at the end of your chain to some speakers, some headphones. So you're sort of seeing the end results of a whole bunch of intermediate things that are going on. But you're not really getting windows into things that are happening in the middle unless you take your headphones and plug them in somewhere else, or if you have an oscilloscope or something like that.

So there's a sense in which, I think that's a very low granularity of feedback, and I definitely don't think of it as material, because the way that the system operates doesn't depend on having an oscilloscope or a headphone plugged into it. I think it does, because, I mean, the user is an integral part of the system.

So you're saying that the sort of the composite of the whole system with the user moving around and doing stuff in it? I mean, I think in all of these examples in this paper, things are framed as, these are famous technical dimensions of feedback in the sense that like you're thinking about what the, what kind of feedback the system

is giving to the user. So in the case of this materiality, like if, you know, you could like walk away from this whole bubbling, churgling synth and there would be all these things going on, that would be sort of invisible. That's my take. I'm putting away dishes and I don't want that sound

on the recording, my bed. I do. That's fine. Don't sweat. Thanks, I think it's different in this sort of thing than in like the synthesis example maybe. But maybe I don't understand what the author or the paper means by materiality. I don't understand what most people mean by materiality. I think it is kind of naive realism in general, which is like a, that is a turn apart in philosophy. Well, I think that the naming of this one is, it's a very speculative.

when I presented this work like a year ago, called it criticality, which was still not something I loved, but that was this idea that somehow the feedback is on like a critical path. It was supposed to be, I was looking for like an antonym to epiphenomenality. Phenomenal. So I did criticality, and I got a lot of pushback on that one. That, you know, people were saying, oh man, this is an important dimension, that's a bad name for it.

And I agree. And I was, I'm happier with materiality, but I don't know how much happier. Was it just me who was talking shit about criticality as a name? Or were there other people who also said that? Oh, definitely not.

No, I don't want to name names. Oh, okay. That's too bad. But I wasn't even, I wasn't thinking of you when I was talking about people being down on criticality. People don't like being super critical.

That's part of the problem. Are you the author, Josh? Yeah, yeah. So this is. Oh, okay. I didn't know that. My best. Also, Jimmy is not the only one who didn't know we were doing this.

Josh also didn't know we were doing this. He's being a really good sport, considering that I told him this was a surprise party for me. Oh, this is a, well, I mean, I imagine it is a surprise party for you, and you didn't know I was going to be here, and neither did I. I also just, I sort of, by luck, happens to wake up right before 10 minutes after the nominal ending time of this. So I was like, I'll pop into that Zoom and see what's going. on. Oh, so you weren't pre-invited? I was invited, yeah.

Okay, okay. But I like, I like sleeping. On the, on the, getting back to the very beginning of the episode, it's about surfacing things from underground, the podcast, and sharing them with the audience. I sent everybody different messages inviting them. For the people who were invited individually, I also did the thing where I, I've now deleted the episode that was in the main feed, and I'm going to delete the social media posts. before those go on for too long. But yes, in addition to staggering the times that everybody was invited, everybody received a message that was somewhat or drastically different.

Yeah, no, I like materiality better than criticality for the feedback. I do think it, I think it captures something very, very nice. I find it funny because, you know, a lot of things that are materialist are the things that are epiphenomenal, but I don't think that actually matters for the name. So I do think it's a nice, I think it's a nice change in the name. I couldn't remember what it was that you had in live. Jimmy, what does epiphenomenal mean? It's time for Jim's phenomenal.

So epiphenomenalism is this idea that we have thoughts, feelings, beliefs, desires, some aspects of mental life. But they don't actually affect our behavior. They're a side effect of the brain functioning. So you might think, like, oh, the reason that I yelled at that person was because I was angry at them. But really, if we check the causal history, it wasn't because you were angry at them. It wasn't because of that emotion that you felt that like sensation in your brain or in your mind, right? It was because your body just did that. That's the physical causes are fully explanatory of all of the things. But we also aren't saying you don't have this mental, what it's like to be,

these quali, et cetera. They just don't play in the causal order. That's epiphenomenalism. Qualia. Qualia. Are you using that word correctly? Yes. Unlike last episode that you intentionally used it incorrectly. Margaret Qualia. It's funny because if I'm not mistaken, the word originates from philosophy of mind stuff,

thinking about these exact questions of are qualia causally active? But it feels like such a more general term to want to have to just say, you know, I've got this complex chain of causation, which things are part of this chain and which things are just kind of spin-offs that don't actually affect things. It seems like it's a word that you would want to use all over the place. So we invented functional programming theoretically is because of side effects. I mean, that's not why we invented it. We invented it because of mass. But the idea is that you can build things without side effects, so you can build things that are pure.

chains of causality that don't have any of these extra phenomenon going on around them. It feels like a collision of the term side effect. Like, I feel like side effect mean different things in these different contexts. Like, like a side effect in terms of reading or writing to a file is actually causally important, even though it's, but it's, so it's not epiphenomenal in this sense. Yeah, you could think of logging as, you know, in this extended sense, that'd be phenomenal, right? It's a side effect in that sense.

It doesn't actually matter for the, it's not the reason why you did think, but the reason like epiphenomena are called like epiphenomena, right? Like that why this like is because this, you know, it's an experience you're having, but in some ways it's a false experience. In some ways it doesn't have the character you think it does. It doesn't cause the things that you believe it does. And that's why like in some ways, the reason I find that E. always wanting funny is because in some ways it is epiphenomenalism you believe that the light the color of

the light is what's causing it but if I put a filter over the color or if I mess up the drawing code and it draws a different color it still would cause the same thing so that's why I find it funny but yet a good example yeah that is funny and there's you know there's something about in all these cases we know that the stuff that's being shown to the user isn't actually driving the computation. You can unplug the monitor, and it's still going to run. And so it is epiphenomenal in and of itself, but not within the world in which the program exists.

Yeah, exactly. There's sort of, there's like a kind of a fictional world being constructed in which the stuff happening in that world is what's driving the computation. The computation lives there, but the world is made out of stuff that is very easy for people to see. It's sort of built from the ground up to support this inspectability and modifiability by people in this kind of quasi-physical way. Like an each-way thing, you know, you know you can just go in and drag things around,

or you can just look at what things are, and you don't have to take extra steps to do that because the world that's driving the program's dynamics is designed to be one that's very inspectable. In some ways, I see this as like a visual homo-iconicity, not to use a worse word for a less clear word to make something even less clear. But you know what I mean? It's like the same stuff that you made the program out of

is, like, it kind of has that same feel of LIS, but like, taking it to the visual world. What does the system think of visual homoiconicity? Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha. Are we doing closing thoughts since we've gotten through?

We should because materiality is the last section. It ends the paper with the bangor, like, you know, the word disciplinaries in there. in a way that I love. Epiphenomenal, which is a word that resists pronunciation on the first attempt. That's a really interesting qualia that it has.

And then after that, there's just an acknowledgement for live 2024 and then an exhaustive list of references in which the name Joshua Horowitz appears like five times in quick succession. Yeah, this is a short, short paper suite. It has a visual language in it, like a visual notation system.

It has materiality, which is like, to me, on the critical path towards the visual programming revolution that I want to, you know, see happen within my lifetime. So do you think, I asked you the question you ignored it. Do you think haste is material? And it's so cool that everybody came out and participated in this podcast recording. You know, it's sometimes it gets really lonely with just me and Jimmy and half of Lou. And so it was interesting. Is haste material?

To incorporate feedback from. a group of live participants. Would you consider Hest to have the qualia of materiality? I didn't really keep track of everybody who was Does Hest exist?

Hest isn't real. Hest isn't real. Hest isn't real. Hest isn't real. Hest isn't real. I didn't really. I didn't really keep track of everybody who joined, but thank you to all of you who did. Yeah.

Jimmy, do you have any closing thoughts about the paper? I said this before Josh joined, so he can't just think it's pure flattery. But I said this was the most organized, like, clear paper we've definitely done on the podcast. And I agree with that. Like, I still believe that. It's very nice just to see these things laid out. I think there's very little to disagree with. I think it is something that does just a really good job of explaining the things that it talks about,

of calling your attention to things you might not have seen before, and giving, like, good material for like, okay, I'm designing a system, how do I think about these various elements? I think it's really good. I think, in fact, this paper, I know it was inspired by, oh, what's the other paper? Technical dimensions of programming systems, right? That's the... Yeah, I meant to talk about that.

Okay, okay, okay, pause the closing thoughts. There's this other paper. Where did I have this? It was tech dams. Here we go, yeah. Technical dimensions of programming systems. Josh, who wrote that paper? That's Joel.

Yakubovic, Jakubovic, something like that. And Thomas Petracek. And Jonathan Edwards. Petrichek. and Jonathan Edwards. Yeah. That's another one that I will admit to having not read it, but it has perennially been very high on my list of like,

I really ought to read this because I think it's kind of my shit. But yeah, this, yes, this paper was sort of shamelessly derived from and adds no real value to. I don't know why I'm being sarcastic all of a sudden. That's not in character for me. This is, you know, in a lineage with that work. Yeah, I was just saying, I think it does what that work tried to do, but in a, I think, very succinct, nice, I don't know, I like this better. I'll be honest. I think that this one is the kind of thing. I understand that one's more broad scope and trying to, you know, set the ground for other people to do stuff. But I would love to see more papers like this. I think it has none of the failures of modern programming papers that I see, or at least things that bother me about. them. But all of the good qualities of clarity, of concision, and I really enjoyed it quite a lot.

And it's definitely stuff I will think about as I'm building systems. There's a very subjective way that I like to think about whether paper is good or not. That is, do I want to print it out and physically highlight it? Or do I want to just leave it on my iPad? This is definitely a paper I have gone to this cool printer and printed it out. Word. Yeah. closing thoughts anybody else i'll find a way to edit this this was a very sweet surprise so thank you for surprising me i'm glad you turned up and uh and played along appreciate that very much and everybody else also sincerely thank you for going along with the game i'll call it catching the spirit of it

this this went basically exactly as well as i hoped it would so um yeah thank you all and uh just just one more final thing before we all off any final feedback on the episode itself. Test, test, test, test.