The Future of Programming: Enhancing Feedback with Live Programming

Programming experiences must evolve towards more fluid and interactive systems to keep pace with advancements in machine learning.

### The Future of Programming: Embracing Machine Learning and Live Programming
* 🤖 Good afternoon everyone, I'm excited to close the conference with my talk, reflecting on my **eight years in research** and the shift from **programming languages (PL)** to **machine learning (ML)** as the **current hot topic**.
* ⚔ As we face the challenge of machines potentially taking over in the future, we must **adapt and become "cyborgs,"** utilizing technology more effectively in coding practices.
* 📊 I titled this presentation "**The Mother of All PL Demos**," inspired by Brett Victor's influential work in 2011, aiming to **enhance programming through better feedback loops and experiences**.
* 💻 Today, we have advanced tools like IDEs that provide **immediate feedback**, but the goal is to evolve programming into a **more fluid and continuous experience**, akin to "**live programming**," a concept championed by Chris Hancock in 2003.
* 🎯 The analogy of programming as archery versus using a water hose illustrates the need for **seamless adjustments in coding**, where **small changes lead to immediate feedback**, rather than starting over each time.
* 🎨 My demos showcase the importance of language design focusing not just on **expressiveness**, but also on the **overall programming experience**, emphasizing features like **co-completion** and **scrubbing** for smoother interactions.
* 🔄 I demonstrated how scrubbing allows for **real-time adjustments** in programming, enhancing user experience by enabling **continuous visual feedback** and **manipulation of variables** without the need for traditional coding steps.
* 🔍 Lastly, I discussed the underlying technologies that support these advancements, such as virtual time machines and a typeless type system, which aim to create an environment where programming feels **more intuitive and aligned with how we naturally interact with technology**.

Okay, so good afternoon. I am proud to have the last talk of the conference, which is a nice spot to be in. Okay, so I've been in research for a while now, eight years in the research lab, and I've noticed recently that, you know, PL is no longer the hot topic anymore. The hot topic today is ML, right? Machine learning, not the language. So, how are we going to fight the machines, you know, because the machines are eventually going to take over. They're eventually going to win, no doubt about it. I mean, we're done for, but hopefully that's like 50 years from now. But until then, you know, we have to fight this battle between PL and ML, and we have, in order for us to do that, we're going to have to become cyborgs, right? We're going to have to use the computers more efficiently in writing code. No longer can we just use emacs and dynamically typed languages and compilers and do everything in our head.

um because the competition is getting smarter, so we're going to have to also get smarter. So, I titled this talk The Mother of All PL Demos, but it was more of an aspirational thing. I don't think I'm actually going to get there, but I'm sure you guys will all still be entertained. Um, Brett Victor, back in 2011, he really did the mother of all PL demos, right? I don't know, is anybody familiar with Brett Victor's work? Ah, good. So, maybe you'll think a lot of my stuff is original. That's great. Um, some of my stuff actually is original, but um, but a lot of it, you know, he's a very smart guy. He showed a lot of really wonderful concepts, and I copied a lot from him. Um, so, you know, in the uh sort of tradition, you know, I'm trying to do my own, get together my own like Grand PL demo so we can sort of push things forward. So, programming, I posit, the programming benefits greatly from

increasingly better feedback loops. So, if anybody around here was programming in the 50s, and I don't maybe think anybody is, but you know, uh man, there's two screens here, all right. So, there's like, you know, these ladies with the switches, right, trying to, you know, program the computer, right. And of course, we then stepped up a little bit. We got card punches and then teletype, and wonderful. And today, we have, you know, keyboards, and we have multiple monitor displays, and we, you know, we don't actually, we can actually see our, we can actually compile our programs at our terminals, and you know, we even have IDs that give us U syntactic or compile time feedback, you know, right away. So, we have a really, we're getting better, more and more tighter feedback loops, um, compared to what we had, you know, in the 50s and the 60s and the 70s. What about tomorrow? What will programming look like tomorrow? And if anybody says slightly better than what

we have today that's not interesting, right? This is what we want. We want, you know, what we see in the movies, right? Um, you know, if you're going to build your power suit to fly around and fight, you know, bad guys, you know, you need a Next Generation programming environment. Okay, um, and this is all fictional. These are all fictional interfaces, but there's an element of reality to them, you know, that the experiences will be more and more fluid. That's what we want, and that's what we should be aiming for. But what does a more fluid experience mean? So, um, there's this term called live programming, and I'd like to say that it was at least the view I subscribed to was invented by this researcher called Chris Hancock. He did this dissertation in 2003. It was beautiful big ideas in computational literacy and real-time programming. Um, and what he stated in his dissertation was something called this water hose, right? We want programming to be like a water hose. And what does that mean? So, think about archery. You shoot the arrow.

you aim, you shoot the arrow, the arrow flies, and it maybe misses the target, and then you have to shoot again, right? But that's a really horrible feedback loop because each time you're kind of starting over again. Maybe you're really skilled and you can kind of steady your aim well enough so that you can actually not start over again, but you know most of the time it really is, you know, for most of us, us, right, is like really hard. And there's an Olympic sport for archery because it's a very hard thing to do. Now compare that with pro, with hitting a target with a water hose, right? This is easy. You take the water hose, you move the water hose over, and you hit the target, and it's done. Very easy. And why is that? Because you never stop aiming. You just move it until you hit it, and you're done, right? Whereas the archery stuff, you stop aiming, and you stop, you start aiming again, and you have this disconnected user experience or

programming experience. Well, if we say it's programming, then you know this is programming. Today, you write your code, you hit compile, you test it, and then you see where it fails, and you start it again, right? That's archery. We're at the archery level right now. We really want to be at the water hose level. So, I'm going to break into a demo here. Most of this talk is going to be a demo, but I added some slides because I want to give you guys some more context, right? And so, the first sort of feature I want to talk that I'll show is sort of this idea that language design shouldn't just focus on expressiveness, shouldn't just focus on the language. It should focus on the programming experience, the execution, the IDE. And one way I've sort of manifested this principle, right, is in these holy terms, right? And what's nice about these things is that, you know, the language has a way of expressing things that you don't know what they should be yet, you know, to then

you can do co-completion, or then you can even execute those. Um, it'll make more sense when I actually do the demo, but I just wanted to give you a little bit of context before I did that, right? And then scrubbing, so this is where we get back to the water hose. So who here kind of knows what a continuous function is? Yeah, okay, cool. What's really cool about a continuous function is that you make a little change in the input, and you get a little change in the output, right? And what we really want is continuous functions for our programming experience. We want little changes in the code to result in little changes in the execution output, and then we can just sort of like, okay, go up, down, okay, better, better, worse, worse, worse, right? Because that's what continuous functions give us, right? And we can manifest this in something we call scrubbing, and I'll demonstrate that really quickly here, and then there, just seeing things, you know, being able to see things in your programming execution, right? Um, you know, you want to

see how the program executes without actually running the program. Maybe you have a strobing effect where you can see a ball, you know, in multiple frames, or you can see the data without actually having to, you know, print it out explicitly, or you can just see it as it changes. Okay, so with that in mind, I'm going to do my first demo, see if I can remember which one it was. No, not that one. There we go. Okay, so um, I'm in now, I'm in my programming environment. I'm going to type a question, right? This is a holy term. Can you guys all see that? Is it, I don't know, these are a little bit smaller than the other place. Okay, well, that's just a question mark too. There it is, a question mark. Okay, it means I don't know what I want to put here yet, right? I didn't know exactly what I wanted to type, and this provides an excellent sort of context for coom completion. So we're going to do co-completion here, and you know, we have a few methods, not a lot.

because it's still a pretty it's a prototype. We have one thing called Draw. I'm going to select draw, and as soon as I select a draw, a little square appeared on the screen. I don't know if you guys can see that here. This square appeared on the screen because, you know, it's executing, right? But what happens is when I select a draw, all these other holy terms appeared. One for the receiver of the draw, one for the color, one for I don't remember what that is. Oh, the pen, right? And then the Z index, okay? But one for the color here, right? And if I can do co-completion on this, then we can have a blue here. And I can do co-completion on this guy, and hey, we can have a circle, okay? Um, and then we have more holy terms. This is the position of the circle, this is the radius, and this is or the diameter, something. And this is the rotation, which doesn't make sense for a circle, but anyways, right? So then I can

um, go ahead and turn this into a tile. We can put some numbers in there. You can put some numbers in here, right? And you know, this is kind. You might have seen demos before where people are writing their JavaScript code, and it's re-executing in real time, right? So, that's cool. I mean, when the first time you see, they say, Yeah, that's cool. Then, the second time you see, it's like, Yeah, maybe that isn't so cool. Because look what happens here. Like, let's say if I want to change this 100 to 200, right? I have to delete the one, hit the two, delete the one, hit the two. Everything's kind of just jumping around. It's not really smooth. It's not fluid, right? And so, this automatic re-execution thing isn't very useful. Well, it's useful, but it's not as useful as it could be because we don't have a very fluid programming experience. So, what we can do is we can scrub, right? And scrubbing basically means I'm going to use my mouse and this

is actually where the mouse is actually useful in programming. Right, I'm going to use my mouse, and I'm going to just change the constant, you know, by scrubbing the value, right? So, we can scrub this back to 100, maybe 150. We can scrub this one, you know. The idea here is that now, instead of just having things jump around on the screen, they're moving very smoothly, right? And so, now we can actually put it where we wanted to put it. We can even scrub both of them at the same time, right? Move it around like this. We can do the same thing with the radius, but we can also do the same thing with the color. And the color is not something that you generally think of as being scrubbable, but you know, hey, we have blue, we have a list of other colors that are, you know, literal colors, and we just scrub between them. And as we move the mouse through the list, we actually see the color that we're choosing, right? It actually executes, right? So, we

make that red, or maybe we want a purple color, or maybe we want something else and more precise. Maybe we want to deal with the color coordinates, right? So then we can scrub those, and we can also scrub these into visually afterwards, I hope, okay? So you know, so having this ability to scrub things works really well in this live programming context. And actually, before I was just doing, you know, type your code and see the execution on the screen, and that was not good enough. And now I actually feel like, wow, this really is better, okay? So I'm going to go and do a more intense example, but I need my little rectangle there first, okay? Good. So let's go ahead, and I have some code set up here, okay? So now we have a circle. We're drawing a circle on the screen. I have a lot of other stuff there, some utility functions and things like that. We're just going to make this circle move, right? And to do that, first, we need to have it positioned in the center. We need to position it in the

center of the circle because if you do any physics computations, it's really hard to do it from the left-right corner of the circle. So, we do this position here, and we do D, and then we subtract that, you know, we subtract the this, and we divide it by two. So, this is the radius times two, and we divide it by two, and we get sort of the dimens, we get the position Circle. So, if we do that here, and let's say we give this a position, and let's say we get this 75 right. As I scrub this, you can see now the position position is being scrubbed from the center of the circle versus the Left-Right, the left-top corner of the circle. Okay, so now we're going to make the thing move, and we're going to say p equals P plus v / 50. All right, so now the circle is moving. Okay, it's not really moving. So, I have this ontick here thing that's an event handler that goes off.

every tick of the every frame, basically every 15 milliseconds, right? And we have 200 ticks that are preloaded in our system. And what that means is that we just go ahead and we execute the program for 200, uh, 200 ticks, and we strobe on every 20 ticks to provide a rendering of where the ball is going. So, if we scrub tick here, right, we can actually see the ball move, right? This is just saying this is time zero, this is time 167, okay? Um, and we can also then can also play with this, the velocity, to sort of, you know, to see where it would go. And a velocity is pretty boring, so we should add, you know, Force, okay? Now we have a parabolic trajectory for the ball, and again, um, we can scrub it, you can see the ball kind of fall off the screen. Um, we can change the force, this is probably what they meant by use the force, okay, never mind, right? I can, you know, move it like that, and we can make that negative, make that negative, and it gets kind of cool.

right, let's just not make that negative though. All right, and make that zero. Okay, so now I want to make the ball bounce, so I need to do a couple of things there. I need to um, so oh, oh, I need to do this first actually. Oh, hopefully, I don't cause a crash because I went off script. I need this expression below here, this D DD ID two. So what I'm going to do is I'm going to create a new value, r r, and I'm going to give it the holy term because the holy term is something that I don't know or I don't want to type again. And I'm going to take my mouse, I'm going to click on the holy term, and I'm going to ground it on this divide symbol, and that will just move it up. So this gets the expression and the value moves down here. Okay, so it's like kind of like micro refactoring in the language. These holy terms are incredibly flexible for that kind of thing, right? And again, I do the same thing here. I

have this P1, and I'm just going to, you know, use the holy term move it, move, move all the stuff up, and have P1 take its place. And then I'm going to clamp it because, you know, you don't want things going off the screen. It's completely not cool. So, RR was like the minimum. That's like the minimum size of the ball, and we can use screen size here for the maximum size. Now, that's not quite right. I need to subtract RR from screen size. Okay, now that's good. Okay, so now the ball at least is not going off the screen, right? And we need to do something else. I wrote these utility functions before the talk, so we have this inflect here, which will look at the position, and if it goes off-screen, it will inflect the velocity. We just have to do a pairwise multiplication of the vector, so, and I do that via times times inflect, um, um, and we need the position P1 and the RR, I guess minimum. Okay, now

it bounces okay. So now we have a bouncing ball, which is like hello world or writing a compiler in the PL for a validating example for live programming because you always see it. Um, and now I'm going to take this. I'm going to wrap it up into a procedure. This is the one that crashed in the last talk. Hopefully, it doesn't crash this time, right? So I'm just going to do the same thing. I define a new method. I give it a holy term, and I'm just going to drag it, and it should just disappear because the method is no longer being called. I'm going to go up here, and I'm going to type a loop for I in Z until, let's say, 10 colon ball. All right, we're only seeing one ball, and there's 10 iterations, but the problem is I gave them all the same position. So I'm going to turn this back into a holy term, control K. Right now, they all have unique random positions, and the holy term is really cool because what it does

is it gives the it gives the um it it computes a value if if you don't specify a value right, and it it provides a unique value so that not every not all your unknown things don't appear in one place, which is really useful, and like the colors too, right? I mean, these guys all have different colors, even though I didn't assign them colors. I could make them all blue, right? But then they're all blue, and that's not useful. So, it really is just nice to have something that just gives random colors to everything, right? So, now we have a lot of bouncing balls on the screen. You can kind of see how they move. You know, we can, you know, change them in mass. Okay, now um, let's see, what was I going to do next? Yeah, oh yeah, and we can also scrub the loop here, right? That's like five. Let me do some return here so we have more space to see what's going on, right? Zero, 1, 2, 3, 4, 5, 6, 7, 32, 33. Okay.

let's go back to something reasonable like five. Okay, then we have five bouncing balls, and we can scrub that just like we can scrub everything else, right? And, uh, we can also see things. We can also inspect the values here. We can do a—I have to go up here—and if I do a Control G, then it will go to the method. This is like goto definition, but it's like go to definitions, go to execution also. And I can do things like probe the color, right? And I can also type a little ad symbol here that will just show it on the screen continuously. And this is actually kind of cool because now you've pinned some probed value there. You can see it forever. We can do that for a position too, right? If we scrub this, right, we can see it's moving in. We can see the position is changing in the UI, right? And, well, we know what kind of ball it is. We know this ball has the same color as this, so we know it's this ball right here, right? And we can change

this right. We can scrub the loop iterator right now. It's the green ball, now it's the purple ball, black, and whatever that color is, right? So we can totally navigate through the entire execution of our program. We can also do this thing called log, right? And in this case right now, we get position and velocity, right, for each of the iteration. Oops, that was not a good idea. That's okay, we recovered. Running out of space, right, right. We can see the velocities and positions here, and there's a two-way connection here, right? We can actually click on this, and we're at the first one, we're at the second one, we're at the third one. What this does is when we click on a log entry, it goes to the log statement as you would expect. Not really, but you should expect, right? But it also goes to the execution context of the log entry, so it's useful for debugging, okay? And we can actually look at one of these guys here. Let's look at this.

one here when it bounces on the wall. No, that was too much. All right, there we go. And then we can look at the value here. One of these is minus one, minus one, and plus one. The x is minus one. So if we go to control G, there we jump down into the implementation of that, and we can see the value there. That's minus one. That's causing it to bounce off the wall. This dark purple one, and that's not bouncing. And we could do that. We can see why this value is its x value is 6817, and the maximum is 6815. That causes the minus one. That causes it to bounce. Okay, so you can see things. You can see a lot of things, and you know you're not setting a breakpoint here. You never set a breakpoint. It's all spatial, right? I'm just scrubbing around my loop iterations and adding symbols and hitting log entries, and I can see all the values in my program without ever typing in a

breakpoint. Okay, so let's go back to the slides. All right, so I have another demo here. So this is my first demo. So we're going to do another two demos and what I showed you before. Okay, scrubbing and this holy term stuff. And so now I'm going to show you some other stuff on abstracting. So people do not deal well with abstraction. It's hard, right? Um, and you know, it's, it's, it's, there's other ways of doing abstraction, right? Instead of just saying, think really hard about the problem and then type the magical abstractions into the computer and then you'll get the right concrete representation for each instance of that problem, right? But there's also this way of starting with a concrete example and then abstracting that. So we're going to do that. We're going to, I'm going to show you an example of create by abstracting, abstracting, right? And then I have this like inside-out picture where everybody goes crazy because the abstractions are just weird and also sketching abstractions, right? So

what we're going to do is I'm going to show you an example where we're going to sketch things on the screen, and they're going to be abstracted aggressively. So, two more demos to go. Let's go this one. Let's just nuke everything on the screen. Sure, the tick is zero. Good, right? Empty. All right, that code is all gone. I'm not seeing my cursor anywhere, so why don't I go ahead and restart this. All right, that's just as good as empty. All right, so what I'm going to do now is I'm going to hit the screen three times, and each time I hit the screen, the shape is going to be created. So, this is for the demo, right? So, I can hit the screen here once, and there's a rectangle where I tap the screen. Okay, I'm going to scrub that into a circle, going to move it to the corner of the screen, and resize it. Okay, now I'm going to do that again, and this one I'm going to leave as

a rectangle and resize it to a particular shape 150 here. Okay, I'm going to build a pill shape here, so we're going to need one more shape set to a circle and moving it into the position here, see 150 and then 100. Okay, so notice that now before I was actually scrubbing in the code view, and now I'm actually just manipulating the shapes directly. It seems like a reasonable way to manipulate shapes by moving them directly, and now I'm resizing them with this dot, and I'm moving them with this some dot up here. We can't see anymore there, okay, and now if we tap this right, we're going to now do a union. So all I have to do is select this shape and then control-click on this shape, and we do a union, and control-click on this shape, and we do a union. Now we have a pill, a pill sort of shape thing, and now we want to make the size parameterized, okay, because we have

this pill, but it's like 100, 15, and we really want something that's a lot more flexible than that. So, what we're going to do is we're going to create another value here, a holy term, and we're going to say, Well, there's a lot of 50s, 100s, and 150s repeated here, so maybe we should turn those all into the same variable. So, we're going to take this holy term, we're going to drag it on this Tuple, right? And it just, again, it swaps out the concrete value for the value I'm defining up there. And then we can take this one, 150, we can drag it onto that. We can take this 100, drag it here, and there's another 100 over here. This one is kind of weird; it's 50. So, we'll just say, Well, maybe it's related to 100. So, what we do is when we drag it, we get the arithmetic expression, right? And, Okay, maybe that's right. So, let's make it bigger. Okay, that seems

fine. Let's keep it at around 200, 199. The problem with scrubbing is that it's not very precise. All right, fine, okay. And then, but if when we do this, this oo, that's not right. We've kind of miscalculated the height, right? So, so for some reason, our, our, our, our, this, this, this expression is wrong, but it could be something else. All it has to do is be some kind of expression that don't do that, um, involves s0, syy, and, and computes to fit to 100. So, let's look at what the other options are by scrubbing that. So, we have minus 50 * 0.5 and divided by two, right? They're about the same thing, right? So, we'll select that one, right? And now, that also takes 100 divided two is, uh, sorry, right? 100 divided by two is 50, right? And 100 minus 50 is 50. So, they're equivalent for that use case, right? But they're a different, you know, depending on what abstraction you choose, has different

effect when you when you change the height and now it works. So we've done a creation by abstraction here, okay. And then we just need to turn this into a method. So let's create a position here, 100 by 100, and translate by P, right? And let's go ahead and define a method here, def pill return question. So we're going to do the holy term thing again, um, now we're going to do it for something that has a return value, which is a little bit more convenient, right? So what happens is that now we refractor this into a method, and it's replaced it with a call to that method, and that's so everything in the program stays the same, we're just abstracting it more, okay? And we can even do things like this, we can take this position here, and we can scrub that, right? We have other options, we have valve R and R, we want to make it an argument, right? We want to make a parametric method, right? So we make it an argument. What happens then is that an

argument is added. We take the concrete value that P used to be, move it to the call, and everything stays the same. We can do the same thing with this. This is technically not correct, but we'll just do it for time right now. You know, I can move this here and change the size. Technically, it's a bit weird because the size isn't exactly right. Okay, so let's add some rotation here. Val R, it's like 13 degrees. And then we can do the just rotate R, right? And then we just change this into an argument like before. So now we have a shape that has a position, a size, and a rotation. And if you remember, remember before I had rotation in all my position, all my shapes, right? So when we scrub, we draw a shape, we choose one here. But when we scrub this, now pill has the right template. It can be a shape just like a hexagon, a pentagon, a triangle, whatever. We can actually then add that to our scrub list, and we can access it via

scrubbing okay so we can just, you know, uh, build up our shapes and, uh, use our abstractions. Okay, so now I'm going to take a different text, so I'm going to get out of this program. I'm just going to close it down, and I have another program. So, this one, okay, so I show these demos, okay, people like them, right? And I showed my lab manager, and he says, Yeah, this is cool, but you know, how does this help Microsoft? I work for Microsoft, by the way, right? And so, Yeah, it will help Microsoft in 20 years, he said. That's not good enough, right? Got to do something for Microsoft today. And, you know, we have all these wonderful surface devices like Surface Pro 3 and Surface Pro 4 and Surface Book, right? These are awesome, right? Because they have little pens, you can use them for sketching, and that means you can use OneNote with them. But maybe we could use them for programming. Maybe we could use the pen for programming. Because we've already found that the mouse works

well for programming, given the right context, maybe the pen would also be good for programming. Okay, so what I did was we, we, I got together with my HCI colleague. Okay, we're working on a new thing that is basically about, you know, we're going to sketch layouts. Okay, so I'm going to sketch a layout here, right? So I have my, uh, I'm not, I don't have a pen on this machine because it's not a surface. It's a, I don't know what brand that is. It's an apple something. Um, but you know, you can imagine that this is, this is designed for stylus, right? So I'm going to sketch a square or a rectangle here. And you know what's nice when you sketch something? You can say, okay, well, that looks kind of like a square, but then of course you take the ink and it doesn't look anything like a square. It's like really crooked and everything, but you can smooth that out. You can say, well, this is, we're going to recognize this as a square, right? And that's a very simple

very common thing that happens, right? And then we're just going to replace the ink with a square. We're going to dry the ink as a square, basically, is what they say, right? And now let's go ahead and we'll just do another one right next to it. And you can see my sketching with the mouse is really bad, but my sketching with the mouse is really bad. But this is the exact same rectangle square, right? And it's not because I was really precise, and I was able to draw the same square twice. It was because, well, that square was adjacent to that square, right? And let's say, well, you know, since you're not being precise anyways, let's try to match what you did previously. Let's look at the adjacent shape, and let's share variables. And when you share variables, something magical happens, right? You're not just... You just don't have two rectangles anymore. You have a program, or well, at least a parameterized drawing, right? So if I select this one here

and if I make it bigger, right? Or if I change the location and I make it wider, they both are affected because they're sharing variables. And I can show you the code over here. This is simple procedural code with a special syntax for declaring values, and that's it. There's no constraint solving going on here. This is just normal code, okay? So now you can do two more hello, okay? And so we have two more. They're all the same. You know, I drew them about the same, and the gaps are even copied so that the gaps stay constant, right? And what we get is all these red lines here. If I want to disconnect this thing here, I can click on this guy, right? And we can see the red lines. And I don't know if you're familiar with design, but these red lines are sort of ways that you sort of describe layout, right? And we have two red lines here. We can disconnect this, I hope. Let's see what happens when I do it, right? And now it's no longer bound. But then I can

reconnect it over here, and it will be bound again, right? So, we have this way of programming without writing any code, you know? And this is something that, you know, designers should be able to use, hopefully on their Surface Books that they bought from Microsoft. Maybe, um, you know, I can draw a shape over here, and of course, it's completely unrelated to this shape, but as I move it in, you see the red lines are popping up, they're becoming active right over here. You know, you see some red lines here, we can align it there, we can align it there, let's align it like that, right? And then I can move it over here, and you can see we can align it on this Edge, Edge 2, right? And then, uh, if we do that, we can see we don't see anything else. Oh yeah, we see that one, this one's good, right? So now, I'm taking this shape in, I'm putting it in post-prior, I didn't draw it next to it, but it doesn't

matter because I can just move it close in, and you know, you see the guidelines in PowerPoint. They say, Oh, this is a good alignment. Why don't you stop your shape here if you want? Right? I don't know if you guys use all the drawing apps are like that, but this is different. This is saying not just, Why don't you align them for this instance? Why don't you align them forever? Right? And so now you know, and now that this is aligned forever, if I move this guy down, right, that shape moves with it. It gets bigger, and if the shape gets wider, it all gets wider, and it gets smaller. Well, that one's not. Well, that I can fix that right away, actually. Click right now. They're all bound. So the idea here is that, you know, people can sketch parameterized layouts or programs, as we would, programmers would call them, without ever touching a single line of code. All right? And I got one more example here, so I'm just going to

restart this demo because I don't know um so one more example here is okay you know geometry people love geometry right it's kind of easy not that's not easy it's hard right so I'm going to do a we're going to we're going to do a shape here and we're going to use programming but we're not going to touch any code okay I'm going to draw a line and I'm going to draw another line so I got two lines here and I'm going to draw a perpendicular from this line right so I'm just going to draw a perpendicular right and what happens is that I didn't draw an exact perpendicular it just aggressively abstracted it's kind of perpendicular and it's kind of in the middle of the the line right so we're just going to take that we're going to fuzzily add a perpendicular line that's exactly in the middle of the line right and another thing is you know we have these two I didn't mean to do that undo right and now we have these uh

lines are intersecting, right? So, intersection is also one of those things that they have actually a mathematical formula for it. So, I'm going to draw, I'm not going to, I'm going to draw a line to that intersection, okay? And if you look at the code here, we have the perpendicular code here, and we have the intersect code here, right? And this is all, I just drew this, and it's all parameterized. Now, if I start playing around with these things, right, you can see that as the intersection point of those two lines changes, so does the where that line ends that I just drew. And if I do this, right, you know, you can see the perpendicular is changing, the intersection is changing. We can manipulate from this point, we've just created a solution to a geometry problem without doing any geometry, right? We can even sort of change the, you know, where this perpendicular line comes out, okay? So, there's two things, right? One is layout sketching, but then there's also this

ability to do trigonometry and geometry without actually doing anything. You know, just saying, Oh, I kind of want this right, and you know, and then you know, we know how to reverse engineer and say, Oh, well, these are the right abstractions to do that right, which allows, you know, us to do, programmers to do a lot more things than they were able to do before. That's it. That's the end of my demos. So let's just go back to the slides, and I have a few wrap-up slides here, right? So I want to revisit the water hose that I introduced in the first demo. This, the scrubbing right, little Cod changes, little output changes. That means you can sort of I, and you can sort of tweak your program until it's right. The problem with that, it doesn't apply generally, right? It applies to constants, it applies to positions, it even applies to simple abstractions like color and shape, but it doesn't apply to, you know, Loops, conditionals, and everything else that you might do in a program. So there's a lot of future work.

here is to make scrubbing useful so that we can actually scrub. You know, we can use scrubbing a lot in our program so that we can actually take advantage of this Auto re-execution while we're programming, right? One idea is to scrub two concrete values and then scrub abstract values and go between the two. And this is kind of like what machine learning does, but we're all going to become human machine learners pretty soon, okay? And I just want to mention a couple of the Technologies behind this work, right? One is the virtual time machine. So, I mean, you know, all this live programming stuff doesn't come very easily. You need a lot of technology behind it. So, if how many people here are using React because you'd be in the other talk right now probably, I guess not many, okay, good one, okay? So, React is this great thing. It takes your retained model programming mod, retained UI model, and provides it with an immediate mode veneer, right? And

that's basically what we want for live programming. We want to have this idea where, you know, if any kind of change is done, we want it to be actually incrementally reincorporated into the program execution, just like, you know, React reincorporates changes into the virtual DOM, right? Um, and this basically means that whenever there's a change, for example, if we want to move the position here, right, and we change it down here, this change gets propagated up because that position has changed, and so the circle moves, right? And if we actually change the code, then that just means that when the code is in a decent state again, that change is propagated immediately into the program execution. And writing a system like this is, I don't know if you're familiar with those little Segways that you just kind of stand on and they self-balance, right? You know, you're continuously unstable, right? We did not make it stable by default. If you want to make that stable, you would have added

training wheels, right? Wheels in the front, wheels in the back. Then you would never fall over, but that's no fun, right? So they add a gyroscope in there. So they say, We're going to make you continuously unstable, and we're going to make you stand on each, you know, at each moment in time instead of making the system stable to begin with. So that's the technology that kind of underpins this. And the other one is this typeless type system, right? This is all the code I showed you in this talk was statically typed, and there were no type annotations. And the way we got that was by inferring types based on how terms were used versus their definitions. Because traditionally, you say, Oh, the type was the value was defined that way, so we can give you a type. But that doesn't handle things like holy terms very well, right? The holy term could be anything, right? It depends on how it's used, right? Is it gives it a type, and that type gives it a default value, and

that default value is red, okay. And one of my friends kind of called this Quantum typing, right? You don't, you know, it's typing based on observations, based on how the value is used, okay. So, I'm at the end, so I just want to leave you here with something that, so when Brett Victor gave his sort of talk at Strange Loop in, I think, 2012, right, somebody asked in the audience, you know, This work is great if you are creating art and processing. What about when I'm writing a compiler? What should my editor do then? And Brett said something really prolific there. He said that these are design requirements for a good environment. How do we change programming to fit? So, what we're working on right now is we're trying to come up with a list of good things that we want in our programming environments, and they're not going to exactly fit our current practices, but you know, the long term is, you know, we're going to, you know, try to make them fit, right, so that we

can actually get that Iron Man experience that I showed you before, and I that's it. I can take questions now. [Applause]

The Mother of all Programming Languages Demos • Sean McDirmid • YOW! 2015

GOTO gathers the brightest minds in the software community to help developers tackle projects today, plan for tomorrow and create a better future.

Learn from thought leaders and innovators with top-rated videos released daily, and at our year-round conferences, masterclasses and meetups.

Get started: https://gotopia.tech

GOTO is produced by Trifork, a leading full-service supplier of high-quality, custom-built applications and end-to-end solutions.

GOTO YouTube Channel Code of Conduct: https://blog.gotocon.com/yt-coc


GOTO Conferences

The Future of Programming: A Battle Between PL and ML

The speaker reflects on the shift from programming languages (PL) to machine learning (ML) as the hot topic in research.

They emphasize the need for programmers to adapt and use computers more efficiently to compete with intelligent machines.

The talk aims to explore the concept of live programming and the importance of better feedback loops in programming, with a vision for a more fluid and real-time programming experience in the future.

Enhancing Programming with Co-Completion and Scrubbing

Co-completion in programming helps users make decisions by providing context-sensitive suggestions.

Continuous functions are ideal for programming, as they allow for smooth transitions between code changes and execution outputs.

Scrubbing, or using the mouse to adjust values, offers a fluid programming experience by enabling real-time changes without the jumping effect of automatic re-execution.

The simulation starts by positioning the ball from the center of the circle, making it easier to compute its movement.

The ball's position is updated using a velocity variable, and the movement is rendered every 20 ticks.

To create a bouncing effect, the ball's position is clamped within the screen boundaries, and its velocity is inflected when it goes off-screen, resulting in a realistic bouncing motion.

The Power of Unique Values and Randomization

The program computes unique values and random colors for objects, which is useful for differentiation.

It allows for real-time inspection and navigation through the execution of the program, making debugging easier.

The demo also emphasizes the importance of abstraction, suggesting a concrete-to-abstract approach for problem-solving.

Abstracting Shape Creation and Manipulation

The demo showcases a process of creating and manipulating shapes on the screen by tapping, resizing, and moving them directly.

A union of shapes is performed to create a pill shape, and the size parameters are parameterized using a variable.

The demo then refactors the shape creation into a method, making it more abstract and flexible for future use.

Using Pen for Programming: A New Approach

The speaker discusses moving and rotating shapes in a program, emphasizing the importance of position, size, and rotation.

They then transition to using Surface devices for programming with a pen, sketching layouts, and recognizing shapes to create a parameterized drawing.

By sharing variables between adjacent shapes, they demonstrate how to create a programmatic relationship, allowing for simultaneous adjustments and dynamic layouts.

This method allows designers to program visually, using shapes and lines without writing any code.

The tool offers real-time alignment and binding of shapes, enabling parameterized layouts that adjust dynamically.

It also provides a way to solve geometry problems by manipulating lines and intersections, offering a powerful new tool for programmers.

The Role of Scrubbing in Live Programming

Scrubbing is used to take advantage of auto re-execution in programming by alternating between concrete and abstract values.

The technology behind live programming includes a virtual time machine and a typeless type system, which infers types based on how terms are used.

The goal is to create a programming environment that can incrementally reincorporate changes and provide a "gyroscopic" stability, ultimately aiming for an ideal programming experience.