Future of Coding - Research Recap Seven - Master Planning

Episode Date: October 9, 2017

Inspired by Juan Benet (and Elon Musk), I zoomed out last week and thought about my "master plan" for this project. You can see a detailed outline for this episode with links here: http://futureofcoding.org/episodes/14-research-recap-six-master-planning.htmlSupport us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Hello, and welcome to the Future of Coding. This is Steve Krause. So these past two weeks were jam-packed with stuff. I was very productive, and I had a lot of fun. Starting with, I have been hearing a lot from listeners like you guys. It's been actually pretty crazy. I think starting on Monday of last week, every single weekday, Monday, Tuesday, Wednesday, Thursday, Friday, I got, I got an email from one of you that from someone I've never even heard, some of you have never even heard of, which was amazing. So yeah, like when I got the email

on Monday, I was like, Oh my god, this was the coolest. And then that that same reaction happened every single day. The only the only difference is that by Friday, I came to expect it. I think it was like 3 p.m. on Friday. I was like, where's my email? But then I got one. So that was really exciting. So keep it up, guys. Please keep sending me emails.

Even just saying that you listen to the podcast and you like what I'm up to means so much to me to know that people are out there listening and find value in what I'm producing. So please let me know. I really appreciate it. And then if you are also working in this space, please shoot me links to stuff that you're creating. I would love to check it out and get to review it on my website and maybe even talk about what I get from you on this podcast. I will just want to caveat that I am, as you can tell, busy. I have a lot of products to review, a lot of things to build, a lot of things to think about, a lot of people to talk to. So I can't promise when I'll get to your email. I can promise that within a day or so,

I should reply and say, like, I've gotten your email. Like, thanks so much for emailing. I will give you a link. I'll put them into the queue and get to them at some point, which I know isn't that satisfying. But I will get to it eventually. And I am human, so if you follow up again,

or again, you know, the more you follow up, the easier you make it for me to follow up, the faster you'll get a full response from me. So, in summary, please keep emailing. before, not these past two weeks, the ones before, as you heard about in the last research recap, was a deep dive into CycleJS and functional reactive programming, which was really fun. And I continued that, well, I finished that up last week. Well, actually two weeks ago. So at the beginning of this last two week cycle, I finished up my CycleJS deep dive, which in this case was finishing up the CycleJS Flappy Bird, which took me a long, long time. Yeah, I ended up finishing it on Webpackbin, which I love. I actually found yesterday while Googling around that there's an alternative to Webpack Bin that I found.

It's like a code sandbox thing as well. Those projects are great, and I really hope that those continue. Obviously, there is the downside where I can't use the CycleJS dev tools and other things like that, but apparently even Andre Staltz uses Webpack Bin, and he's a creator of CycleJS. So let's see what what else I ended up using like a new part of the ununify API, which is really cool. They, they like refactored the way you're supposed to deal with a dynamic collections of sub components. It actually took him 300 comments to come up with the new interface API for how to deal with this, which is really amazing. It actually took him 300 comments to come up with the new interface API for how to deal with this, which is really amazing. It's part of what makes CycleJS so amazing that Andre comes up with an initial idea that's okay. And then through collaboration with the open source

community, he gets to things that are better and better and better and better. Yeah, so that was great. I really enjoyed it. However, it did take a long time and it did hurt my brain, which are things to note. However, once the code was written, the mental model I had of it was really strong and I was able to change things with a surety that I knew what I was doing. It was like the opposite of spaghetti code, which is the reason you program in CycleJS and you use FRP, or at least that's one of the main reasons. So then I wanted to continue this functional reactive programming trend and kind of dive deeper. So I started making a Flappy Bird in Elm, which was also really fun. It was much, much faster than in CycleJS. Probably a significant portion of the reason why it was faster is because those frameworks are very, very similar, as I'm beginning to understand more and more,

the more I use them both. So because I just done it in the same app in CycleJS, it was much easier to build it in Elm. I knew what the model would look like. I just done it in the same app in CycleJS, it was much easier to build it in Elm. Like I knew what the model would look like. I just basically copied that over. I knew what the general ways the model gets updated is like. And so it was really just a matter of converting my CycleJS code into Elm, which is a really useful exercise. And it helped me to understand this question of how they're similar, because when you look at them both, it doesn't, it doesn't, it's not immediately apparent how they're similar. So let me actually talk about that for a second, because that did confuse me

for a while, but now it seems kind of obvious. So I guess one thing to put out there is that they're only similar when you use Cycle.js in a similar way. So Cycle.js is a very low level stream library. So you can use it in a lot of different Hakamemi kind of ways. If you go back and see the first version of Flappy Bird that I had, maybe like a month ago, you'll see that it was in this, I designed in this really, really crazy way. Like, for example, the Y position of the bird, I made totally as a declarative function of stuff. Like, it was like, like, I took the stream of space bars, and I merged it with the stream of mouse clicks. And whenever and whenever you did a space bar or mouse click, I turned that into another stream.

And I collapsed the stream. I got many streams of streams. And things were very, very declarative. But they also really hurt my brain. And they wouldn't have scaled to allow me to do things like when the XY position is greater than a certain value, the game should be over. But when you press the restart button, the game should be restartable. Basically, what I'm getting at is certain pieces of state depend on other pieces of state. And so really the only way to not hurt your brain is to have a singleton of state. And once you have a singleton of state in Cycle.js, that moves it like an inch closer to the Elm architecture. And then what you might want to do is create a notion of actions. And an action is basically just a label, like a thing that happens that updates your singleton event,

singleton storage of data. So like a tick event, whenever that happens, I move the pipes a little bit, I move the bird a little bit. A tick is like the tick of a clock, like time is moving forward a little bit, and I move the bird a little bit. A tick is like the tick of a clock. Like time is moving forward a little bit. You could also think of it as like the next tick of a render cycle.

And then like a jump event is like either a space key or a mouse click. A new pipe event that that's a could also be a an action so so you can in my original version or of the cycle jazz flappy bird I didn't have actions I kind of did it in a hackamay me kind of way, but over time I refactored things into proper actions and my code became much more readable. I also separate things out into like view and my model and my update. You know, I like slowly came up with the architecture

that Elm already has by default. And I'm sure you could do the same in Elm. You could like slowly intuit the architecture over time. And I think that's actually how the same in Elm. You could slowly intuit the architecture over time. And I think that's actually how the Elm architecture was invented. They created this language Elm, and they iterated through a bunch of different architectures. I think it used to be a lot more functionally reactive and much more stream-based than it is now. But I think this is how it came to what it is now.

It was much more stream-based, and they realized that there's this common set of use cases that people use and if you just build the architecture to work for that use case with all the defaults built in with like the model and the update and the actions all kind of built in then it just like makes things really much easier for people. So that's my current understanding of how it works. And I guess potentially if CycleJS wanted to make things clearer for their users, they could probably also have, they could explain the CycleJS architecture default, kind of like Elm has the Elm default architecture.

Elm is a little bit more prescriptive about how to use Elm than CycleJS is at the moment. But that's, I think, partially just because Andre likes to kind of be less opinionated and then watch where users take things and react from there. So yeah, those two were really, really interesting experiments. I learned a lot about functional reactive programming, and I had a blast getting to code. I guess one final note that I've made probably a few times already is that both these take

so, so long to program. And if you compare this to making the same game in WoofJS, it takes much, much, much less time. And I guess what I'm getting at is this begs the question, is functional reactive programming a good paradigm if it's so much less intuitive and so much harder than sequential programming like Scratch or Woof to make things happen? And that's a really good question. It's a good open question. And I think in order to answer it, you have to think about what specifically about functional reactive programming is hard and can we make it better? And you could say the same questions about imperative programming. What about it is bad, and can we make those things better too? The reason I'm more thinking about the first question, not the second question,

is that functional reactive programming has a lot of amazing benefits. I guess they're similar to the benefits that functional programming has. Your code is just more understandable. It's clearer. It's more declarative. There's a great picture that I have that explains what declarative programming is. But I'll talk about that in a minute. But then the problems with declarative programming are also numerous.

And so thinking about how to address those problems is a good line of inquiry. And so where this usually leads me to is, well, can we build a better... So one of the things that's really hard is typing it, just knowing what you could type, what actions are acceptable. But what's great about functional programming is that we have strong types, so it's very clear if you give the computer some information, it could help you figure out what other things are even possible with the values and types it's been given.

And so that's where Luna and Lamdu and Unison and Isomorph kind of come in. These are our projectional editors for functional programming. I think VisiCalc would fit in this category as well. So those are really cool in my experience. While using those, it has been a little bit annoying and frustrating. I will say, though, that Isomorph was actually very pleasant to use. So that was good. And also, if you listened to last week's podcast with Christopher Onand,

he also has a projectional editor for but for ALM programming for students. So apparently that makes things a lot easier for kids. So yeah, that's that. And then on the second question, which is, can we make Scratch programming or WolfJS programming, the sequential programming better? That's harder. Sequential programming inherently is messy. Like the computer just doesn't know what's supposed to happen because you don't tell what's supposed to happen. You're just telling it what to do imperatively. So there's less semantic meaning. It's more, it's lower level. So it's harder to, because the thing that's bad about sequential programming is that your code can get really messy, but refactoring it's basically impossible because the computer doesn't know the computer

helping you refactor it is impossible because the computer doesn't really know what's going on so so i think it's much it's much more tractable to make functional programming more intuitive and easy than it is to make sequential programming more uh more abstract more declarative better more abstract, more declarative, better, more refractorable, more understandable, more maintainable. So then things took a bit of a turn for the interesting. So I had a surprisingly amazing phone call with Andreas at curious underscore reader from Twitter who tweeted at me after my conversation with Paul Chisano from Unison, because he's a longtime fan of Paul's. He had some interesting links that he shared on Twitter. So

we reached out over email and we set up a time to talk. And I was kind of thinking, you know, I wasn't expecting very much because he was just a random stranger from the internet. But wow, he was a wealth of knowledge. It seems like he knows more about this space than i do he had notes about alan k and all these same people and more and it was really wonderful talking to him and um to be honest i've only looked through one of the links he sent me so far and that was a link to and and this one link as you'll as you'll hear that kind of changed everything so that was a link to, and this one link, as you'll hear, that kind of changed everything. So this was a very productive phone call, considering that I haven't even looked through a single other link from Andreas yet. So he sent me to the interview on the Y Combinator

podcast with Juan Bennett, who some of you may know of as a creator of the ipfs the interplanetary file system and filecoin which works is built on top of that uh and so what's relevant to this conversation about that isn't anything to do with the block stack which was fascinating and you should go listen to that conversation because oh my god that's really cool there's a lot about the block stack which is bubbly and scammy and weird, especially right now, but Juan Bennett is really cool and has some amazing thoughts here. But what's relevant about that here is more the way he talks about and thinks about solving problems. So three years ago a mutual friend of mine, Juan, sent me, like forwarded me an email of his, basically him rambling his

like master plan. It didn't really even feel like a master plan, it was more just like here are the problems that I see in the world, here is how I want to go about solving them. And I read it at the time. I thought it was like mildly interesting, but I mostly just skimmed it. And then a few months later, I was trying to start this problem that was like a graph of all the knowledge in the world. And I found this project called Athena that he'd started a few years before. And so I reached out and asked him if he would want to talk and help me because I wanted to do a similar project. And so he made time for me and I asked him all these questions and he was very helpful, giving me good advice about Athena. But I didn't really ask any questions about what he was working

on. At the time, he had stopped working on Athena and was working on the interplanetary file system. And I just thought it was wacky and irrelevant to me. So I didn't ask any questions. And then fast flow for three years, I listened to this podcast. And holy crap, this kid has accomplished so much in the past three years. And so much of his dreams have become reality.

And so many things that he didn't even think would be possible two or three years ago when he wrote this have become not only reality, but he's blown past certain goals. Like, for example, in his master plan, he talks about the importance of creating the next Bell Labs to spur on the next wave of innovation and research. And he's still talking about creating the next Bell Labs and how that was his goal and how he's doing it with his Protocol Labs company now. And now, given that he's raised hundreds of millions of dollars for a Filecoin, he has the capital to actually do it and hire a full team of really smart people to innovate and create the next breakthrough innovations for the world. And there's something about the way he analyzes the problems that exist in the world.

And I think he considers problems that most of us don't even consider are problems because we just accept them as reality, the way things are. For example, he says, you know, really, I think one of the biggest problems that we have to solve is the backwards propagation of value problem. And I was like, what is he talking about? And it turns out what he's talking about is like rewarding people for the work they do. That's the problem we want to solve. Because let's say you had a bunch of agents and they all do random stuff and you want to reward the ones that do stuff well so they can do more stuff. And so capitalism is an approximation of the system. But it's a very bad approximation because two things. One, people can amass lots and lots of capital without doing good things for the world um and then two um people can do all sorts of good things for the world and not get any capital backwards propagated towards them and there are all sorts

of other problems but if we just leave it at those two those are some real problems and most people just assume that you know well they're really unsolvable but um he's ambitious enough to like recognize that that's a problem and say even though i don't have a solution here are a few ideas how we might solve the problem um and like he's trying to do it like even in the next few years he's like using the blockchain and and using voting um and using like maybe systems like open collective he he's like tackling big big hairy problems like that and so this kind of like sent me for a loop on Friday. This wasn't this past Friday.

It was the Friday before. Sent me for a total loop. And I realized that I need to be much more articulate about why the problem I want to solve is important. Specifically what I want to achieve. And then also talk about my strategy about how I want to achieve it. Basically, I need to create an Elon Musk style master plan. And I think really, Elon Musk is like the most comparable person I could think of to compare Juan Bennett to, because who else do you know that thinks of massive problems that the world faces, conceives of far-ranging

solutions to these problems that everyone thinks is impossible and not going to happen and like he's out of his mind and then just like a short number of years later like has achieved significant portions of his plan? Like who does that? Elon Musk, I guess maybe Jeff Bezos says it a little bit. I think he might be a little more secretive about his plans. But boy, boy, that's cool and powerful. And I want to rise to that level of awesomeness. So I spent a bunch of time that Saturday, like the next day after last Friday. So not this past Saturday, though before. I spent a bunch of time that Saturday, like the next day after last Friday. So not this past Saturday, though, before. I spent like an hour and a half just like brain dumping my master plan in the slash about page of my website.

So futureofcoding.org slash about is where my master plan currently lives. I don't know if that's the right place for it, but that's where it is now. But one of the biggest things I realized on Saturday is that for whatever reason, I implicitly assumed that things like master planning and strategizing, thinking about how I'm spending my time, if I'm spending it well, I kind of assumed that that would just happen like somewhere. I wasn't allocating time for it specifically. Like I do have time to reflect on what I did the past two weeks. That's the time that I'm using right now to plan and record this very research recap episode. And these episodes are great, and I want to keep doing this.

But I need to allocate more time thinking about what I'm trying to accomplish, articulating what I'm trying to accomplish, strategizing about accomplishing it, getting feedback on my meta plan, on my master plan, getting feedback on how I'm going about things, whether or not my goal is a good goal, things like that. I haven't kind of thought in that strategic way before I was inspired by Juan Bennett, but now I am. So I was planning to continue working on diving deeper into functional reactive programming last week. I did for a day or two, but then I couldn't resist master planning and strategizing and thinking about things strategically.

And so that's what I spent a majority of the rest of last week doing. And I expect that master planning to continue for at least the next few days, maybe even the next week or two, in fits and starts. There are other things I want to do, other activities I want to do, like other things I want to research and think about. But I really want to continue to articulate my master plan and then send it out to a bunch of my friends and mentors for advice to get feedback on how I'm approaching things

and then kind of incorporate that feedback into the plan and then feel confident in attacking the plan for a few months, head down, and then maybe revisit the plan a few months afterwards to see how things are going. So let me walk you through the master plan as it sits right now. So firstly, computing is power for two reasons. And these are distinct. Number one, as software eats the world,

those who can manipulate software basically become magicians. The fact that I can create an app that actually does things in the world is magical. Maybe 30 or 40 years ago, when things weren't in software, when things existed on paper or in people's heads, coding was cool, but it wasn't that cool. And as time goes on, as things become more and more software

based, people who can control software have a lot of power. And secondly, and really close to my heart, learning to code itself teaches you how to better think, how to think more clearly, how to think more precisely in a more organized way. That's a really important thing for me. And that's a big part of why I want to create this tool to teach people how to think. It's kind of like an Easter egg that's kind of, I'm sneaking in there. People are going to use this tool so they can do things with it. But through doing things and learning this tool, they're going to learn how to think better, and it will be magical. The problem is that the current usability of our tools that kids use to program in are very poor. There are a few that aren't. There are a few notable exceptions like Scratch and Woof and other tools that have been designed with usability in mind. But on the whole, the usability of our tools is very, very poor,

and it takes hundreds of hours of grueling practice to learn how to code. It's like everyone I talk to who hears that I teach kids to code asks me to teach them to code. Because it's something that they want to know how to do at some level, or at least they know that they should want to know how to do it, but they also know that it's really hard and takes a long time. But then, even if you spend the time, like I have, if you spend the decades it takes to learn how to code,

it's still really hard. Like it's still harder for me to code than it should be. By like an order of magnitude, it should be like two or three or four or ten times easier than it is for me to code, even after spending thousands of hours programming. Yeah I really think we could do better. I think Brett Victor's talk The Future of Programming does a really great job of kind of explaining how programming used to be in binary and then someone had the idea of going up a

level of abstraction to assembly and then a level of abstraction up to C, and then Python, and then Haskell. We keep jumping level of abstractions with languages, but it feels as if we've kind of stopped, at least to most people. In my world, it feels like if you listen to this podcast, you hear about all the people who are innovating and trying to move to the next level of abstraction. But to most programmers and to most people, it feels like we've stopped, and we aren't innovating, and we aren't trying to move forward. And that's what this podcast is about, moving forward, as you may

remember from the first episode of this podcast. The main thesis is that we could do better. So I started working by myself, but then after a few years of working alone, I decided to start this podcast and to think out loud, like my idol Sam Harris. I don't know if any of you know who Sam Harris is, but I would recommend checking out his podcast. He describes himself as thinking out loud. And so that's what I'm trying to do here. All right, great. So that brings me to my goal. My goal is the same goal as, you know, like Alan Kay and Seymour Papert and Chris Granger at Eve,

make computing accessible to everyone, but also in a way that makes them better thinkers. So there are two parts to this goal. One part is education. So like, even if, even when we have tools that are usable, and kids can use kids and people can use them intuitively to build things, they still need to go through, they still need to learn the tools. And that's non trivial. And that's my first company, the coding space, that's what that company is about. So we have curriculum and a few tools that we built, but we also use Scratch from MIT. And so we have a teaching methodology, we have curriculum. And so we built these things

to teach kids how to think computationally and build things with software. So learning to think computationally is still something that needs to be done. And that's kind of the first thing that I worked on in this space. However, kids are limited by the tools that are usable. So Scratch is usable and Woof is usable, but kids want to build more complicated things. They want to build like complicated apps that talk to different web services. And there are no usable tools, at least that I know of, for kids to do those things. Every time I've tried, kids have gotten really frustrated and stuck trying to do that, trying to do complicated things. Another way to think about this problem is when people ask me how to learn to code, I say, well, you know, I've spent years making what I think is a very intuitive curriculum to learn to code. That's project-based where you can learn while making things.

But the things you have to be making are games and animations that are that you know seem childish like i know you want to make an app to go change the world but first spend like 100 hours building childish games and then you'll have like kind of the the right computational building blocks in your brain to learn more advanced coding so that's what i have to tell people now how wonderful and magical would it be if i could just give them a So that's what I have to tell people now. How wonderful and magical would it be if I could just give them a tool that's as intuitive as Scratch or WoofJS, but as powerful as any other

general purpose programming language like Python or Ruby or JavaScript or React or any of those things. How amazing would that be if people didn't have to learn to code? If they didn't want to build something, they just build it in a tool. This is, I guess, similar to spreadsheets.

If someone wants to analyze some data, sure, they kind of have to learn how to use spreadsheets, but spreadsheets are pretty straightforward. It's like a dozen hours or so, or maybe even less, and all of a sudden you can really analyze some data. You don't need to learn anything more than that. And so that's the world that I'm trying to create here,

really democratize computing and make it accessible to everyone. So to summarize, the goal of this project, the Future of Coding project, is to create a tool with the power of a general-purpose programming language with the usability qualities of a standard end-user application. So general-purpose programming language, that's like Python or Ruby or JavaScript. And with the usability qualities,

that's like the user friendliness of a tool like Facebook or a spreadsheet application. Obviously, Facebook is easier to use than a spreadsheet, but directionally, you understand what I'm getting at. Significantly easier to use than the tools we have now for programming. I think it's also interesting to note what's missing from that goal. The goal is not to create a company.

The goal is not to make money. The goal is to create a tool. And also, the goal is not to just create an interesting podcast where I have a lot of listeners. This podcast is not the goal. This podcast is the means. Another thing you may note is that the goal of this project is for a tool to be created, but I don't necessarily have to create this tool. If one of you who are listening to this podcast are inspired or influenced or informed by what I'm saying, and you go off and create the tool

that changes the world, that solves the problem I'm solving. Sorry, solves the problem I'm describing. That is amazing. And I'd be so happy. And I'd give you a high five, metaphorically maybe, if you're far away. And I have other ambitious problems that I'm trying to solve out there. And I'm just going to move on to the next one.

And that'll be amazing. I'm not trying to like make, get rich here. So like, why should I care if I create this or someone else does um the goal is to create this tool and if no one beats me to it I'm gonna do it and and if someone beats me to it great I I have uh a few other projects like five or six that are that I I will start writing the master plans for those as soon as this problem is solved so so if you can solve this problem more power to you uh then I can go and work on my next exciting projects. So maybe start a podcast for those as well. Alrighty, so then I spend a lot of time in this about page. It's a little disorganized right now.

I spend a lot of time thinking about what I know, what I don't know. I think one of the biggest things that master planning helped me realize is that I'm building know. I think one of the biggest things that master planning helped me realize is that I'm building a tool. And so at the end of the day, we know some of what a tool looks like. A tool is code that is on github.com. It has engaged developer communities, not just me, it's a whole bunch of people. We're talking on issues, we're debating things. Maybe we have a Gitter where like we're talking, we're debating things. Maybe we have a Gitter where we're talking, we're teaching new developers how to use it.

It also has an engaged user community. People using the product, the analytics are looking good. So in a lot of ways, it looks kind of like how the WoofJS project looks right now. Engaged developer community, engaged user community, good growth on both of those. And then at some point, kind of like woof it becomes apparent that i should kind of pass it off to the next person potentially because a lot of the

interesting development that's been done uh or like the truly innovative stuff has been done and at this point it's it's more about maintaining and growing um which maybe i'd be interested in doing for some amount of time. But I think soon after it gets started, I'd want to have someone else take it over. And then I can move on to some of the other big problems that I was just bragging on that I have. These other really ambitious projects that I've been working on or that I've been marinating on in my head that I want to solve as well. Maybe I will talk about some of those ideas in a different podcast, but this one is going to be long enough as it is. So I will spare you those details right now. Okay, so if we know that my goal is to build a prototype,

then the most useful thing I can do is actually building prototypes, but only when the prototype I'm building is a worthwhile thing to build. So at the end of the day, the only thing that will move me closer to my goal is working on a prototype, but figuring out what prototype to work on, what to not work on, what order to do them in, strategizing about how to do the prototypes. It's not very clear how I should be dividing up my time between coding and talking to people and doing research and master planning. You know, there are a lot of different activities I can be doing and when I should do which ones. It's not always obvious. I think I'm starting to get a better intuition for it than I had before. Like for for example, Brett Victor has hours, like hours, like maybe

20 hours of content that I should be reading at some point, but when should I be reading that content? I think before I did this master planning, I thought, I wasn't sure if I should be doing that now or later. And I think now I'm pretty sure that I should stick to prototyping, like thinking more directly about what prototypes I should be working on. And only when I'm really stuck and don't have like a clear prototype idea, and I feel like I need more general knowledge, should I go and do general research, like reading everything Brett Victor has ever written, kind of like how I did the same thing with Alan Kay. So that's where my head's at right now, as far as general research goes. And I'm laser focused on figuring out which prototypes are interesting things for me to work on, and also, more importantly, which problems are interesting for me to solve. And you might find interesting.

So you've heard me talk about stream sheets. Stream sheets was the thing that really inspired me to learn more about reactive programming, CycleJS and Elm over the past few weeks. However, while master planning, I was thinking that, you know, I'm not sure if stream sheets is the right prototype for me to build. There are a lot of unknowns there.

Even the people who work on CycleJS day and night, who are real functional reactive programming experts, even they're not exactly sure. And I'm talking about Andre Stoltz and Nick Johnstone. Even they're not sure how a CycleJS code IDE editor experience would look. And it feels like that problem needs to marinate a little bit more before we know. And so in the meanwhile, I should probably a on a problem with a smaller scope and so that problem is like a functional reactive version of woof or scratch which i may have mentioned on this podcast but i've definitely mentioned in various places on my website to summarize scratch and woof js are micro worlds where kids can build games and animations easily, very intuitively. And they're wonderful libraries. One problem with these libraries is that the code paradigm is very procedural, very sequential.

You describe the steps the computer should take to do certain things, one thing after another. And while this is very intuitive, the downside is that it's very error prone, and it leads to spaghetti code more and more. And it's kind of hard when you have a big project that's written sequentially to know what's affecting what, when bugs happen, and how debugging them is very, very, very hard, things like that. And the reason that functional reactive programming, or functional programming in general, but functional reactive programming is so great, is that it solves that specific problem. Your code is much more understandable, much more maintainable, much more elegant,

much easier to change things. It's better to have your code written in a functional style than it is a procedural or sequential style. However, it is much harder to write code in a declarative functional style than it is a procedural sequential style. So the question is, can we build a library that allows children to make games animations like they could in Scratch and Woof, but in a declarative functional style? But here's the kicker. Can you make it as intuitive or as easy as programming in Scratch or Woof is? And that's an open question. There are a number of people who are doing really interesting research in this exact space.

There is Emmanuel's Bootstrap program. number of people who are doing really interesting research in this exact space there's um uh emmanuel's bootstrap program they have the pirate language p-y-r-e-t the pirate language um that that's like an interesting um language that's in this world um then of course if you remember from last week christopher onand is doing interesting research in this space with a functionally reactive language, Elm, which he created a library for that allows kids to make games and animations in Elm. And even better, he created an iPad app that allows kids to edit their Elm programs. It's a projectional editor, so they can't make syntax errors.

They just click on the text and it allows them to do very simple things. It's not a complete experience. There are very few things you can edit. And that's actually my main complaint with the Elm framework that Professor Almond has. There's like, usually in the games that he has kids edit,

there's like a section of the games that he has kids edit, there's like a section of the code that the kids are allowed to edit so they can change the coefficient of gravity, but they can't really change like the engine of the game. There's like a section of code that's commented off that says like, don't edit anything underneath this comment.

And that's really the interesting part of the code. And so for me, that's like a no-go the kids have to be able to build the games from scratch no pun intended, sorry the kids have to be able to build the games from zero code to as complicated as they want and be able to change any part of it and understand how it works and so my question is can I build a framework

can anyone build a framework that's both declarative and functional and intuitive? And that is a really interesting question. I think that might be the next prototype slash problem that I work on. An open question is whether or not that's going to be a functional version of Woof or a functional version of scratch and so the difference there obviously is that scratch is a graphical user interface tool where you drag and drop blocks and woof is a javascript framework and so it's it's really not obvious which direction i should go because scratch was actually created before woof woof was created as a library that i made

that was inspired by scratch to be like the next step after Scratch for kids. However, if you really think about things, Scratch was created heavily inspired by Logo and by Smalltalk, both of which were textual languages. So the textual languages came first, and then the graphical interface. But there really is no textual language that truly represents how Scratch works, except for Woof, which came after the graphical interface. So from some ways, you could say, you know,

the textual languages already exist to inspire this. They're Elm, they're Pyret, they're Haskell, they're Segal.js. Those languages already exist. The real innovation would be taking this and making a graphical user interface out of this, like Scratch did for Logo and for Smalltalk. But I think you could also say building graphical user interfaces are tricky and slow and hard, so I might be able to iterate faster on my language by building an actual textual language

like wolf.js so so more more of an equivalent so it would probably look very similar to elm or would look very similar to pirate uh and so i think what i would think about is i'd make a few more games in elm uh and see and pirate and talk to Christopher Anand and Emmanuel from Bootstrap and Scott from Ucode, who's also teaching Elm to kids. I talk to those guys and see what their advice is on building this declarative framework for kids to make games and animations. And then at the same time, I'll think about how I would do this in Blockly to come at it from the other perspective to make a declarative framework for Scratch, but with blocks. So that's how I'm thinking about my next few stages, but I'm not jumping to anything yet. I want to really take

my time and articulate what the stream sheets prototype is, what problems it solves, what my thinking is about it all in one consolidated place that I'll continually update. And then I also want to do the same thing for this functional reactive scratch, this functional reactive woof. And then there's this new idea that I've been noodling on, but my conversation, my recent conversation with Andre Staltz really helped bring to the forefront. So one thing Andres explained is that you really want to work on something that has a clear goal, like an interesting problem with a clear goal that's scoped well so you can really finish it

and polish it and get feedback on it and iterate on it. Because when you work on a project that's too ambitious, it's hard to make progress in any direction. And so one subcomponent that will go into almost anything I build is an expression editor. So if you're thinking about it, what is an expression editor?

Think about when you go into Excel or Google Spreadsheets and you type the equal sign, anything you type after that equal sign is an expression. It's usually a mathematical expression, but sometimes they're complicated and they involve VLOOKUPs and other mathematical computations. So to this day, when you want to go type an expression in an expression editor in Excel or Google Spreadsheets, you're typing characters. And sure, there's autocomplete

and they help you a little bit, but you really can make an infinite amount of syntax errors. It's really hard to not shoot yourself in the foot there. I constantly am having trouble with that. There has been work here to make improvements. I think the apparatus editor, aprt.us, the editor there, is pretty neat. It's usable, but still you can make syntax errors. I think Glenn, I don't know how to pronounce his last name, but glen, G-L-E-N-C-H dot com. He is doing some really interesting work here. I actually just met him for the first time last week. I'm going to meet him again later today. So more on this front. He created a thing called

Legible Mathematics. You can read up his post. And it's very much in this vein. It's trying to create a better expression editor. And he has some really, really interesting prototypes. So potentially I would continue down this line because what's great about this expression editor project is that it's well-scoped. It's very straightforward. And anything I build would want this. And not only anything I build, but a lot of things other people will build would want this. And not only anything I build,

but a lot of things other people will build would want a tool like this. I think this is kind of similar to CodeMirror. There are many places on the internet that want code-enabled text editing with all sorts of add-ons and extensions and customizations. And it's amazing that CodeMirror exists and the Ace Editor exists.

Otherwise, Woof wouldn't really exist. Or at least the editor would be much sadder than it is today. The editor in Woof right now is so souped up. We basically have every single add-on that exists turned on or has been used in some version of Woof. Syntax highlighting everything. We use CodeMirror to the max. It's crazy. And the fact that IMirror to the max. It's crazy.

And the fact that I don't have to create that, I can just use it, and everyone on the web can just use that, oh, it's so great. And so this expression editor, it might already exist, so I should definitely do my research, but this expression editor

could be a really wonderful subcomponent to spend some time working on, and then I'll be able to use that in other projects. The only reason why I wouldn't work on this first is because it's not an interesting problem like at the end of the day you can just type out your expression you could do the equal sign and you can just write the expression uh right there uh we still do it for google spreadsheets we do it for excel and excel is usable like like you know nobody has fun doing that but it's usable uh people people do it um so the only reason i think i would i would do it is if i'm really stuck and don't have a prototype to work

on or the main reason i would do it is if i think for some reason that this is the limiting factor like if kids had this expression editor and it and it like showed them what things were possible uh it would really make functional reactive programming more intuitive and easy showed them what things were possible, it would really make functional reactive programming more intuitive and easy for them. So I would do it there. I guess, relatedly, thinking about how customizable and how big this expression editor is, is relevant. For example, I love Google Blockly, and it's great,

but it's limited in a lot of ways. And it's very sequential in the way things look, and it's great, but it's limited in a lot of ways. And it's very sequential in the way things look, and it's limited. It's great, and it has problems. You know, I have a love-hate relationship with Google Blockly. I've spent maybe like dozens of hours with it so far. I started to really understand its internals, or well, superficially understand its internals. And it gives me a lot of things for free, but there are problems with it. So maybe this expression editor would be the beginning

of a my own custom block library. So maybe I start with an expression editor. And then I say, you know what, I know how to make I can turn this expression editor into a block-based editor for Elm. And you know, I can turn this block-based editor for Elm into a generic block-based library that people can use to make block-based languages. Like if I could do that, if I could create a library for block-based languages, that's kind of like Blockly, but more customizable.

So that, so, cause Blockly is really just Scratch. Like you can build block-based languages that are procedural like Scratch is. It's very, very heavily inspired by Scratch, which is amazing, but it limits the level of innovation that people could have. So to make a more generic version of Blockly,

ooh, that would really spur on the innovation in this world. So I kind of talked myself into this project. But yet, I don't want to jump into it yet. I want to keep developing these ideas, keep thinking things through, put all these ideas on paper, talk about them more with other people, get feedback,

and really marinate in the problem, in the problems, as Andres Staltz said in our phone call this morning, marinate in the problem, marinate in the possible solutions, don't go to code quickly, really explore the problem space, get the shape of the problem,

get to know it, get to meet it, get to talk to its parents, live with it for a little while, and then and only then when the solution is so apparent, because you know the problem so well, you know a series of solutions, you know why other solutions have failed, and only then do you

start working on different problems. This is not to say that I don't think too abstractly. Part of how you get to know a problem is by proposing solutions and critiquing those solutions. But I want to make sure that by proposing solutions and critiquing solutions and even creating some little code prototypes, I'm not jumping headfirst. I can always zoom back out, look at the other solutions, look at the other problems, see where I am, be very deliberate and thoughtful about things. So that's what master planning sounds like in its raw and unedited form. So inspired by all of this master planning, I've been doing a better job of organizing my thoughts around the specific problems and solutions and ideas that I've been

thinking about and talking about with various people. And what I've come to realize through doing this is that in the past, while I was collecting a lot of good content, it wasn't well organized and I was inhibiting the thinking I was able to do around certain things, and it was also inhibiting me being able to share my ideas with other people. I was kind of assuming that I would organize things at some later date, but that's a lot of work. It'd be better if I just had a better structure. So part of what got me thinking in this way is I had a really great future programming meeting last Monday with a bunch of people who came, with new people, with old people. It was really great.

And we talked a lot about structured programming editors. So they use the word structured editors. I have often used the word projectional editor because the first future programming meeting I went to someone used the word projectional editor but the structured editor, projectional editor, editing code via the AST as opposed to editing character by character, other words I other noises I make when I talk about projectional editors are prune and lambdo and luna all those things are protectors so or structured editors and so we were thinking and talking about structural editors and I got an email from someone who wanted me to review their

structured editor. And I just figured, you know what, it's time to write up my thoughts about structured editors. And so I did. And I talked about how a lot of people are frustrated with structural editors. And so I have this George Carlin quote I begin it with, which is, inside every cynical person, there is a disappointed idealist. And I think that quote is really relevant to this discussion because of all the pessimism around structured editors. So if you listen to my conversation with Lloyd Tabb, you'll remember that

part of the reason he's so negative on structural editors is because he tried to build something like one in the 80s. He spent like years of his life on it and failed and text won. And it was just like, I think it was really disheartening for him, which for me was shocking because for like a long time, he and I had gone back and forth on the pros and cons about these things, but I never thought to ask about why he was so negative on them. And we really got to it in that interview. And I think that that's a common thing. If you talk to people about structured editors,

oftentimes they'll be really, really negative on them. But if you dig deeper, you'll see that it was because at one point they were super optimistic about them, and they spent a lot of time trying to make them work, and then they failed. However, despite all that, I think I'm still optimistic about them, and I think there's a lot of promising work here. Luna, Lamdu, Isomorph, etc. And I reviewed Nico Ad Audio's micro editor. He's the one who emailed me and kind of inspired me to write this write-up up,

and I reviewed his thing. He has some really clever and interesting ideas here, and I'm excited to continue to talk with him and follow his progress. I also reviewed Bill Vannon's foolproof HTML. He actually tweeted about the fact that I wrote about it, which was super exciting for me. I really love Foolproof HTML. It's in a similar vein to Legible Mathematics by Glenn, which I spoke about earlier in this podcast.

Potentially, I might do something in that vein at some point because it has to do with the expression editor idea that I was just talking about. Then I went on, I started a list for structured editors on a GitHub issue, and Yair, I hope that's how I pronounce his name, from Lambdew saw that GitHub issue and commented that he already started a list of editors on Reddit. And his list is way, way better than mine. So I should probably just close my issue and just link to his because his is great. And then at the end of this discussion, I decided that, or like I kind of explained why I'm thinking that it's not the highest priority thing that I could be working on right now.

I use the argument that I've referenced before that Paul Chisano of Unison came up with. It's basically, would you rather a brain-to-text interface to x86 assembly or a Vim editor interface to Haskell? And most people would choose Haskell because that's the real leverage here, the better abstractions. And so a structured editor is basically that. It's a better interface

to the languages that already exist today, but it's not that much better. It's really the same level of abstraction. It just precludes you from making syntax errors, but then all the other errors that you can make are still there. So for someone like me, programming in JavaScript, I don't make syntax errors anymore. I've spent my thousand hours. It doesn't happen, or it doesn't happen often, and I can solve them easily. At this point, I have a parser in my brain.

I understand how to parse JavaScript, but I still have all sorts of problems making websites with JavaScript. So even if someone builds the best structured editor for JavaScript, it doesn't come close to solving these problems. We have to think bigger than just structured editors. I will caveat that with if someone builds like the right structured editor library language combo, it could allow us to, it could be the building block to more innovation. I think like Luna and Lamdu and Isomorph, they all are custom languages that are built specifically for structured editors. And those are some really exciting projects. But as far as I've seen, though, all those projects look basically like Haskell. And while

Haskell is great, I still, I've spent hundreds of hours in Haskell, maybe even, yeah, not a thousand, but hundreds of hours in Haskell for sure over the last decade. And I still have so much trouble building things in Haskell. So, so like my reluctance to keep working on these things is that I can kind of see the future, like even if they were done today, it still wouldn't solve the problems that we have. And then I also went ahead and wrote a similar kind of like, here are all my thoughts about this topic, write up for stream sheets, my prototype idea, how I came up with the idea,

what my goal is, how Alan Kay inspired it, how it's similar to Alan Kay's ideas, what FRP is. And that's about all I got into that idea. And that took like hours just to get all that out. It's pretty long. It's like 2,400 words at this point. And it's like not even a quarter of the way done. And so you can check that out on the website. That's too much to go through here right now. But writing this whole write-up about structured editors and about stream sheets, the word just flew out of me. And part of the reason is I've been thinking about these ideas and writing about them in various places in my journal. But my journal is a time series store of information.

It's organized around time and when I think the ideas, not around the ideas themselves. And I'm realizing now how crazy that is. It is really cool to kind of see my journey and how I come up with ideas that it's amazing but that's not the point of this project the point of this project isn't to watch me come up with ideas it's for me to produce a tool and so I need to structure my ideas my thinking around the ideas but around the content not around when I think of them. And so that was kind of a big breakthrough for me. And I had to ring the death knell for my journal. I really love my journal. As you can tell, I love thinking out loud. I like thinking as I type. I'm going to keep doing that,

but I'm not going to do it in my journal because I don't want that to be where my thoughts are thought in this time series way so I'm going to push all the content that would go in my journal like thinking about the problems thinking about the solutions think about what I'm going to work on well everything but what I'm working on now all the ideas that I'm producing those will go into appropriate folders and files about those ideas but okay but what about the the like more day-to-day thinking about what am I going to work on? What am I thinking? Okay, so what I come up with for that, preliminarily, it's been working okay so far. What I've come up with so far is that that's what the commit log in Git is. The commit log in Git, when I make a change to various files and I commit them,

I could just leave a simple message, I added a file or whatever. But if I have more information about what I'm thinking, what I'm nervous about, just thinking through writing like I do, if I have that kind of energy and thoughts, I'll put them in a really long commit message. And I was able to hook up my preferred editor to the commit log thing so now whenever i commit things it goes to um it goes to my my preferred editor and i can i can kind of write out the whole thoughts like i normally would and i write them in markdown so there's nowhere yet that automatically turns a commit log and renders it to markdown but i'm gonna have to build that and that's going to be part of But I'm going to have to build that.

And that's going to be part of the website. So in the future, if you go to futureofcoding.org slash log, you'll have every commit message and link to the specific files that were changed. And then if I provide a longer message, it'll render it in markdown. So that's a new thing. And then if I want to just think about what i'm working on without adding to any specific file just make a journal entry about what's going on i can um commit to git without changing any files that's a thing git allows you to do i could always just add an add a new line to a file or something if i wanted to but i think they allow you to to push empty commit messages as well so this got me thinking about a real problem i have which is if i want to let's say

delete the journal on my website right now because i do want to fully depreciate it because it's i'm not going to put content there what happens to the hundreds of links i've made to various anchor tags within my journal like i don't want to break all those links that would be crazy and and i really face this problem firsthand because i go i go back and read alan k and brett victor's journals and and and um and also i'm forgetting other people's journals from from decades ago and many of their links are broken and it's really sad and it's hard for me to do research so i would really hate for that to happen and that's just that's just unacceptable so one way to solve this problem

uh the obvious way is every time i want to change a file like journal for example i could leave the old version there and just put a big header at the top saying this has been depreciated blah blah blah blah um which is fine it's just a little bit annoying because i want to move files around all the time and it's just like an extra tax on my thinking because I can't just move things where they need to go. I have to think about the migration plan constantly. So referencing Juan Bennett again, the way he described the interplanetary file system was that everything is referenced.

So when he was describing it, he explained how the web right now works by referencing things by their location. He thinks you should reference things by a hash of their content. And so it got me thinking about identity. How do you refer to something? I think there are roughly three ways. You can refer to the content. So if I were to refer to myself, that'd be the specific atoms and where they are in my body right now. Another way to refer to me is by my name. My name is Steve Krause, Steve Miller Krause, you know, or my name is Steve, you know. So names are complicated in and of themselves,

and some people have the same name as other people. So names are complicated, but are also used colloquially, and they have their uses. Another use, another way we identify people is by location. You can list your home address, where to find you. And so the web currently uses location, and that's fine for certain purposes, but it doesn't work very well when you want to move. Like, for example, if you move somewhere else, and all your mail is still sent to your old house,

and you have to send a forwarding address, it's just annoying and complicated. It'd be neat if that problem was solved. And so I was noodling on this and it struck me that Git already has hashes. Every version of every file that I've ever created in my repository is saved on GitHub somewhere. That's how Git works. So in theory, this should be possible. Shouldn't I be able to link to content and have it never go away? So what I came up with is if you link to something by a hash, it's the current content, that's

great but what happens if that content is updated and you want to notify the person that, hey, you know, you're viewing an older version of this document, click here to view the updated version. So I thought about it and I said, you know what, that's fine. I think if I link or someone else links to my website, they're linking to the content at that point in time. Chances are that's what they're linking to. And chances are the content hasn't changed.

So we should show them the version of the content that was linked to when it was linked to, when the link was made, not whatever happens to be there right now. But also notify the user that, you know, there's an updated version of this page. And also, let's say the page was deleted. We can show them the version that was linked to, and let's say, you know what?

Just so you know, this page has been deleted, but you're viewing the historical archived version. So that's all fine. But what I have to do now is whenever someone comes to my website, if there's no commit hash already in the URL, I have to go ahead and pull from Git the current commit hash and put that in the URL bar. So if they go ahead and copy that link and paste it anywhere else, that commit hash will just be there automatically.

Implicitly, they don't even have to think about it. It's just stored in the query params of the URL. And yeah, that's basically how the system works. I decided that this could be its own project that other people might find valuable. Right now I'm calling it Unbreakable Links. basically how the system works um i just i i decided that this could be its own project that other people might find valuable uh right now i'm calling it unbreakable links very very clever name i know and you can check it out github.com stevecraft unbreakable links i've just started the project i kind of listed it out all things that need to happen in order for it to be done

and i don't want to spend too much time on it although i really want to because it sounds like a fun project but i'm resisting and i just built built out the basic structure of it it doesn't work it barely has any content you'll see if you go on there right now but if you happen to have some free time and want to help out you know go help out it's in a it's in a good place for someone else to to work on it. So I would appreciate the help. And if not, I'll get to it myself shortly. Because as I now reorganize my thinking around ideas as opposed to time, I'm going to need this system so I can move quickly and change things. Move fast and break things, as they say at the good old Faké book. All right. Okay, a few

more things. I had an amazing call with André Staltz this morning. We talked for 90 minutes, and it was luxurious and amazing. I love that guy. And it was really fun to get to have so much time to talk with him. And I engaged him in a high-level conversation about my master plan, my strategizing, what I should be thinking about. We talked a little bit about CycleJS specifically. He helped me get things up and running on Cloud9. And it was very simple. We just cloned the repo and started things running. So the technical conversation was kept to a minimum. It was mostly high-level strategizing,

how to solve problems, how mathematicians think about problems. The word he used was really stay with the problem. And the word that stuck in my brain, I don't know if he used it, was marinate, marinate in the problem, really explore the problem. So that was really useful for me to hear about.

He also had a chance to tell me about his Scuttlebutt project, which is really exciting. It's kind of silly, but I draw a parallel between Juan Bennett and Andre Stalt in that they're both brilliant people whose side projects

I've been really, really interested in and whose main project I haven't been that interested in. And so the last time this happened to me i didn't pay attention to the main project of this genius person that i was talking to so i didn't make that mistake this time so i so we talked about scuttlebutt and it's really cool it's basically a facebook competitor built on the decentralized web and yeah it's far-reaching implications and it's exciting it's like a really cool project and it and it has like a small devoted implications and it's exciting it's like a really cool project and it

and it has like a small devoted community andre's working on it for free so i would bet on andre and i'd bet on scuttlebutt so if you if you haven't heard about that you could check it out um some other interesting notes i all the notes about andre are on the website but some uh he he had he encouraged me to think about designing a programming language for the future given that this is a 10-year project i'm designing for the future why not think about what technologies that don't exist today might exist in the future for example machine learning and ai uh and and we talked about that a little bit um i don't think i'm gonna i don't think i'm gonna go and learn about AI too much, more than I already know right now, but he was pushing me in the right direction.

And as I mentioned earlier in this podcast, he really pushed me to think about building a subcomponent for this project, like an expression editor, something like that. And so I really want to think more clearly and more thoroughly about expression editors. And I'm sure I will get some feedback on that idea in just like an hour when I talk to Glenn about his legible mathematics project. Okay, so my plan for the next two weeks is mostly, like the number one one priority is to continue master planning writing and strategizing getting feedback while writing and strategizing from my friends and mentors number two i'm going to start writing more explicitly about the problems that i'm thinking

about i think uh this is directly because of andre's advice so as opposed to just writing about the solutions like stream sheets or reactive woof or reactive scratch, I'm going to think about the problem. So there's the view update problem that I identify in stream sheets. So I should just talk about that problem outside of the context of stream sheets. It's its own problem.

And the problem of iterating on graphical languages is hard it's graphical languages are harder to iterate on than text is so like that's its own problem that's kind of a meta problem really that would kind of speed up the whole space like blockly did um error messages error messages are really hard and tricky and if you compile to a language that has error messages like how do you handle those messages for example like when i program in javascript i don't get like messages from like an assembly i just get javascript error messages so how do you if you're going to compile to another language or interpret if you're going to build an interpreter how do you handle all of the error

messages of like the the language one level of abstraction below you and then another problem that i mentioned in stream sheets is that when you're trying to understand a project uh piecing it together from looking through the files and folders on github is so terrible and so uh cycle js and the data flow diagram stuff really solves this problem well but anyways write about my problems and really marinate on the problems that's a really important thing to do and then i also want to really think about my solutions and really articulate them each one will have its own page on the website um or if i don't make that page then have pages on the website because i'm having to finish unbreakable links yet i will uh create github issues for them and collect all my thoughts about them on the GitHub issues.

So these ideas are stream sheets and functional reactive woof. I've already started GitHub issues for those, but I need to start GitHub issues for functional reactive scratch and for building Elm with a Blockly interface and building a Cycle Blockly interface and building an expression editor. And then my lowest priority thing, but probably the most urgent thing I have to do is build unbreakable links so that I can

go ahead and move things on the website without worry about links breaking. So yeah, that was a lot. I apologize for how fast I spoke this episode. I had a lot to get out. I had a lot of energy and I didn't have a lot of time. So I said it as fast as I could. I once read that mumbling is actually not a bad thing. It's a way that humans compress speech to speed things up. I read this in high school when my parents were complaining that I was mumbling too much. And so I apologize to you if I mumbled too much. But on the bright side, it did compress my speech and made things a little bit faster for me on the recording side. So that is that. I will talk to you all next week with an interview and the week after that with another recap. Bye.