Future of Coding - Research Recap Five

Episode Date: September 11, 2017

The last two-week-research-cycle was my most productive yet! In this recap, I debreif my Alan Kay deep dive, discuss tweaking my schedule after reading Peak, review conversations with Jaime Brandon and Dan Scanlon, read aloud my thoughts on proper computer use patterns and my prototype idea LogicHub, recap my early morning meeting with CycleJS creator Andre Staltz, and discuss the next steps for my StreamSheets prototype (which is why I'm putting my Bret Victor deep dive on pause). If you were able to follow all that, my hat is off to you. I barely made it through the recording and episode of this episode alive. If you need help pieceing this episode together, you can find the notes on my website: /futureofcoding.org/episodes/9-research-recap-five.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 first and foremost, I have to apologize for the lack of episode last week. This is the first week I've missed an episode. I had it kind of ready to go, but I was checking with my guest to make sure that I could release it before I did, and so if that's why it's late, I'm going to work on making sure that doesn't happen in the future. But I should hear back from them soon, and so I should be able to release that episode this week or next week, as well as the episode that was normally scheduled for next week.

So you should get all the episodes you were promised just a little bit later than expecting. And you'll notice that things are out of order because this episode is the ninth episode and the last episode, the eighth episode, was also a research recap. So I have two research recaps in a row because my schedule was a little messed up. So again, apologies. And we should be back to normal starting after these next two interviews in a row. So I went ahead and published this podcast and website broadly two weeks ago on that Monday, and that was fun. I didn't get that much traction but I did get some which was neat. Let's give you some summary. The number of subscribers, people subscribe to the podcast on like iTunes or whatever, grew from 50 right after I launched it to 130. So I don't know how accurate that number is,

but that seems ridiculously high. In total, I've had 156 different people listening to the podcast, and 403 episodes have been downloaded. And then the website analytics, I think the most interesting number is that I have 245 monthly active users, 35 weekly active users, and six daily active users. This is very exciting to me that I have even a single person, let alone five, people other than me that come to my website every day. So I think that means that, well, what I hope that means is that they're like using it to help inspire their own research or something like that, these other five people. So

that's pretty cool. So before I go deep into what's kept me busy these past two weeks, I'm going to preface this with, I did a lot the last two weeks. I spent much more than the allotted 15 or 20 hours doing research. I kind of overshot things, and I spent a lot of time, maybe like 30 hours a week, or even 40,

doing research each week over the past two weeks. So this episode is going to be longer and more filled, I think, than the other research recaps, except maybe for the first one where I recapped a year of work. So this episode may seem kind of scattered and hard to follow. I apologize in advance. You can go to my website and view the page for this episode or the page for me thinking through how to structure this episode in my journal to kind of see how I outline it and more details about each topic that I only touch on in this episode. So hopefully that helps you get through this episode if you really want to understand where my brain's at.

Without further ado, let me tell you about what's been going on this week. So, towards the end of the prior two-week cycle, I did a deep dive into this guy, Jamie Brandon, who used to work at Eve, now does his own thing with other people, but kind of on his own. And his journal, his development journal for one of his projects, Imp, was what inspired my own journal and other parts of this project. So I owe a lot to him and I was really excited to get to read everything he's ever written. And I did, and that was great. One of the things he recommended is this book called Peak, which is about basically Malcolm Gladwell's 10,000-hour rule.

So the researchers who developed the research that Malcolm Gladwell misinterpreted and misexplained, so he wrote his own book. It's called Peak, and it talks about how to get better at anything through deliberate practice. And it was very inspiring and empowering for me to read this book. Because I wanted to believe these things anyways, that anyone could get as good as anyone else at anything. But I didn't really have the data. I didn't have like a scientist behind me. But now I do. And I was really excited about that book.

It had two impacts on this project. The first one is it inspired me to get a teacher, like a mentor of some sort who I could check in with on a regular basis and they'd give me sort of meta-feedback about how to structure my research and things I should be thinking about. So, you know, it would be a dream if someone like Alan Kay or Brett Victor would want to take on that role. You know, I guess I'd have to structure it in a way that it wouldn't be too much of an imposition. You know, but I don't need, you know,

maybe I could find someone else who's less busy who'd want to do that for me. So that's something that I'm on the lookout for. And then the second thing that this book inspired is a more of a debugging mindset about everything in my life, including this research project. So the things that aren't related to this research project, I set up a separate page on my website, stevecraft.com slash debugging for me to like help debug all the things in my life I'm trying to get better at, like eating healthy or stuff like that. But then more relevant to this podcast, I have spent a lot of time thinking

about my schedule and the way I'm doing research. And as I've said before, I didn't like how I was going to bed whenever I wanted, waking up whenever I wanted, doing research whenever I wanted. I generally structured into days. So I had like Monday, Wednesday, and Friday were generally research days. And I did research the whole day. And then Tuesday and Thursday were meeting and email days. It was working okay. But I was finding that it was hard to really stick to Monday, Wednesday, like on Mondays, Wednesdays and Fridays, I would like kind of not actually stick to research that day.

Because other random things would pop up and I would just do those things instead. So I was I had problems, I was thinking about things. And so eventually, I decided to like meditate on it a little bit more in my journal. And I came to this new idea where I would wake up every morning at 7 o'clock and then from 7.30 to 10.30 a.m. every morning Monday through Friday I would do my research. In order to do this I'd have to go to bed at 11 o'clock every night and I would drink coffee every morning to wake up. So I tried this experiment out for one week last week, Monday through Friday, and it worked.

I actually stuck to it, which I'm a little surprised, but also very proud of. And I really liked it. I like the feeling of it's 10 o'clock, it's 10.30, and now I have the whole day. I accomplished the thing I set out to accomplish. And I don't check my email before then. I don't get distracted. I do my research and then I move on and and you know it sounds rigid but I found that it's pretty flexible because if I need to skip a morning or I don't have enough time to do a full three hours on a given morning I can just decrease the amount of time one morning and increase it the appropriate amount another morning so the amount of time stays constant as

long as I I move it around in in way. One thing that I know I need to think about still is taking a week off, for example, or more than a week off, because I think I might want to. It feels a little bit like there's too much momentum here, which is a good thing. It's the opposite problem I had before where I didn't have enough momentum. But I'm sure I could just decide on taking a week or two off and put it in my journal, put it on this podcast, and no one's going to call me out for it except for me. I'll just have to decide when that is. Another thing I want to do is think more precisely about my time because I'm kind of ballparking it oh 15 hours here five hours there and things take more time than I'm I'm giving them credit for and so I'm ending up spending a lot more

time doing things than I'm allotting which isn't bad you know I want to be spending time on this project but it's just not realistic and so I think I'm doing more work than I want to be doing or at the very least I should have a more accurate view of how things are so I should I'm doing more work than I want to be doing. Or at the very least, I should have a more accurate view of how things are. So I want to do that soon. So I had two fun calls this week. The first one was with Jamie Brandon, which was really fun, because he's such an inspiration for me. So we talked a lot about the things he's working on, which I don't

want to go into too much here but I have some notes about that that I hope he'll let me share and then right after that call I had a call with Dan Scanlon who I met to my co-founder and and he's we kept in touch a little bit and he's, we've kept in touch a little bit, and he's been working on future programming things as well. What was really exciting to hear about from him was that he listened to a few of these episodes when he was on a long drive. I've listened to most of the episodes now. I was driving for like four and a half hours yesterday. Neat. I was driving for like four and a half hours yesterday. So I went through, yeah, like Kevin said, two through I think four or five and then I just listened to most of the most recent ones as well.

Awesome. Wow. Thank you. That means a lot. I don't have, as you can imagine. Yeah. I wanted to get caught up on like where you're, like what the speed of your research is and what lens you're viewing this world through. Yeah.

I guess that, in theory, will speed up this conversation a great deal. That's awesome. Yeah. That means a lot to me. I don't have too many listeners at the moment, so that's a big deal to me. Thank you. I mean, it's just the beginning, and I do think that what you're doing,

if everyone else who was thinking about the kinds of problems that you're thinking about would contribute it publicly in an open manner, I think things could progress a lot more quickly and there could be a lot more borrowing of ideas. Good idea. While we were talking, he helped me articulate the state of my current research, particularly as it pertains to stream sheets and what I did over the last two weeks.

Let me play that clip. Yeah. So I don't know how much you heard me blather on about a prototype idea I have that I'm calling Stream Sheets. Yeah, I've heard at least like 20 minutes worth of that, I think, over the few episodes. Great, okay. Very interesting. Sweet, thanks. So I spent a few hours on Monday of this past, not yesterday, but the one before, trying to prototype it.

And pretty soon into it, I realized that it's very, very similar to Cycle.js, which it was inspired by. Yeah. And so are you familiar with Cycle.js at all? Yes. Cool. Andre Stoltz. Yes. Yeah, I'm so obsessed with that guy.

So anyways, I realized that it basically is Cycle.js. And I was thinking about ways to make the prototype more and more, make it smaller and smaller and smaller and smaller. And eventually I realized that the way to prototype something like this is to do it in text. And so I started putting various parts of the prototype into text as opposed to a UI. And I was like, wait, what would it look like if the entire user interface to this prototype was text?

Oh wait, that exists, it's called CycleJS. Great, okay. So knowing that was a big insight, and so now I'm thinking that my actual compile target for this prototype is CycleJS code. And it's two way. I can import CycleJS to this thing. I can export any code from here to CycleJS code. And so I like, anyways, I have a lot of thoughts in that direction. And so on the, yeah?

What limit are you trying to push with that prototype? Like what do you feel like is like the imposition or the shortcoming of traditional environments or whatever environment? Got it. What's the problem I'm trying to solve? Yeah. Yeah. Okay, great. So I have a lot of answers to that question.

The first thing to mention is that the way I came to this prototype is specifically trying to think about a problem first and then a solution. Because often... Anyway, I was watching an Alan Kay video that talked about how people often focus on existing solutions and how to improve on them and how that only leads to incremental progress. And so I was like, okay, stop thinking about that. Think about like pie in the sky. If you could design things from the ground up,

what would you want? And so what I wanted is to make it, like the metaphor that stuck in my brain is, like wouldn't it be neat if any app you were using, anywhere, your phone, the computer, anywhere, you could, there was just like a corner at the top right that was like a peel back type of thing. And you just pull on that corner and then just see the code, like, quote, one layer of abstraction down below. And kind of see how it works.

Tweak with things. Put the first layer back on. See how those changed. And continually pull back layers one at a time and kind of change things. You can pull back the layer of just one component. You can pull back the layer of just one component, you can pull back the layer of the entire screen. What I want and the problem I want to solve is that people who use applications to be

able to modify those applications without leaving, going to another website like GitHub, installing a bunch of software, spending hours and hours hunting through files and folders, all that to me is garbage. The problem I want to solve was I want to increase the surface area of the intersection of the people who use an app who can also modify that app. Got it. So that was my problem that I was trying to solve.

Okay, so how do you translate from the top level of that editing interface, the spreadsheet, into the user interface? Yeah, okay, great question. So all of these questions and problems are very speculative. But where I ended up is, why not just make everything a spreadsheet and so at the top level it could be anything like so everything is just a stream and streams are just observable values so anything any value that changes over time is a stream and so if and just like what you're saying like if

like the inputs are abstract data types and the outputs are abstract data types like it's extensible. Andre Staltz says the same thing about streams. If the inputs are streams and the outputs are streams, it's just anything. So the bottom-most layer in my head is the event stream of everything that's ever happened that your system is aware of. But basically, any event stream can be the input.

And then the output of the system, if what you want is HTML, then the output is just a stream of HTML. And the reason I like spreadsheets as a way to visualize things is streams are like, they are just values that change over time. But what I like about spreadsheets is that you could see the past values, they're just higher rows

in the spreadsheet. But then most things that we wanna talk about are objects, and objects are really just rows. So you could just have a column that's like, so you could just have a row of like, so each HTML element is a row, and it has children rows. Like, I don't know, maybe visually describing HTML in a spreadsheet table will be super unwieldy

and hard to build, like I don't know. That's not the core assumption that I'm trying to test right now. So like one of the first things I decided to do was to like put all of the other spreadsheets in scope for a like React JSX style function that returns HTML. So basically I wanna like, the core thing I'm trying to figure out

is whether or not the spreadsheet metaphor is an intuitive way to do stream programming. That's the core assumption I want to test now. And then later down the line I'll test whether editing HTML in a tabular format is neat or not. I don't know. Because at the end of the day, something more WYSIWYG would be better anyways. So that's not the core assumption. The core thing I'm trying to test, the sub-problem of sub-problem of sub-problem

that I'm working on right now is I see CycleJS as a really neat way. CycleJS has a lot of neat implications if you write your application in it. However, in practice, I found it incredibly difficult to write applications in Cycle.js. Right. And so what I'm trying to test is... Due to some breakdown around stream programming.

So, yeah, so one way to put it is, so even once I wrapped my head around how streams work, which took a handful of hours, which for someone like me who has a lot of mental representations and is able to assimilate new models quickly, that says a lot, that it took me a number of hours to wrap my head around it. That means it'll take months for someone who's new to programming, I think, or weeks, whatever. That's the first roadblock. But then even once I wrapped my head around the mental model

and I had the list of CycleJS primitives pulled up on my screen and I was like, okay, I want this thing to happen. Which one of these primitives is what I want? And it took me a while to figure out the right one. And then even once I had the right one, like getting the syntax to work and imagining in my head what the new stream looked like and debugging whether or not it did what I wanted, it was just all it was just very very very slow going so um

the thought is that so um another thing to mention is that cycle.js has this really great visual tool called in the cycle.js dev tools where once you've already written a cycle.js application it'll visualize it as a data stream and it's beautiful i like visualize it your entire application as a graph from top to bottom and that's that's the reason you use cycle js because when you when you structure your data in the stream way um you can it's just beautiful like like this is the reason to use cycle jazz because it organizes your code in a logical way. But that's only after you've written code. That helps you understand code and debug code, but that doesn't help you write it in the first place.

And so what I'm excited about now is creating a user interface for Cycle.js that's better than, like, typing out the commands. And I found, and Andre Staltz has, like,ed that this is something he'd be interested in working on. So I sent him an email. We're talking. He said he's really busy over the next few weeks for different conferences he's speaking at. But on Friday, we decided, I'm going to reach out to him again on Friday. And hopefully, he'll give me some much-needed feedback on this idea. So that's where I'm at there. But before I move on and tell you what I've been working on in the meanwhile,

because I've been waiting for Andre, I want to pause for questions or comments. So I invited him as well as Jamie to the New York City Future of Coding meetup group and Slack. And then one last thing, I'm going to send you, there's a meetup group that I'm organizing in New York for future programming people. So I will get you on the Slack group and invite you to all those events because you're moving to Brooklyn. Yeah, yeah, that would be awesome. Have you had any yet?

Yeah, we've had like three or so meetings so far. We had one yesterday. Nice. That's awesome. How many people come out so far? I think the first one was like three or four people. The second one was like 10 or four people. The second one was like 10 or 11.

The third one was even more. And then this last one, we made a mistake and did it on Labor Day and it was just me and one other guy. So, yeah. But anyways,

I'm excited to have you at one of those soon. Awesome, yeah. I'd be happy to be there. So we'd love to have more members. so if you're interested in joining, please reach out, let me know, and I'll add you right away. So really with the Alan Kay Deep Dive, the more I progressed, the more silly I felt about not having done this sooner. So much of my research has been inspired by Alan Kay

that to just read a few of his things, watch a few of his videos, and feel like I got a sense for it was just silly because there was so much gold there. There's so much that I could see where I was retracing his steps when I could have just been

learning from his mistakes and moving forward. So that's like the general theme of the past two weeks. I was just in heaven, just reading all these amazing papers and being inspired by all of his amazing ideas. One of the things that I helped, that it helped me see was how the like genealogy of ideas is laid out. I kind of thought that it went from... Someone once explained to me that Scratch was a baby of Seymour Papert and Alan Kay. And that made sense to me at the time.

That still kind of makes sense. But now I see that it's more of a linear progression from Piaget to Papert to Kay to Resnick to Victor. It kind of goes more in a line. At least that's how I see the line. I'm sure there are people in between there that I'm missing. And it's not really a line. It's much more messy than that.

But at least the people who get credit for these ideas in my mind, the people who are stand-ins for the web, that's kind of how I think about it. Another thing I was really struck by in his genealogy of ideas is how many of his ideas and Seymour Papert's and Brad Victor's ideas were influenced by Montessori, Marshall McLuhan, and Neil Postman, people that I also am really excited by. I didn't quite realize that Alan Kay was into those people, which now seems silly, because of course he is. I also didn't realize how much Alan Kay was influenced by Seymour Papert, particularly create things for children I didn't realize that small talk was meant to be a language for children and then only Ended up being a language for adults because you know he couldn't make it better like you know The goal was for it to be

For kids and then it it was good enough for adults and they just ran with it I think Dan Inglis just ran with it and Alan Kay, I think it was a little shame ashamed of it and um a a clip uh like a quote from a few weeks ago in this podcast samantha john was talking about how brett and alan really want to get things right because for them the ultimate tragedy isn't not having anyone use your thing. It's that having everyone use your thing and it being a bad thing. And I think where that comes from potentially is from bad design ideas in GUIs and in Smalltalk that have now pervaded software in a bad form as opposed to keeping the results of Smalltalk secret

and developing them more further before releasing things. So that gives me some more context to where that worldview comes from, wanting to get things right. I spent a lot of time with the Steps Project. I think the way it's referred to is capital S-T-E-P-S. And it's a really interesting project that they, that they, Alan Kay led in modern times. It's,

I think the project began like in 2008, something, sometime around then. And it got a grant, like I think it was like $5 million or something over a number of years to develop it. And I, I,

first of all, I couldn't believe how similar in goals this project was to my goals, generally, of making software more understandable at every layer of abstraction. And make it so that people could modify things at any layer of abstraction. It also has a lot to do with Paul Chisano's notion of getting rid of apps, having app-less computing where there's a shared data model and you can just compute over all of your data, and apps are really just playlists of different computations.

So that's what the STEs Project kind of is. It's redefining programming. And the way they explain it is how I think of it in my world. But the way they explain it is instead of having hundreds of thousands or millions of lines of code from an operating system, a kernel, the whole thing, instead you replace that whole thing with beautiful abstractions and do it in 20,000 lines of really good code.

And they basically did it. I think there were, it depends on how you count lines of code, but in my book they did it. They built a whole GUI interface thing in a very small amount of code with really beautiful abstractions. And where the punchline is, is that they did it all with reactivity so that and like something very very similar to the cycle.js or react.js architecture but they were way ahead of their time on this one like react.js

was only just being made so and a number of the ways in which they it what I would call made mistakes or made interesting or like bad design choices, like it's hard to blame them for it because reactive programming wasn't even that old by the time they were doing it. They were mostly working off of Elliot Connell's work with functional reactive programming which was under the 90s. So I was shocked to see how similar our ideas were. And that they were using streams in order to enable the same goals that I was trying to enable with stream sheets.

Wacky. So I skipped most of the progress reports in this research project because it's just too much reading. But I did read the final report, which wasn't that long, actually. Most of the final report was these addendums, these other two papers that it references. One is on KScript, the language they built this whole system in and then k world which is the like uh the framework that they build things in and so those

were really really interesting very fascinating papers and that's where they explain how the reactivity of the system works and they have the is kind of like CoffeeScript. It's all very, very interesting. And it really, to me, begs the question of what if they knew about Cycle.js before they did this system? Because there are a number of places in which they have, where they break their model, and they don't follow the stream metaphor to the end. They have like an imperative set where you can just,

you can just like basically i think andre stouts will call it like shamefully set it's it's it's just not elegant or mathematically abstract and they explain why they think that you need to do things like that but i think at least the impression i get from talking to andre stouts is that no no you never need to do that. You can always describe things elegantly with pure mathematical streams. And so what I wonder is,

can I use the stream sheets and CycleJS ideas to really accomplish what the steps paper was trying to accomplish? And I don't know. It remains to be seen. But now that I know this project exists, as I run into problems about bootstrapping the system and building up the layers, I know I can come back

to these papers for inspiration and pointers to other papers that could answer my questions. It was really a great find and it's just hilarious how so much of my world view and my research is inspired by Brett Victor and Alan Kay and I was like, well, you know, those guys are cool and inspired me a lot but, you know, gonna go do my own thing now as opposed to these guys inspired me i gotta go read everything they ever did and i know it's intimidating because they've done a lot but you know i really i really have to so this is why i have decided that i'm going no further doing no other research until i read everything i can find on brett victor

and so i started that a little bit. Mostly I've only gotten through like his personal stuff from when he was 23, which is my age. And it's, it's really interesting and endearing. He, you know, I almost don't want to say it in public because it's like, you know, personal stuff, but it is on the internet. Anyone could see it. So I guess I can share. He, he was like going through a bad breakup with his girlfriend and he, you know, he was sad and like trying to find direction in life. And it's really interesting to get to hear about Brett Victor's whole, you know, heroic journey from there to where he is now, where I think is such an impressive place to be. So I'm going to do that. I'm going to do the same thing I did with Alan Kay with

Brett Victor. It might take the same amount of time, a whole two weeks, maybe more, maybe less. I don't know. But I'm sticking it out because I have a feeling that more kernels of gold, just like I found with the steps and KScript and KWorld that so directly inspires and helps my current prototype, I think I'm going to find that if I do the same thing with Brett Victor. So somewhere in the middle of doing this Alan Kay deep dive, I was struck with inspiration to write about computer GUIs, overlapping windows, and optimal computer use strategies. So I wrote this essay. It just kind of flowed out of me, and I figured, you know, it's kind of interesting, so I might

as well read it right here on the podcast. As a computer user since the age of three, I have had ample opportunity over the last 20 years to develop better computer usage patterns. One of the most effective I've found is to never have any minimized windows, overlapping windows, or windows totally hidden behind other windows. Instead, I make liberal uses of tabs and split screen. My default view is two windows side by side, each taking up half the screen. On a Chromebook, this is easy to set up with the use of Alt-left square bracket and Alt-right square bracket, which are shortcuts built

in to send windows to the left and right of the screen, respectively. On the left window, I pin a number of tabs to apps that I want open throughout the day for constant use, like Spotify, inbox google calendar and slack this pin makes it harder for me to accidentally close the tab and also makes the tab seem more quote fundamental than a regular tab which is more ephemeral ephemeral in some ways the left window usually has one non-pin tab on it which represents the main task i'm working on at the moment for example when i was writing this the tab is currently open to Cloud9, an online integrated development environment

where I was typing this very journal entry. A moment ago, the tab was still on Cloud9, but in the slash links file, so I could take notes on a paper I was reading in the right tab. Similarly, if I'm writing software, I will have my code in the left window and the preview output for the reading in the right tab. Similarly, if I'm writing software, I will have my code in the left window and the preview output for the code in the right window.

If I need to Google things to debug my code, that will also be in the right window. In some occasions, I want one window to be full screen, in which case I will put all my tabs onto the left window and hit control plus, which is the Chromebook shortcut to making windows full screen. I also try to do things in logical chunks. This means not leaving any task in a dirty state such that if you threw my computer into a river, I wouldn't be upset at any lost work or effort. One common mistake I see people make is having more than a handful, like five, tabs open

for long periods of time. This is a problem for two reasons. One, if your computer or web browser crashes and you lose all of those tabs, that is lost data, because open tabs usually represent a list of links you want to look at. Number two, it makes your desktop more cluttered,

which can then make your thinking more cluttered, and it makes it difficult to find what you need. This is similar to having a mess in your room that you don't clean up. It's like a common psychological thing that cleaning up a dirty room or dirty locker helps you just have less anxiety and more clear thinking. Thus, whenever I have more than five or whatever the amount of tabs I'm currently working with at the moment, whenever I have more than those open, I take the ones I'm not working on and copy and paste those links to an appropriate list or funnel or Trello or

bookmarks folder, and then I close that tab. Another common mistake I see is to not save every logical change directly to a cloud service. Having a Chromebook makes making this mistake harder, but still possible. This is similar, but less true for a Mac or PC that has Dropbox installed. Because there are still so many ways to save things to disk and so much disk storage on normal computers that you might make the mistake of saving things not in the Dropbox folder. For example, if you're using an app like GarageBand,

the default is to save those files in a specific place on your computer and you have to kind of monkey with things to make sure that it saves natively directly to the Dropbox folder. So I'm going to hit pause here. Occasionally it can be helpful to have more than two windows on the screen at the same time. I used to run into this when I was developing on my computer before I was using the cloud9 ide when i needed a third window on the screen in addition to my code editor and the code preview for the terminal however cloud cloud9 combines the terminal and code windows and and even the preview window into one or two windows so that's no longer

a problem for me but i could definitely see a use case for having three or four windows on the screen at the same time however at no point is it useful to have windows overlapping each other given that i can resize the boundaries boundaries of windows to any rectangular shape and zoom in and out on their contents i can always get a view of all the things i want without obscuring the contents of any other window side by side byside windows are more than enough. It is not only that overlapping windows aren't helpful, but they are also harmful because their excessive expressibility allows users to put their windows in a suboptimal, disorganized fashion.

I think it becomes even worse than just disorganized. Having windows that are obscured or minimized is harmful because it doesn't allow the user to realize that some applications are open and draining computer resources. It always annoyed me that when you would hit the X button on applications in a Mac, it wouldn't actually close the application. You would have to make sure to quit the application, which is different than closing. Unless you were an advanced Mac user, you would end up with all these applications open and running, taking up CPU time, and not even realize it. Even worse than that though is that you could have an application open with data in an unsaved state. I think this has happened

to everybody where you like you have to type some stuff in a Word document and you minimize it you do and then days later you you forget about it and it's still open in an unsaved state and then your computer crashes or you want to shut it down or something and then right then you have to like figure out if you want to save the changes or not it's like so disconnected from the changes you actually made and oftentimes you hit the don't save button or or the app crashes and you lose all that data which is so sad so um not allowing that by saying you know either either you're working on it now or it's closed and the data is all saved to the cloud. Those are the only two options.

There's no like it's invisible, but there's dirty state middle case. So I just want to say there is a special case where you would like to do some processing on data in a minimized window while you work on other applications in visible windows. However, even in this case, I think the correct way to do it is to upload the task to some web processing service and then close the window and then have that service email you a link to the finished product when it's done. I did this once with an audio processing service and that's how they handled that task and I think that was perfect. You know, the Chromebook model of applications hasn't totally taken off yet. It's still hard to do some things on a Chromebook, especially if it's a lot of processing or you need a lot of storage. But I think it's only a matter of time until this is the way things go. And then it'll

be easier to operate your computer in the quote correct way so given that our goal is to complete tasks and logical chunks one may inquire how we could design a computer interface to support such a workflow so the first step could be helping the user think through the steps and sub steps of their current action and organize them i've described how this could be done in my wolf js workflowS workflow prototype and write-up paper, which I talked about a few podcasts back, and I also wrote about on my website, which you can find at futurecoding.org. So if the steps are stated precisely enough in some sort of programming language-y thing, upon finishing the step, the computer system itself could check to make sure that what you did met the requirements for that step, that all unnecessary windows and data are cleaned up, and the appropriate outputs are saved to the cloud, etc. In this way, it would not only become possible, but easy to travel back in time to any previous semantic state of your computer workflow, and you'd be able to see how your project was constructed piece by piece.

And it's the same for archaeologists or historians who want to see how you thought through certain things. You would never lose any work or data in this way, and your logical path through your app would be elucidated easily. Taking the idea of working in logical chunks to an extreme, the ideal we could shoot for in theory is the ability to throw the user herself into the river and feel content that the contents of her project

are safely stored on the computer in an organized fashion. So for example, it would be less of a problem if George R. R. Martin died before completing the Game of Thrones because the current state of his brain would be preserved in this nested computer structure and someone else could kind of pick up where he left off in an ideal world. Okay, so that's the end of my overlapping windows and computer optimal use strategies

logical chunk thing rant. There's one other idea that I have been developing over the past few years that I didn't quite think was relevant to my project of the future of coding, but the more I read Alan Kay the more I feel like it is relevant. One of the reasons I think it's relevant is in the STEPS project that I mentioned before, one of the examples that keeps coming up is that they have a bullet point in their example of what the system looks like and it's like what is science or what is this thing called science which

is I just I can't keep laughing at that I just can't stop laughing at that because I'm reading a book now called what is the thing called science about the philosophy of science and I think it's also relevant and it's all wrapped up in this idea of creating a medium for human thought, or thinking thoughts that aren't thinkable, or augmenting human thought. And yet building the future of coding is just kind of a subset of that. And it is a medium, but I think it could be much broader. And I don't know if this means that I want to combine all these ideas into one massive,

really powerful language interface, but that's probably too much. It's more that it's relevant somehow, and I don't know what I'm going to do with that piece, but I'll just describe it a little bit so you know what I'm talking about when I refer to it later. So the name I'm using right now is Logic Hub, that's what I'm calling it, partially because it's been inspired by GitHub in a lot of ways. So in short, Logic Hub is the repository for all human argumentation and evidence. The goal is to create the right structures such that humanity can bring its

logical prowess to bear in the least biased way possible. As Karl Popper says, criticism is the root of all progress, and my dream is for a system like Logic Hub to transcend the printing press's limitation that necessitates that criticism be entirely separate from the content it's criticizing. More specifically, I want to unify and make canonical logic and argumentation so that we can have incredibly detailed, nested discussions about everything. And it's very structured, too. So I can even imagine a paper, I can even imagine a world in which scientific papers are written directly in this tool.

And so are court cases and even bills in Congress. Because then we'd truly be able to fill Philip Morrison's vision, which I found this quote earlier in Alan Kay's writings, that the evidence, the experience itself, and the argument that gives it order is what we need to share with one another and not just the, quote, unsupported final claim. Imagine a world in which we don't call each other names like global warming denier or environmentalist hippie, but we can truly see the arguments, evidence, assumptions, and perspective of one another through this structure. So there are a few subtle details and key points. I thought this through a lot, but not nearly enough that I need to,

but some of the key points that will help elucidate it is that you have a few different kinds of things. You have propositions, which are statements, and by default they are unsupported claims. And then you have arguments that support them. And then arguments are made up of more propositions. They can reference other propositions in the system. And so when you create a proposition,

every word of the proposition has to link to a definition that defines that proposition and definitions I guess also recursively link to other definitions so words are defined in terms of other words and you may wonder about an infinite regress problem but I don't think that's a problem just like how dictionaries exist it's not a problem they describe words in terms of other words.

So then let's talk about how these things nest. So I want the confidence that we have in certain propositions to flow up and give more confidence towards propositions that depend on those propositions in their arguments. So, for example, if you have a top-level proposition A, and then the argument for A refers to proposition B, and proposition B has zero support, then that will weaken proposition A. But if proposition B has a lot of support, that will strengthen proposition A. And so we'd want to have some sort of number,

like from, let's say, 0 to 100, representing the confidence in these things. And so then the question is, how do you structure it? So like how much should an increase in the confidence in proposition B affect the increase in confidence in proposition A? Like, I don't know, maybe something like Bayes' theorem would help us here. People seem to think that's a useful way to update your confidence in propositions based on new evidence. But I guess just to give you a sense of how I think about it,

I would never want to ask people to vote, how much do you agree with this proposition? That's a poll. That's not what this is. The way I would want it to work is to have people play what I call the logic game. So you give them a top level proposition and an argument. And that argument has a number of propositions that make it up. And I see an argument as like a string of text where a number of pieces of the text are underlined and those underlined pieces are propositions which you can click on and see the whole tree below them. And so, but you don't give them that whole tree. What you give them is the top-level proposition and the argument below.

And the argument contains the words that describe propositions, but not things below them. person, given that this argument, what you wanted to figure out is if this argument is 100% true, if this argument holds, to what degree does this argument support the proposition, if every part of the argument holds? And then, so maybe this argument gives you 80% confidence, if everything in the argument is true. Then you say, how much, what percent of that confidence is each of the propositions that make up the argument responsible for. And so you break down an argument based on how the pieces of it link together into this numerical structure so that when the children propositions

get their ratings through the same process, you can have the confidence flow up towards the top. I have a lot more thoughts on this, but I don't want to go too much into it right now. I just want to let you know that this idea exists, and I am reading a lot of philosophy of science to help flesh it out. In particular, I'm reading Karl Popper, who doesn't really seem to think, from my interpretation, doesn't seem to think this idea could exist. Because he talks a lot about how defining definitions isn't that important, and building theories up from the ground up with evidence isn't really how science is done. Science is done more kind of messily. You know, people shout out theories, and they compete based on evidence,

and it's more haphazard than this logical structure I'm trying to build up. So hopefully through reading him and meditating on this more I will have some more ideas for you on this later. So after I finished my Alan Kay deep dive and sent him an email I had one mostly full research day to start my Brett Victor deep dive. And at this point I haven't found that much about software and user interface design. Mostly I've got to learn about Brett's life when he was 23 years old, the same age I am now. I got to see the lyrics to his parody hit single Caltech Girl. I think I even found a link to him singing it,

acapella, and I got to hear about, you know, all sorts of things where his mind is at and struggling with his direction in life, which is really interesting. So I look forward to continuing that soon, but as you'll hear in a second, I don't think I'm going to continue that right away. I think I'm going to put that the Brett Victor deep dive on pause. Because I had a call today with Andre Stoltz. And if you listen to this podcast, you know all about Andre Stoltz. And even if you don't listen to this podcast, you may know all about him because he is wonderful. He is the creator of a user interface library called CycleJS, which is inspired by React, JS, and Elm. It has the idea of unidirectional data flow, but it takes this idea to an extreme with the idea of streams. So it really, I've never seen the ideas of streams taken so extremely.

Pun not intended. I don't want to spend too much time talking about Cycle.js, but basically the idea is you get rid of all side effects and everything becomes very mathematical, very pure. And ultimately, what's so great about CycleJS is you can visualize your app as a data flow diagram from top to bottom, one directional. No arrows go back up in the wrong direction. And it's amazing. So anyways, I got Andre Salt on the phone this morning at 7 a.m. Eastern Time.

I don't know where he is in the world, but I think it is not Eastern Time because he sent me an email at like 4 a.m. Eastern Time this morning. So I had a lot of questions for him, and I don't think I have time in this episode to go through everything he told me, but I'll give you a quick overview. So first he explained what he meant and piqued my interest when he said, CycleJS DevTools as IDE. So what, the reason I was so excited about seeing that bullet on a slide, a talk that I didn't even listen to

because I didn't know it was on the internet. So what excited me about seeing that bullet is I began to realize that StreamSheets, my prototype idea, is basically a GUI, a similar abstraction, on top of CycleJS. So I was thinking maybe a gooey a similar abstraction on top of cycle.js so i was thinking maybe andre had had a similar idea and that there would be some room for collaboration so it turns out so it turns out this guy nick bostrom who actually i think i had come in contact with on the internet before he had helped me with getting PsychoJS to run at some point.

So it sounds like he and Andre had this relationship that I kind of was hoping to get. I think Nick has this idea for a PsychoJS visual editor, and he and Andre are going to work together on something like that. And it makes sense. Their vision is very similar. My vision is a lot more speculative and ambitious than what they're shooting for. But I'll let Andre talk some more about that. I'll link to you a good blog post that came out recently about our core team in PsychoJazz. So Nick is also in our core team, Nick Johnston, and he was basically being interviewed in this blog post,

and there he mentioned a bit, like, his vision for, like, things that he wanted to build, and then he started building other things, and he ended up hitting the same need for a visual programming editor so like more towards the end of the blog post you can find one of the videos in the conference that we we had he gave a talk there I'll link that as well here. And there he starts talking about the need of having an editor called Bonsai Editor is the name he gave. And I can also give links to that. He has a bunch of projects, and one of those projects was Bonsai Editor.

Nice. And anyway, like, his vision was very similar to my vision. And that's what I was, that's what I meant with, like, sort of converting the DevTools to an editor, because we could join efforts of what Nick is doing plus what I'm doing in DevTools and sort of get the DevTools code base and sort of shape it to be also an editor. Or basically get common pieces from the DevTools that could still be only in DevTools but also use those other common pieces for other projects.

Cool, yeah, that sounds great. Yeah. Let me link those as well. Bonsai editor, This is very early stuff. Basically, there's nothing there. I mean, there's some sketches, but then there's Streamtree, which is a bit more, like, in shape. Streamtree is basically a way that Nick found to draw a diagram as ASCII art,

which is, you know, visual programming, but just embedded inside a template stream. So that's also what he talked about in his conference talk. Cool. So these things are being made. That's amazing. Yeah. So, I mean, of course we want to find time to build these stuff. But right now it doesn't look like we're building it because we sort of paused stuff to fix other things. Yeah. So the ASCII art thing is pretty interesting. I mean, it's not the most convenient way of writing code. But the visual aspect of it is pretty interesting. I mean, it's not the most convenient way of writing code,

but the visual aspect of it is pretty cool. So as I was saying, we want to get to that point. But we found some other things in between that we want to solve. Because basically, you don't want the visual editor to be just a summary of your code you want it to be the full code yeah because you know there's UML for summarizing code and we don't want that we want the graph to be code yeah so right now we're focusing on like other minor aspects so that everything can be visual and not just some things.

Got it. So can you be more concrete? What are those things that you're working on so that everything can be visual? Yeah, I can give a link as well. But what we found, this is something that we found when we were discussing in the CycleConf. We found the need to handle something called pool data. And I can link you the discussion. It's a huge discussion. Great. But the basic example is we want to support math.random in CycleOJS applications.

Okay. Math.random is a type of function that, you know, it's not a stream of events. You don't have a bunch of events of random numbers coming. You just have random numbers, and you can pull them out, right? Like every time you call math.random, you give no arguments. Yeah. You get a number, right? Like every time you call math.random, you give no arguments and you get a new number, right? Yeah.

So you can think of that as a source where numbers are coming from, right? In the same fashion, we also have the use case for getUUID, so unique identifier. And that's also a function that has zero arguments, and you get a new number every time. So it's basically a source of data. Sure.

But it's not a source of data that lives on its own. It's a source of data that makes data only when you request for it, right? Okay. So currently the way that we do that in CycleJS is that we just put it as code, and it won't appear in the graph as a source of data. It just pops up from nowhere. Okay, I see. And that's what we don't want.

We want everything that is a source of data to be visually represented as an actual source node in the graph. And so the links that Andre talks about, I'm going to include in the notes on my website. So to give a quick overview of how the CycleJS DevTools works, I have the notes on my website, but the key insight is that when you have a CycleJS app, you can type window.cyclejs to see the data structure, the core data structure that CycleJS knows about, and it'll give you all the syncs for the app, and those syncs are traversable.

You can kind of walk the tree up. And that's how you get all the other nodes. And that's basically how they visualize the tree that you see in the CycleJS DevTools. And I have links explaining all the important functions and the links to them on GitHub in my notes, which you are more than welcome to check out. Andra and I talked about a few other things so we talked about how if I was building stream sheets how I could go from a graph data structure of a CycleJS project to code like how you go in the other direction instead of going from code to the graph, how do you go from the graph to JavaScript code, he mentioned in this context that they're

thinking about creating a domain-specific language that's like a subset of JavaScript that limits its expressivity, which is actually something that Andre and I have talked about in the past because he mentioned how even if you write the const keyword, it's not truly a constant because if you create a const object, you can still mutate the keys of that object. So if you truly want immutability in JavaScript, there's a ESLint file that he linked me to that truly makes JavaScript almost Haskell-like in its purity, its immutability. And so that's the sort of DSL type language

he's imagining for CycleJS. So what seemed the obvious question to me was, well, so then isn't that basically Elm? Like what's the difference between CycleJS and Elm if CycleJS isn't Cycle JavaScript, it's a Cycle domain-specific language that doesn't allow side effects. And he had a really great answer. So it's subtle, but there is a distinction. So the first is that Cycle.js has first-class streams, and you can do combinations on streams in very clear, explicit ways.

And it's not as clear and explicit in Elm. Elm has like a runtime that takes care of that stuff for you kind of invisibly which isn't the same. So that's one major distinction. The second major distinction is that Elm has callbacks. You basically pass functions. You give your user interface elements, you give your buttons functions that then are called when the buttons are clicked. So I think technically it's no longer callbacks, but you give an action to your buttons on click attribute.

But it's basically just the action is just filtered to a function. So it's similar to giving a callback. The key point is the same data structure that has your view code also has your handler code. It's coupled in this way that in CycleJS it is not. In CycleJS, the events are clearly at the top of your application as the sources, and the user interface is clearly the output of your application at the bottom as the sink. And of course, you may then ask, well, how do you refer to a button at the top of your application?

And, you know, this is the one place that Cycle.js has to kind of wave its hands, you refer to buttons and everything by IDs or by classes up at the top. So that's how you get around a cycle problem. The cyclical nature of you have data streams that produce a view and then interacting with a view mutate the data streams with which then mutate the view so the way you get around that is you refer by reference to those things by their name and then down below you you name name certain things so i don't see it's not as elegant as i would like but i don't see any real problems with it at this point.

We talked a bit about NoFlow, which Andre had pointed me to maybe a year ago, last time we talked. He doesn't think that NoFlow is relevant here for the way he wants to build the CycleJS dev tools as IDE. But I do want to spend a full day with it, maybe more like how I i did with with eve and other tools but most but eve was the one that i really kind of stuck with even though it felt buggy um and then um i kind of pushed andre's vision for what it would look like to build an app in the cycle.js dev tools as ide particularly with like your html like how do you add a button to your app? How do you add a fold or a merge to the streams? And he conceded that yes, while you really would be able to edit your app

in the CycleJS DevTools, at the end of the day, you'd still have to type the code. You'd have to type formulas. You'd have to type your HTML. And he really thinks that that's kind of the most efficient way to go about things. If you have a formula,

if you have some HTML, you just type it. Which, you know, makes sense to me. And I think would be the way that I initially built out stream sheets, you know, with... The formulas would be like visual basic formula type things. It would be equal sign, then you kind of type out your formula. So that's reasonable. And then he mentioned that he would want it to really go to link back to your code. So you would be able to import code into the CycleJS DevTools IDE,

and then you'd mess with that code, and it would then go ahead and modify the code in your text editor, which sounds like magic to me. Like, how do you sync between those things? But he didn't seem to think it was going to be too crazy difficult. So then I ran Andre through the problem I was trying to solve with stream sheets. To repeat it again, I want to make it easier to write CycleJS apps, not just debug and understand them. And the idea was to have this visual spreadsheet metaphor thing. And he knew what I was talking about.

He said that sounds a lot like an earlier version of EVE. Well, he thought, one, that the programming model sounded like EVE, and then two, this particular idea sounded like something that they had done in the past. And so he sent me a link to that, which is definitely something I'm going to look into ASAP. And then he also mentioned that he really likes the idea of a visual editor for CycleJS because, you know, the way he described it is that it can constrain the thinking in a positive way. Instead of just a text box where you can type anything,

it would say something like, where is the data in your app coming from? Do you have data coming from a server? Are you going to need to send a request to a server? And it can help you construct your application through a series of questions. And, you know, this to me sounds great, but at the same time,

I understand the feeling of dread you may have of a WYSIWYG wizard guy that asks you questions to set up an app, because we've all had to do that, and they've been terrible. So obviously we wouldn't want to do that. I think in principle, it doesn't have to be terrible, but I guess that remains to be seen. So then he walked me through some of the metaphoric challenges I'm going to have with spreadsheets, particularly how there are two kinds of streams. So there are values that change over time, for example, your age,

and then there are events, for example, your birthdays. And so it's clear how your birthdays are a series of discrete rows in a spreadsheet that populate that spreadsheet as they happen. But your age, it's like every nanosecond you get a new age. That doesn't really make sense. And so the way Andre is solving that, and it's kind of the way he solved it with math.random as well, is with this concept of a signal. And so a signal kind of is a function of, it's a function from time to a value.

And so you can think about it as producing these values every nanosecond, and then you can sample that signal by some event. So you have a signal, you combine it with an event, and you get a stream. And so you could sample your age every button click, or you could sample your age every number of seconds. And that would give you a stream of your age every event. And I think what he's working through right now in Cycle.js is thinking about how do you make the distinction for new users between signals and streams? Do you necessarily have to immediately convert signals to streams before you can do anything with them?

Or can you use signal combinators on signals and then later down the road convert them to streams? He's thinking about those sorts of questions. My intuition is that having these things, signals and streams, which are so similar but different, will be killer for beginners. Learning stream processing is hard enough on its own, and then to throw another thing in there,

it reminds me of how React has both state and props, and it's just, like, the most annoying thing ever. So I would love to see them resolve that in a way that is intuitive. So I guess we will see what Andre and crew comes up with in that vein at some point soon. He also encouraged me to reach out on the CycleJS Gitter. He says Nick and himself and the other core team are on there all the time responding to things within minutes, basically. So if I run into issues, I'm sure I will be on the CycleJS Gitter. And last but not least let's talk about my next steps with research. What I plan to do over the next two weeks or so.

So there are two obvious next steps. I could continue with the Brett Victor deep dive or begin a visualization of the CycleJS dev tools data object as tabular spreadsheets. And before I talk about those, I went ahead and brainstormed other things I could do with my time just to make sure that I'm not at a local Maxima, but at a global Maxima. So I looked at my futureofcoding.org slash ideas website, and I saw there were a few blogs I could write.

I saw there was like a widget library that I think would be a cool thing to build. And I also decided that it wouldn't make sense to do any other research on my links page other than into Brett Victor because of how well the Alan Kay deep dive went. So anyways I came up with these two other options but I kind of discarded them. They were really strong men to begin with. Alas, so I'm going to put a pause in the Brett Victor deep dive and go ahead and start prototyping a visualization of CycleJS data as tabular spreadsheets.

So I started to think about how I could do this in code, but then I realized that that is not the level of abstraction I should be working at. And now that I have a sense of how this could be possible in code, I need to think about the metaphor, the metaphors. So looking at the Xstream documentation, Xstream is the stream combinator library that Andre created to work in combination with Cycle.js. There are only 26 core stream operators, which is part of the reason Cycle.js is so amazing.

There are very few things you can do. There are very few primitives. So it seems like the next step is to create pictures, either by hand or on the computer, of metaphorically how you would do that action in a spreadsheet. And see what happens. See if you can do all 26, which ones are troublesome,

if the whole metaphor breaks down who knows it seems like the quickest way to stress test this metaphoric prototype idea so that's where i'm going to go next and um and then if that goes well then i'll start uh if it goes well on paper i'll probably probably do it on like a Photoshop tool and publish those screenshots and maybe even release that as a blog of some sort. And then if that goes well, then I'll go to code. Go to code probably, yeah, soon-ish. And if at any point I get stuck, I'll either like reach out to Andre or go back to the Brett Victor deep dive or some other prototype. So that's kind of where my head's at now.

I'm feeling really good about this prototype and I'm excited to begin making things happen. And part of why I feel excited is that Andre is available for the next foreseeable future so if I get stuck I can get him on the phone right away and get unstuck quick. So the only real roadblock in the way that I can see is either if the idea just isn't going to work and I run into a core block, which is fine. I just move on.

But I guess a bummer would be if I run into a block where CycleJS isn't quite expressive enough, and I have to wait for them to make some core language decision before I continue. But I don't foresee that happening. So given that I spent basically the entire day today talking to Andre, planning out my next research steps, recording this podcast, editing it,

I'm not going to have time tomorrow to do more research. I'm going to have to do what I plan to do this afternoon tomorrow morning. So tomorrow is a day of no research, and then I'll be back researching Wednesday. I'm actually skipping Thursday, so Wednesday is particularly long, and then I'm back Friday. So we'll get some of these pretty pictures I promised you on Wednesday and Friday. And that is it. Thanks so much for staying tuned through this whole scattershot episode. I hope it wasn't as much of a pain for you to listen to as it was for me to kind of get my head in the right place to record it um and if you got lost along the way i i sincerely apologize please please check out my website i

think it's a little bit more organized so i think it could help make your your head a little bit less jarbled like like mine is right now uh talk to y'all soon bye