 Oh, thank you. So yeah, I titled this talk In Search of Tomorrow. And I wanted it to sort of evoke a journey, because we're going to go on a bit of a journey. So over the past, I guess, almost six years now, I have sort of been working on trying to find an answer to this question. What does programming look like in 10 years, right? And my first sort of real approach to this, my first actual time that I was tasked with trying to figure this out a bit was, as Fernando said, at Microsoft. So I was a program manager on Visual Studio at Microsoft. And as time went on, I originally started as a program manager on the editor and eventually came to own the experience of using C-Sharp and Visual Basic. And while I was there, I sort of carved out this little interesting position for myself, which is trying to figure out what Visual Studio will look like years from now. What is the future of Visual Studio? If we were going to make this programming thing better, if we were going to make programmers more efficient, what would it look like? And in order to answer that question, I managed to convince my superiors to let me do a study. And so I did the, to my knowledge, only ever done end-to-end study of Visual Studio, where I sat behind a one-way mirror and watched people program and solve problems on a computer in this very general set of tasks for a month and a half. And as a result of that, I gained a lot of insight into what it means to program, what it means to be a good programmer, and how we actually do it. And this is important because as an industry, we're actually not very introspective. I loved it. We would have these guys who come in, I only use the keyboard. I never, ever touch the mouse. Well, we have videotape of them using the mouse about half the time. It turns out that depending upon what tasks you're doing, what your mental processes are kind of doing at a time, you have different modes of operating. And one of those modes typically is done with a mouse, not a keyboard. And so I did this study and started to design what I thought the future of programming would kind of look like. It's specifically tool-oriented. That was what I was tasked with. I wasn't looking so much at the languages or any of that. There was somebody else's job that was. And so I built a bunch of interesting prototypes and stuff. And they've been slowly trickling out of Microsoft since then. But this is where I first started. I started at Microsoft on Visual Studio imagining what programming will look like in 10 years. And I'm like, it will be really fast to write. That's kind of where I got to. And it will not only be really fast to write, but you'll be able to navigate really efficiently. These were the two things that I sort of latched on to. And that study also taught me something very important. And what that thing was led me to the next project, which was Lighttable. And what that study taught me was that despite, as Fernanda said, Visual Studio is a monument to humanity. It is 55 million lines of code when I was there five years ago. It is a gigantic piece of software. But in that study, I found out that most of the things that are in Visual Studio weren't actually helpful. They could have been. They could have been useful. It wasn't that the features themselves weren't good, but they were dwarfed by the fact that everyone was playing computer inside of their head. This was how they came to understand the software that they were working with. This is how they came to understand programs they were unfamiliar with, even ones they were familiar with. When something goes wrong, your only action is read some code, imagine what the computer would do, and play it out in your head, write some stuff down, and just keep doing this over and over and over again, until eventually you have basically simulated the program and you found your error. The premise behind Lighttable was, what if we were directly connected? What if there was no time between change and result? What if we shortened the feedback loop to effectively nothing? And I think there were many interesting ideas, I think, in Lighttable, but the one that people really latched on to was what I called at the time the InstaRepel. And the idea was, you typed code on the left-hand side, and if there was anything that ran as a result of that, on the right-hand side, you'd see the code filled in with all the values, right? So if we kind of zoom in on it, right? So this is in closure, so it's a list B syntax, but if I add three and four, it shows me that the answer is seven. So I undo some math, and then what's interesting is this def end thing is a function, right? And so the function takes two arguments, and you can see they got filled in as well, and you can see what the result is. And what this enabled was, as I typed, it did this, so I could literally watch the data flow through my program, right? There was no question what was going on. When I said that people were forced to play a computer inside of their head, what they were trying to do was make the program observable, right? They were given this sort of opaque thing with a set of instructions explaining how it works, and the goal here was, let's just open the box and let you see inside of it. And that was really interesting, and it was useful, and there's lots of very neat things that came out of LightTable. I mean, it had other ideas too. It had this sort of small talky notion of like, I'm gonna put code, like little snippets of code all over the place and embed running applications in it so that I can sort of create my own organizations for code, right? I'm not limited to just what I can put in a linear file. I can create this sort of canvas upon which all this stuff sits. So we did LightTable, and one of the things we had sort of an explicit goal of was not just unlike at Microsoft, where the goal was purely like make programmers more efficient. Our goal with LightTable was actually, yeah, we wanna make me more efficient. That's great and all. That has potentially huge economic value. But more importantly, we wanted to make programming more accessible, right? One of the things that we came to was this idea that the reason programming is so hard is because it's unobservable, because you can't see what's going on. You can't see the effects of change. You can't watch your data flow through and so you're doing this replaying in your head. And LightTable with features like this, yeah, hey, we're pretty good for programmers actually. That study that I did for Visual Studio, we kind of replicated it with LightTable to see what the difference was, right? And for a career programmer, hey, programming this way, it's about twice as fast. And there were lots of interesting things that came out of that. For example, in Visual Studio, people would write large swaths of code before ever pressing the play button basically. With this model, people wrote little tiny bits, right? And we're trying it all the time. And as a result of that, they built up, as they were building up sort of abstractions and all these functions and this sort of set of primitives, they knew what every single one of them was doing. They knew it worked correctly. They knew what their result was going to be. And so that was great. Career programmer could be maybe twice as fast. Turns out that twice as fast actually isn't enough. This is something that people have sort of a religious attachment to, right? These are our tools. These are the ways we express ourselves as programmers. And so 2x, while interesting and compelling, is not enough to get me to drop Emacs, right? Or is not enough to get me to get out of Visual Studio, or whatever the case may be. So it didn't really get the sort of attention we had hoped for in that regard, although we got tens of thousands of people using it. More importantly though, it did nothing for our other goal, this goal of making programming more accessible. And we tried to understand this. And that understanding resulted in an essay that I wrote a while back, called, Toward a Better Programming. And in it, I sort of realized that I had approached this problem. I used to say, I wanna make programming better, right? And I realized I had made a classic rookie mistake, which to this room is probably well known and understood. I tried to answer a question I didn't really understand, right? Like, what does making programming better mean? What is better? That implies that there's something wrong. What is wrong with programming? What even is programming, right? It's kind of an interesting question to start to ask. And so we started doing some research. We asked a bunch of people, built a bunch of prototypes, tried to sort of develop an understanding for what we were actually trying to do. And I sort of came to an answer about what is wrong with programming. If we're gonna do anything to fix it, we have to have some notion of what it is we were actually fixing, right? And it came down to three properties. The first I basically already started to talk about, right? It's that programming is unobservable. I make some change in code unless I manage to execute that code path, you know, in manual clicking around on a screen or whatever. I have no idea what happened. And as I'm making the changes, if I make a whole bunch of them, I have no idea what the effect of each individual change is, much less the effect of the entire aggregate of changes. And this is a lot of what we were trying to address with LightTable was trying to make programming more observable. But there's another problem too. And that is that programming is indirect. So if I'm, let's do something fun. If I'm describing a drone, right? And I have this thing hovering over here next to me. If I want to make that drone do something using pick any language you want, right? I have to first translate it into that language. I have to first translate it into the computer, right? I have to think like the computer in order to get the computer to do what I want. This is very indirect mapping. And if you look at the vast majority of errors that happen when people program, they come from actually relatively simple translation errors, right, is this indirection that causes a lot of friction. So when we were doing that study on Visual Studio, we saw this over and over again, where somebody had the right solution. Just along the way, they just did it slightly incorrectly. And again, it wasn't that their logic was incorrect or any of that. It's just literally the mechanical process of translating that logic into Python or C-Sharp or whatever is not easy. We're not very good at it as human beings. And the last one, and this is something that career programmers really latch on to when I talk to them, is that programming is incidentally complex. What I mean by that is that the vast majority of what we do when we program has nothing to do with the problem we are trying to solve, right? A very, very simple demonstration of this is, I like to pick on how long does it take to set up a dev machine from scratch, right? I watch people take the better part of a week doing this at Microsoft. That's just to get code to run, right? That's like not even trying to do anything interesting yet. That's just to get started to start your problem, right? And so when I say that the programming is incidentally complex, I mean that we spend a great deal of time solving the problems around solving our problem. So to give you a simple example of this, to sort of demonstrate exactly how hard programming really is, right? We tried to come up, and we did this talk a while back where we went around and had a bunch of people try to build what we thought was one of the simplest possible programs you could imagine a normal person wanting to build, which is a button on the screen that counts the number of times it's been clicked, right? And so I click the button, it says one and two and three, and that's it, right? If you think about this, like what it takes to build this little button, we'll assume you already understand HTML, which is a big jump, right? But we'll assume you don't know enough to write this little bit of HTML here, and then it's not so bad, right? It's just six lines of JavaScript. Well, let's unpack exactly what's in the six lines of JavaScript. So first off, you have to understand the notion of identity, which is arguably one of the hardest problems in programming, even though it seems like it should be something very simple. You know, I have to tell the computer, hey, that button that I just put on the screen, I'm still talking about that button. I wanna work with that one, right? You then have to deal with scope, right? This, again, six lines of code has a function in it, which is creating a new scope and things are weird in this sort of world. Things that you define in there don't escape, but if you talked about them above there, they're ambiguously escaping. You have the notion of mutable assignment. Fast majority of programming errors are the result of mutable assignment. You have closures, something that still most career programmers don't understand correctly. You have asynchrony, which is probably unquestionably the hardest problem in programming at this point. You have objects and properties and the DOM. That's six lines of code contains the context of years of work, right? You have to have spent years to understand what all of those things are doing. Yeah, sure, somebody might be able to go to Stack Overflow, you know, copy some of this out and ta-da, I have a button that works, but that means they can't change it because they don't understand it, right? Those six lines of code, you know, I joke here like too long didn't read for six lines, but that is kind of the reality, right? Programming is hard. Question is, does it have to be hard, right? Is this sort of intrinsic? My standpoint is no, but this is where we ended up with Lighttable, right? We had taken these, this kind of language, we took JavaScript, we took closure, we took Python, we're like, well, if we remove the feedback loop, programming will be easy now, right? Cause you don't have to play a computer in your head, but this didn't change. All of this is still true, right? All of this is still necessary. And so as a result of that, it, you know, didn't make things much better. And that's sort of the sort of like fundamental problem with trying to make it more accessible, right? It's programming, it's still programming, no matter how good of a tool you make for it. And the problem with that is that these languages and these tools were built around the idea that we were going to build applications, right? That the end result of programming is a little icon that you double click on your screen and does one thing and somebody writes it and they give it to you and that's that. But the reality is what we really want when I started to think more about what it meant to make programming more accessible. It wasn't about making applications. We struggled with this for a long time, right? We're like, oh, well it's gonna be building websites. So we'll make it easy to build websites, right? But it's actually to do something for our more fundamental, right? It's just to think. Fundamentally, if you go back to the beginning of the 1970s when a lot of what is modern computing came to be, the idea back then wasn't the single purpose appliances, right? The idea was a tool to think with. And if we're going to make programming more accessible, ultimately what we are trying to do is make a thinking tool, not necessarily a tool for building large scale applications, right? Because at the end of the day, the computer is the greatest thinking tool ever developed, right? If I know the magically incantation necessary to punch holes in this card, I can get the computer to think for me, right? And that is a hugely, hugely powerful thing. You know, when we went around pitching this to folks, we labeled it a superpower, because that is fundamentally what it is. It is one of the only times that given a computer, you can start with nothing else and create something of immense value, right? Just by knowing how to punch these holes. And so that's what sort of ultimately led us to this project that we're working on now. And that project's name is Eve. And it is this idea, okay, I started with Visual Studio, trying to make programmers better. Realized that the tools are actually not all the problem, right? It's like the model of programming itself is a problem. Got to LightTable like, hey, the feedback is now there, so that makes it observable, but it wasn't quite the way there. And it was still a tool, right? We were still approaching this from a tool's perspective. Eve is, what would happen if we tried to solve this problem from the ground up, right? Ignoring basically everything that exists, what would you build if you could? If you could basically imagine building programming today, right? So the first approach to this, of course, as a programmer, was to take all of the things we thought were good about programming. And all of the sort of trends that were happening, like functional programming and mutability and all of these things, we'll put them all in a pretty little package and that's just gonna work. So the first prototype of this was a thing that I showed at Strange Loop, which is a software conference. Oh, is it not playing? Oh, there it goes. It was a software conference that sort of like deals with a lot of the more interesting sort of avant-garde ways of thinking about the world. And so the idea was, okay, we'll take functional programming and immutable data and we will put it in something that looks a lot like a Jupyter Notebook, right? And we'll make it so that you're like literally working with the data, right? I like right click on a thing and I tell it what I wanna do with it and you can see all the results and don't get hung up because it doesn't look super great at this point. I built this prototype in like four days but it was really interesting because it took a problem that would normally take quite a long time. Better part of a day, for example. So this was taking a bunch of data out of Mongo, doing so usage data out of Mongo and then doing some math on it and then getting a graph out of it, right? And all of this again was done by just sort of like dragging and dropping and right clicking on some things. And there were a bunch of interesting ideas in this. One is the idea that you're always kind of working with the domain itself. So you'll see here in a second, when I wanna write out some math, I actually do it in math. And by that I mean mathematical notation. Zoom ahead here, so I'm apparently being slow. Right, so I wanna sum over all the x's and divide it by the number and ta-da, I have average, yay. So the idea was right, like you're working, if you're working in a domain, let's say for example, I have my drone example again, right? If I'm working with a drone, there's a drone on the screen, right? Instead of describing a set of operations that I'm performing, I just move the drone around, right? And it's capturing what those steps were. And then I can parameterize them by data or get a chart or whatever I'm trying to do, right? So this was interesting and we took a much better, much prettier cleaned up version of this. We're like, this is awesome. We can build all sorts of things with it. Later in the video I show, I'll skip ahead. I show like building a website this way where you just have these tree of functions that do stuff. And it was interesting and cool. As a programmer, it was very exciting. And I happened to be at the opening of Brett Victor's laboratory, CDG in San Francisco. And there were all of these non-programmers, brilliant, brilliant people, physicists and mathematicians and all these people there, don't know how to program. And we set, like I said, a much better version of this in front of them and like, try it, right? We were like, we were excited, we were stoked. We're done, this is gonna be amazing. And actually the reactions were really positive. People liked it. They thought it was really interesting. They got why they would wanna use it. And then much to our horror, we watched them not be able to do anything in it, right? And I will never forget the reactions we got, which is they were trying so hard, right? And they were very well-meaning. They genuinely wanted this to work. So they were like willing to do things that most people probably would not really be willing to do. But there was this thing that surprised me, this thing that they struggled with. Out of all the things that I expected to find out in this, the hardest thing for the non-programmers to work with was scope. So in functional programming, you end up with these deeply nested set of functions, right? Everything is about this magical tree of functions that you're gonna call. And the reactions that we got were really obviously bad. So somebody would look at it and go, they had some data up at the top of the function stack and they had some calculation they wanted to do at the bottom of the stack, right? And they're like, I want this down here. And you're like, oh, look at, I mean, well, you'd have to pass that through all of these and you can't really do that. And they're like, I don't understand. I see it, it's right there. Why can't I use it here, right? Well, okay, fine. If I can't do that, can I use this up there? No, you can't really do that either. We'd have to thread it through going back up, right? It was like this really, I no longer believed the arguments I was making because you're like trying to understand, you're like, well, scope is really important, right? Like you need it for functions and functions are really important. And I don't know, that's like something we can't do, right? And so we tried to do a bunch of things. We tried to make this nicer. We're like, okay, well, we'll make it look prettier. And we tried to do a bunch of things to make the scoping thing less of an issue. So there was no variable shadowing. We had a much simpler version of scope. We do arrows, we colored things the same. We tried to do all of these different things. Nothing worked. It seemed like it was kind of like just this fundamental problem that was really hard to get over. And so that let us down this very odd line of questioning. Which is, well, if our first attempt at this, what the industry seems to think the future of programming is, is like I said, functional and immutable and yay. If that's not right, and scope is a kind of a problem which basically encompasses all of programming, where do we go from here, right? Like what does it mean to remove scope from programming? So if you think about it, without scope can have functions. So that's already scary to begin with. It also is that when you're building up these like nested data structures, they're creating scopes, right? You're starting to worry a lot about where something is in this tree of data. And you don't want to duplicate because you've put that data somewhere and you put it in another place, then they're gonna be out of sync and you have all these problems. It was another version of the scoping problem. So you can have functions. Can't really have data structures. If you don't have data structures, you don't have anything that can keep things in order anymore. So you don't have ordering. So if you think about what programming is, if you asked a career programmer what programming is, they would probably say an ordered set of steps, typically executing functions over a set of data. All of that falls away if you remove scoping. And so we started to look into, well, has anything ever worked this way, right? And there is at least one massively successful example that works exactly like this. And that is Excel, right? So Excel has a single data structure, but you don't work with the data structure directly. It has no scoping. If I can see a value, I can use it anywhere. It has no inherent ordering. It has scalar functions, but you're not like nesting these deeply, right? You're writing out basically equivalent of a mathematical formula and it never goes deeper than that. So it has all these properties and that is a fantastic result and also a terrible result. But a fantastic result first is a fantastic result because 800 million people use Excel every single day. It is unquestionably the most accessible thinking tool available to us. And people have done amazing, truly amazing things with Excel. I was telling the story at lunch that I had this opportunity to talk with some folks at a Fortune 500 company, right? And it's cruise line. And they have this spreadsheet. There was 10 gigs in size. They had been built up over a decade. No professional programmer had ever touched this spreadsheet, but it modeled the entirety of a Fortune 500 company's business. They could have nuked every other system and run it off of this spreadsheet, right? This is amazing, like totally utterly amazing. And so that's great. Now at the same time, Excel, this is the downside, Excel wasn't meant to do that kind of thing, right? So they would joke around. They're like, yeah, if we made any changes to the spreadsheet, we had to go to lunch because it took an hour and a half for it to propagate, right? And Excel is constrained, right? It's a two-dimensional grid of numbers. If your problem is not easily specified as a two-dimensional grid of numbers, kind of out of luck. So we looked a little bit more. And we found that there was one other case that worked this way. Again, massively successful. And that is relational databases. Relational databases have the same set of properties, right? They don't, you know, if you can see a value, you can use it anywhere. If you can see a table, you can use it, you know, barring access rules, basically. There's no inherent ordering, either to the code, the execution, any of it, right? Even the data has no inherent ordering. You order it as you will. And again, no, like, deeply nested functions or any of this crazy scope stuff going on. You just have basically functions and scalar values. And that is a great result, again, certainly not accessible like Excel, but it solves the other side of the equation. It is a flexible thing, right? The world runs on relational databases. At the end of the day, basically every bit of data ends up in one of them. And we have built games and websites, all the things you couldn't imagine really building in Excel. So we discovered this, like, hey, relational databases is an interesting case. Let's see what people have been saying about them recently, right? There's gotta be stuff other than Postgres out there that we can look into. And that's where we ended up on research out of here, actually. Joe Hellerstein's lab, the boom lab, had been working on a language called Bloom. And they were working on that language to do distributed systems. The idea behind it was that it was a query language, so a little bit like SQL, but it was based on Datalog. If you know what prologue is, it's kind of like prologue's little cousin. It does a lot less and is a lot simpler and is able to be a lot faster as a result. And they were building distributed systems. So they re-implemented Hadoop, right? And we were like, oh, that's really amazing because it was orders of magnitude smaller and all these great things. Could we build a website this way, right? Like, could we take this, maybe stretch it a little bit, think about it in a slightly different way and how far could we take it? So I built this prototype. This is ultimately actually the prototype we raised money on. And it's a very interesting thing because if you read what these little things do, we had an intuition, which is that prologue or Datalog or any of these is written in predicate logic. And predicate logic is pretty hard to get your head around. But if you think about it, it kind of looks like filling the blank sentences, like those mad lib books we had when we were kids, right? It's like, put a color here. And if you squint and you think of it that way, if you think of these predicates that way and you think of horn clauses as like, when you see this thing, do this thing, you get this kind of very natural way of thinking about it. So this is the incrementer button, right? That little button I was talking about before, say like, well, when I'm setting defaults, remember that the counter is zero. And when the counter has a value, draw this button. And when that button is clicked, change the counter as whatever its current value is to the current or to the value plus one, right? And so like I said, we built, you know, interesting things out of it. We always build to do MVC because that's what everyone builds. But started building interesting things out of it. And we started to realize this crazy way of programming, you know, that has no data structures, has no inherent ordering. When I built this prototype originally, I didn't even have aggregation, which is interesting. Sort of made us realize that a lot of the things we think are fundamentally necessary for programming just aren't, they just, you don't need them at all, actually. And sort of as an interesting example of this, not only yeah, we built this website and you could say, oh, well that's a toy or whatever. The IDE that it was written in was written in it. And I know a thing or two about building IDEs at this point. I've built a few. You know, Visual Studio is 55 million lines of code. Lighttable, which does far less than Visual Studio and was designed specifically to be as small as humanly possible, was over 10,000 lines of code. This was 600. Right, we're talking about a totally different way of thinking about the world. Not only was it 600 lines, it was written in a week in a language that had no tools that didn't even have aggregation, right? Like it had bugs in it and we still managed to write this in a week. And so that is a tremendously awesome result that we can take some of the things that Joe's group had learned about distributed systems and apply them more generally to these other places. And if you squint at this, it starts to kind of look like one of the holy grails of programming. It kind of starts to look like an executable, an English executable specification. I read it to you. And if you think about the description you would give of the incremental button, it's not very far from this, except maybe the when setting defaults part of it, right? And that's obviously pretty surprising and like really interesting, right? Again, this is one of those things we've wanted for forever. But we found out that actually this way of programming isn't that great. The whole, I, you know, a lot of people still think that the English specification is like the future of programming. If we ever get there, we've made it and we're kind of done. And I no longer believe that's true. The reason why, after having programmed this way for a little while, is that if you read an English specification, every line of that English requires you having understood and internalized every previous line that was written. Right, if you think about a big part of what makes programming hard, right? Or a big part of dealing with complex systems, being able to box parts of them up, right? Like, I don't need to know about this. I don't need to know about this. I can just like go with this. And these English specifications required you to basically understand the whole thing all the time. And yeah, they were shorter, so maybe you could reasonably do that. But when we actually tested this out with people and sat them in front of it, they were like, I can read these programs. I get what they're doing. No one was successful in writing one, right? Which is kind of interesting. And yeah, you could argue maybe it was our tooling, maybe it was our strategy, maybe it was whatever. But I think it's probably actually more fundamental than that. Like I said, I think it has to do with this context problem. That every line requires the context of all the previous long lines. And so we get, okay, let's try something totally different. We know this Excel thing works. Could we make it look like Excel, right? And so we started to realize that these operations, you could perform visually on tables because that's basically all that was going on here. And so in this example, it's gonna be a little hard to see, so don't worry about it too much. But what I'm doing is this is the first time Eve interacted with the outside world, it sent us a text message. And so what we did, we had this set of buttons down here at the bottom which you can't read, but it has our names on them. And if you clicked one of those buttons, it was gonna send that person a text message. And the way this worked was that there were these tables inside of our system that had event information in them and had the people in them. And then we would join those two things together. And now you can see every time I click on one of these, it has the information for Chris or Jamie or Rob and has the fake version of our phone numbers, but we actually did do this with our real phone numbers at one point. And so it's kind of like writing this thing in Excel again with some more interesting abilities than Excel usually has, right? We can join things. It had basically the properties of a relational database. And this was neat. It worked for some definition of worked. It allowed you to do relatively simple things, but we found a bunch of problems with it. For one, once you had this nice little table, you lost all context on where any of this information came from, which when you're building things, is actually pretty important information to know. You just have these values. They just have kind of like random names. But it did kind of prove to us that you could start maybe treating this as a very different problem. Maybe instead of thinking about like writing code, even if it were English code, maybe you could think of it as like operations on these tables and you could do it very visually and you could do it almost essentially just mouse driven, right? And it could look like Excel. We sort of ran into a bunch of roadblocks here. Like I said, just like a very simple example of this is not knowing where anything came from. But as you started building up these more complex tables, you realized that people don't really think of the data this way. They're like, they have to think about keys a lot, right? And like joining on the keys and it was still pretty hard. It wasn't the right solution. And it was shortly after this one that we're like, well guys, I don't know yet about how to do the whole like make this thing accessible, but can we at least prove that it's a good idea, right? That the foundation of this is a good idea. Because we had essentially broken this problem up into several problems. The first was, could we find a version of programming that was very simple, right? And by that I mean of few parts. And that version of programming has to be something that I could use as well as it's gonna work on Excel like problems too, right? So it had to be a general purpose language. But it needed to be very simple. And so we really, really liked the stuff out of the boom lab. And we had built some interesting things but we wanted to deal with it more. We wanted to really try and develop some stuff with it and see what happened. And so we built this prototype which given how much time do I have? Oh, not too much time. I'll show you very, very briefly what this looked like. So we had this thing, don't worry about what this looks like. But, so you know, here's a clock, right? We can zoom in a little bit. And everything in this language, like I said, it's just like kind of like sequel basically, which is kind of this weird way of thinking about the world where all you're ever doing is querying. And specifically actually you're building views in our case which are queries that are always up to date, more or less. And so very first thing sticks a row in a timer table, which generates a timer for me. And that's what runs this clock. And then down here we have this line which pulls in from the timetable which is what that timer sticks values into. And then we aggregate over that timetable to get the latest time and then we just turn it into hours, minutes and seconds. And then we draw our clock and this is just me being bad at math. And then they had this little language down here that allowed you to describe UI. And we never, what's interesting about this language is you never describe how things change. Basically all you're ever doing is like asking a question and formatting the result of that question. You build all sorts of crazy things this way. Yeah, we build a clock. That's interesting. Of course, we built to do MVC, right? Can't not have to do MVC. We also built a Turing machine just to be sure. So that is in there. And what's interesting is once again, we bootstrapped it. So everything you saw being rendered on the right hand side, all of those tables, all of the UI, even so this thing was actually pushing processes distributed. So it would run your program in another thread and then subscribe to that other thread and pull data in. This entire little thing here was written in 200 lines. This is all of it right here. So again, this is like totally like crazy way of thinking about the world, but it kind of works, right? And so it was from this prototype that we started to realize, okay, we don't yet know how in the world we're gonna present this to people, but this seems like a pretty sound model to build off of, right? There are definitely problems that we have to figure out. There's performance and interesting things there. Although surprisingly, if you reduce your language to only operations on a B tree, which is what a query language ends up doing, it ends up being pretty fast kind of by default. But there's still lots of interesting work to do there, but the foundation is solid. The foundation can express the kinds of things we want to express and we just have to figure out how to show it. I don't know how to get back to my presentation. So we tried again. This time, I don't know why, but we ended up going back to the Excel thing. But this time we had something a little bit more interesting which was you could actually build UI and this was the first time that you had like a drag and drop UI builder. And I know that's a little hard to see, but I dragged out a button there, right? And we're gonna build the incrementer example. And I'm gonna give my button a name, we'll call it incrementer. And there's this little button down here that says get the clicks for that button, which is just a table. Everything is always just a table, right? If data's gonna come from the outside world, it gets shoved into a table. If you wanna do something to the outside world, we shove it into a table and something out there kinda looks for it and does something with it. So every time I click, I got a row in this table and then incrementer button is just counting the number of rows in the table, right? And this had that Excel thing going on. So you wrote like an Excel formula in here. You said count them. And then you could just drag that column onto the button and that was now bound, now it's sort of like data bound it to the button. And yeah, it was asking me what to bind it to, bind it to the text and ta-da, an incrementer button. So what a problem that took, we would take a professional programmer easily 30 minutes to do, assuming they knew what they were doing and if they don't, who knows how long, could take 30 seconds, right? Like we could be much better at this if we thought about the problem slightly differently. That one, again, suffered from the same problems that I described before, which was that you lost all the context when you're building up these tables and it didn't really fit the model very well. So we tried this other thing, we were like, hey, the UI builder thing worked out pretty well. Let's clone Foursquare, let's clone a production ready website and see what that looks like. And we built each time, right, we build a new Eve to try and do this, try and understand it and we test it with people. This one was good enough to build a production ready clone of Foursquare. It was abysmal doing it. It was really, really bad, although not because of the UI editor, that worked out really well. But the way we wrote queries in this was really awkward. We tried to mix the two. So we had the tables, right, and then we had the information, basically the sources of all the information from the tables up at the top and it kind of looked like a SQL-y looking language. It was just bad. It's hard to explain exactly what was so bad about it until you use it and you fully realize exactly how bad it is. I don't have enough time to show it and I don't want to be ashamed, so I'm gonna skip that one. But it was still interesting. It was the first time we did not have to write any code to build a real website, right? You could do this purely without typing anything, more or less. Which was interesting, again, but it still wasn't right. So the next step after this was what we initially released, so we're all open source and this is what we pushed out when we open sourced. And it was based on this intuition that, well, all of our attempts of writing queries not in a query language that a programmer would understand have kind of been crappy. But we had this intuition that when we passed around queries to each other, we drew them on the board and we drew them as what looked like entity relationship diagrams, if you know what those are, little bubbles with lines between them. And we realized, well, if we draw them that way to explain them to each other, could we make them work? And we hesitated going in this direction because we know lots of problems with this kind of visual programming. And we had even built the boxes and arrows version of this long, early in our process and realized this is not gonna work. But this is a very different property because what you're describing is not a set of steps or a data flow. You're describing a shape. You're saying, I am looking in the database for a shape. And specifically, this is a famous shape. It's known as the three-click query or the triangle of friends, basically a friend was a friend of a friend was a friend. This happens to be a notoriously difficult thing in databases to optimize for. And you'll notice it has this wonderful property. I asked for a triangle, so I represent it as a triangle. This is one of the first times that people seem to understand relatively complex queries without us having to explain much of anything to them. A very simple set of things. And they were like, oh, okay, triangle of friends. It's a triangle, right? And then, you know, here's a slightly more complicated one where you're getting the, you know, you have a bunch of departments and you're trying to find out what percentage of the total cost each department is. So there's a bunch of aggregations going on in here and then you're dividing those to get the percentage. And this was really interesting because like I said, it was the first time people could understand it. It didn't suffer from the same scaling problems that data flow, like visual data flow languages do because your shapes never get that big, right? It's not like you're describing the entire flow of a program which could be, you know, of infinite size basically. These were you're only ever asking for some shape and it looked roughly like this. And so it seemed to scale halfway decently. It was really hard to build systems in it though. And we learned that this focus on individual queries and results wasn't really the right thing. It sort of, it took you away from what you were actually caring about, which is the data, right? You're always asking a question to get an answer back. And this focused a lot on the question and a lot less on the answer. And these like units ended up creating these silos that you then did a lot of back and forth with. It was a lot like how you deal with, you know, if you're building a program and you have a bunch of different files, right? And you're like going back and forth because the functionality one is across four or five different files. Well, you have the same problem in this but exacerbated where, you know, it's like only looking at one function at a time, right? Okay, so we zigzag because that's what we did. And we tried, hey, let's take the madlib looking thing, the fill in the blank sentence thing. Let's put it in a notebook like the very first one. Let's focus a little bit more on the answer and let's make it a little bit more visual and let's see what happens. So we wrote this. And this was interesting because this one would allow, you could actually like talk to it. So we did this, I put this, I got it running on my phone and phones have dictation on them now as you could literally just like tell it a query, right? And it would just give you an answer back which is really interesting and cool. Like that's a compelling place to eventually be. But we found that unlike in like the Jupiter case where you're kind of like writing out the set of steps you got to an answer for, we're talking much more like these are all live, right? They're changing, they're not captured in time. So the linearity of a notebook is a really bad solution to this problem because it implies that this, then this, then this, then this, which is not true in this world, right? So you might do something at the bottom that would totally change the first thing and that didn't fit the model very well. And also it still feels like programming. You're still kind of doing this joining stuff. You had to know the names of the things you were looking for, right? Not the names of like Chris but like the names of the relations. Is friends with or you know, has a house, right? Which again is a hard thing because who knows what they are. If you didn't write them, you kind of have to guess. And yeah, we could build tools that help you navigate that. But you're talking about lots of them. It's, it doesn't matter what tools you have, right? Okay, so we love the foundation. We still hadn't figured any of this like UI stuff out where we tried. We had built basically 30 versions of Eve at this point, right? And we were like, okay, we're clearly doing something wrong. What assumption are we starting from that screwing us up? And I think the assumption was, and once we threw it out, it like cleared things up a bunch, was that we were still approaching this as if we were building a programming environment, right? And the idea wasn't to, it wasn't really to make programming environments, right? The idea was to enable a thinking tool. And a thinking tool doesn't have to look like a programming environment. So stop, basically. And where we are now, and the thing that we've decided to commit to, because it's tested extremely well, and we're extremely excited about it, doesn't look like programming at all. Not even a little bit. So I'm going to show it to you a little bit. So we have this box, and it's kind of like a search box. It's just a really fancy search box, more or less. So I'm in the system. If we look up Chris Granger, there's not a lot about me. Here, I'll make it a little bit bigger. It's not a lot about me, but it says I am an employee at Kodawa. That's the company that we run. I have a salary of 20, which is way too high. We'll change that. I have a salary of two. And so this is actually kind of like a wiki, interestingly enough. If you know much about wikis, this is what's called a semantic wiki with some changes to it that make it a lot more powerful than semantic wikis typically are. But the idea here is important. One of the things we found, every time we focused on the excels like way of representing things, was that people don't think of their data as like tables a lot of the time, right? A lot of the data that we really wanna put into a system for thinking, yeah, some of it is gonna look like a table and you should be able to do that. But a lot of it doesn't. A lot of it's stuff like random stuff about Chris. And I'm just gonna like write random properties that I happen to know about him at the time, right? That like I have a salary of two and his height is really short, right? And now to die, that data is just available there for me now and I can start to ask questions about it. So what is Chris Granger's salary? Well, it's two. What about his height? The thing that I just add, hey, he's short, right? So this has this very, very fluid way of working with information. What's interesting about it is, again, one of the problems with this navigation thing I was talking about before, right? You have to know the names of all these relations and all that stuff. Well, in this case, they're just links, right? Like here are all the things that I'm related to. It even tells me down here that I'm related to another thing called engineering. And if I go there, I see the engineering card and here are all the engineers at Kodawa. And that's interesting and I can like dive around in these just like you could on Wikipedia, right? And that's actually a really interesting thing because, A, we know Wikipedia works. B, if you could imagine at Wikipedia where all the data was available to you to ask much more complex questions, that's a pretty compelling idea. So for example, we know that there are departments and I can look and it says, oh, there are two departments here. This is just sort of generated by the system, right? If I add a new card that says it is a department it'll just show up here. But let's do something interesting with it. Like, let's sum the salaries per department. So if you think about what just happened there this is important. There is no direct link between department and salary. Departments don't have salaries. Employees have salaries, right? But because of the way the data is structured we can trivially figure that out for you so that you can say it in this very natural way, right? I don't need to say, well, first get all the employees then link them to the department then group them by that and then sum them. And actually if you wanna see we can actually see exactly what it chose to do. They can pop it open and it says, oh, it actually just gave you the process I just described, gather departments, gather the employees related to those, look up their salary, group them and sum them. But instead you just ask this very straightforward question, right? And you can see it gives us back this nice data table here and this is another important thing. It shows you exactly how it got that answer. So this is something that SQL will leave you in the dust with. When you start to do things like grouping you start aggregating all the aggregands are lost, right? All the things you aggregated over are gone. One of the things that's amazing about this way of working is that we know where every aspect of the information comes from. We have complete and total provenance information. And so we can show it to you. This is exactly how we calculated the number 16. Here are the people that went into it. Okay, so I said, I mean, that's cool. We can ask questions, get an answer. But this isn't programming yet. You need to be able to format the results into something interesting. That's when you get programming. That's when you get change and stuff. So the way we do that is just by adding a card. So we call these cards. And what we wanna do is we wanna say, this is like a placeholder, we wanna take the department for each department up there, right? And we're gonna say something new about that department. We're gonna say, well, that department has a total cost. And that total cost is equal to the sum that we have there. And you'll see, now we have this little card down here. And nothing looks like it's changed, but if we go back to engineering, you'll now see there's a new value down here at the bottom of this card. This is engineering has a total cost of 16. I can now compute over that. So we can start to say, departments with their total cost. Right? It's just new information. And so this is like almost like a Wiki where you can ask a question and then generate new information as a result of that. And that is enough to build anything. You can build compilers this way. You can build websites this way. You can do all sorts of crazy stuff. But what I think is the most compelling is that you don't need to build an application to do anything here. For the most part, you could just work in this, right? You could just sit here and continue to ask questions and set up these little rules that you have to do very interesting things. So for example, let's go back to Chris and let's make my salary crazy again. Which is way too much money, right? And if we go back to, let's get the total cost of departments. You know, it doesn't really matter how I write this for the most part. Total cost of the departments. You'll see it's 34. And actually, you know what? Let's change this around and we'll say that departments with a total cost greater than 20, right? So this is actually a full query language. You can write all sorts of crazy stuff in here. And what we'll say is that those departments are, this department is overspending, right? And now if we go to engineering, do I not do it correctly? I forgot what I called it, two, two important. All right, departments with a total cost greater than 20 and this department is overspending. If it doesn't work this time, we'll do it. All right, good. So there you go. Now this department is overspending and now I can again start to ask questions about that. Get all the departments that are overspending, send their heads an email, right? And the interesting thing is all of this stuff is live. So if I come down here and open another one and go back to Chris Granger, you'll see my engineering has a total cost of 34. That's because I have this really high salary. But if I go and I change it back to two, all goes away. It's 16, right? This is all live. I never describe how things change. As they change, it's just views over the data. And so I was gonna show an example here that I thought was funny. So there's the Apple, the recent Apple keynote. They showed a thing that got a lot of people really excited. So they showed on the Apple TV, you can now talk to Siri and have it find you. The example that the specific query they gave was episodes of modern family that contain Edward Norton, right? So we can do that. So we can say episodes of modern family with Edward Norton. There you go. That happens to be the only one. We can also say, well, how about without Edward Norton? How about we count them? Right? This way of working allows you to just very easily, very fluidly just start to ask questions. And I think that the craziest realization for me and all of this has been, if we took a step back and stopped thinking about this as programming for a moment, right? We managed to come up with a thing that doesn't look like programming anymore. It's just asking questions and formatting results. And that encompasses all of the things we wanna do. And that is like an amazing result to me. That is a fascinating thing. And there's still lots of work to do here, right? I'm not saying we've done it. And I have no idea really what programming is gonna look like in 10 years. But my hope is that whatever programming does look like that it looks nothing like the programming we have now, right? The programming we have now, the last thing I want is you guys who are trying to cure cancer or who are trying to understand the cosmos or whatever you're doing, have to worry about Unicode or have to worry about event ordering or these ridiculous things that have nothing to do with the amazing stuff you were trying to do. I don't want it to look like that at all, right? Because at the end of the day, like I said, the real goal here is a thinking tool. And that is what we have to get back to. And again, it's not a thinking tool for just me, right? I want to remove the cards. I don't want you to have to punch the holes anymore. And I want it to be able to think for a soul. So there you go, that's my spiel.