Future of Coding - Toby Schachman: Cuttle, Apparatus, and Recursive Drawing

Episode Date: July 21, 2021

In this episode, I'll be talking to Toby Schachman, who many of you are surely familiar with thanks to an incredible string of projects he's released over the past decade, including Recursive Drawing back in 2012, Apparatus in 2015, and most recently Cuttle which opened to the public this past week. All of these projects superficially appear to be graphics editors, but by interacting with them you actually create a program that generates graphics. Their interfaces are wildly different from both traditional programming tools and traditional graphics apps. If you are not familiar with these projects, I strongly recommend that you actually go and play them (they all run in the browser), or watch the Strange Loop talk where Toby demos Apparatus and explains the thinking behind it. This episode was sponsored by Glide, and the transcript was sponsored by Replit — thanks to them both for making this possible. The show notes and transcript are available right here: https://futureofcoding.org/episodes/051Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Welcome to the Future of Coding. On this episode, I'll be talking to Toby Shockman, who many of you are likely familiar with thanks to an incredible string of projects he's released over the past decade, including Recursive Drawing back in 2012 and Apparatus in 2015, both of which superficially appear to be graphics editors, but where you are actually

creating a program that generates graphics through interacting with them. And their interfaces are quite different from both traditional programming interfaces and also from traditional graphics apps and if you are not familiar with either of those projects that's okay i will do a little bit of an explanation for each of them but i also recommend that you go into the show notes where i will have links to these projects themselves so that you can play with them because they run in the browser or uh talks that you can watch where toby demos how they work and the thinking behind them which are absolutely worth watching just as a bit of quick background into each of those projects recursive drawing which was sort of toby's first

hybrid graphics and programming like experimental prototype tool which was his thesis project at itp in 2012 it's a program that takes a very common pattern in graphic software where typically you can you can draw a shape and then you can wrap that shape up as a reusable component and then and then make multiple copies of that shape and it sort of wonders about and then answers the question what would happen if you could take one of your defined shapes and put a copy of itself into that shape and so it's this editing environment he's created for creating these sorts of recursive shapes where shape is is contains itself and you get these beautiful fractal likelike patterns from it. And in the ITP presentation he gives about it, asks a bunch of interesting questions like, oh, is it possible to use this to create a drawing that represents the Fibonacci sequence?

Or in the actual webpage you can go to for this project, there are a number of interesting prompts that sort of challenge you for different things you can try to create within this model, like the Koch snowflake or the Sierpinski triangle or other things like that. It's a very interesting approach to creating graphics and to visualizing something that as programmers we work with all the time, but don't necessarily get to work with in a very immediate tangible very physical way and so in that sense it's a it's a fascinating bit of work that he later built on in a number of other smaller projects but that eventually culminated in a tool called apparatus and this one is truly truly something special if you have not seen this project I implore you to go take a look at the Strange Loop presentation that Toby gives about this project and to actually play with the editor in your browser. It's a direct manipulation drawing environment that allows you to very interactively set up these relationships between different aspects of your drawing. So you

could take the rotation or the scale or the position of one shape and feed those into another shape in such a way that the relationship between those things is always live and is always updated, that your manipulations of the one shape can then in turn manipulate the other shape. And this lets you do just some absolutely incredible things. For instance, some of the demos that Toby gives show him building his own UI elements for then, in turn, making new drawings. So it's this sort of

environment where you can kind of ladder your way up from the primitives that the environment gives you to a more sophisticated, more robust, more specialized environment for making the kind of dynamic drawings that you want to make. And Toby's goal with Apparatus was to create an environment that was very specialized and very

focused on explorable explanations or dynamic drawings. These sorts of cool pieces of multimedia that you see created by Brett Victor in some of his essays like up and down the ladder of abstraction or created by nikki case and some of their projects that teach you how to do different graphics techniques or that explore different simulation models in a very dynamic playful sort of way or even some of the some of my favorite examples of explorable explanations are those created by Amit Patel on his website Red Blob Games, where he covers a lot of algorithms that are very common in game development and teaches those algorithms in a very, very visual, very interactive, very playful way. interactive diagrams, normally they require you to create them using traditional text-based code in, you know, in JavaScript so that they can run in a web browser. And the, uh, the actual, uh, work that you have to do to create one of these kinds of diagrams is so different from the way that the diagrams themselves feel when you are using them and, and the way that you would be

thinking about them if you were trying to create one of these things if to create the visual aspect of it you're thinking in a very spatial way you're maybe working on paper and drawing and and thinking about the the geometry or the color or the relationships between the shapes but then to actually go and build it you got to write some code and so apparatus is this is this project that was meant to create a tool that just absolutely excelled at that that kind of interactive diagram and it's it's um up there as one of the most interesting tools in this space um in in the future of coding space and i i once again i implore you to go check it out if you have not seen it um nowadays toby has actually taken a lot of the

ideas that were in apparatus and is working on a new tool that is sort of like a spiritual successor to apparatus called cuttle and whereas apparatus was a research prototype that was designed to help you make those explorable explanation style interactive diagrams cuddle is focused on creating cad diagrams or creating cnc instructions that you would then use with a 3d printer or with a laser cutter or some other tool to take something that you've designed in a digital tool but then actually manifest it into the physical world because in addition to toby's programming projects he's also done a lot of artwork over the last decade plus and that artwork explores a lot of very interesting themes that

also relate to the programming work that he's done and we'll get into that a little bit in the interview but this new project cuddle is sort of a permutation of apparatus with a very different focus and that difference in focus has led to a number of interesting design decisions that kind of contrast with what apparatus is so we'll talk a lot about that in the interview as well some of the other themes of toby's work that I think it would be worthwhile for me to just touch on here before we get into the actual discussion are that much of his work is about wanting to get away from writing lines of text that micromanage what the computer does in a sort of a do this, then do this, then do this sort of a do this then do this then do this sort of way and upon reflecting on programming requiring that approach toby has noticed that programming self-selects for certain kinds of people typically logical sequential thinkers and the fact that that is what programming as practiced sort of self-selects for those people who then go on to make new approaches to programming tend to reinforce those modes of thought and so it's that that self-selection forms a kind of a feedback cycle and so we get trapped in this mode of

thinking that is is very much about accounting and symbolic thinking rather than thinking spatially and working with models and diagrams and those other modes of thinking. And just because it's my own personal area of interest, I found this remark that Toby made in one of his early presentations very interesting in that Toby, when looking at, you know, approaches to visual programming people often point at things like patcher languages like max msp or vvv origami and quartz composer those sorts of node and wire based languages and and similar and those don't cut it in toby's view because they well they do give you continuous feedback which is something that is i think an essential property of all of toby's work but also the work that he was inspired by while those those patch languages do give you that continuous feedback that you would want from an artist tool they aren't actually spatial because

the spatial aspect that you would want to be working with if you are trying to produce a spatial result like some sort of interactive graphic or something like that the spatial aspect of the work that you're trying to produce is in no way mirrored by the spatial aspect of the code that you're working with so as an example of that in one of his presentations he shows a pure data patch that somebody made to control a human-shaped robot and And the patch has all of its nodes arranged so that you can kind of see the shape of a person like they've got two hands and two legs and a torso and a head, the nodes are kind of grouped together and the and the the wires between them kind of make it look like a stick figure. But there's, there's no inherent relationship between

the arrangement of the code and the arrangement of the visual geometric result that is being produced and so that is what makes toby's work so interesting to an outside observer like me is that he really really embraced this idea of making the programming experience mirror in its spatial character the geometric result that you're producing and he's done just a number of very interesting things to tie those together you'll notice that i'm i'm uh offering more context for his work than i normally offered in my other interviews and that's because on this interview, I tried something a little bit different rather than just approaching it

as a kind of a summary of Toby's work and sort of reviewing the decisions that he made and then sort of using the interview as an opportunity for him to kind of repeat ideas that he'd previously thought about. I approached this interview as an opportunity for me to ask toby some questions about his thinking in these projects that would hopefully motivate some new reflections and some new thoughts and tease out some of the aspects of

his work that were a little bit further below the surface and And so this interview, it's a weird one, but I think it points to an interesting direction that this show could go in terms of how it handles exploring the work that we're all doing in this space and how to have a show that kind of reflects on that work and shares that reflection with a broader range of people so that they can kind of reflects on that work and shares that reflection with a broader range of people

so that they can kind of incorporate that thinking into their own work. It's so that it's less about the particulars of what Toby's done and more hopefully focused on themes and broad ideas and modes of thinking and general approaches. And hopefully that comes through as is usual uh we have a couple sponsors today and i will uh touch on them both at two pauses

in the middle of the conversation but just off the top i will thank replit for sponsoring the transcript which you can find at futureofcoding.org slash episodes slash 51. And I would also like to thank Glide for sponsoring the podcast as well. And I'll tell you more about them when we get to it. So without further ado, here is Toby Shockman. do you remember what you imagined that programming was like back before you actually learned how to program i don't think i ever knew that programming was its own discipline, I guess, when I started programming. You know, I played Nintendo games when I was a kid, and me and my friends would talk about, like, oh, it would be cool if there was a game like this,

and we'd draw the levels and that kind of thing. And then I got into HyperCard, which no one told me was a programming thing i just used it to draw pictures and make little like hyper media adventures and then started making more elaborate games with it and with my friends you know so like little sim like games or fighting games where you have, because you can only move like buttons around. So everything was represented as buttons that are like moving around the screen. But you could, it's a full programming environment. So I'm pretty sure that I started programming before I sort of knew that programming was a term of art, I guess.

Yeah. And then at some point, I'm sure you learned, okay, computer science is a thing, and compilers are a thing, and there's this whole other world of non-interactive, non-direct manipulation programming. And do you remember at all kind of what it felt like to go through that transition i don't know when i thought about computer science as a thing uh probably not until i guess i was in college i mean so i i did hypercard as a kid and then i got into web development you know just because the web was a new thing and it was fun to make web pages I did a bunch of that in like middle school and high school I mean certainly by high school I understood that you could make a living making things on the computer

because me and my friends were sort of making a living making things on the computer and then i went to to mit and i remember wanting to go to mit because i had seen sort of cool research projects like i think i had seen stuff from like lifelong kindergarten type groups and media lab type things. I was like, Oh, that's really cool. But I guess computer science as a thing probably wasn't something that I ever really thought about until I was actually taking classes at MIT.

And by that point, it's sort of like, like you'd gone on a gradual ramp up towards seeing what that style of programming like what i would call the predominant style of programming is like so i'm i guess it didn't feel particularly shocking or anything like that then i guess i guess not i mean it seemed like everything else in the adult world i guess like a little bit more complicated than it needed to be. That encompasses so many feelings right there. So that's my sort of silly warm-up question that I like because it kind of takes us briefly into the backstory of the person I'm interviewing, which I feel like as an interviewer, you're kind

of expected to do that kind of thing, sort of things. And so I'm trying that hat on, but I, I like it because it always sort of helps us understand a little bit about what the person I'm interviewing, what their feelings about what programming is, happens to be, or maybe what informed that and how that kind of plays into the bulk of what the interview is going to be about, which is the work that you're doing now. To actually get into the thick of it, what I want to spend most of the interview talking about is sort of the design and the conceptual thinking that goes into your projects. Because a lot of your work has been in pursuit of certain goals. You've done a project pursuing a goal.

You've gotten the project to the point where you can actually play with it, and then you revise the goal a little bit, or you come up with a different idea, and then you go a little further on that. And there seems to be these sort of common themes, but that you're constantly kind of revising your thinking and then doing a new project kind of revising your thinking and then doing a new project and revising your thinking and doing a new project. And so I kind of want to

explore that arc and then also where you're at now in that process. But the place I want to start is with one of the things that's been a really common element in all of your tool projects, going back to recursive drawing was at least the first place i saw this which is that you always have a sidebar of components on the left and unlike most graphics tools that i've used where if there's a component you can just kind of click or double click on the component and it spawns an instance of that component somewhere on the canvas in your tools clicking on the component does nothing and you actually have to grab the component and drag it out onto the canvas to to create an instance of that component and i'm wondering if that decision came from something specific and what it is that you like about that UI convention.

I don't think it's anything specific. I mean, I agree that that shows up a lot. I mean, I did that first in recursive drawing, and then all the other things are sort of variations on recursive drawing, like you were saying. It just seemed the most natural thing for recursive drawing. I feel like recursive drawing is the most pure in terms of the gestures, but I mean, I don't know if, I wouldn't say that there's anything, like, I'm a fundamentalist about having a left sidebar that you can drag things out of, and it doesn't really scale, like like the idea of sidebars in general doesn't really scale beyond a screen that has sides that are within reach so like with dynamic land stuff for example like the idea of a sidebar i don't think it really makes a lot of sense yeah i i can't i can't say that I have any insight onto why that always is, other than it's approach make so much sense in recursive drawing is that it forces you into this sort of direct manipulation paradigm like quite deeply right off the bat

whereas the idea of oh I click something over here and something spawns over there is already a little bit of spooky action in direction and by having having to actually drag it out, it makes it feel a little bit more like it's an actual concrete thing. And I think that that's just one of those little touches that does a lot to communicate to somebody who's new coming to the program for the first time a little bit about how to think in this program well you need to be able to edit the definition uh in addition to being able to instantiate the definition so there needs to be like that's clicking is is usually like oh i want to edit the definition at least with apparatus and cuddle and all of all of the above but there was there was a uh a version of apparatus i think for the

strange loop talk that you gave where you had to click a little pencil icon to do the edit oh yeah and if i remember clicking on the sidebar didn't do anything but i'm not i'm not sure but it it's yeah it's one of those it's one of those things where it's uh it's it's different from the norm and i like that it's uh i think canva does it that way though where you have to drag things out and canva is actually the norm right like that's like probably the most popular i suppose direct manipulation things though that's that to me that feels like such a different world i often just kind of relegate it to the back of my mind but you're right yeah yeah all those like uh the it's the same with cuddle like a lot of people who like talk and think about these things think

that like 3d printers are the norm but actually the the cricket is the norm like that's like a way bigger community than the entire like what people call the maker community like just all the people with the vinyl cutters i'm so outside of that community i don't know what the cricket is the cricket is a vinyl cutter or it's it's a it's a knife cutter a digitally controlled knife cutter and it's about the size of a printer and it costs about a printer like maybe 300 or something and they have an aisle at michael's or like any of these hobby art and craft stores it's like much bigger than the whole 3d printing community but for some reason like the maker thing tends to ignore this huge community you know it's a different demographic it's mostly women who are working with crickets it's mostly on like facebook

it's a cool community i mean it's it's much bigger it's much different and it's sort of more like canva than it is like i don't know figba or something and i'm sort of reminded of uh what was the the knitting social network was it ravelry was that the one yeah that sounds Yeah, where it's like they were this massive social network and they had this tiny team that were amazingly productive, but nobody in the tech sector was talking about them because they were a community of women knitting and crocheting and that sort of thing and sharing patterns. And it's just interesting to learn about these blind spots

that we have for massive communities that are right next door to where we're paying all of our attention. Totally. And do you know if anybody from the cricket world is using Cuddle or has sort of more small-time cricket bloggers, but she's fantastic, has been playing with Cuddle and giving us feedback. According to her, she's, I mean, and she's right, like she's like a few years ahead of the rest of the cricket community. So hopefully that pattern will continue. Cool. So I watched your ITP thesis

and in the QA session after that presentation, someone asked what it would take to make recursive drawing into a real programming tool. And you said, and I quote, the hard part is the user interface conventions.

That's the hard part. As you discover better interface conventions, that informs how you can evolve the interface. And I'm wondering now interface conventions that's the hard part as you discover better interface conventions that informs how you can evolve the interface and i'm wondering now that you're making cuddle does that still hold true is the user interface and the user interface conventions still the hard part i don't know it's hard to i'm just trying to like bring to my mind like the toby of that time which was it was only like a decade more than 10 years ago yeah yeah you uh you should have seen uh my interview with

miller puckett asking him about creating the original max patcher back in the mid 80s that was that was definitely him going i don't even where that was the 80s it was a long time ago yeah um what's the hard part i don't know what is the hard part these days i mean the i don't know if if what i said was was true or if i still believe it what i believe i guess the hard part is these days are first of all, like being able to know that there is a better solution is hard. So like just knowing that like a better way exists. This is something that Brett Victor is pretty good at. He's, he's, his talks are are good at showing you, oh yeah, there is a better way, even if can be doing a better job and i feel like just knowing that a better solution exists is sort of the first hard part and then i think also i'm learning but also knew that like actually making like a product is a is a hard part you

don't have to make a product to make a research prototype and research prototypes are great like people should make research prototypes but if you want to make like a product that's like this huge 10 times more work than making a research prototype or more like it just in terms of you know it's like hypercard was successful not just because it was like sort of a great work of software art by you know essentially one person driving the creation of it but also because there were like 100 people making the documentation and figuring out what the intro stacks were going to be that you would use to get started with it you know all all that stuff is a big part of what makes something usable by a larger audience which is then and you sort of need the usable by a larger audience if you want to drive the

ecosystem forward i think it's like the research prototypes do that also but you know because because of hypercard and then because of flash and now because of you know sort of this new crop of like you know your figmas and notions and air table type things like that does also i I think, drive the ecosystem forward. So then there are more conventions that you can just rely on and people will be able to get it. Just like the idea of being able to get the idea

of having a component and then instances of that component, it's like that's not something that is perhaps as natural as like wissy wig what you see is what you get which was like at the time like a big innovation as these things get invented it's like genre conventions i guess it's like you can make a film now and like there are all these different genre conventions you can it's like you can make a film now and like there are all these different genre conventions you can use or like certain kinds of shots that mean certain things and the audience will just like implicitly understand what that means but if you were at the start of film

you couldn't do that you didn't have that vocabulary yeah like people thought the train was actually coming out of the screen like that uh that famous film that yeah showed a shot of a train coming towards the camera right but but even like subtle things like you know if you see like a shaky camera behind some trees looking at the girl or something then it's like oh there's like a stalker or something right like that's like a convention that you know you can do that in like three seconds of the movie and then you've already you've established all these things with the audience just from that one shot all those things are little words in your vocabulary and the more rich that vocabulary is sort of the more you can do

with it i mean people obviously made great films back in the day before there were all those words but like the more words you have the more sophisticated a film you can make and i think the same is sort of happening with software like there are more words that get developed and then the audience becomes familiar with those words and then you can leverage that in the software you're making and i guess kids just grow up with it so like it's just natural to them there's an interesting parallel here because what you're talking about is sort of in terms of the advancement of a culture broadly whereas i'm also used to encountering this idea in the context of individual people and the example i'll point to is that there are certain very artful video games that are able to create a very

powerful experience for the player. For example, a game like What Remains of Edith Finch. But those games, to be so impactful, they need to be very pure in their communication. And that purity usually comes at the cost of tutorialization. They don't have a lot of UI. They don't do a lot of hand-holding. And they kind of expect you to come to the game already being familiar with the language of gameplay.

So things like if you see a ladder, you can walk to the ladder, look up and walk forward to climb the ladder. They won't spend a lot of time coaching you on that kind of stuff because they just want to focus on the main thrust of the point of the game. And so there's this interesting kind of, you know, deepening familiarity with the culture on a personal level that someone can go through in their life to gradually get to more profound experiences, or in the case of tooling, more sophisticated tooling. And so I think that there might be something there, not just in the need for HyperCard to flash to tools like Cuddle and Brett Victor's work kind of on a continuum over the long arc of history, but also within a person's life, there might be. And I think maybe that's a little bit of the criticism that is levied at tools like Scratch,

which is sort of they're seen as not being similar enough to quote-unquote real programming and so people don't want to use them as a learning tool and so there's i think there's a lot there that as a as an industry and as a practice you know we programmers are still trying to figure out like how do we communicate that that this is a program that requires people to be familiar with a certain set of conventions? And how do we, at least in my case, the thing I'm really interested in seeing is how do we get away from the idea that there is only one universal set of conventions that everybody needs to be fluent in? And that is Git and the terminal and compiler and a text editor with syntax highlighting how do we have a broader programming culture than that and have some subset of people who are able to

go through a different personal progression of becoming more and more familiar with these alternative tools with things like instantiation like you of a component where it's you know is this a copy or is this an instance if it's an instance i know from past experience that that means i can go to the source component and change the source component and the instance will inherit those changes versus a copy where it will not and that's something that uh if you took somebody who's a a 3d graphics person who's using those tools that idea is old hat because 3D programs, all of them have been doing that forever. But if you took somebody from the world of Photoshop,

that's not an idea that is very commonly presented and reinforced there. So it's interesting to me to kind of identify what interface paradigms, you know, us sort of people making these experimental programming tools can uh depend on and which ones we still need to have a lot of teaching around and a lot of hand-holding and that sort of thing yeah i like your example of the ladder in the game um i would say even more than an individual thing i think it is a cultural thing in that like i mean certainly things like a ladder in a game is something that like you can just pick up as a kid and you just get it and then you unconsciously learn a thousand of those things

as you're playing video games and then you're just ready for it when you then you can you know have these sophisticated games that leverage this cultural knowledge and then some of the things maybe do require like individual growth i'm not sure but i mean alan k always talks about like reading and writing like that's not something that you just pick up like you really do need i mean i don't know maybe people pick it up but it's like it it it does require like practice and like it's it's not as easy as like unconsciously picking up that a ladder means that you can go up and down in a video game well when you put it in that context yeah the reading and writing certainly has has quite a bit more depth that you can go through in your development of awareness of it

yeah so I don't know if there's a difference in category between just these tropes and things that need to be learned in order for you to leverage them yeah I mean the idea of a spreadsheet or something that has data flow that need to be learned in order for you to leverage them. Yeah. I mean like the idea of like a spreadsheet or something that has like data flow,

is that something that you just unconsciously pick up or is it something that requires like a good amount of practice before you're really fluent with it? And maybe my opinion might be more towards the latter versus like something like, I i guess drag and drop where like once you someone shows you that you can drag and drop one thing you sort of get it really quickly or like you know some of the gestures on like touch devices that you know notoriously like kids or chimpanzees and whatever can pick up like just really quickly.

Or even something like knowing that if you can select text, that means you can also copy it. Like that's an available verb anywhere that text is selectable, at least in our modern interfaces. And perhaps this dichotomy, you you're wondering if there's a difference in category here between these things perhaps if it is it's a little bit like with playing music where there's sort of the difference between developing proficiency at an instrument which is sort of about you know you need the practice to be able to take something that maybe you can hear in your head and to express it on your instrument versus the culture of, like if you're a drummer or a percussionist or something like that, knowing what rhythmic patterns will evoke certain feelings or complement certain styles of music or clash if you want to be confrontational about it it's the sort of the pieces that are about your own ability to be expressive versus the pieces which are what you choose to express it also reminds me of like doug engelbart's stuff was like i think his attitude was like people should just take a few hours to like

learn how to use the thing um and like nowadays the idea of taking a few hours to learn how to use an app is like sort of it's it's funny when you say it, but it's ridiculous in industry to require that, right? That hurts my heart so much. Because it's not to make this about me, but one of my schticks is that I think there's a lot of focus in the community doing research on new programming interfaces on the beginner experience. And I sort of, one of my bents is that you can improve the experience for experts in a way that also benefits beginners. And it's an easier sell given the culture that we have if you make an improvement for an expert and pitch it to people as an improvement for an expert. But then it also kind of quietly sneaks in like,

and it makes it easier to learn how to do this if this is your first time. And so I feel like the, you know, that focus on it being a requirement that you have to pick something up and figure out how to do it without, you know, investing any time in it. Like that's something we've got to outgrow as a culture

at some point it just seems so so far from from present constraints of reality that we're subject to well i guess like there are some related ideas and that like well like first of all i agree with your advice like i i also like to focus on like making things better for experts and then that also benefits beginners learning it and i think that's it's also like you know things that are like targeted at kids for example like i feel like kids like to use the things that adults use and so for example i want i i think it would be great if like cuddle was like used by kids but i feel like it would be used by kids because kids see cool stuff and then they just start using it not because it's like made for kids i don't know i guess like

things that are made for kids seem a little like patronizing to me but then another related idea is that video games are able to teach a bunch of things, but are able to do it in such a way that you feel like you're learning the whole time. And the tutorial's not built as a tutorial. It's just the first level. At least in a good game. There's plenty of count examples yeah like there's your you know your jrpg where the the tutorial is four hours of clicking through text boxes but aside from that yeah totally i know exactly what you mean I would like to thank Replit for sponsoring the transcript of this podcast, which you can find

at futureofcoding.org slash episodes slash 51. Replit is an online REPL that gives you a very immediately productive environment to get up and running with any number of different programming languages and frameworks and tools that you can use, including Git integration. They have a multiplayer feature so that multiple people can hop into the same REPL and work on the same project together. It's all very batteries included, very easy to get started with and easy to scale up to much bigger projects they've created this just fantastic sandbox for trying out new programming ideas trying out new languages they just have this constant stream of new things that they're adding and new ideas and new tools

and they're just absolutely firing on all cylinders when it comes to making this environment robust and productive even if it's not the kind of environment that you find yourself working in frequently it's the kind of thing that's useful to have in your back pocket if you need to pop up something on the go and just test something out or if you want to as a weekend project stretch your legs on a new language but not spend half the weekend installing the compiler and all the dependencies and getting your environment set up and going through all that work check them out they have actually a couple of months ago i think changed their name they're no longer repl.it replit they're just replit and their new url is replit.com so go to replit.com to check out their programming environment and all of the tools that come with it.

My thanks to Replit for sponsoring the transcript and helping bring us the themes of your work is that the user of your tools is creating and manipulating a program that generates graphics, rather than manipulating the raw graphics themselves. And I'm wondering if you've considered the inverse, where you are creating and manipulating raw graphics that generate a program? I guess, I mean, I think that's a valid approach. And I guess I think of that as programming by example, maybe. Though I'm not sure if that's, I know what, your question could be asking a bunch of different things, but I guess I'll interpret it as like programming by example, where you like, you make your, the finished artifact and then the computer like sort of figures out, well, what program generates that artifact or these series of artifacts the the way you characterize my own work i think is accurate like it's you're still programming but you're using a different a different set of affordances to to create your program rather than typing it in and i didn't mean for this question to imply

any specific interpretation. I realize now that I worded it as kind of like a yes or no question, like, hey, have you thought about this? No. Okay. But the other thought that I had, and part of why I'm asking this is I'm kind of curious to generate these sort of like, you know, because when you say you're creating, manipulating a program that generates graphics, like that's a theme that has come up a few times on this show. For instance, Ravi Chug's project Sketch and Sketch is the same way where there's a programming textual interface on one side of the screen and on the other side of the screen is a graphics canvas and you can do direct manipulation and that those manipulations that you do on the graphic side update an

underlying program model that generates these two views the textual view and the graphical view and it's it's that same sort of idea that you are still programming and and so i'm kind of curious if like is this sort of like a software eating the world kind of thing where it's, you know, it's all programming. Photoshop is programming. You know, Excel is programming. HTML is programming. Or is there even another side to this coin? And the thing that I thought of was the, there's an Iso Lang.

Hey, future Ivan here. The Iso Lang I'm thinking of is named Piet, after Piet Mondrian, the Dutch artist famous for his abstract paintings of rectangular shapes in bright colors. And the Iso Lang takes its name from that artist because the programs you create end up looking somewhat like one of Mondrian's paintings. You create a PNG that has different colors and sort of a pattern of squares, and it makes an image that looks like an artwork. And when you evaluate that program, the evaluator actually looks at the pixel values and executes that. But you're still, even though in that case,

the interface that you're working with is more about the graphics, you still have to do that sort of computational thinking about it. You still have to think systemically about it. And so I was curious if this is something that's come up in your exploration where you found like, oh, here's an idea for an approach where you can like oh here's an idea for an approach where you can do programming but get even further away from having to think computationally or think systemically i kind of feel like you have to think systemically to program i mean i guess

maybe some some of this new like machine learning kind of stuff, you're thinking a little bit not systemically. I don't know. I'm not an expert in that stuff. But I can imagine some sort of machine learning paradigm where you're training the computer and so you're not really thinking systemically. You're just sort, rolling with it in some sort of way, which I don't think that really exists yet. But I can imagine that existing at some point. I think you need to think systemically, even if you're not really thinking in so much on the symbolic spectrum. So like, status quo programming, you're like, typing all this stuff and that's like that's like leveraging your linguistic capabilities and your like symbol processing kind of capabilities and you can do like if if you have the right kind of programming environment you know you can you can draw flow charts or or you can draw timelines. There are all sorts of things you can do

that aren't quite so heavily symbolic, but I think there are still pretty systems. The system thinking seems like a more essential part than the symbolic thinking. And I guess thinking about some of the approaches to programming by demonstration stroke example uh that i've seen are the the systems where the computer will present you a number of choices for um like you'll you'll you'll make a change in the program the the system will generate a program that would

have produced that change, but there might be several ways to go about it. And so it will say, you know, oh, you know, which of these examples of me extrapolating from that is the one that you meant. And then in that case, it's kind of like your machine learning example. You're not thinking so much about the the how you're just thinking about the what of it maybe yeah and those i think in that well it's different than the machine learning the machine learning one is like its own mess because that's just all in some weird probability space or whatever but like yeah the the some of the what you're saying about the programming by example uh examples where it's like it's sort of doing some of the system

thinking for you and it's certainly doing some of the like corner case thinking for you that's like such a hallmark of like programmer mentality that um it's probably like that that's probably a sort of that's probably a big deal i can imagine like because so much of your mind as a programmer at least when i reflect on my own experience or like the experience of people i'm working with it's like so much of your your mind is just thinking about oh what corner cases am I missing? Like here, here, and here. And you're like, always trying to think about the corner cases. And there's whole disciplines devoted to like, we're going to use stricter and stricter type systems and, and TD, no BDD to try and make sure that we're always catching all those

corner cases and failure modes and all that. And I can imagine the computer being able to assist in that in such a way that you don't have to be thinking of the corner cases so much or you can be like there's a really good um takeo igarashi work who's who's great he's the the one who did um like teddy if you're familiar no i don't know. Well, the one I'm talking about is one called Pegasus. You draw with a stylus or something, and then it says, oh, did you mean to draw a line that's perpendicular to this other line?

Or did you mean to draw a line that's something else? And then you can say which constraints you want basically but you don't have to like think about what the constraint is before you draw the line you just draw it and then it tries to figure out what could you have possibly meant by that and then give you the option to choose what you meant so i feel like that's like that paradigm of like you don't have to be thinking about it at a very like low level all the time you're thinking more about what your intent is for the result and less about what the mechanics of achieving that result would be.

Yeah. I mean, your intent was to draw a perpendicular line, but you just didn't phrase it to yourself that way. Right, or phrase it to the computer, yeah. Right, yeah. You didn't have to remember the word perpendicular. Yeah, that's neat. So I'm going to keep moving through questions,

and then I've got a lightning round at the end. we're going to go through a bunch of sort of fuzzy philosophical sort of like what were you possibly thinking kind of questions and then we'll get down to some ones that are like you know this pixel here in this spot tell me about that pixel that kind of thing so um so and this is going to be another one of those questions where if, if the answer is just, ah, I don't know, uh, that's fine, but I figure it's worth, uh, exploring. Um, and this is kind of a long question. So your, your artwork and especially your later artwork focuses a lot on mirrors and, uh, like mylar reflectors and you did a mirror hacking workshop and and uh and a lot of projects with kaleidoscopes um and it feels to me like this is a good fit

with your programming projects uh like recursive drawing and even apparatus because an apparatus there's sort of the recursive drawing feature in there too, where a shape can contain itself. And the results of the things that you create in recursive drawing and an apparatus and to some extent in Cuddle also have that kind of fractally kaleidoscopic kind of patterning to them.

And then you also did a project where you created a sort of a prototype for what an interactive textbook might be like. And this prototype was focused on pixel shaders, which are the things used by a, just for the listener's sake, they're the things used by a graphics processor, a GPU to actually color all of the pixels in an image.

So instead of a normal computer program where you might have a single thread that goes pixel by pixel by pixel and sets them all to whatever color they need to be, in a graphics card, the GPU will take the same program and run it massively in parallel on a whole ton of pixels all at once. So you might have like 3,000 different execution units all running the same program on 3,000 different pixels. And for that kind of job, it's a much quicker way to get a result. And so in that project, you said that traditional programs,

like those on a CPU, are usually quite long. And the challenge is in understanding how the computer steps through the program, where GPU programs are often fiendishly short, and the challenge is in understanding how a simple program, when performed thousands of times in parallel, can produce a powerful effect. And to me, that is yet another example of the theme in your art and with recursive drawing and and and the other drawing tools that can have that kind of fractally pattern or this like mirror like kaleidoscopic kind of effect which is it's about little pieces repeated again and again with slight transformations building up to a much bigger result. And so kind of realizing

that theme in your work made me wonder that all of these examples, and especially mirrors, are about creating more of something in that they double their input. You have a mirror of one thing and the reflection is a copy of that thing. Now you have two of it. And the more mirrors you add, the more doublings you get and same with recursive drawing you put something inside of your of itself and you get a whole ton of that thing you get an infinite amount of that thing and that these ways of thinking and of working are all additive and so I was wondering if you've sort of thought about the additive nature of this kind of work. And if this is something you thought about, or even if it's not something you thought

about, I'm curious if there's a way to do a conceptually subtractive relationship in a sort of a direct manipulation or spatial way. And I don't mean just like Boolean subtraction where you have, you know, one shape and then another smaller shape and you, you know, punch out like a hole from a square or something like that where you're, you know, subtracting one shape from the other. Because to me, that's still additive in a way where you've got two shapes that are being combined to produce a certain effect. And I'm wondering if this sort of additive nature of creating things in in all of your projects is something that uh that you've thought about

and if you've run into limits with that and maybe there's like another side to that that you've done any exploring of i like the question a lot uh and i like that you found that connection between my mirror sculptures and uh the kinds of stuff that i do on the computer i think the i hadn't ever i guess thought about the mirror as being a thing that adds i usually think of it as like or i try to think of it as something that folds so it folds the space that's how i think about a gpu shader also and that like if you're sort of working in the grain of the medium you're like you, you're like folding space rather than painting. But in terms of this thing about it's always adding, I see what you mean. And I could see it potentially as being a weakness of sort of the approach that i've been taking and that it's sort

of like i don't know it can be kind of baroque i guess like it like it adds too much uh fine detail or something like always adding and i agree that a bo Boolean difference is also adding. So how could you do something that would subtract? I think it's a really good question. I don't have an answer right now, but it's something that I'm going to think about. Do you feel up for spitballing on it a little bit? Okay. So because I wrote this question a few hours ago and I've had a tiny bit of time to think about it,

the only thing that I came up with as an example of where this additive quality might manifest in your work as a limitation, where maybe something subtractive, conceptually speaking would fit and this might just be my own like not knowing how to use cuddle and and uh see other related tools you've made but it's it feels sort of like these relationships that you build in in something like cuddle where you're making a component and then you're

Reusing that component inside other things and in a sort of a nested way and you're kind of building up these like it's a very sort of tree like structure of relationships between components and There's not Is that fair to say that it is like you're always creating a sort of a tree-like structure? Or are there ways to use Cuddle so that the result of putting components together is more like a graph, where at some point there might be like a narrowing down of things in the hierarchy? Cuddle is like, at least right now, it's sort of the same amount of tree-ness as a typical status quo programming language thing. So it's like, you know, usually when you're programming, you've got tree-like stuff, because you have your conditionals and your loops and things, and your functions that can call other functions but you

can also in your call graph that's a graph right like you can call functions so i feel like a typical cuddle design is i mean it's sort of modeled after programming oh and then parentheses obviously we use a lot of parentheses in programming that's also a tree-like thing i mean if you have self-reference then maybe like if you have self-reference and conditionals then maybe there's a way to make it less tree-like and more graph-like and i think it it's that conditional-ness of it. In Cuddle, is there a way to say that you have a component that contains two subcomponents

and then there's some kind of parametrization of the parent component that's like, in some circumstances, show the one component child, in other circumstances, show the other component child? Like a way to kind of right um there's there's nothing built in but you could probably make that yourself or we could it's the kind of thing we would consider built uh building in like i've seen that pattern yeah and it because it makes me kind of wonder, like, I think that's where this this thought came from, for me, is it sort of like the, the thing that you focus on in to me, it kind of gets into a bit of a murky soup.

Cause like, is the addition of some kind of conditional logic conceptually subtractive or is it conceptually additive or does that distinction even matter? I think it's additive. I think if you're putting more logic, even if it's taking away in some dimension, you're adding in another dimension. I guess like the place I would go with it is like meditation.

I don't know like what the implications of that is, but like, that's like the only thing I can think of where it's like, you're, you're really like, like that discipline is sort of all about subtracting, I guess. There's not really many disciplines that are all about subtracting that I can think of.

Yeah, it's like it comes up in aesthetics, perhaps like minimalism, or, you know, the very norm joke about jazz about it being the notes you're not playing. Like there's there's some places where... Yeah, and it's, yeah, I guess like like design in general like subtraction is a very important part of becoming fluent at design like taking away all the things that are unnecessary to achieve your result is part of what makes a design good it's interesting to me to just think about you know is there a category of not even features but a category of concepts in programming that are about that sort of narrowing down and taking away because whatever that category might be it feels like your work doesn't focus on that and instead focuses very much on on like and it makes sense to me you know why you would

be so focused on addition because you're focused on giving people expressive power in a new way and about letting someone like create a very impactful result very fluidly and i think that the sort of their um like the focus on that experience drives you towards building tools that can produce a a big impact a big result very quickly whereas the the other side of it the like you know actually i want to have less of a result i want to you know spend a lot of time honing things and about, you know, reducing stuff like that seems maybe complimentary, but definitely like to the side of what you're focusing on, at least in my sort of headcanon. Are there things in the computer world that are on that side of the spectrum? I guess i think of most things in the computer world as being very

additive yeah that's a good question just as an aside something i've wanted to do with this show is have more of these kind of conversations where it's sort of exploring a theoretical space or a design space together rather than just strictly doing an interview about a person's work and their backstories doing a little bit of thinking together on the show and the thing that i'm realizing now trying this with you is that dead air is hard like and especially because we don't see each other we just have like the sound of my squeaking chair and that sort of thing and it's sort of um i don't know what you're feeling but i feel like there's a pressure to kind of keep the momentum of the show going so that's an interesting but it's thematic to have dead air if we're talking about

the opposite of adding oh there you go yeah all right there you go there's uh it's like i don't know where i heard this but there's like some tip for like if you're like trying to like sort of lead a conversation in a grounded way that like before you say something you like take a breath it like forces you to slow down the conversation that feels like a subtractive technique it's not a computer thing but it's like the those are those are like the kinds of things that i'm thinking about when you're like huh all these things are additive and then I'm like oh you're right

like and that's actually like a big a big problem with sort of modernity I very briefly went to art school and by briefly I mean about nine weeks and then dropped out of college and went off on a different adventure. And one of the things that my very charming, very grumpy, grizzled drawing instructor said is that human beings are meaning-making machines. And that one of the functions that we can't help ourselves but do is interpret and make things meaningful in some way. And it

sort of feels like that push against entropy is so inherent to the human experience that, A, it makes sense that meditation is something we have to do as a subtractive practice, you know, as a push back against that meaning-making nature that we have. But then it also makes sense that something like computers, which are so modeled in our own mental image, so to speak, are so much about creating more and more and more and not giving us tools to do less it's a big problem with computers i think a lot of people experience that in their lives like not programmers

just like everyone you know with the technology it's like so much adding and not enough dead air. You know, like maybe a tool for CNC, which is, you know, that's Cuddle's stated purpose, at least in its current form, that was more about subtraction might do something like help you take an existing design and simplify it rather than starting from nothing and building a new design it would be like an experience guided towards you know how can you reduce the number of parts that are in this thing or reduce the amount of material that it takes to make this thing and

you could use current cuddle in that way but it's i don't think that's a a goal of the project per se yeah it's um i mean like the best answer i can give you towards this end would be that a goal of cuddle is to get you off of the screen as quickly as possible and working with the actual physical thing that you're prototyping and making. So, you know, if we can make it faster for you to like not be on the computer, that's what we want. A lot of that is like being able to quickly sort of sketch your idea without having to do unnecessary steps and then also quickly iterate your idea without having to repeat a bunch of steps which is sort of the status quo of design tools i like the idea of something that can simplify a design though um by actually removing it's like if you could like you know if you wrote a program

could you have the computer like just eliminate lines of code or like write it in a more elegant way it's not i mean maybe you could do it that would be a cool research project well that's haskell right like haskell's whole thing about being lazy like that's the point of laziness in haskell is so that you can write something that is that's more about the evaluation model that's that wouldn't simply like i i want to simplify your mental model uh right yeah and how do you envision that working maybe maybe? Well, when I worked with Brett, he would spend days doing that. He'd print out his code on four pages and spend a few days trying to make it three pages. And he would say that he thought the experience was like writing poetry,

which I don't really do, but I think he does, where you're trying to say the same thing, but in a more economical way. And writing poetry, I don't know if that's like a thing that a computer does very well, and certainly not in the subtractive sense, I would think. Like you could make a computer write a lot of poetry but that's like not what i'm going for it's like how do you make a computer write like

really elegant poetry or even just like it's something that comes into computing culturally in that there's a culture around like code golf or something like that which is a different but related thing i guess there's also a culture around like optimization like can we make this process use less memory or finish faster burn less battery life that kind of thing but that's different than what you said about reducing the conceptual model, which I think is, that's really something. If we could find an approach to programming that was about that, that would be, I think, very interesting. Yeah, maybe like automated proof assistance or something i think i think there are some like results where sometimes the the computer can come up with some like elegant proof that no one had thought about before

that's like does it in fewer moves so to speak though it seems like and and maybe this isn't with proof assistance so much but with with um with the kind of related field of programs that are for deriving formula it seems like you know a situation that arises quite often is that they'll come up with a formula maybe to explain some some phenomenon in physics or something like that and the and the formula will be so fiendishly complex that there's no way for a human to verify it like it goes beyond our capacity for like it's not tractable by humans you just have to kind of trust that like well the program that we built has a robust model and it's telling us that this this formula holds so we have to assume that it holds um sounds like an overfit yeah maybe

yeah i'm though though that might only be the case if if there's some sort of inherent truth to the idea that um that there's a sort of a pure simplicity to reality that like like just because all the fundamental formulas that we've discovered for you know acceleration and thermodynamics and so on and so forth have gradually trended towards simplicity over time perhaps like like um principle of least action like the principle of least action if that's conceptually simpler than the things that it that it explains just because that's the direction that we're sort of trending in our discoveries doesn't inherently mean that that's true of everything in the universe like maybe there is some aspect of physics out there

that is like truly thorny beyond like like maybe you know grand unified theory or something like that like maybe it's an equation with you know 200 quintillion terms or something like that. Like maybe it's an equation with, you know, 200 quintillion terms or something like that. Like there's, I don't know if there's an essential reason that it needs to be conceptually simple. Yeah. I mean, that's a philosophical debate.

All right. I'm going to take a break. Yeah. Yeah. For two seconds and I'll come right back and then we continue. Cool. Yeah. Cool. Okay. Our second sponsor today is Glide.

I introduced them last episode. That was the first time they appeared here on the show as a sponsor. And so we're back for round two. I'll give you a really quick review of what they're doing. And then this time I wanted to share a couple of thoughts that I have about it that I think kind of point to what I personally find particularly interesting about what they're doing. Glide's mission is to create a billion software developers by 2030 by making software dramatically easier to build. We all marvel at how successful spreadsheets have been at letting non-programmers build complex software. But spreadsheets are a terrible way to distribute software. They're an IDE and the software built in it rolled into one, and you cannot separate

the two. One way to think about Glide is as a spreadsheet-y programming model, but with a separable front-end and distribution mechanism. The way it works, and here we get to the part that I like, is that you pick a Google sheet and Glide builds a basic mobile app from the data in the sheet. So just to repeat that, because this is the thing that I think is cool, rather than creating an app, and this is great for apps, like for instance, if you want to build like a directory at your company or something like that,

so you can record all of the people and their different positions and their responsibilities and share that app around. So it's really easy to find a person who's the responsible party for a particular function in your organization. That is like a perfect fit for Glide because the database that you use is google sheets you have a

really nice interface for working with tabular data in google sheets that's what it's all about and you can use that interface to create and update and work with the data and get all of that information into the shape that you want it to be in, and continue to modify it over time, and Glide will pull the data out of that sheet and populate it into the app. And the app's interface is dynamically generated based on the spreadsheet that you present to it. So there's, well, they do offer some control over what the app is like as a result, and that's something that they want to improve in the future, they already do a lot of work so that you're focused more on the

data in your app and less on what it takes to actually turn it into working software. So that big focus on the what of the programming rather than the how of the programming, which I think is huge. So here's why Glide is sponsoring the podcast. They want Glide to become a lot more powerful. It needs to have much more flexibility and much more capability. As they say, its declarative computation system has to support many more use cases without becoming yet another formula language. Its imperative actions don't even have a concept of loops yet or of transactions. Glide needs to integrate with tons of data sources.

That's an interesting thought where they could go with that. And scale up to handle much more data. To do all of that, Glide needs your help. If you are excited about making end-user software development a reality, go to glideapps.com slash jobs and apply to join the team. That's glideapps, G-L-I-D-E, apps.com slash jobs. My thanks to Glide for sponsoring the show and helping bring us the future of coding. okay i'm back welcome back i've got three more kind of broader questions not not nearly as broad as the last one um okay so the first one being that cuddle is meant to be a practical tool subject to real-world use rather than more of an experimental prototype like apparatus or recursive drawing. And you've said that in an early introductory post that you wrote about Cuddle that you're walking back some of the more experimental ideas from those previous tools.

And I'm just curious if you could talk a little bit about what those ideas are that you're choosing to not pursue. A couple of the ideas in Apparatus, I think they're ultimately good ideas, but they're just weren't ready for me to have that many balls in the air, I guess. Like, I mean, the thing that I'm keeping is the idea of you can directly manipulate your literals on the canvas and type them in in the inspector in the symbolic way. And I'm keeping the idea of components and instances. And I'm actually adding the idea of modifiers which Apparatus didn't have. Apparatus had no way to refer to geometry that had already been created. But then there were a bunch of ideas from Apparatus that I'm getting rid of

not because they're not good ideas but just because they're too tricky to handle all at once. So probably the first big idea would be Apparatus didn't have parameterized functions. Instead, it had this sort of strange prototypical inheritance where you'd make a thing and then any instance of that

would be like a variant and you could change anything about that and if you go back to the original definition and change it those changes would propagate to the variants except in places where you've overridden it so for example if you have a definition that was a shape consisting of you know a circle a square and a star and then you made another instance of that well it starts as the circle square and star but then maybe you could like delete the star or make the star have 10 sides instead of five sides or or you know whatever and then if you change the original those would propagate through except

if you change the color of the star well the star isn't there anymore in the you know in the instance um it's actually based on jonathan edwards's work subtext is that that's the name of yeah that's the one yeah so the the first subtext i believe is the one where he has this thing where it's like you sort of copy the whole tree and then you can make modifications to that tree and then the propagations go through and it's something that you can't it doesn't make sense in textual programming it just becomes way too hard to like deal all the bookkeeping, but it does sort of make sense if you have a very sophisticated IDE, so to speak. So that's a good idea, I think,

but instead I was like, no, we'll just do their functions. You have parameters that are sort of at the top level, and you can reference those parameters in general i try i'm trying to like where i can leverage things that are like tried and true from status quo programming so like the idea of like a function that has a couple of parameters and then you can use those parameters within the function like that, that form seems to work. Like it scales to pretty complex stuff.

So it's like, I'm not going to reinvent that right now. Cause I'm trying to reinvent other things. And is that the removal of inheritance inheritance from apparatus is that kind of the main thing that you've done away with or are there other things you could also point to where uh where it was an idea present in your previous work that is is deliberately absent in in cuddle uh i also got rid of spreads from apparatus which i also think is a great idea, and I kind of miss them, but I'll probably end up having something more like a traditional for loop in Cuddle.

Cuddle doesn't currently have anything like that. It has these modifiers that you can sort of use in that way, but it'd be good to have a sort of first class for loop type mechanism an apparatus had these spreads which i borrowed from vvvv anywhere that you can like say pass a number you could instead pass a spread of numbers which is like a list and then then everything that comes out is the list so it's i guess it's sort of like a list monad that it just comes for free. That idea was an apparatus and it was really powerful. And I don't have that in cuddle, but it was, yeah,

it's just like, if you have that, then it's like, there's a lot of extra implementation things you need to make that work. And UI things. And is that, cause when you talked about taking out inheritance, which was something I'm actually, I'm curious to talk a little more about, because that was something that I ran into in my in playing around with cuddle. that you need to do and i'm wondering like in taking these things out or in taking out spreads

in particular i guess is that motivated mostly by wanting to simplify the interface or wanting to simplify the like the conceptual model inside of cuddle like what sort of motivates the the removal in that case well with the inheritance is definitely to simplify the conceptual model because i could never get it quite right in apparatus it was never really clear to me like what like in using it like what you were doing and like especially if you ever try to make like a really recursive thing in apparatus it's like really tricky to understand sort of what level you're changing a definition um whereas it's like recursion's not easy with traditional functions but at least it's like sort of a solved problem and they're like

known patterns and we can just don't really have to think about it because it's like something that we've been doing at least by we i guess i mean programmers have been doing for a while and especially like quite experienced programmers. Sure, recursion can be tricky when you first encounter it, but once you've practiced and come to a level of sophistication with it, it's a well-established pattern that we've done a lot of work to codify. Yeah, I mean, so if you have a function in a traditional programming language didn't declare any parameters but every single literal in your function became a parameter like that would be an abstraction mechanism and it's

more powerful than declaring like only some of the things are parameters but like it's also a very different way of working and that was sort of more like how apparatus was it's like all your literals are actually parameters because when you instantiate a thing you can change any of those things and it's just changing the default values of those particular parameters it's more powerful and like it sort of made sense in Apparatus. It was a great experiment, but Subtext, I thought, did it. It was interesting because it had that feature, but inventing all of the UI conventions around that is its own year or two or five of work.

So we're just going to have to suffer with parameters that you have to explicitly say oh this is a parameter of the thing but it's you know a known way of doing abstraction that's the thing it's like because there's there's this whole landscape of abstraction mechanisms like how do you pick where you're going to stand on that landscape and trust that it'll like give you the power that you need and so unlike apparatus where i was like experimenting with exploring that landscape with cuddle i've actually picked a spot which is sort of status quo programming where you have functions with parameters and i know that that'll you know give the community most of the power that we need but like may not be a perfect match there's probably something better that exists but it would take a

lot of research to like figure out how to find that sweet spot yeah because at least in this case you know what the like the possibilities and the limitations are whereas if you did something more like apparatus you know there's probably emergent properties of that design that would be very hard to create a good reliable experience around without a lot more work and so that sort of i think ties into my next uh question Like the first thing that I tried to do when I started using Cuddle was make generative art, like the kind of thing I would do

in processing or one of those kind of tools. I'm not coming to Cuddle to try and make a tool path for a CNC machine to cut out a piece for my bike or for something that I'm building. I'm like, to me,

this is a drawing tool, there's a canvas, there's shapes, there's colors. What can I do with that? What surprised me was even though that's not really the initial focus of Cuddle, there was so much there that I could already do that made it really good for generative art. And I found it charming that like the limit i ran into

was not about how expressive i could be with shapes and patterns and forms and geometric relationships because that was incredibly robust but that i couldn't do even something like gradients like when it came to actually making things have color, the tools that were most apparent were like sort of the first level you'd get from SVG or something like that where you have strokes and fills of solid colors. And doing something more than that required kind of doing it at the level of geometry. Like if you want a gradient, you can do a repeating pattern of shapes and and change the color on each repeating shape a little bit and if you if you have enough of them you know a kind of a roll your own spread gradient approach and so i'm kind of wondering like cuddle feels to me like something where you are quite focused in your initial design but that there's a lot of potential here to grow beyond the initial focus on CAD.

And I'm wondering if that's a long-term goal, and if so, how you might go about doing that. I think I do want to keep focusing on CAD rather than adding gradients. I am just really interested in the idea of making physical objects. so that's what cuddle is going to be about but i think some of the like broader ideas and cuddle could be uh used for other domains like you could make a whole animation system or something for visual art or something for for sound or music using a lot of the same ideas of like you know you have these primitives that are directly manipulable but you could also parameterize them and you have the idea of like modifiers and components which you know give you ways of sort of like combining and abstracting so like it's like taking like a lot of the things

that you get for free so to speak when you're programming and bringing them to other domains and making environments that are really top-notch for like working in that domain but the domain that we're focused on is, right now, cutting tools. Some of the best advice that I've heard for succeeding in making these kind of novel interfaces gain traction in the world is to be super focused on a domain. So it is cool to hear that you are happy with the domain that you've picked and are keen to just stay really, really focused on that. So if someone else were to make a general

purpose programming environment that was inspired by Cuddle and Apparatus and your other projects, what do you personally think that kind of a tool would look like and in what ways would it be different from what you're doing with cuddle i don't know i feel like it it has to be like you're always like implicitly choosing a domain that the tool is good at making things within like i don't buy the idea of like general like python is a general purpose programming language like i don't know i don't really buy that like it's like every medium has like things that it's good at you can look at like something like hypercard or something it's like general purpose but it's also very domain restricted to like certain kinds of things. I feel like all you can do is pick a domain and then

get good at that, I guess. I don't know. Or you can do what Brett's doing with Realtalk, and that's more of a systems-level operating system kind of project with similar

kinds of values and approaches. But I guess I'm not buying the premise of the question i love it and i think what i meant by it not to not to try to constrain or invalidate or anything like that your response but what i think about when i think about that is that there might be a notion of openness or closedness to a design, like maybe in terms of a degree of focus in building something and in imagining how it might be used. And then in finding people and evaluating how they use it and seeing what they make with it, you can see the limitations that they run into. And so that's just where that curiosity came from. Like you specifically said, hey, we're probably not going to add gradients to Cuddle

because that's like, and in hearing you say that, it's like, of course, because the goal is to make something that gets you away from the computer. And adding gradients doesn't help you get away from the computer and back to working with something, you know, that you can hold in your hands necessarily. And I guess the only other thing that i'd be curious to hear if you have more thoughts about is like is there something that cuddle is doing that's there to focus it on this domain of cad and cnc where maybe taking that thing away from cuddle would broaden its usability i guess like what what

drives it's like there's there's principles that i'm sort of using in all of these projects and then for each individual project it's driven by some sort of particular examples that it's trying to be good at making those examples. So for example, with Apparatus, I had made some explorable explanation kinds of things just using JavaScript with a canvas and that kind of stuff. And then I was like, well, what if there was a tool using some of these principles that could make that thing? And so then Apparat is a good tool but it's not great in the same way that like writing javascript is like a good tool for making explorable explanations but that's not great so then i started making cuddle like focused on that

and and now like the community is sort of driving how the pieces evolve and each domain i think does like encourage certain kinds of certain kinds of sophistication and certain kinds of like moves that you make when you're like adding functionality so for example with cuddle like you can make a modifier that, like, rounds all the corners, but often in CNCing, you're like, well, I want to round all the corners except for this corner. And it's like, well, what's the abstraction mechanism for that? We don't actually have a great answer to that right now, but that's, like, a big thing that we think about. So it's like like that's driving the abstraction mechanisms in a certain way that like well how can you do a thing but have some exceptions to that thing and that's different than like the things that are sort of driving apparatus like an apparatus there's this cool

idea that we don't use in cuddle that's like uh there's like this sort of back solving mechanism where you can write a formula that says well i want this you know say i'm making a planet going around the sun diagram and i have a formula that based on the time the planet's going to be at this location then you can also do this back solving thing where you make the planet an interactable object that you can then drag and then that changes the time so rather than time driving the position position can drive the time and that's actually really cool because it like lets you make sort of generic like drag and drop user interfaces so like i think in the apparatus demo i make like sliders and then you know you

can do all these things with sliders but you can make all these other kinds of ui things so i think like depending on what domain you're in like that determines sort of what what you're trying to invent to make that domain more like just make a better experience to be working in that domain and then it's a like co-evolutionary process so like apparatus is probably more general purpose because you can like the things that interactive diagrams take you to is sort of like what you need to be making arbitrary screen interfaces. So it's like more general purpose if you're trying to get towards more screen interfaces. If you're trying to get towards more interfaces, because there's, I think, a sort of an essentiality that people feel about

general purpose programming where like their success criteria is, can they use it to make more so-called general purpose programming? And it's, if you step away fromcalled general purpose programming and it's if you step away from that for a second it's like actually you haven't made something that is truly general purpose you've just kind of defined general purpose as being able to make more software and that's a powerful thing to be able to make more software but like it's not it's not the be all end all of things there's a couple of other features that were in apparatus that i think fall into that bucket where it's like these are features that were very clearly made because apparatus was pursuing that goal of being useful

for making explorable explanations and to me as, as somebody who was very fond of Apparatus and goes to Cuddle and not having any participation in that maker community, I look at Cuddle and I just see the absence of these capabilities because I'm that person who's like, I'm thinking about making more software. And so I see those features. Like in Apparatus, the control that you have next to certain properties

where there's a little circle you can click, and then that means that whenever you drag on the symbol on the canvas, you're going to be manipulating that property, and it triggers the back-solving. That's not in Cuddle because that's not what cuddle is for right yeah um or even uh in the in the strange loop talk about apparatus you mentioned that one of the future potential goals for it was for the interface of apparatus to be bootstrapped i can imagine that that is absolutely not a goal for cuddle yeah it's not it's not something that is like high priority i guess

on the other hand we do a lot of like bootstrapping in cuddle at least for sketching whenever there's like a geometry algorithm that we're trying to figure out we'll often just open up cuddle and like start making it within cuddle like because it's so easy to to live program but then also like make geometry appear and then like you know like like algorithms like say you have a bezier curve right like a cubic segment and you want to be able to drag on the on the oh it's so hard to do a podcast where i can't gesture and like draw drag on the mid on the middle control point kind of thing or yeah but not a control point just like anywhere like you're stretching it like it's a string oh yeah yeah right like which is a common gesture and it's in cuddle you hold option and then you could stretch on the thing like it's a

string um it's not there there's no uh there's not a single solution to that like mathematically like the curve could do all sorts of things and it would you know be correct so to speak but you're trying to find an algorithm that like feels good that like feels like you're pulling on it and like well what do you want out of that algorithm and like so like when we were prototyping that like we just did it all within cuddle so it's still even though it's focused on on cnc and and um and cad it's still useful as a tool for thinking about geometry because it's a tool for geometry. Yeah. So that's an interesting interpretation of the term bootstrapping in that the impression that I got was if you were to bootstrap Apparatus,

it would be that the user interface was created using the same components and the same kind of back- and and inheritance and that that you would be using as a user of apparatus just um like and and maybe there's some way to like pop the hood on that and to go in and reconfigure the interface and is that and that that is a powerful notion of what bootstrapping is but yeah i I guess I was thinking of it more in a mental model sense, sort of, and the analogy would be like when you're saying that, like, oh, Haskell has lazy evaluation. And I'm like, well, that's just the evaluation model. Like, it's the mental model. It's like bootstrapping the mental model using the tool. That's a theme throughout our conversation is

that my initial thoughts about something are yeah but how do you implement it in computers and your thinking is more um uh yeah but how do you implement it in like in the idea space of the of the person doing the thinking i love that um that's a that is a valuable lesson for me to take away from this conversation. So I had promised a lightning round at the end, but we ended up actually talking about and answering all of the questions that I had down there except for two. All right. So the first one is in apparatus, you can drag an attribute and it's kind of like it makes a little bubble into the expression for another attribute as a way of kind of setting up a relationship there. Is that possible in Cuddle, or is that something that you decided not to do, or is that something that's just not there yet?

I can imagine it not being there yet, but it is true. Apparatus, the way it's not, references aren't done using names. They're done using like sort of unique identifiers, and then the name is just a label on the identifier. And I think there are some other, so Subtext had that. The name is just, it's like the difference between the name being meaningful to the computer and the name being a label that's only meaningful to humans i didn't want to like like i thought it was important for cuddle to be both approachable by existing programmers and also for people who are not programmers they can at least like if they start learning cuddle then it's like not too far removed

from like what their real world programming experience so to speak would be not by real world like status quo like i like the idea of someone being able to like learn javascript by doing cuddle and then being able to leverage that learning for other things in their life even if i don't think j think JavaScript is like the best possible programming language in the world. Anyway, that's just a way of saying that like a lot of the, so I am using just names in Cuddle, for better or worse, not trying to innovate the language too much. Does that mean if you you if you declare a variable at the project level and then you use it in a couple of places if you rename that variable does that

renaming propagate to the places it's used or is it just it it does but only in the sense of like the ide is smart enough to understand where you referenced it and it changes it but you can shadow variables uh yeah yeah and that's something i guess you couldn't do in the apparatus model is do that kind of shadowing yeah well that's the thing it's like in that like unexplored abstraction world like what can you do shadowing like maybe i haven't explored. Yeah, totally. I don't know if this is a good way of thinking about it or not, but to me, Cuddle feels a lot like the relationships that exist between things in Cuddle feel very much like the relationships you get when you're building code versus in Apparatus,

it felt more like the relationships that existed were more like data relationships like in the inheritance model for instance or in in this example of variables like it sort of feels like in cuddle in the way that you've described it in the kind of the analogies you've used you've talked about it being very much like about um like you're trying to make the things that you're building in cuddle feel like code and to me that's that's not how i would describe how i how i as a as an outsider felt about how apparatus worked yeah yeah it's very intentional and that's because apparatus was designed in a context of like, I was at, you know, this research group and like the imperative was to try to push the limits and like explore more.

So that's why it took all these interesting experiments. But with Cuddle, the idea is both to be practical, which means like being familiar, even if it's like not quite the optimal thing it's the familiarity counts for some points um and also i guess like it's more conservative because it's like the same structure as how you would code up your geometry if you were doing it purely with code. And it gives you that nice escape hatch into JavaScript, and the two sides can kind of work nicely together. And I guess the last question is, back when you were doing your presentation, your first

presentation, at least the first one that I saw at, what is it, IPT? Is that what it's called? ITP, Interactive Telecommunications Program. Yes, there we go. at least the first one that I saw at, what is it, IPT? Is that what it's called? ITP, Interactive Telecommunications Program. Yes, there we go. And it took me so long to find what that acronym means. It's like not anywhere on their website, but yeah. Well, everyone thinks it stands for Interactive Technology Program,

but apparently it stands for Interactive Telecommunications Program. It's a wonderful program, by the way, for anyone who's looking at something like that. It seems super cool. And I'm going to include a link to that presentation video that you gave. And when you were introducing recursive drawing there, one of the inspirations that you talked about was the movie Inception, in that it allows you to have... it's it's been a while um and that that movie is about having shared dreams and that maybe one of the long-term goals that you had that 10 i won't say you had that 10 years ago toby

had uh was this sort of a multiplayer multi programmer kind of like collaborative sort of vision for working together on on these kind of shared creations and in asking this question now I can I can once again hear myself falling into the trap of thinking ah that means you know the answer to this is like figma style we're gonna make it so that multiple people can move their mouse cursors and you see where everybody's mouse is going. And I'm not to answer this question for you, but I bet you're going to say something about, you know, it's about getting away from the computer into the shared world with other people. But, you know, to now to give you the chance to answer this question, is that still a goal of

yours? And in what ways do you that that you're still pursuing that goal well i think that was like the the shared goal that we had for dynamic land and brett is still working on dynamic land and i hope to still be orbiting and engaged with that project in the years to come. I mean, it's supposed to be like a 50 year plus project. So I would say that cuddle is more of a, it's, it's a different, I don't know. Um,

it's its own project, I guess. Uh, and I would hope that it allows us to create things that lead to shared experiences. I mean, like the reason that I would make anything laser cut is because I'm trying to share it with people in physical space together. And, you know, whether that's like art installations or sculptures and the you know something with like the pandemic from last year is like because there haven't been any uh events whether that's like festivals or gallery shows or anything like that my my art practice has been withering because i can only do i guess i can

only do art when i have a like a venue like and when i understand like what's the space and like what's the context so hopefully i can like bring some of that energy back with things starting to reopen well that's a uh i think a beautiful sentiment to end on before we go i just wanted to uh give you one last chance if there was anything you wanted to refer the audience to or point to as uh something that people might be interested in seeing but that didn't come up during our conversation today well i mean like the takeo igarashi reference like both pegasus but like all of that group's work is definitely worth looking at they have sort of a i feel like a different perspective on how to create creative powerful but playful interactions and then something else i thought of when we were talking

about you were saying how like you know everything that i've been making is like uh an interface for creating a program that generates an artifact um there's a i really like the foreword to Essentials of Programming Languages, which is this book. The book itself, I haven't really been able to crack too much, but I really like the foreword, which is written by Hal Abelson, I believe, about sort of how one of the great ideas you can have as a programmer is like when you learn that like everything is a program and you can write an interpreter for that program and it's it's just like a really powerful perspective to have and something that i think i was doing at the time but reading it there sort of cemented it as like oh oh yeah, that is what I do all the time. It's like just being able to write interpreters, I think is a good skill to have.

Toby, thanks so much for letting me interview you today. I think this was definitely one of the most out there interviews that I have done so far. So thank you for going on that journey with me. I had a good time. Thank you. So that brings us to the end of the episode. That was my interview with Toby Shockman. Like I said at the top, kind of a different vibe than the other interviews that I've done so far but I just to kind of speak extemporaneously for a minute here as I am wont to do

I kind of like this it's something that I'm going to need to hone in on a little bit more in the future interviews to try and strike the right balance between as we remarked on dead air and actual you know things that are said but i think that the the podcasting medium is still very young and it doesn't need to mirror the sort of the the

format and the norms that have become common in things like television interviews or radio interviews where they have a a sort of a fixed schedule that they have to hit and they have to be approachable to a very wide range of demographics. I think that with a podcast like this, where it's speaking in a really particular way to people who are doing a really particular kind of work and have a lot of shared background and shared culture, but also we're gradually taking new people out of the mainstream crop of programmers and bringing them into this, these new modes of thinking and these new approaches to making software, et cetera. I think that there's room for the podcast to just stretch a little bit away from being a more traditional interview format and getting a little bit more into collaborative

thinking and about exploring subjects in a way that's hopefully reaching a little bit deeper, even if that's kind of a risky thing to do. So hopefully you will stick with me as we continue to explore what this medium can be. And as I personally grow as an interviewer, because this is a new skill that I'm working on that I have just a tiny bit of practice with. But hopefully through many episodes to come, we'll find a rhythm and an approach that really sings no matter who the guest is and really, really puts the spotlight on them and their thoughts. Thanks so much for listening. Thanks again to Toby for coming on the show. And I will see you in the

future Thank you.