Future of Coding - Exploring Dynamicland - Omar Rizwan

Episode Date: August 27, 2018

Many of you have heard about Dynamicland, Bret Victor's new project. Omar Rizwan comes on the podcast this week to tell us all about it. He recently wrote an amazing write up about it, [Notes from Dynamicland: Geokit](https://rsnous.com/posts/notes-from-dynamicland-geokit/), that I'd highly reccomend to everyone interested in the future of computing. futureofcoding.org/episodes/28Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Welcome, Omar. Thanks. Great to be here, Steve. Yeah, really exciting to have you on. So, you get credit for being the person to first put me on to Brett Victor, which is a pretty big deal, given what a big impact his work has had on my life. So, thank you, I guess, or not. My girlfriend, who is tired of hearing the name Brett Victor, probably wouldn't thank you, but I'm happy that I know who he is. Yeah.

I thought it would just be interesting to set the scene. I guess I was in my freshman year at Penn. You were in your first or second year of the Teal Fellowship. I don't actually remember. Yeah, I mean, it was definitely at least like a few months in if not the second year cool and um and i had a team that i was going to go to this hackathon at pen pen apps with but they dropped out the last minute so my friend uh i think james was like oh well i have these these three teal fellows that are coming and you know teams can be up to

four people so why don't i put you with them and i was like yeah i felt very lucky that sounds great um and you guys were very nice in uh accommodating me as an addition and and that actually that was the first weekend i ever programmed in javascript uh javascript really i didn't know that i think at the time you knew it because you taught me JavaScript. Now I'm like JavaScript, you know, like that's my favorite language. I'm like really intensely a JavaScript programmer. I mean, that's, that's, I think that's like a, that's almost like an industry wide thing over the last few years.

Like you've, you've tracked like everybody else in that way, I think. What do you mean? Like in that, you know know like now everybody who like now tons of people are doing this javascript stuff yeah yeah well that's an interesting perspective my perspective on it was um i had only done academic computer science up until that point which means scheme java haskell you know all the all those languages and so i was just so excited to be building a thing that's actually a product on the internet. And you were like teaching me what these callback things were. And I was just so confused, but you did a great job.

We made some good progress. Yeah. And that was a fun, it's also funny because, you know, often you get people who are like, you get people who are kind of trained in industry, who are very familiar with JavaScript, who are very impressed by like the academic, you know who know haskell yeah of course um there's wisdom on both sides um but anyway so the scene that i remember was you and i were sitting there kind of nervously waiting to present what we built uh and we're like kind of like what like

half-heartedly watching everybody else's presentations. And I don't know what I had said, but you were like, you really like this essay. You pulled up learnable programming on your computer and put your computer on my lap. And I started reading and I was like, I can't read this now, but I'm definitely going to read this later. And that was the beginning. Yeah, and you did read it later, which, you know, I'm glad you did. Yes, that is a thing um i've recommended that essay to a lot of people but i think i can only remember one person actually taking me up on it and reading it all the way through and it took her a while you know because it's a long essay and it's dancing yeah there's a lot in there

so so anyways that that's the story of how i got to know victor i was wondering if you have a story of how you heard about him the first time. Yeah, it is actually a story. So a couple of years before I was in the fellowship and before I was at Stanford, I had been working for a few summers at Khan Academy, the kind of education, nonprofit, startup type thing. And the summer before I went to college, they were doing this new computer science system where people could come in and learn how to program. It was like this classic Tupain,

Brett Victor style programming environment where you could make live changes to the code on the left and you'd see a canvas on the right. So I was not working on that system, but it was a small organization. I knew the people who were working on it, and at the end of the summer, they released it in August or whatever. And when they released the computer science framework, they citedtt's work as a big inspiration to them and like getting them to make this two-pin structure and having the scrubbing of numbers in this live programming system and so i went and i looked at his stuff and like i just remember like you know i watched the inventing on principle video and then i just sort of spent the rest of

the night like looking through the rest of his website um because I've been so excited by the video and like I posted it you know in these Facebook groups I was in at like three in the morning um all this other stuff and so that was how I got got into his work uh for the first time and then it became you know from that August on into the school year it sort of became this motif where I'd share it with people and like look at it every once in a while and you know I think he he came and visited Khan Academy like in October and I went you know I made the trip from Palo Alto to Mountain View and like you know saw the Q&A so there were sort of a bunch of opportunities for that work to keep coming up and I think that was what part of why it stuck in

my head so much in addition to the like addition the initial exposure being so impactful to me yeah that's interesting that that's where you you initially uh entered into this world and i just want to connect the dots there because i i recently learned that um johnzig, who works at Khan Academy and was behind that environment, was at that talk, Inventing on Principle. I think he was physically in the audience. Oh, really? I didn't know that. I recently read that in an article somewhere and I was like, oh, wow.

Okay, so that's kind of where... Inventing on Principle happened, then John Rezig made... John Rezig, who's also the creator of jQuery, made Processing.js on this environment. And then, to further connect the dot, then Brett, kind of in a ranty way, criticized this environment that you're talking about that Khan Academy made to say that they kind of missed the forest for the trees. They took his specific examples, but didn't quite understand what he was getting at through them uh and so that's that's where the essay learn more programming the one you showed shared with me came yes yes yes so this is all one big really um like all these things are very deeply connected yeah yeah they really are and uh you know i was i think he released that

essay in the fall so i wasn't physically there you know, I saw some of people's reactions. And I think certainly John was not – he wasn't thrilled just on an emotional level at the response from Brett. Yeah, well, I think we've all – at least I've been there. I've also made Brett victory things and had Brett be less than pleased, then I'd be very sad in response. Yeah. Yeah. please then i'd be very sad in response yeah yeah um but that's something that i think we all uh end up dealing with yeah yeah but victor uh we're seeking his approval um i guess on that on that note you've made a lot of projects very much in the spirit of of red victory inventing our

principal things um i kind of want to list a few of them uh you have um this it looks like kind of like a game simulation thing where you have a ball that drops and and you can like see into the future that's a very bright victory you have a geometry workspace where you can like figure out like geometry math problems it seems very paperty like paperty or like alan k would be into that too. Yeah. Maybe the most obviously Brett Victor thing you have is Cruncher, which is like it's a literal programming environment where you can put numbers and connect them to each other

and scrub them and they're all kind of connected in a cool way. And there's a nice graphing facility, which is great. And that was explicitly inspired by Brett's scrubbing calculator concept. Yeah. And then also recursive explanation editor. That seems also very related to a lot of the ideas from Alan and Brett. Yeah. I mean, one way I think of that one is that it's like trying to figure out what kind of structure would be useful outside of quantitative, you know, simulatable areas,

what kind of interactivity would be useful, what kind of, you know, what, what, what can the computer do to help you with that kind of writing? Yeah. Fast, fascinating. Each one of these is like a fascinating area that can, that I think would be interesting to go further down each, each branch of the tree that

these projects have started. So maybe I'd be curious, because you have so many of these projects in this world, I'd be curious to know kind of how you decided to work on these, why you stopped, what you learned, if you're ever going to continue in any of these directions, that sort of thing. Yeah,'s it's it's a great question and you i think it's worth understanding that a lot of these are in the context of the two-year fellowship that i had where i had you know a lot of flexibility and uh and so i would kind of work on whatever i was interested in at the moment and a lot of these are also in the context of me trying to learn and this is this is something maybe more prosaic a lot of these are also in the context of me trying to learn. And this is

something maybe more prosaic. A lot of these are in the context of me trying to learn some particular technology. So for example, the scrubbing calculator was also, I think, the first, you know, kind of web project that I had done. You know, I had done web-related work at Khan Academy. I'd like written little exercises, but this was one of the larger projects uh that i'd done kind of from scratch on my own got it um and so did uh so speaking of brad victor approval and disapproval did did he ever look at any of these projects and comment positively or negatively yeah um you know the scrubbing calculator was actually what got me in touch with him for the first time uh and i think and i've uh presented a few others uh when i went out to the lab and fred had a workshop with a bunch of us in 2014 got it yeah i think you might yeah who else was there if you don't mind i could

i like the like the social aspect of how everyone yeah so this was the uh this was the explorable explanations workshop um nikki case was there that was kind of how we first got connected even though we were both also in the fellowship um oh he's a teal fellow i didn't know nikki was a teal fellow yeah um i don't think it's like super widely known, but. Cool. I'm going up to Boston next week to hang out with him. Yeah. Nikki was here for a lot of last month. So we spent a lot of time hanging out. Yeah. Mike, Michael Nielsen, Manish Agrawala, who's a professor at Stanford now.

And that was kind of how I first got connected with him. Amit Patel, the Red Block Games guy. Yeah. And there were kind of 20 people who were all doing stuff in this area. And so it was great to meet all of them and also great to spend a few days in the old CDG lab in San Francisco, the lab that's now evolved into Dynamic Lamp. Yeah, yeah. Oh, man, what an amazing all-star crew.

That sounds awesome yeah um cool so um so you did the teal fellowship you made a bunch of these projects and then you decided to go back to stanford and finish your degree so i'd be curious to know why you decided to do that and and how that was yeah it's it's a it's a, it's a good question. I mean, from my point of view, you know, I wanted to continue with some of the projects I was doing and it seemed like it would be difficult to do that if I went and got a job or something, you know, a lot of my friends who had done the fellowship had kind of ongoing startups that they just kept with, kept going with after the fellowship but that was

not something that I was involved that you know that wasn't the case for me um so it was a question of like okay what do I want to do next and uh yeah I went back to Stanford and I actually you know I had been there for one semester before the fellowship and I actually completed the degree in two years so it was you know it was considerably faster than most people. It wasn't like a four year commitment. And I also, you know, by that point, had a much better idea of what I wanted to do. You know, I was I knew I was connected with professors at Stanford, I kind of had a good idea of what kinds of things I wanted to learn. And so I found it actually quite useful, I think, in a very different way than it would have been if I had just stayed continuously rather than taking time off for the fellowship. Oh, interesting. Are there any professors in particular that you worked with or

you benefited from? Yeah, Manish, Pat Hanrahan, who's in graphics, have been, Stu Card, who is one of the original Xerox PARC people, who's now a professor emeritus at Stanford. Those are the three faculty that I've really worked with a bunch on this kind of work. I mean, they're all familiar with Brett's work. And now you have a pretty cool situation where you're working with someone. And I don't remember exactly the situation but it seemed like a pretty nice setup at a university um where you could work

on these sorts of projects who's that that that's that's been with pat um and also you know i also meet with the other faculty and that's been the situation for a bit over a year now. So, I mean, this is like, you know, the way academia works is that, you know, if you have an advisor who's willing to work with you on your projects, then you can do your projects, right? Cool. And so you're pursuing a degree with these? Yeah, I'm a master's student,

which, like for a lot of people at Stanford, I think the master's degree is a way to stay on and take more classes. But for me, it's more been a way to have that time flexibility to just continue doing this kind of work. Cool. That sounds like a great setup. And I know that you've used a lot of that flexibility of your time to spend time driving up to Dynamic Land and hanging out there. Yeah. When did you start going to Dynamic Land? So they opened the lab up. Well, they sent an email to everyone on their kind of mailing list of friends almost exactly a year ago, I think, saying, hey, we have a working system.

We're going to have an open house like this week or whatever. So a bunch of people came up. We went to the lab. We saw the system. So that was the first time that I really came in. I would say it took a few months for me to really understand, okay, when can I come in and play around with the system? I think it took them a while to figure out what exact policies were,

and it took me a while to be comfortable coming in. Yeah. Well, so part of what I want to do with you on this podcast is uh is like articulate what dynamic land is and i think it's very hard it's quite difficult yeah it's very hard so i don't think we can just go at it directly i can't just say like tell me like in a few sentences what it is i think we kind of i think that's been that's been the approach that has been tried before and i think it mostly fails as as an approach yeah so one idea i had was i'd be curious to get your like initial impressions That's been the approach that has been tried before, and I think it mostly fails as an approach.

Yeah. So one idea I had was I'd be curious to get your initial impressions, if you can remember them, and maybe go through and have your understanding of it deepened over time. Yeah. And maybe give some anecdotes. That's one approach. Do you have another way of elucidating? I think that's a good approach. All right.

It is kind of something I want to talk about anyway. Okay, yeah, let's hear it. So what were your initial impressions? Was it profound or you didn't get it at first? I didn't get it, like, at all. I was pretty unimpressed, I would say. Oh, that's fascinating. Yeah, and I think this is, like, not,

I think this is a common experience, especially among people like you and me who are familiar with the earlier work or programmers. You know, I was, I was like not super impressed with the system. Yeah. Yeah. Like, cause we look at Brett's work and it's like so dynamic and magical. And then you show up to the dynamic land and it's like all flat and paper. Yeah. And I think, you know, it lacks, like there's this smoothness that maybe he inherited from apple

that it lacks in in little ways yeah yeah okay so um so like maybe paint the scene so you show up in the lab and and what what is it that you're looking at that's so unimpressive to begin with um i would say there's there's two things uh the first thing is the low quality of the demos that are everywhere. So one thing to point out is that in August of last year, there were only pretty low-resolution projectors. So basically, you would just see these shapes moving around. The text would have to be two inches tall each letter for it to be readable and then the second thing is is the editing experience where to do anything you have to pull out a laptop to edit pages so despite the pitch of dynamic

land being that you can get rid of your laptop in practice anybody who was working in the space was on their laptop. Yeah, yeah, that does sound like it doesn't live up to its own promise. So maybe I'll just backtrack a second. I'm realizing now we should maybe give a brief explanation that what you see, like the core technology is that there are like projectors on the ceiling pointing down at tables,

and there are also cameras next to those projectors detecting what's going on in those tables uh so that's like the basic hardware setup and then there's like software that that handles a lot of the basic tracking of pieces of paper using these dots you may have seen on twitter and it associates paper to programs that are also printed on this paper the piece of paper. So that's kind of the basic setup. Maybe you can help me explain that better if you have anything to add. Yeah, I would say that's the explanation from kind of the implementation out.

I would say the explanation from the interface in is that each piece of paper is a program and you put a piece of paper on the table to execute it. And program behaviors can be like, they want to draw something on themselves and then a projector will do that. Or, you know, they want to do something based on where the paper is or other pieces of paper that it's pointed out. But, you know,

there's this conceptual idea that like this piece of paper is that program and the program code is printed on the piece of paper. Got yep that that makes a lot of sense um okay so so those are your initial impressions so why did you keep coming back if you weren't that excited um i think one big reason is that like you i was so impressed with brett's earlier work that I was like, okay, if these people and Brett's, the other researchers in the lab also had done pretty interesting work in the past. If these people are working on this, they must think there's something there. So I want to hang around here and see what is the big deal. Why are they interested in this system?

Yeah. Okay. And did what did you do there for the first few times what were you building or working on uh so i think the first time that i built anything it was uh this little bart this is almost an embarrassing project it was was just a little BART map. So it would show where BART is like a subway system in the Bay Area. So it was this big kind of poster-sized piece of paper. And it would show you, it would basically just draw the route lines of BART, like geographically. And I remember, so it was, so you put it down, it would basically show these lines, then it would also show the station names and like dots where the stations are. So it was basically like an internet API thing, right? Like it

would go to the BART API and like get this geographic shape file and then render it to this poster. And I remember, you know, showing it to this poster and i remember you know showing it to other people and like grabbing this little dot robot that was a line follower and putting it down and just followed the bart line in the same way that a train does in real life which i thought was pretty cool and that is on twitter somewhere interesting and so was that like exciting you know what was your impression of that? Because I feel like even there, you start to get a sense of how things are so composable and dynamic. Yeah, I think the little robot was the most impressive thing.

And also, I added a little thing where you could put a dot down. It would highlight what station was nearby. So I think those two physical interactions were the thing that impressed me, but I wasn't impressed with, I still wasn't impressed with the programming experience building this thing. And that's part of why I say I'm a little embarrassed by it, because it's a very, in my view, it's a very typical programmer's first project at DynamicLand, in that it's so, like, talking to the internet, you know, rendering a bunch of stuff. Interesting. Yeah. So it sounds like there's really like a, a dynamic land style. It's different. It's almost like, um, you can tell when someone who's like from the eighties is building a web app.

It looks like, Oh, I can look at, yeah, that's a great comparison. Yeah. Interesting. Yeah. So, so, um, talk more about the dynamic land style. What's different? Like, how can you tell if someone's building something dynamic land thing I write about in the post that you've mentioned earlier, this post about one of my dynamic projects, is that it's not idiomatic to have a program that's more than one page. You should split it into multiple pages so that there's this modularity and so that the pages are individual objects that you can use and so like if you see a lot of programmers who come in you know they'll sit down and they'll point the keyboard at a page and then they'll just like start programming

and they're basically using the page as though it's their laptop display yeah yeah i i went there and i did that i'm yeah i think i think you i think you transcended it at some point like i don't even know if if there's a way around that like i almost think at this point everybody just has to go through that phase if they're a programmer yeah that makes a lot of sense so i i just want to like linger on this a second because it's like a profound point that i don't know if it comes across so in what you just said is that in dynamic land um a program is not supposed to be longer than a like 8 by 11 white sheet of paper like printer paper like there should be no program longer than 70 70 73 lines i think is the equivalent in lines of code that are on the page. Yeah, so 73 lines of code.

And then there's also comments. And also, you really don't want any line to go beyond, like, 80 characters or whatever, because then it literally won't be on the page. Right, right. So when you put a piece of paper on the table, it executes that code. And the way it's not reading the code on the paper, it's reading the code based on the table it executes that code and the way it's not reading the code on the paper it's reading the code based on the dots and on the corner of the paper but the idea of dynamic land is that humans should be able to like read the code on the

paper whenever they want the system should be inspectable in that way right and i think we want we want people to think of it as though the system is reading the code on the paper. That's a productive way to think about it. Then you can imagine being able to cross things out with a pen, et cetera. And actually knowing that you crossed it out. Yeah, that's, I guess, the dream. There are no dots in the corners. It's actually a camera that's reading the lines of code and executing them.

Yeah. I try not to think too much about the dots because I view that as like, that's just an implementation detail. That's not fundamental to the system or the things we want to prototype about the future. Fascinating. So I think this, this aspect of it, the like very short amounts of code, very powerful abstractions, this, it seems to have inherited a lot of ideas from this, the Alan Kay's STEPS project.

Yeah, absolutely. Absolutely. Yes. Maybe you'd be better to summarize the STEPS project and explain how it's an influence on the system. Yeah. So the STEPS project was done by Alan Kay's lab, which was kind of one of the predecessor labs to the CDG or the dynamic land lab.

So this was down in LA, Alan Kay and some of the researchers from, you know, past small talk things wanted to build a new operating system, I guess. And they wanted it to be in total under, I think, 20,000 lines of code. So they wanted to,

wanted it to be orders of magnitude simpler and and more comprehensible because it was less code compared to you know windows which is millions of lines of code windows and microsoft office which are millions of lines of code and they wanted it to have you know roughly the same functionality so why why do they think this is like an important goal yeah well i think for them it comes down to comprehensibility. Like, if you have 10 million lines of code, no human being, no individual human being can understand those tens of millions of lines of code. Whereas if you have 20,000, that's something that, you know, I can write in a few months, probably. Or that's something that like an individual person can understand can rewrite it i think there's almost uh one of my friends said it was a jeffersonian kind of yeoman farmer

ethos where like anybody can come in and do meaningful stuff to the system because the small human scale system and then it's kind of that seems like the right way to think about it whereas if you have 10 million lines of code it's kind of the technology has sort of an authoritarian bent because you just need this large organization like microsoft or apple uh to be able to contend with the code and make changes to it you need like division of labor and people to focus on their little fiefdoms yeah exactly so uh when i've talked about you know the benefit of one person being able to understand things, people kind of look at me askance and say, well, of course that'd be nice, but that's just clearly impossible.

But I guess the STEPS program, that's what it is. It's saying, actually, no, this is a working system. It's not impossible. Proof by contradiction. And there were mechanisms they used to try and achieve this, like making a tower of domain-specific languages so that you had these very simple interpreters and then the domain code was very simple.

The total amount of code was not that much. Yeah, that seems like a powerful way to go. And DynamicLand is also a very small amount of code, correct? Yes. The whole system is very small. And I've seen photos or tweets that say that the system runs in itself somehow. Is that how it runs truly now? Yes.

The core of the system. There is like one cut out right now, but for the most part, you can think of it as being self-hosting. Fascinating. So, did DynamoClan use the same idea of domain-specific languages later on top of each other, kind of like Steps did to get this code reduction? Because then it's a pretty complicated system. How is it possible to be built in? How many pages of paper is it? Like 30 pages of paper? It's like a few thousand lines of code, the whole system?

I think so, yeah. So the physical is that it's all printed out on pages that fit on the front and back of two whiteboards. And I think they're trying to keep to that constraint, or maybe even shrink that constraint. So two whiteboards worth of pieces of paper that are kind of tiled on the whiteboard. Is it called Big Board or the Boardroom? What's that? I feel like it has a name.

Real Talk OS is the banner above it. So the operating system, like the pieces of paper that are running, even if they're not out on the table in front of you, the kind of core pieces of paper. Got it. Yeah, and I think one thing I want to mention is I think this is one of those properties of the system that you don't appreciate when you first come in. Like I mentioned earlier, you know, I didn't get it when I first came in. And this is one of the things that I didn't get. So which one? The fact that it runs on itself?

The fact that it runs on itself, the fact that the system is designed, like one of the design goals is this type of simplicity and understandability i think is something you don't appreciate until you've had some time programming in the system and you don't have some time programming in the system when you just come in for a tour got it so okay so the that makes a lot of sense so do i i don't know if you know the answer to this how how like how are they able to build a system that's so complicated in 30 you know or in two whiteboards back to back it's still a question that i'm wrapping my head around but one answer that i give in my post is a lot of user interface code is not needed in dynamic land um so so i give the i give the example in my post of you know i have this map system where you have

there's these individual pieces of paper that represent individual data layers like there's one for demographic information there's one for and there's one that's a normal map and you can kind of point them in order at a map to like render all those layers so you know you have these this mechanism for arranging and adding and removing layers where you don't need to implement any user interview you don't need to implement like a list view you don't need to implement check boxes to check and uncheck layers you don't need to implement like drag and drop and event handlers so i think one reason that the code there's less code is that you don't need to write a lot of the of that kind of basic ui code when you're doing

anything you don't need to write like ls to like list files you don't need to write a list view control ui component um yeah well so i think not having to write user interface code is yeah it's like a wonderful theme because you have reality reality is the interface you you don't like you can use tape and glue and scissors and like physical things uh you don't have to write code to to make pixels to to like simulate those things you can use the real thing ourselves and have cameras detect what's going on yeah or even to like take input um or like print things you don't need to write like a shell there's a there's a a lot of that kind of stuff. So I think

the fact that you don't have to write user interfaces fits into the theme I saw in your article of all the things you get for free. I guess you mentioned the robot that followed the line on your train diagram. So you got that for free. There are two things that were modularly

built and you just put them together and you get a third thing for free. Yes. Yes. So maybe you can, so modularity makes a lot of sense how modularity would get you some things for free and then also user interfaces for free. Is there anything else you get for free in dynamic lane? User interfaces, modularity. Well, I would call out that the system is sort of a reactive system. Maybe let's talk about the programming paradigm, because I imagine a lot of our listeners are programmers and they're like, what, like, what language is this?

JavaScript? Is it C? like what what language is this javascript is it c what are we talking so this is this is lua uh or it's it's a superset of lua because it's you can use lua to do normal programming normal computation but uh we've added some extensions that are real talk or dynamically and specific and just to put another phrase on that what what i found helpful is to describe it as like Lua with a few macros. Yeah. There are a few pieces of syntax that just compile directly to the Lua function. So you can just think of it as Lua with a few

code generator, just a few syntactic shippers. Right. And I should say, this is sort of like the dots in the implementation detail. We're not strictly wedded to Lua, but I think we want to keep the programming paradigm if it's the right programming paradigm.

Maybe eventually you don't write type code or maybe it's like a custom language or something, but there's a lot of things that I think are genuinely part of the idea in the programming paradigm. Okay, so let's talk about the programming paradigm. What's the basis? Yeah, so as I said, I think of it as sort of a reactive paradigm. So there's kind of three of these macros that have been added. There's claim, wish, and when.

And I think these originate in natural language data log, which is like a related earlier project. And so you can, when you're writing a page, you can make claims, which kind of attach, which are claims and wishes, which are sort of statements that go into this global database. And then other people or you can use when to match on statements in the database. So one example is in this map post about my map system that I did, I make a page that represents a map of San Francisco. So I write on it, you know, claim I'm a map of these coordinates that are San Francisco.

And then I have a separate page. It's like a map engine that looks for all the pages making that kind of claim and then it knows how to draw san francisco on them interesting okay so why yeah why does this make sense i like what i it's not intuitively obvious to me why that's like it's a good paradigm yeah um it's i think one of the big things that um yeah what i i think one reason it makes sense is that it decouples like it decouples basically everything from everything but it decouples the mechanism from the goal so for example if i want to draw something i say you, you know, I wish this page has this illumination with these shapes on it. And then anybody else can fulfill that wish. And, you know, in right now, the projector will and it'll render the shapes on top with projected

light. But you can imagine maybe there's like a little pen robot that will draw them instead. And so this decoupling, this decoupling makes a lot of sense, I think, for this system because you have created pages implementing behavior and you're often changing like one page at a time and leaving the rest the same. So you don't want that kind of strict binding early just when you make function calls. Interesting. Interesting. Yeah, so a wish, like, I can't say do this thing, and then when it's done, let me know.

It's more of a, like, I wish this were the case, and that wish is just out there, and I can't, you know, assume that it's going to get done by somebody. Yeah, and, or if you make a claim about something you know that data is just out there and somebody may use it and multiple people may use it which i think is one of the advantages of this kind of decoupling is it makes it really easy to introspect on the behavior of other things um because like if you make a function call nobody else other than you and the callee knows that you made the function call but if you make a claim or wish, you know,

others can introspect on it that they can translate it into other claims and wishes. It creates a much more open, open system. Yeah. This, this is a very intense decoupling. It's like, instead of, yeah, calling functions very specifically, you're just kind of, yeah, you're, you're, you're pushing things into a queue or a database and then other things are grabbing them out of a queue. It's very decoupled. Yeah.

One thing, one other property I'll call out that came up, we were messing around with this last night with a friend of mine, is that this also, there's a kind of natural, multiple things are able to happen at once. So one example is if I have a page,

I can wish that the page is labeled with some string. So I can wish it says hello world and then a render hello world. But if multiple people wish that a page has different labels, like maybe one says, maybe one page wishes that it says hello world, another page wishes that it says goodbye. It can just do both, right? Like you can just say hello

world at the top and then goodbye at the bottom. So, I mean, that's a very simple example, but there are a lot of little things like that where multiple behaviors will just stack or will just happen side by side in a really easy way. Yeah. Well, I think composability is, is really when you, when you really reduce coupling like this, you get so much composability for free,

which is what we were talking about before. Yeah. And like one, one idea in particular comes to mind. That's something that happened with you and I, and I think also like epitomizes collaboration. Yeah. You know what I'm getting at?

Yeah, I know exactly what you're going to say, but go ahead. Yeah, so I was working on this, I was at Dynamo Clan for a week and I was working on this number system, which I'll link to because it's better seen. But it's like, I called it like spreadsheet in the world uh you can have numbers or lists of numbers you can add them and multiply them and divide them all by just moving these pieces of

paper and putting poker chips uh like colored dots on top of the piece of paper which would you know if you put a one that's you got a blue a blue dot maybe that's a one and a red dot's a 10 so that would be 11 if you had them on the same paper so i was working on my number system and omar was working on his map kit i guess but i don't know if you if you knew it was going to become a kit at the time did you yeah yeah um i think i had it in the i think i had that in the back of my head because i was wanting to move into this more idiomatic like kit making territory But it was very unclear what would exactly be in it. I was just playing with drawing maps.

Yeah. So Omar was playing with drawing maps. I didn't quite get what he was doing or why. But I saw that he was playing with drawing maps. And I was playing with my number adder thing. And at some point, Omar needed a number input to his system. And I had named my, like, I had made a claim about that, like, I am a number and my his system and I had named my, like I had made a claim about

that like I'm a number and my value is four or something. And you had a number system that had a slightly different convention, but you just changed to mine. And all of a sudden, we just slid my number over to your system and you had a number input

and it worked with all of my functionality and all of your functionality just immediately composed, and it was quite satisfying. Yeah. Like, it was like you moved yours over to mine that was, like, fixed zoom, or it was like you could customize the zoom by changing the numbers your way. And then I had, like, a slider to, like, zoom in and out,

and I just moved that over to yours, and now you had a slider that you could put in your spreadsheet computation graph. Totally, yep. I think the composability there, I think there's a few things in there, but the two things I'll mention are there's the composability and there's also just the physical being able to just physically slide

programs over to each other rather than having to rip some code out of some giant library and pasting in the other library or like figure out the api bindings it's like okay okay so hold on we want to collaborate now okay so let's install git all right so you're gonna create the repo i'll create the repo all right so you pull you clone now all right great you know it's just like cooperation between two programmers on computers well first of all we wouldn't have even known that collaboration would

make sense because like i'm on the screen you're on a screen i can first of all, we wouldn't have even known that collaboration would make sense because like I'm on a screen, you're on a screen, I can't see your screen, you can't see mine. And the screens aren't big enough. They're too personal. So we wouldn't have even known to collaborate.

And then the cost of getting started collaborating would have been so high we would have never even really considered it. And then of course, the mechanics of it are just terrible. So yes, I think to me and then and then of course the mechanics of it would just are just terrible so so yes i think to me that really epitomizes the a lot of the benefits of dynamic land all in one little story yeah yeah um so one on the on the negative side i want to just kind of get your

thoughts so i'm also a big uh i've been indoctrinated in this idea of the comprehensibility. This Jeffersonian style makes a lot of sense. And I actually just finished writing a paper about the comprehensibility of reactive systems. Yeah. And my claim is, or my perspective on this issue is, I take a very, very different angle. I think the angle that decoupling is is quite bad uh it's very it's very wonderful to write decoupled programs and you get a lot of composability for free and it's it's nice but then on the comprehensibility perspective if you come to a complex system and you're trying to understand how it works you have really a hell

of a time with it because everything's decoupled you have to like basically my argument is when things are decoupled you have to read every line of code and in your head put together how they they make sense as opposed to a system with tight coupling done well you know not not to say tight you know a system that really lists all of its dependencies basically explicitness is what i'm getting at yeah really makes things comprehensible you know it's harder to write that way and it's also hard to understand but but for complex systems it's really necessary i would argue so what's what's the response of your response or the dynamic response to that criticism yeah well i think um if you have less code you get a lot for free in terms of uh like you're kind of, you have it in it. Yeah. And you also, like, you know, one comparison I'd make

is like, a lot of people say, if you have static types, then it'll catch a lot of bugs. Or if you have tests, it'll catch a lot of bugs. But another way to have less bugs is just to have less code, because then you don't have as much code to check for bugs, or that can be broken. So that would be the first thing I would say okay fair and then the second thing i'd say is i think a lot of it actually comes down to tooling like i think there's a tooling question in terms of like the the advantage that you put forward for for couplet for tight coupling is that well okay if you have tight coupling then it becomes really easy to follow the path of dependency from a given piece of code outward. And I think an alternative approach is,

let's go, okay, maybe we have really loose coupling, but we have inspection tools that can actually trace at runtime why things are happening. And I think that, you know, I think we still need to see, like, is that a viable approach, even at dynamic land? But I think that, you know, I think we still need to see, like, is that a viable approach even at DynamicLand? But I think that would be the DynamicLand approach to solving some of these problems is to do runtime tracing rather than to try and statically analyze or statically present these types of dependency chains. Classic. I could have guessed that would be the response. I think this epitomizes the um the divide there's the uh the interpreted uh slash like run timey people like brett victor small talk alan k scratch like it's all it's all happening dynamically in live and that's part of what makes it beautiful and then on the other hand there's the compiled people

and there's the hassle people and the typed people and and they're not as interested in life and i think we really need i i am of, I'm of the opinion that we need both and maybe you are too. Yeah, I mean, I think we need more approaches. Like I think, you know, I think there needs to be more people kind of just playing with this stuff. Like if there were another dynamic lane

that took a totally different approach but kept the principles, I think that's totally possible that you can achieve these things in a different way. One example I bring up is, yeah, I think it's a shame that a lot of the static typing folks don't go down the live programming path as well, because I think, you know, like one example I bring up is Go, the programming language, it has a really fast compiler, and so I think that actually really changes the way people interact

with it. Even though it is like a compiled, statically typed language, it has this short feedback loop that characterizes programming in Python or a language like that, where you write code and then you run it and it takes a few milliseconds to close that gap. Yeah, that really does make a difference. I've been programming in Haskell's GHCJS, you know, Haskell's JavaScript compiler. Yeah.

And like, I really, I don't want to be critical because I'm like, it's fun to program in JavaScript, but it really is hell on earth. Like I leave those sessions like angry at the world, like my family, my friends, like everyone can see that like, like, oh, sessions like angry at the world like my family my friends like everyone can see that like like oh stevie was programming in jtjs like like he is angry now yeah it's just really really shitty to like have to use emacs you know it's part of the issue that i just don't like emacs i have to use emacs and and i like make a small change i like the way

it's forced me to work is that I have to make the smallest possible modification to each program because if I make a big modification then I don't know what caused the problem so I make the tiniest modification then I have to run the program wait three or four seconds and then make another modification it's just

it's the worst but it's crazy because I love Haskell so much for so many other reasons that you know i really i really think yeah merging of of these worlds it can be the way i think of this is actually like it's all about the feedback loop um between you and the program and it's like that feedback can be the program running it can be a type error you know it doesn't yeah like i think those are both valid forms of feedback but you want to get the feedback back fast whatever yes and you want yeah yeah yeah it's

true it's true yeah i i don't know if you're you're i could probably talk with someone who's more of a hassle a person but like i i like why is it so why is haskell so slow like like can i do it's it's characteristic of this generation and i think this is why this is an understandable reason for skepticism of the static stuff is like you know if you look at the rust compiler or the swift compiler they're also pretty slow like these modern languages tend to be pretty if they have sophisticated type systems and like optimization yeah i guess like you know the idea is they want their programs to run quickly uh so they're doing all this like smart stuff to like make it run quickly but like i'm i don't

care like i like yeah i'm not building a program to run quickly i'm building a program right now to figure out what program to build and then like eventually when i want to deploy like sure then take as long as you want to make it fast. I don't care about that. Yeah, exactly. Yeah. So anyways, rant in a tangent. Let's take it back to the normal trend if we can. Well, one other thing I wanted to bring up is there's an interesting blog post that I saw last year, I think, about, and the thesis of the blog post was that there's a,

if you start with a compiler and say, I'm going to write a compiler, versus you start with an interpreter and say, I'm going to write an interpreter, it just puts you in a fundamentally different mode of thinking about what kind of language you're going to write. Yeah, so that's exactly what I'm getting at. Yeah.

Do you remember the title or author of that post? I'd love to have it. Yeah, I'll have to dig it up, but I'll definitely send it to you. Thank you. Yeah, so I think, like, in the abstract, you know, obviously there's a lot of stuff you can do with a compiler or an interpreter, and maybe we just need people to stretch their brains and be like, okay, I'm going to write a compiler,

but I want to think like an interpreter writer about live programming and, you know, loose coupling or whatever else it is. That's kind of what I think is going to happen to me eventually when I eventually make a language. That's the dream. I want to go into creating a language with the idea of both. Well, actually, I was going to bring this up later but now's a good time on your website you have the phrase uh thinking about programming as a user interfaces and that phrase means a lot to me but i don't i'm probably still listening to this podcast but

like to my family it doesn't make any sense that phrase yeah yeah so if you can help me unpack it i think that'd be an interesting conversation yeah i think i think the phrase is almost it's like in the context of not thinking of programming as this sort of formalistic you know language construction endeavor like it's like like like i think the way that i think of programming systems is like a programming, a good programming system is one that's good for people to use rather than one that has certain formal properties. And so I think opposition to a lot of the work you see in the academic field. Interesting. Yeah.

Yeah. Like maybe the formal property, maybe it's useful to have such properties in the service of having a better user interface, but it doesn't seem to me like the method you want is to just prove that certain properties are fulfilled. I see. Programming isn't like mathematics for its own sake. Yeah. That's interesting. It's interesting because I followed the trace of programming history a little bit differently.

The way that the path through it I've looked at is initially we had programming languages like they came up from like assembly and like circuits, you know, circuits and whatnot. And they were very much it was very practical. I mean, it was never thought of as an interface that's that's as far as i can tell but it was definitely just seen as like higher levels of telling the computer what to do and then it wasn't until uh scott and strachery and maybe getting their names wrong dana scott and strachery who who first was like they tried to create these mathematical objects to prove certain properties about pieces of programs to like see if like,

they were the first people to talk about denotational design and program correctness. Haskell people reference these guys a lot. And what they found was that you really can't prove anything interesting about the languages we have. They're just, they're so willy-nilly, like anything, you know, can do anything to anywhere.

We have like no idea about correctness. And I think that's where, there's a really famous Turing Award lecture. I think it's, can programming be liberated from the von Neumann lecture. Where he's like pulling on their work and it's like, my goodness, we've got to make better programming languages that we,

that we can prove things about that are mathematical. And so from anyways, I'm kind of taken with that line to history of like, cause to me the reaction of like, of like, Oh my God, like how can we have, how can we let people be

writing these languages that we can't have any assurance about like if it does what we think it's going to do like that that to me seems like um like a huge crisis i think you know the the other so you're reacting negatively against like overly formalizing math uh programming but i think you also you don't want to go too far in the other direction because uh yeah yeah so anyways well i i think um it's interesting that you trace that line because i think that the line you know for example that real talk and dynamic thing comes from is like a very different line just going back historically um And one, one distinction that you hear from time to time, there's a, I think a paper about like the idea of programming language versus

programming system. And so I always describe real talk as a programming system in the vein of, you know, small talk or the list machine, which we're sort of totalizing like there's a language, yes, but there's also an operating system and an editor and specific ways in which you program. Whereas to me, the notion of language is that it's something that you write in Emacs and then you go to your terminal and you run a command and that closes the loop. Yep.

Yeah, yeah, that makes a lot of sense. That, of course, is its own thread, programming systems. And they've mostly, they've been getting a lot of short shrift in modern days. Like people think of language, like that's the idea of languages. They're like, they're literally just text in text files. You can run them on any machine as opposed to, I guess, today's world, probably the most popular programming system would be scratch that i could think of well i'm sure there are others it depends on your definition of programming yeah like excel or whatever but yeah yeah yeah yeah you're right it excels i guess

pretty much i guess my view is like once you have gone and once you've chosen programming language as you're framing you've sort of you've given up a lot of the battle, right? Like now you've admitted, okay, we're going to let people use their own text editor. We're going to have a compiler or interpreter command. Yeah, yeah. Whereas if you just have a programming system, you have a lot more scope available to you

in terms of crafting the interface and the experience. Ah, interesting. Yeah, yeah, yeah. So if you decide that you're going to write a language, you've decided that the interface is a text file and the way to get around it is a keyboard with, like, arrow keys and letters. Yeah, exactly, exactly, yeah. Or it's like pick your own interface.

You can use VI or you can use ZMAX, you can use Sublime. We're just focused on the language. Yeah, yeah. Yeah, and so I've been talking a lot to Jonathan Edwards these days and he's, I think one of the people who's really promulgated this idea that you need both. You need to like focus on the language and the semantics. That's really important,

but also the interface. He's trying to do both. He's trying to grow the system towards each other at the same time. Um, yeah. Brett, Brett more mostly focuses more on the, the interface part. And then the compiler mostly focuses more on the the interface part and then the compiler

people focus more on the language part uh don't ever try to focus on both is that how you see it too yeah i think you know maybe one reason that brett has focused more on system is just because there's less work in system so you can make more more of an impact there um But yeah, I mean, I think my view is that like, if you say system, you are, you know, you are including language in the system. So you can write, you can still do work in language. Whereas if you say language, you're not including system. So I kind of view, but certainly, yeah, I think I guess the like, one way to put it is I think a lot of the techniques are from people who just think about languages are useful, but I don't think they're the goal for me. So I do kind of think

I do like things from both. Interesting. Yeah, that makes a lot of sense. And I agree with that, that there's a lot less work, especially in academia, done on the system and user interface side of things. But if you're someone who's really in this world, like I

am and i was i got the impression that like all the work was on interfaces because like when you or i or people who watch brett's work and try and like imitate it or build off it we do a lot of interface work uh so recently i've kind of reacted with my own work reacted in the other direction and decided you know what like i want to do interface work eventually but i don't yet have a language or like semantics that i can build an interface on top of like yeah you know so right now i've kind of died i mean really i mean real talk even real talk has you know semantics like it's yeah it's it's not a pure interface yeah of course design yeah yeah

so i think i agree with you like you about the linguistic, the paradigm side is useful. Anyways, I just wanted to put out there that it's hard for me to communicate to people in this world, and especially people who don't understand this work, that what I'm doing now is I'm investigating semantics of a paradigm that I will then build a programming interface system for. Right. You're like in a pocket of a pocket of a pocket. Yes. Like, yeah, it's a weird tangent.

And so when people say, oh, like, how's the programming language going? Or are you like, are you building a language? It's like, I'm like figuring out the semantics for a thing that's going to look kind of like a programming language maybe one day. Yeah, it's hard. It's a multifaceted problem anyways um that was a fun little tangent i i want to just check uh if there are other interesting anecdotes you have uh that can elucidate the benefits or some of the negatives in it we've

mostly been very positive on it like you have other little tidbits to share to give a fuller picture of the space? Yeah, let me think. As far as negatives go, I think one of the open questions is, is Dynamic Land going to be able to sit on the critical path of day-to-day usage for anyone and you know i like i know it is a research project but if you make the comparison as everyone

does to zero in the 70s you know people at zero park were using it to send email to each other you know people spouses would come in at night to write their theses on the word processor and so i think having that kind of use as part of a workflow is something that we don't quite have yet, even though people have written a lot of code and played around with the system. There's now 19,000 roughly pages that have been done, but I don't think it's on anyone's critical Monday friday path for their you know separate work that that that's an interesting criticism uh i i guess to like to play devil's advocate to that criticism what the arcs park built happens to be like the uh like place where work happens today you know like yes yes yes so like to pick that example

it's kind of like unfair because it's like saying i i don't know it because because what what a computer is is like where we do all of our work and like all of the apps like microsoft office like the excel apps powerpoint like that's where every you That's where anyone who does knowledge work is sitting on a computer doing this work. And so, of course, Xerox PARC, even an early version of that, would be the thing that's immediately on everyone's critical path nine to five.

So that comparison, if this is trying to be a replacement for that then that comparison would make sense but i don't know if if it is i don't think it's trying to exclusively be a replacement for that but i think that is part of the vision it was subsumed this type of knowledge work is subsumed into um but i think on the positive side um you know i don't know if you ever got to visit the old cdg lab in san francisco no but i you know i visited don't know if you ever got to visit the old CDG lab in San Francisco. No. But I, you know, I visited there a few times.

And my criticism of them was always that it was like pretty kind of, they had these little experiments and then they had this laser tracking system. And it all kind of felt like pure demo wear, right? Like it was the kind of thing that you only used to show other people, but didn't use yourselves day to day and i think dynamic land is definitely a step in the right direction away from that and toward uh sort of the use that can test the system and and get it um to work really well even if just for one or two paths so when people come into the space what you're building a map kit and that makes a lot of sense it's like um actually let's talk about map kit what it what is it and uh how do people use it how do you use it yeah so it's a kit for um for maps and so the idea is when you say a kit is it

like a library or framework how do we program where it's processed what a kit is yeah i i think i mean you uh i assume steve will put a link you'll you'll put a link up to the to the post if you want to know more but yeah yeah but um yeah of course but it's it is like somewhere between a library and a framework and an application i mean these things are not so separated um because anybody can extend or read a piece of code or like use some functionality as long as they make the right wishes and claims. Right. Or as long as they check on wishes and claims that the framework makes. And so to be clear, like the protocol of wishes and claims for dynamic for MapKit, it's all like text. It's just strings.

Like, like, can you give an example of a wish or a claim that someone would have to interface with? Yeah, so a claim would be, claims are usually about domain data. So a claim in this case would be like, for a given page, like I represent a certain geographic area, like with longitude and latitude coordinates.

So I represent like these coordinates that are San Francisco, or these coordinates that are New York City. And so that's an example of a claim and if someone want to interface i like the thing that kind of struck me is they just have to like use the word if you use the word represent in your interface they just have to spell the word represent in the same way and then all of a sudden yes so yeah um which is an interesting like it's it's it seems like um you know, like you can certainly portray this as like just a key value thing,

but the fact of having to spell sentences and like do pattern matching on them, it feels like a very different qualitatively, qualitative experience. Yeah. It's not like you're calling a function with the same name or like inheriting a class with certain properties. You're just writing an English sentence in the same pattern as the framework you're using. Right. And when you do a when,

which is what matches on claims and wishes in the database, you're basically pattern matching and you can extract data from the statement. I know what one feels. Yeah, go for it. And you can also do joins where you want some conjunction of statements to be true and you want some pattern match variable to be the same in all the clauses. Yeah, go for it. yeah yeah and so to me it feels it felt a bit like when's were kind of like callbacky things is that how you think of them yeah that is that is kind of how i think of them and i think that's mostly uh correct that's mostly like a useful way to think of them um i the other the other

comparison i make is to the react uh like render routine um in, you know, the render routine in React, if people are familiar with React, it's called whenever the property, the props or state going into a React component change, the render routine is called and it generates a new like view. And so a lot of the whens work this, the whens will work this way as well. Like whenever a claim changes, the whens that depend on that claim will be re-executed. Maybe they'll make new claims and wishes in turn. So that's why I call it a reactive system. Got it. Okay, sorry, I interrupted you a bunch. You could continue explaining what MapKit is.

Yeah, so it's this MapKit. And so you can get maps, right? Like you can have a map of san francisco and there's a bunch of different ways to obtain something that's a semantic map and then you can draw layers of of information on top so there's a layer that's just like a normal open street map map that looks like what you go what you get when you go to google maps like the streets and the house shapes and whatever else and there's also a layer that's like a racial dot map. So you can see drawn or painted on the map, the sort of distribution of races or demographics in

that part of the US. And then there's a different layer that's public transit lines, where you can see like what are the major public transit lines in that place. And you can layer these all on top of each other. You can take them in and out and they will work on any map so so the way i think of it is that there's ways to get maps of particular places and then there's these tools that you can apply to a map and so so how can you get maps um so one way is you can just type in the claim uh and have like a fixed map of a certain place another Another way is there's these zoom lenses that you can point at an existing map and they'll zoom into some region on the map.

And then like the zoom page will turn into a map that's zoomed in of that region. And then you can also apply the layers to that zoomed in map. And then you can apply a zoom page to a zoom page and like get something that's further zoomed in. Yeah, the composability, beautiful. And there's also a tool that will like you can

point at one of these virtual zoomed in maps or any other map and it'll like print it out with like a picture from google maps that's been you know uh that's been tagged with the right coordinates then you can put that down and draw layers on top of it um so there's like a variety of different ways to get maps and once you have a map all the tools will work on it immediately beautiful and so why did you choose maps what drew you to those initially um so so it was something i'd been interested in you know i've been interested in public transportation in cities for a few years and so when i came into dynamic land i was thinking about things i wanted to do this was an area that really appealed to me because it was a way to explore this interest. And it's also deeply spatial in a way that I think is almost ideal as a demonstration for dynamic library because being able to move, being able to, you know, move these

zoom things around, like this idea of a zoom chain was one of the first ideas that popped into my head and kind of inspired the whole design of the system having like a page zoomed into another page zoomed into another page um and one one thing that i've realized over time is another advantage is that it's really engaging and collaborative to people like when i when people come in and i show them the system the first thing they'll usually do is they'll type in their hometown or where they live now. And, you know, we'll, we'll all stand around and we'll look at it and we'll like talk about different neighborhoods where they live and like the demographics of different

neighborhoods and where the public transit runs. So it's a really great way to get people engaged and get people involved, like playing with the system a little bit. Yeah. You had a few stories in your wonderful article that we keep referencing about how people have used it. It's really cool. I totally did not, like you say, it's very easy to miss things when you go visit.

When you were building your map kit prototypes when I was there, I did not understand the potential and where this was going but now it makes a lot more sense yeah um yeah and it's it's one other thing i'll say about it is that i i kind of talk about it as though it's one big project but it's really kind of a concatenation of like a lot of smaller projects right like there's the first prototype i was working on with you where i was just learning how to draw maps and then eventually like little things would get added on as i come in and like learn about something or some function of the system um but i think having this one unifying project has helped it you know be really cool and kind of accrete interesting stuff uh and and get more and more refined.

Yeah. So besides the development of MapKit, since I was there at the end of January, what else is new at the World of Dynamic Land? Yeah. So I think when you were there, we were just starting to make the transition to keyboards. So I mentioned at the beginning, you know, until like a few months ago when you came in, you had to use a laptop to edit any of the code. And now we have these free floating keyboards that you just point at a page and edit that page.

And it makes a huge difference in terms of engagement because now, you know, once you have your laptop, you're on your laptop. You're like on Facebook, you're checking Twitter, you're checking your email, but having keywords and having an editor that's implemented in the system in real talk makes it's made a big difference. Having high resolution projectors is the other thing that I mentioned. That's what made the map kit possible in the first place is being able to render high resolution maps. Yeah. So those are technical improvements. There's a lot of different projects that have happened recently.

Nikki came in and did this Frog Wars thing, which is really great. It's a really fun half physical, half digital game where the computer keeps track of scores. And like the computer keeps track of scores, but you you hop around these little paper frogs to play and you can take turns. You can choose different rules, kind of like a board game right like you can choose whatever rules you want and the computer um layer of computation i'll talk about um there's a few other um really cool projects people have done there's um there's a geometry there's a like group theory like tessellations demo where you can draw something next to this page and it will like make a tessellated demo where you can draw something next to this page and it will like make a tessellated version of it i don't fully understand it but it's a really

fun thing to play with because you can just draw or move things in front of the camera um i i have a few projects that i've been doing recently i started writing a web browser which is an interesting project yeah and uh And I've also started playing with these Raspberry Pis, which are really exciting because they let me plug new kinds of sensors and actuators into the system. I built a little robot this past week that is connected to RealTalk and programmed in RealTalk, but you can drive around. Oh, wow. Cool. Yeah, that's awesome. yeah so so a lot of uh super exciting stuff and um you know

and i know that some of the research staff are working on some even more exciting stuff over the next few months so hopefully we'll see more of that cool um so yeah i'd be curious to talk about the future of dynamic Land or how you see the future. Because we talked about a bit how, of course, you have to compare it to Xerox PARC. But I think it's not I don't think I'm actually pretty sure that the people behind Dynamic Land don't see the success case as a modern day Steve Jobs rolls in and takes what they refer to as a low pass filter of the ideas and then go capitalizes on them and we're all stuck with a version of Dynamo Clan. That's not success.

Right, right. So what is success in their mind? Or in your mind, how could this project succeed? What's the path forward yeah it's a good question and it's something that i it's another one of these things that i'm still trying to wrap my head around because the vision is you know very ambitious and long range in a way that you don't often see well yeah let's linger on that like uh just can you articulate how long because i remember remember, it's not like, oh, I want this company to being in the first 50 years of the printing press being made and, like, trying to figure out, like, what are the forms?

Like, how big should books be? You know, what kind of, how is this different from scribal work? What's the effect on society? And, you know, people argue, like, the Protestant Reformation, like, the Catholic Church, like, those all came from this availability of this new medium of the printing Church. Those all came from this availability of this new medium of the printing press. I think that's one of the moles that they're thinking in. We're here to make the dynamic, the computer

medium, and we're here to do it right for the next 50, 100, 200, 300 years. What's the right ways to do that technically? What are the principles we want to follow grant so okay so anyway so so that's that's the vision so what's uh what are the more concrete steps forward in the next three five ten twenty years yeah it's it's a good question i think um the this this sort of path that um i think that the path is like

get this dynamic land right like get it working figure out what the right ways to do things are um then once once once we think we have a good idea know, maybe have more dynamic lands in other places. And then it becomes sort of a public library type model where it's a community space. It's a place where people can come in and do computation in the same way they go to a library and get books as a resource for their own work. I've recently spent some time in libraries

and I don't know how well dynamic land would be it's very different than a library yeah well i think um you know computation is different from from books uh yeah that's true i guess what i was going to say is that libraries are very solitary you go you don't talk to anyone you you're trying to be as quiet as possible yeah and i think this is one of the interesting things is like one of the ideas like some of the ideas in dynamic land seem to me like not just a rejection of the personal computer interface that we have now but also almost a rejection of books right because books like are the precursor to this kind of solitary that's an interesting that's a fascinating idea like so i went to a library

and there were all these people they were interesting all from different walks of life i spent the last few weeks i've been visiting libraries in new york city and and we don't interact or if we do interact it's you know that's like the example interaction but if this this library looked more like dynamic land and we all just had really no choice but to do our work in public man like that would be entirely different feel like i'd like chances are there'd be someone working on something interesting to me or other people and like conversations collaboration my goodness because the thing that the smartphone has been doing to us all is i heard this great story in another podcast uh where someone said someone said 20 years ago,

he went to jury duty. And in the breaks, you would chat with other people. You'd be reading the paper, you'd see what they'd read, you'd chat. But today we're all on our phones getting content that's specifically tailored to us based on Twitter and Facebook,

what they know about us. And so we only see the people who are just like us that we're interested in. And nobody's talking to anyone else. And so it's, it's fascinating that dynamic land really is trying, it's, it's kind of a social idea.

They're using technology really to change the social fabric of, of our society. Yeah. I mean, I think, I think we think like, you know, the technology like really matters,

like the smartphone, you know, there's technical choices, but those have social consequences. Yeah. So, so that's, that would be like, you know, the next five years, the next 10 years. But I think eventually the vision is, you know, you talk about the smartphone. I think we kind of view the smartphone as like a flashlight. It's like you put the batteries in, you carry it around with you.

But eventually we want there to be computation infrastructure, just like you have light bulbs in your ceiling that it's just everywhere that's a great metaphor wow that's really cool you don't you don't you don't bring a flashlight around with you they're just you go walk in a room and you press the button and the lights turn on yeah fascinating wow we don't we're not lugging around computers i'm not lugging around smartphones the kind of there's there's a view i think the modern view of new technology is that it has to be a device but you know it could be infrastructure also and that's like a different way to do uh technical that's crazy. Fascinating.

Fascinating. Yeah, it's interesting. Like, I guess that version kind of is like everything's in the cloud. You're not carrying around data in your pocket. I guess you could, but yeah, I mean, I think, you know, you want to know what's going on. Maybe there's a cloud or maybe you just carry it on paper. I'm not sure, but fascinating. Wow.

Yeah, that's quite a vision. Even after going to Dynamics Land and thinking about it a lot, I never quite realized quite how grand the vision is. You know, like, screw these devices. The computation can be, wow. Yeah. Computation can be like lights. Right.

And then, you know, keeping all the proper, like, you your computer your little pieces of computation with you you could edit them you can still change them like all these things should still should be oh interesting so it's not not rigid structure right not like i usually think you get an app and it's like it's you're not gonna change it yeah if's a if it's infrastructure because you know i don't know of any city infrastructure that's mutable it's all yeah or like it's all very yeah i think i think there's like an infrastructure layer and then there's like a you carry your pages around with you or you buy pages or whatever and then those are those are editable interesting yeah yeah it's funny because um i don't know if you've seen in big cities they

have these wi-fi towers where you can charge your phone get directions and i've seen those in in new york i think yeah yeah yeah so i think a lot of cities are they're popping up um and they have little ads on them and i don't know like what reaction i have to them mostly just mirth like haha like yeah kind of a funny little box like on the sidewalk i guess we're i guess it's 2018 now it's official like new york city knows uh but this is like an entirely different way to think about technology's infrastructure that like it's just so far from that so much so much grander than like a little wi-fi tower yeah that can charge your phone. Wow. That made my day. Thanks for that.

Cool. Okay, so got it. We've covered dynamic, man. Thanks for walking me through it. I think for the people who can't get out there just yet, this conversation could be very helpful. Yeah, I think there's always kind of more angles to take to illuminate it. So I hope this is useful as far as that goes.

Yeah, I think we're taking the time for that. In the last few minutes, I just want to talk a bit about you and what your future looks like. You've worked on a lot of really interesting projects. So I'm, of course, where where you're going next if you have thoughts on that uh i guess in particular um i just want to like the angle that is also curious for me is balancing making enough money to live with working on each project you find interesting like finding a sustainable way to work on interesting things yeah it's a

great question it's still something that i'm trying to figure out um and you know like i'm happy to chat with anyone uh who wants to talk about this kind of stuff who may have an interesting project um i mean i think there are things about the we've talked about this before i think there are things about the market mechanism that are useful in terms of like um knowing that you're doing something that people find interesting and useful um i think i think the balance there is the short-term versus long-term orientation and that's why dynamic land has taken the attack that they have where they're like we can't make we don't want to make the kind of thing we can make money on in the next year we want to take a long-term orientation and so that's why they've done this whole non-profit thing um but you know if that's

not a concern i don't have any objection like in principle to making money off of that makes sense um i think that i've read in other writings of yours that you along with me and many programmers of this type suffer from oh maybe building tools that are over generalizable with like yeah like a clear specific without a case without a use case first yeah yeah so i'd be curious yeah like what have you learned from from those battle scars and how are you approaching things differently now yeah i mean i think the the easiest thing uh you know i have the screenshot app that I've actually put on sale this last year. The easiest thing is like having a tool where I.

And so I know it's kind of useful for me and people like me. I think the step beyond. So that's that's kind of step one or step zero um in terms of not making things that are too general making things that you know are useful to you if yeah if that's a goal um because i figure if something's useful to me it's probably going to be useful to other people who are like me like maybe it'll be useful to you maybe it'll be useful to some other friends of mine um i think the step beyond that is and this is is hard, is just to have other interests. The map kit kind of emerged from my interest in public transportation or my interest in maps.

And I think if you stay just in the programming world, I think there are a lot of interesting problems there. But I think one of the reasons you get that overgeneralization is if you're just kind of working in the programming world you don't have anything concrete in mind from outside into ground up yeah yeah that's a good point yeah brett gave me that advice too it's kind of hard advice like get a hobby right yeah it's like this is my hobby right i mean a lot of the early you know if you think about fortran used for for computation for math and science, if you think about COBOL used for business, LISP used for artificial intelligence, you know, there is at least like a vague kind of outside domain for a lot of the early work that start kicked off the field, right? Of course. Of course. of course um so you mentioned just a few seconds ago that um if someone you said like you know if anyone's interested in talking about projects you'd be happy to talk can you be a little more

specific you're saying like if someone wants to hire you to do something like the work you've done or maybe start something together yeah i mean at the moment i'm kind of looking around um for things i want to do next so um you know if if somebody out there is interested is you know find some of the projects i've done interesting i'm always uh interested in chatting with people who are doing this kind of stuff i've talked to a bunch of people um at education startups for instance about uh you know visualization and languages and stuff like that it's always nice to meet people in this field right like it's a pretty small you know people like you and me uh yeah have you um i forget the name the company that jan jan paul used to work at have you spoken to that remix um i've not chatted with them um

but i feel like that's a pretty natural yes yes it's a pretty natural spot for you. It's maps and, you know, and like probably, you know, it's a lot of the themes you're interested in. Yeah. I've chatted, I've chatted with, with, uh, JP a little about them also. Cool. Um, yeah, fascinating. Um, all right. So if anyone's listening, uh, that's interested in working with Omar,

that's, that's really awesome that you're, that you're like open to a lot of different opportunities. It's a, I hope, I hope. Yeah. I've done, I've done a lot to keep up kind of flexibility, you know, to pursue various things like, you know, playing around at dynamic land, you know, doing the screenshot app. So it's something that i'm hoping to keep keep going with cool um sounds great um is there any other thing you want to mention like uh talk about things you want to like interact with you know should people email you if they have questions about certain things what yeah how do you want emails great. Twitter is also great.

Those are both good ways to get in touch with me. You've been very funny on Twitter recently, I have to say. Yeah, I've been trying to get, you know, there's a lot of thinking around this stuff

that I think like, you know, Dynamic Clan in particular, but also other related things, which I think like has never been written down, let alone shared with anyone. So just trying to get

some of those things out of my head and other people's heads. It's a noble project. I appreciate it. Also, I got a few laughs. It took me a few seconds, but Douglas Engel Muni, that was a good joke.

That's a good one. Sometimes it's just stuff that's stuck in my head. Cool. Well, thanks again for taking the time. This was wonderful to talk to you. Yeah. Yeah. Yeah. Sometimes it's just stuff that's stuck in my head. Yeah. Cool. Well, thanks again for taking the time. This was wonderful to talk to you. I know this was, this is super fun.

Yeah. All right. All right. Thanks to you. Yeah. Thanks.