Future of Coding - Reflection 14: /about

Episode Date: December 3, 2018

If you haven’t been following my research journey, this episode is a great place to join! I recap of who I am, where I come from, what I’m trying to accomplish, and how I hope to accomplish it. The mission of this project is, broadly, to “democratize” programming. My new phrase is: Enable all people to modify they software they use in the course of using it. This mission would cause the following changes, in order of increasing importance: All software will be co-created by decentralized communities, rather than centralized groups or companies. Through the power of crowd-sourcing, the quality of all software will become much higher than existing software. All software will be much more composible, interoperable with other pieces of software. All software will be arbitrarily customizable, allowing for bespoke, tailored experiences. Learning to communicate with computers teaches one how to think more clearly, precisely, mathmatically, and powerfully. If one can manipulate the software one uses, if only one learns how to organize one’s thoughts, many people will self-teach themselvse to do just that. As the fabric of the world is eaten by software, the ability to fully manipulate that software one uses is an essential freedom. This vision is not new nor creative: it’s obvious that people would change things if they could. Yet this problem has proven stubborn over the decades and most have given it up as insoluble. We have all but forgotten the essential characteristic of computers: their malleability. In order to accomplish this vision, I believe there are three large categories of problems that need to be addressed: Rid ourselves of the IO Monad, replacing it with better abstractions for whole systems. Create a better programming experience for the complex abstractions we create to avoid IO. Reimagine version control for a world where software looks very different than it does today, with many more forks, at many more levels than just one-deep off of master My recent work was on ridding ourselves of the IO Monad from user interfaces, which is building on Conal Elliot’s FRP work. My paper and talk at REBLS last month argues that Elm Architecture makes software take longer to understand (which is untenable if we want people to be able to modify the software they use in the course of using it) as compared to the higher-order and cyclic streams of Conal’s original FRP. My future work will be improving the programming experience of “original FRP”, potentially with a Haskell-inspired structured editor. I will also extend Conal’s FRP work to also removing the IO Monad from the “backend”. In the episode I add a lot more color to these points, as well as discuss my personal background, the past and future of Future of Coding meetups, my experience at SPLASH last month, and other whacky ideas! You can see the transcript for this episode at https://futureofcoding.org/episodes/33. Support 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 welcome to reflection 14 where I talk about basically how my last three months of research have went. The last episode reflection I did was on August 24th so this one is for the end of August all of September, October, and all of November till today, which is basically end of November of 2018. For those of you who are tuning in to this episode far into the future. And now a message from our sponsor. Replit is an online repl for over 30 languages. It started out as a code playground, but now it scales up to a full development environment

where you can do everything from deploying web servers to training ML models, all driven by the REPL. They're a small startup in San Francisco, but they reach millions of programmers, students, and teachers. They're looking for hackers interested in the future of coding and making software tools more accessible and enjoyable. So email jobs at repl.it if you're interested in learning more. Okay, so it has been a really great three months. So instead of going through the three months chronologically, I'm going to start with my new about page, futureofcoding.org slash about. I'm going to mostly just read it and have a few side notes as they come up. All right.

So, about futureofcoding.org. TLDR. Future of Coding is a research project and podcast by me, Steve Krause. My research is focused on building an open source programming language. The podcast alternates between interviews with programming language experts and reflections on my own research journey. Me. Hi, my name is Steve Krause. When I meet people, I like to begin with life stories.

Context is important. Here's mine as it relates to this project. I was born in New york city in 1994 and raised in south florida as a kid i was bad at school and particularly bad at math however i was also a computer kid and partly because of that i started going to a wonderful after-school computer science program imaxMAX. Through learning Logo, Scheme, Java, and Haskell in middle and early high school at IMAX's self-paced and nurturing environment, I became a computational, mathematical, and introspective thinker. I became very good at

school, especially mathematics and physics. I went to the University of Pennsylvania for college. After taking most of the computer science classes at Penn, I left without graduating in early 2014 and went to work at Looker. I left Looker at the end of 2014. While at college and Looker, I was deeply influenced by Brett Victor and Seymour Papert. Ever since my experience of transforming from a self-identified stupid person to a self-identified smart person in middle school, I was curious about how it happened and if similar changes could be nurtured in others. While reading Seymour Papert in college, I learned that my own transformation was no accident. Papert intentionally set out to create mathematical thinkers from mathphobes with Logo,

and he accomplished his goal in me. It was a really mind-bending experience reading Papert in college and realizing that the changes he caused in me were on purpose. He spoke about his motivations for creating Logo, the design choices he made in designing Logo, and then he would tell stories about how Logo affected children. And I would remember similar experiences from my own childhood, and I could recall how those experiences helped me in life.

So with these thoughts in mind, in July 2015, I co-founded the Coding Space, a New York City-based after-school program where we taught kids to code in a self-paced environment in a very similar spirit to IMAX. There, I created our Scratch-based curriculum, as well as WoofJS, which is a JavaScript framework and online IDE built to transition kids from Scratch to JavaScript. So the idea behind Woof is that for every block in Scratch, there's an equivalent command in JavaScript. So kids who know Scratch well can leverage their existing Scratch knowledge while learning JavaScript syntax. And I think this is a much better curricular progression as opposed to

starting in a text-based language and having to learn both concepts and syntax at the same time. I think it's better to start with the concepts and then layer on syntax once the student is familiar with basic constructs such as variables, loops, booleans, ifs, branches, etc. So in mid-2017, I left the coding space to work on programming languages full-time. Now, so at first, I thought I'd have this whole thing solved in just a matter of months all by myself. I'd have this brand new programming language and everything would be great. I was wrong. While I did make some interesting prototypes in the first few months or year or so, I spent most of my time retracing the steps of those that came before me.

I learned the hard way that I need to read my history. Then in the summer of 2017, I was approached by Irvin Huang, who suggested starting a New York City-based meetup group for people interested in the future of programming. Now, I thought that was the dumbest idea I had ever heard. Why waste my time talking to other people when I could read Alan Kay papers in my room? But he, despite my misgivings, organized a first meeting, and I went, and it blew my mind wide open. I learned so much in that hour. It's astounding.

It inspired my log, futureofcoding.org slash log, which has since become the core of my research practice. I put all my research notes in it, in like a effort of radical transparency um and i learned many other things and met some really wonderful friends that i'm still friends with to this day at that just that initial meeting so uh after irvin became busy with his new job i took over the group and created a slack for future of programming folks which is now used by people all over the world. And we're having meetups pop up in various places, which is really cool. So I learned the easy way the importance of community. Thank you, Irvin. It was also around this time that I began this podcast, which alternates between recapping my own research, as I'm doing now, and speaking with experts. It's been an incredibly invaluable experience for me, helping to add structure to my research, gaining new insights through collaboration, encouraging me to reflect on my progress,

and giving me energy as people like you respond to episodes on Twitter and email and Slack with excitement and ideas of their own. My framing for this project has gone through a number of turbulent stages. Brett Victor wannabe, total disenheartenment, irrational exuberance, etc., etc. But I have recently, as of fall 2018, come to a very positive mental space, which I'll describe in a sec. These days, I describe myself as a programming language designer because my goal is to create a working system, not just produce research, that resembles a programming language in its expressive power,

but will feel more like a system in the Excel or Smalltalk sense than a text and compiler-based programming language. Okay, my mission. The mission of this project is to enable all people to modify the software they use in the course of using it. Now, just a quick caveat, I have a note on this page that when I say all people, I guess I don't really mean 100% of people. Because even today, not 100% of people in the world can read and write. Or not even 100% of people know how to use a computer or a smartphone. I guess I'm talking about a lot more. Like maybe 90% of people will have the ability if if they so choose or whatever maybe

maybe 90 of people who know how to use computers basically a lot virtually everyone everyone you know anyone listening to this podcast any of your friends and family especially people of a younger generation i don't know about the older generation anyways when i say all people, that is a phrase that needs to be pinned down more, I need more nuance there. But directionally, I mean, a lot more people than, than now, like order of magnitudes more people. So like maybe 100 times or 1000 times or 10,000 times. Well, actually, if you think about it, let me read the mission. Again, the mission of this project is to enable all people to modify the software they use in the course of using it. So how many people do you know that modify the software they use in the course of using it?

I think the answer is basically zero. Maybe there are a few people who have side projects that they also use on a daily basis, and maybe they're modifying their side projects while they're using them. I've done that a handful of times, but on the whole, nobody does this. So we want this number to look more like millions of people. Maybe it's not billions, but at least millions. All right. So here's why this mission is important. And I'm going to list six reasons. And the sixth is the most important. The first is the least important. So number one, all software will be co-created by decentralized communities rather than centralized groups or companies. Number two,

through the power of crowdsourcing, the quality of all software will become much higher than existing software. So this is just drawing right on Wikipedia's success. Number three, all software will become more composable and interoperable with other pieces of software. Number four, all software will be arbitrarily customizable, allowing for bespoke tailored experiences. And so I spoke, so number two was that the quality of software would become better.

And I think that will be true in an absolute sense. But I think more importantly, software will become better because it'll be more what you want. You'll have the power to customize it to be exactly what you want. And not only will the quality be better because you've made it exactly what you want it to be,

but you will have the sense of self-sufficiency. You'll have this sense of power, autonomy, which really is priceless. Number five, learning to communicate with computers teaches one how to think more clearly, precisely, mathematically, and powerfully. If one can manipulate the software that one uses, only if one learns how to organize one's thoughts, many people will take the bait and will self teach themselves to code in order to have power over their computer, their virtual world. And so this is kind of a little bit of a paternalistic goal.

So I have mixed feelings about having goals like this, bait and switch goals. But given my background and how my life was changed by learning to code, it's very motivating for me to build a system that will entice others to learn how to code. And the goal here, to be clear, is not that I want more people to learn how to code to learn how to code. The main thing with this one is I want them to learn how to think clearly. I also want them to have autonomy over their computers. So I don't care about them building apps so they can go make millions. I want them to have control over their virtual worlds. And that's number six. As the fabric of the world is eaten by software, the ability to fully manipulate that software is an essential freedom,

particularly the software that one uses on a daily basis. All right, so now this vision is not new, nor is it creative. It's obvious that people would change things about their software if they could. Yet because this problem has proven stubborn over the decades, most have given it up as insoluble. Most computer scientists, but particularly most lay people. We have all but forgotten the essential characteristic of our computers, their malleability. We look at computers and the apps we use as being rigid and out of our control,

just like the laws of gravity are out of our control. When was the last time you thought, hmm, I wonder what it would be like if gravity was a little bit stronger or a little bit weaker or the strong nuclear force i wonder what the world would look like if i tweaked that a bit you never wonder those thoughts because you know you have no control over them and similarly you never wondered well maybe those of you listening to this podcast have but most people 99.9 percent of people haven't really wondered that much about how to change the software they use because they know they have no power over it we've forgotten that computers can be anything we imagine them to be and so part of why i say this is because when i tell people what i'm building and why i'm building

it they aren't that excited lay people aren't that excited sometimes they people aren't that excited. Sometimes they'll say, you know, I just want things to be simple. I don't really care about customizing things. And this makes me think of how people don't always want democracy. They don't always want the right to vote. I remember reading like a history of the suffrage movement, women's suffrage movement. And I was shocked to learn that the suffragettes early suffragettes had to convince women that they wanted that they wanted the right to vote it wasn't like a natural thing to want i think the same is true here it's not fully a natural thing to want something that you can't imagine having. But that doesn't mean we shouldn't fight for people's right to have it. All right, so my thesis.

My current angle on this whole mission is most influenced by Jonathan Edwards, out of the tar pit, Connell Elliott, Brett Victor, and Paul Chisano. There are many, many, many hundreds of others who have influenced my thinking here, but I can't, I don't want to start with them all. Those are the people that really come top of mind when I think about where my thoughts come from, particularly not only on the inspiration for the mission itself, but for how to achieve it. All right. Not only on the inspiration for the mission itself, but for how to achieve it.

All right, so my thesis, number one, the comprehensibility of large software is of utmost importance. So the mission is that you should be able to modify the software you use on a daily basis in the course of using the software. So if we're going to make that true, what needs to happen is that when you want to make a change to a piece of your software, you have to be able to understand exactly what's going on in the code underlying that software as fast as possible. So you can make a change and then get back to whatever it was that you were doing. I'm envisioning you kind of like, you're driving your car, you pop the trunk, you make the

change, you get back in your car. It's not a great metaphor because cars are kind of hard to understand, but just bear with me. Pop the trunk, tweak, pop the trunk back down, drive off in the car. And so let's just talk about comprehensibility for a second and why it's so bad. Have you ever, as a programmer, been working on an open source project and wanted to contribute in some way? Maybe you found a bug, something else. Who knows?

You want to make a little contribution to the code, not just the documentation. And so you just the documentation. And so you download the repository, you figure out the build script, you probably just quit because after you try installing it and it breaks because of some dependency was missing or some incompatibility, who knows. So the whole build thing is annoying, getting the code to run is annoying. But then you do all that. And you try to understand the code. And even if it's just 1000 lines of code, if it's more than 100 lines of code, you're basically screwed. 500 lines of code, it's going to take you so many hours to understand how that code works, that again, you're just going

to give up. So that's why comprehensibility is so important, because our code, in order to make a change to an app like that I use every day, I'm gonna have to understand not only 500 lines of code, but probably hundreds of thousands of lines of code. Like Microsoft Word is millions, millions of lines of code. So the comprehensibility of large software projects is critical if we want to achieve this mission. And now maybe after you heard me describe how hard it is to understand an unfamiliar code base, you'd think that, you know, let's just give up. This is impossible. I don't think so. I think as long as we keep our eye on the ball of comprehensibility, we should be fine.

Okay, so point two. In order to enable comprehensibility without sacrificing expressivity, we must strive to eliminate all forms of incidental complexity in programming. Programming should describe the essential nature of the problem, problem, problem. The view from the user. If only the user were made to see

the implication of all things okay so this this is a really important point but it's it's it's a little bit hand wavy i'm getting this incidental and essential complexity from initially from fred book fred brooks and but it's also referencing out of the tar pit um all right so point three is also a little bit um hand wavy mathematics is the language of essence or as close as we can get if you have something better let's talk about it um but math is pretty good uh something like the lambda calculus um is is pretty much as close to we can get to the language of pure computation free of mechanical and historical accidents. Again, I'd be open to alternatives.

The lambda calculus also seems kind of random, but it's the best I can think of that represents essential natures of of computation okay so number four the solution is to create denotative languages or a denotative language a language where each term denotes an equivalent mathematical object um so in other words basically what i'm getting at is we need to point five5 rid ourselves of the io monad and replace it with better abstractions for whole systems so now connell elliott has a really really wonderful post will functional programming ever be liberated from the von neumann architecture and so in this point he makes a really really wonderful distinction. So monads themselves are this very benign type class thing with laws. They're kind of mathematical and categorical. They're great.

And they're not that hard to understand. The thing that's kind of hard to understand, I think, is the IOMONAD. And I think part of why it's hard to understand is that Haskell people aren't honest about what it is. The IOMONAD is imperative code embedded within Haskell. That's what it is. You get to write code with side effects within your Haskell program. And it's a reasonable compromise given the world we live in today. Because you want to have the benefits of Haskell, but then you also need your code to have some side effects. But Connell Elliott shows us how we can do better than the IOMONAD. And he showed how with FRP.

So functional reactive programming, he argues, and I would agree, is a way to do side effecty things. Basically, you have a user interface on the screen that a user can interact with, and it can be dynamic and update and whatnot. So there are all these side effect things happening. Your computer is doing stuff and yet the interface to the programmer at the Haskell level or at the FRP level has no IO. You describe the view as a pure function of state. It's beautiful. It's a beautiful system. And so this essay argues that we should be able to extend that idea of getting rid of the IOMONAD and replacing it with better abstractions for whole systems to the entire world of programming. And so this is pretty wacky. And I don't know.

I think most Haskell people, functional programming people, won't agree with this vision. But I'm really excited about it. And so FRP is all about removing the IOMONAD from user interface construction. But then what about all the rest of programming? So we have the backend, for example. We have databases. We have file systems, sockets, all that stuff. Okay, so now here's the key idea. There are a lot of things

that programming languages deal with now that they shouldn't deal with. They're too low level. So just for an analogy, think about FRP. So before FRP, we use jQuery. Before like React, for example, you use jQuery to manually mutate the DOM, manually mutate the HTML on your websites piece by piece. But now with React, you simply say what you want the HTML to look like at any given point in time, given the state. And boom, it does a jQuery for you automatically. So you don't have to dirty your hands with the IOMO net, with mutability. You can just declaratively say what you want. And it's a computer's job to figure it out.

And in React's case, it does it with diffing the DOM tree to figure out the minimal set of jQuery changes it needs to make in order to get the page to look like how you want. So let's apply that same kind of thinking to every other part of programming. So many parts of what programming does isn't necessary. So putting things to the console, getting characters from the console, writing the file system, opening sockets, all of those things are too low level for programming languages.

We need to build better abstractions on top that get at what we're actually trying to do here now i'm going to say that again files we shouldn't have our programming language shouldn't be able to write to the file system there's a higher level goal that we want the program to do and the abstraction should encode that so so maybe you want some data to be saved somewhere. So you could talk about that. But how it's saved, maybe you say, I want this data saved locally. And then yes, your programming language will write it right to the file system. Or you could say, I want this data saved to the cloud somewhere, and then it'll do that as well. But you shouldn't have to talk about the file system and you shouldn't have to open a connection to a database in order to get those things persisted.

So I'm just going to stop talking about this point. I could talk about it for a while. So point number five is we need to rid ourselves of the IOMONAD. And so FRP is about doing that in user interfaces. But I've also started working on how we're going to do that for the backend. Like what is a user? What is the denotation of a user? What about data?

What about, you know, real-time multiplayer games? What about a CRUD app? How would you do all these things without the IOMO net, without explicitly making a request to a database? In other words, we're blurring very, very much so blurring the line between front end and back end in your code, kind of like Meteor, but even more so. You describe your user interface, and then maybe you lift an event, so you have a button click. So here's an example. A classic FRP first hello world app is a button that counts its clicks, a counter button.

So that makes a lot of sense. Basically, you say here's the button and you say inside the button or off to the side of the button is the count of all click events that will ever happen on this button. Very declarative. Beautiful. So let's say I want a multiplayer button. Anyone who loads this app on their screen should be able to add to a global counter variable. So basically, what you want is to be able to take this event that's on my computer, the click events and lift it to a

a cloud based click event that like everyone can get access to and then sum over then count the clicks in that thing um it's a hard thing to explain and i part of partially is because i have a very hand wavy understanding of it but i'm excited about it and i talk more about it on my website and my log and other places so So anyways, that's point number five, rid ourselves of the IOMONAD. Point six, we must have an editing experience that's lively and fluid. The mathematical abstractions we'll need to rid ourselves of the IOMONAD and build denotative languages scare people, partially because their UI stinks, partially because the abstractions are complicated. So this is a very difficult UI problem to build this programming experience around denotated languages,

but it's tractable. It may be one of the most complicated user interfaces ever created itself, but it's possible to build. Okay, so the next section is vague dream programming language system. So I'll just read some bullets. It's a Haskell-inspired structured-ish editor in the style of Lambda, early Unison prototypes, Luna, Isomorph, etc. This UI problem is large and unsolved, and it will likely be one of the most complicated

UIs ever created. Eventually, bootstrapping it would be great because the goal of this tool is to be able to build user interfaces, so you might as well build it in itself, and then of course people will be able to make it better and more customized for what they want, which is the whole point of the project. Okay, so web-based. So it'd be great if it could run entirely in browsers, but it wouldn't be the end of the world if it had to communicate to some server in the back end

to do some processing or whatever. Maybe one day it'll compile to WebAssembly. I don't know um it recently occurred to me that this vision will require i think moving past the web html css and javascript and all the web standard stuff partially because it has such different goals from the web, it's trying to be so much more peer to peer as opposed to like what the web is now, which is like Silicon Valley makes things that everybody else uses them.

There are a lot of peer to peer internet projects happening now, like Dad and Beaker Browser, some blockchainy stuff. And it's related to that, but it's different because the security model right now is very restricted because the code is so complicated that we can't expect people to read it and understand it. So we need to protect them from themselves, from installing something that they don't know what it'll do. But in this world where we want to give people the autonomy

to build their own things, the security system needs to be a little bit more permissive, but also more typed somehow because we're really concerned about denotative languages so anyways that that's one reason and another reason is i was recently given a tour of pharaoh and the glamorous toolkit by tutor gerber and um he made a really good point that if you want a system that's truly moldable, it needs to be created in a single render tree. The single render tree concept is a point that I don't really understand why it's important, but it feels really important to me, that we need to blur the lines between apps. So if you've ever seen the Alan Kay steps project, or maybe early small talk stuff, there aren't really clear distinction or boundary points between apps, like the whole system is

cohesive more. And there are definitely pros and cons to this. You have less polished single purpose apps, but you have more composability between little tools. In the past, it's always been done in a way that to me felt very, very messy, like overlapping windows, just text that can side effect anything, anywhere, context everywhere. It felt like a mess. But I think it can be done well with strong types and a right focus on making it be really comprehensible somehow. So we're blowing the line between apps, but we're having strict lines on types. All right. Another point is definitions or expressions will be hash based in the style of Unison and maybe IPFS. I want to really take immutability seriously. And it's crazy how you edit a Haskell program

by mutating the text. It's crazy. If we're going to take immutability seriously, we really got to take it seriously. But on top of this immutable, like expression-y world, I guess we probably need a mutable naming system. So like I make a website and then I want to make a change to it. And the hash will change because

it has to because the definition changes. But I want some sort of consistency of identity. So like it's still my website. So I want whoever wants the newest version of my website to get the new version not not the old version so so maybe a naming system in the style of dns or something more modern or peer-to-peer where specific people get rights to assign names to hashes and reassign them whenever i i don't quite know how that'll work out open research problem next bullet uh so live programming in the sense that terms are evaluated immediately even if they're incomplete in the sense of hazel so here we're entirely blurring the line between

running and stopped codes code like your code is just running all the time in pieces there's no such thing as running code uh any any more there's running or pausing a google doc you can you can look at a google doc you can close a google doc you can delete a google doc but you can't run it or stop it from running and so i i think i like that metaphor for this you you you have code and it just runs or if something refers to it is is like on the screen or or in you somewhere it'll it'll run so you have to kind of like disconnect it or something if you want it to stop. I'm very vague on this sentence, but it feels important. Of course, we don't want people to not be able to stop code

that needs to be stopped. We'll allow that. But I think the metaphor of like you wrote some code, you have to press a button and then it runs and then it stops when it's done, that should go away. The way I think about this is kind of like you're coding in pieces. I don't know if you've used a Photoshop app or Sketch or something where you have this big open infinite canvas and you have different pieces of your designs in different places on the screen.

You can kind of scroll around and drag things around. That's kind of what I'm imagining for code. And I'm getting this from jason brennan he has a app platform he calls beach where where that's kind of the metaphor of like an open infinite canvas all right last bullet actually i have two more working on something new doesn't break anything existing changing a definition only produces a new definition we are given the option to update old hashes to the new definition if you wish so it's a kind of a garf actoring tool so if you have a whole connected tree of definitions and

you change one in the middle um it'll say like there are a lot of things that depended on this old hash do you want to create copies of all the other definitions and point them at this new hash and all the things that you'd want? And I think Unison is dealing with a lot of these research problems and maybe they'll be able to help here. It's complicated, but I think it's the right framing for version control and collaboration. And then I think I said this before, but to reiterate, we're entirely blurring

the line between front and back end coding. We were collapsing the distinction to one of, you know, my computer and, you know, data from elsewhere, or like cloud data. Computation can happen, you know, anywhere you want. And maybe you have to like put your credit card or something in in the code somewhere in order to make the computation happen on someone else's computer or in the cloud, something like that. So now there are four big problems in order to make this vision a reality that I've talked around in the last text, but I'm just going to make them explicit now.

So number one is ridding ourselves of the IOMonad. And now 1A is user interfaces. 1B is backend users, databases. Basically, we want to rid the IOMonad from everywhere. Number two is collaboration version control branching. And that's what I've been talking about recently about hashes and names and that kind of thing. The hashes and the not be able to change thing, that's also related to number three, the programming experience. And I mentioned before, given how difficult it is to use denotational languages without the IOMONAD, the types and abstractions are so complicated, we're going to need to spend a lot of time thinking about a really good programming experience in order to make these things usable by millions of people, programmers and people who want to learn to program.

And then the fourth problem is adoption. and people who want to learn to program. And then the fourth problem is adoption. So we have this beautiful system, and how do we get people to use it? And particularly the issue is if we make it its own world, kind of like Squeak or Pharaoh or the Lively Web, Lively Kernel systems, those systems tend to be isolated systems that only a handful of devoted people use, and they don't spread out to the rest of the world. So how do we break out? So here's one idea I have.

We start with a killer app. And so people often talk about that in order for a platform to succeed it needs a killer app so microsoft had um i think it was microsoft had um like a spreadsheet app lotus lotus notes i don't know if it's microsoft maybe it was ibm someone had a spreadsheet someone there was a new operating system that was created and then lotus notes is why people bought it and so for the internet people say that the killer app was email and so i think it may be a little bit too cute to say this but i think we could steal the internet's killer app of email and here's why i think so. Everyone's email workflow is specific. And it's a huge part of how we all run our lives.

Being able to customize things to exactly how we'd like them would be a superpower. For myself, I'd like to be able to combine my email app with features of task management applications, such as reordering items, nesting items within other items assigning them to people emailing them to people basically i want my inbox to be real like really like a kit of like you know i can i get incoming emails i can drag them to wherever i want elsewhere in my computer i can reply to emails in a nested nested thing somewhere else i i want something that looks a lot less like an email app. And basically I want my email app embedded in all the other tools I use to manage my life.

And I think that this is why we've all struggled so much to find systems that we like. People are constantly looking for new note-taking apps, new to-do list apps new email apps because they're all isolated and what we really want the solution that will all we all want is something we can build our own workflow that merges all the tools that run our life to suit us best so part of the inspiration for this killer app idea is that Google inbox my own preferred email client is being shut down in

a few months by Google. So people always talk about how Google does this, but this is the first time it's really hit me really, really, really hurts. And then now I finally have learned to, you know, not, not trust Google or any, any company that makes apps because the economics of building apps are crazy. It's so cost intensive to build a quality app that you need to get millions of people to use it to justify the cost of initial and maintaining the development of it. It's really, really a sad state of the world we live in. And we're all going to have lowest common denominator software because of it. Because it needs to work for so many other people. The only way to maintain quality, personalized experiences is with a crowdsourced development platform. And that's what we're trying to build here. That's the whole mission.

And initially, I imagine we leveraged Gmail's API to do this and, I don't know, trying to take shortcuts. Okay. Now I have a how is this different from section. Kind of messy. But basically, I compare my vision, my dream system to Unison, LAMDU, Luna, Isomorph, and Dark. Because those are also Haskell-inspired structured editor things. The main difference between what I want to build in all of those systems is that I'm focused on the construction of user interfaces and none of those

systems are focused on the construction of user interfaces. I'm also really concerned about this moldability of your own programming, your own computing environment in the Pharaoh sense, and none of those, I don't think are really focused on that. One open question is, given that we don't want to expose IO to the user at all, how do we enable developers of this tool, this like dream tool, to write, how do we enable them to write abstractions over IO, because that's necessary, that's going to be necessary. So one way to handle it is we could use the i o monad like haskell maybe and like a lower levels we could have like a few different levels

i don't really know that that's that's an open question okay so so that's my about page thanks for bearing me. It only took 40 minutes to read it all, when I'm sure it would have taken you a lot less time to read it yourself with your eyes, but this way you get a lot more context. So hopefully you enjoyed it. Okay, so now let's go a little more chronologically so in the past few months they've been good i'll start with that i um so let's pick up where i left off so the last reflection i was just finishing putting the finishing touches on my paper about frp that i was going to submit to

rebels explicitly comprehensible frp so good news paper was accepted um great news actually it was really fun to prepare for the talk and give the talk and get some feedback it was all wonderful so i um the talk was accepted they gave me some really good feedback from the reviewers that i incorporated. And then Jonathan Edwards came up with the idea for me to record me doing the talk with the slides and then sending it around to a few friends. And then we all got together and Jonathan Edwards led a writer's workshop format feedback section where I stayed quiet and just took notes. And everyone else talked about the good and bad things about it and how to make it better. It was really, really well done. So thanks, Jonathan Edwards, for organizing that and also, you know, for making this paper happen without Jonathan's mentorship. I wouldn't have known to write the paper. I wouldn't have known where to submit the

paper. None of it would have happened. So thank you, Jonathan. And also thanks to my friends who joined for that feedback session. Jeffrey Litt, Ivan Rees, Joshua Horowitz, and Jonathan Edwards for organizing it. And thanks Glenn Cacchiari for his notes separately. Alright. So I think in the last research recap, I said that I might read the final version of my explicitly comprehensible FRP paper on this podcast.

I don't think I want to do that. The talk version is on the internet. The paper version is on the internet. The slides are on the internet. futureofcoding.org slash papers slash something. If on the internet futureofcoding.org papers slash something if you just type future of coding.org papers you'll get there or if you just go to future of coding.org it's right at the top i'll just do a quick summary basically i i complained about the elm architecture which has since gone on. It was started in Elm, but it has since gone on to inspire React, Redux, Vue, Vue.js, and Cycle.js on Unify.

So the thesis of, or the point of my talk and my paper is that FRP has become really popular in web development these days and mobile development. Basically, UI development is dominated by FRP. And the industry seems to have agreed that the Elm architecture is the solution. Let me describe the Elm architecture briefly. It's characterized by a single state tree, where all the state free application is stored in one object. And then the view, the way your app looks, the HTML or whatever, is a pure function from that tree to something like HTML value, that state tree to some DOM tree. And then your view emits events, which are then pattern matched on by this reducer function so the reducer function takes

the previous version of the state the current value of the state and an event from from the view and and updates the view you know it's immutable but it but it's updating the view it's producing a new value of the sorry a new value of the state one one tick forward in time so if you have a counter the value the initial value of the state would be count counter zero that would be passed to the view which make a button with with zero in the button the button would have a on click event it would emit a at like a increment event and then the reducer would say oh oh, when I get an increment event, take the old value of the state, add one to it, put it back into the counter piece of state. If you don't already understand the Elm architecture, that's not really going to help you. But hopefully that was a good

summary for those of you who already understand it. So the industry of user interface people especially in like silicon valley have have gone have kind of circled around this elm architecture single state state tree plus reducer way of doing things and the point of my explicitly comprehensible frp paper is to say that that's not a great solution that solution is very very similar to mutable imperative programming it's not really functional programming and um the point i make is you have global state it's basically mutable and basically anywhere in the code you can emit a thing that will change a piece of state so it's really hard to understand how pieces of state behave over time. Worst of all, it doesn't force you to be explicit about which pieces of state depend on other pieces of state

and which pieces of state, by their absence, are independent of other pieces of state. So this is a really important thing. So going back to my overall mission, we want to make the comprehensibility of large software quick. We want really fast comprehensibility. Particularly, you're using a big application to do something with your life. You want to change a small part of it.

You don't understand the whole thing. You don't want to understand the whole thing. You just want to change a small part. So in order for't understand the whole thing. You don't want to understand the whole thing. You just want to change a small part. So in order for that to be possible, you need to be able to really quickly determine which parts of this large code base are relevant and which parts are irrelevant to the change you're trying to make right now.

And so given that the code is thousands of lines, thousands or tens of thousands or millions of lines long, you need the computer to help you automatically make that determination. And the you need the computer to help you automatically make that determination. And the only way the computer could help you is if we've been explicit in the code about which pieces of state are dependent and which pieces of state are independent of each other.

So that's why this is so key. And that's why I'm very bearish on the Elm architecture. No, bullish. I don't know. I'm not excited about the Elm architecture. No, bullish. I don't know. I'm not excited about the Elm architecture. So what's the alternative, you ask? Thanks for asking. So I think the alternative is to go back

to the original FRP conception, the original conception of FRP that Conal Elliott came up with, with Paul Hudak in the 90s. And in order for us to do this, we need higher order and cyclic streams. So the justification of why we need higher order and cyclical streams in order to escape

the hell of the YAML architecture, that's a complicated point that I haven't even fully convinced myself of, but just assume it to be the case. So we need higher order and cyclical streams. And those really aren't around very many places. After a lot of searching, I found them in Haskell in this library called Reflex, which you can use for web development via the GHCJS compiler. But it was a real pain. I love Haskell, but it's just getting it to install and run and

compile, it's just kind of a nightmare, particularly just the feedback loop. I write some code in Emacs because I have to be in a shell, whatever, because I use a Chromebook, so I can't compile it unless I'm like SSH somewhere, so I write my thing in Emacs, I save, I use Emacs to go to another buffer thing and run my code and wait three or four seconds and then tab over to a new window, refresh the window. It's a nightmare. Like 10 seconds between feedback loop cycles, it's a nightmare. Even just for things like syntax errors. so um as an aside i after this project i actually just just just last week i went around trying to set up a better haskell development environment for myself i went around offering haskell developers money to help me set it up

in a way that would be more fluid and live. And nobody could do this for me. I asked on Twitter. Basically, it's a chimera, a fluid Haskell experience. People talk about it, but I'm dubious it exists. Or maybe it exists, but it takes so long to install all the things and the dependencies and fix all the bugs that once you've done it once on your computer, you don't want to do it on someone else's computer. It's not a repeatable process. Maybe I'm wrong. If I'm wrong and you're listening to this, please let me know.

I'd love to get that set up. But luckily, I found a good alternative, which I'll talk about in a second. So anyways, back to explicitly comprehensible FRP. If we use higher order encyclical streams, we can regain the comprehensibility of regular old functional programming. In other words, when you read some code, you can be sure that the definitions you're reading are definitional. Nowhere else in the code can side effect the definition you're reading to change it.

If you want to understand a piece of state, you just read its definition and the definitions of the terms it refers to recursively. That's it. Explicit data dependencies and explicit data independencies, which is what's needed for global code comprehensibility in a quick way. Or piecemeal comprehensibility in a quick way. Okay, so that's explicitly comprehensible FRP in way too short amount of time. So go on the internet if you want to know more. So as I was saying, Haskell was just a pain. But luckily in the last few days,

I found this library called Turbine. So it actually, I'd seen it a couple months ago, but I passed it over for some dumb reason. But luckily, a few days ago, I popped on Twitter to waste time and I was thwarted. My time was used very productively because right at the top of my Twitter feed was Conal Elliott praising an essay written by the framework creator, Simon Vindham, of Turbine. And so I read it and revisited it. And I was like, holy crap, this is exactly what I'm looking for. And so I played with it for a few hours, and it was great. Really, it's similar to Reflex. There's a few things I like about it less, but it wins by a

mile, simply for the reason that I was able to install it in like two seconds. I still need help setting up TypeScript, but I was able to install it without TypeScript for like two seconds or very quickly. And then on every keystroke, it'll reload the page like instantly. It's so quick to compile and run it. So for that reason alone, it just warns me about syntax errors. It warns me about silly errors. It's just so much, so much better. So that was a really big win. And I have since emailed Simon about maybe collaborating. They need documentation.

I need help setting up TypeScript. I need to be able to figure out how to inspect my streams better. There are a lot of little low-hanging fruit things that could really improve the library a lot. So I'd love to help with that somehow or collaborate on that somehow. So we'll see if we can get that set up. But he seems to be busy with schoolwork and stuff because he's in school, I think. So in the meanwhile, my next steps in this thread

of removing the IOMONAD from UI is my next steps might be with Turbine to build some sample apps and just get more and more used to the library. There's this wonderful project called Seven GUIs, which is kind of like TodoMVC, but even more legit. Instead of just TodoMVC, there are seven tasks. project called seven guis which is kind of like to do mvc but even more like legit i get like they're instead of just to do mvc there are seven tasks you know i really love to do mvc because it it embodies a lot of what's hard about ui programming but uh seven guis is also good um so maybe i'll build some seven guis things or play with the to do mvc

or or think about what a DevTools extension for it would look like. Maybe I'll write some documentation or something. He sent me a tutorial that he wrote, so maybe I'll read that. Things like that. Next steps. Okay. Okay. So once Turbine is in a decent spot,

and I feel like I can use it to actually build things, the next step is to build something. Build what you ask. So remember that programming experience thing I was mentioning before? So once we remove the IOM monad from user interface construction what we'll have left is a really beautiful way to build user interfaces but it's really hard to use so even after i i make all the improvements i want to make to turbine programmers may be able to use it, but not most people. And it's like, you know, programming is needlessly bad, especially because we have all these

wonderful abstractions. We should be able to build some sort of wonderful programming experience on top of it. So I'm calling this prototype P4. I built three prototypes in the past, approximately three prototypes in the past. For quick summary, the first prototype was blocks for jQuery. The second prototype was blocks for React.js. And the third prototype was a structured editor for JavaScript, which I called Rose. The first two I called CycleV1 and CycleV2. And then this is P4. All right. So I spent a little bit of time working on p4 in the last three months

this may be a little bit surprising to those of you who listened to the last research reflection and thought where i said that i was going to be working on this sort of thing like visual metaphors for streams full-time uh but i that didn't quite happen the way i expected for a few different reasons. But one of the main reasons is that I don't really like drawing things, or at least I need to come up with a better way to encourage myself to do it. But really, the main reason was that it's quite difficult to build a editor that is direct manipulation-y. It looks like buttons.

You can drag them and whatnot and change their color, but also abstract. And so what I mean by abstract or expressive instead of abstract is that if you want a system to be fully programmatic, anywhere you put a widget like a slider number or a picker, anything you put like an interface, a UI thing thing i need to be able to put any expression there like fully nested as deeply as possible so basically what you realize is basically i just want expressions everywhere and occasionally some of the expressions could be represented as ui but

you need to be able to like get rid of the UI and just put another expression there. So that's kind of like, like Brett Victor scrubbing idea. So you have a regular programming interface, but then the numbers can be scrubbed. So that's kind of where I'm at now, we have like a regular programmatic interface. But then like if you have a color, obviously, it's not just a color, it's a color picker, like if you have a color literal, so all the literals in your system are interfaces that can be deleted but everywhere else it's expressions that's like my new thesis i don't know if that'll be the best thing ever but that's a good place to start and then streams in the past i thought maybe streams could be something that we like interact with maybe but right now i'm thinking

again they could be like annotations to the code to like illustrate how the expressions are working. But you have text-based expressions. That's like the main way you look at the code other than looking at the output. So then if that's what it's about, then I guess I'm in projectional editor land. And so that's why earlier in this episode, I talked about Luna, Lambda, Isomorph, Dark, etc. Unison, etc. Okay. Yeah, I guess I already spoke about a lot of the things for P4 in the dream section of my about page that I already read here.

So I can kind of skip a lot of that. One extra note I see here is that the fast feedback loop is really, really important. Pretty, pretty straightforward. The term live comes to mind. It's a term, live programming, it's a term that we use a lot. Sean McDermott used a lot. He actually quotes the original guy who came up with the term, but I forget his name. But what live is about, at least to my current memory, is it's about when you make an incremental action, you get an incremental result. And I think that that's really important for fluidity, the feeling of fluidity and the

feeling of flow. You make a thing, you see something. You like press a key on a keyboard, you make a click, you see something immediately as soon as you do anything. Even if it's just, you know, a loading icon or something just to tell you that the action you took had a semantic meaning. We heard you, you know, it helps you feel heard another note i have here is that types should feel like guides not like they're yelling at you like referees that's a really important distinction because all statically typed languages that i've worked with they allow you to write code and you hit a button and then they yell they yell at you so it's like the the compiled button is the like yell at me now button which is really an annoying button. I think what you want instead is you want an environment where it lets you do dumb things

from a type perspective. But it warns you. It's kind of like underlines your mistakes in red, like when you're writing in a Google Doc or whatever, and you spell something wrong, it'll just underline it in red so you can come back later and fix it so the main selling point of types is that they're automated reminders for you to handle all the cases you forgot to handle that's the real selling point of types and so that's a selling point they're just reminders they should be like off to the side they shouldn't prevent you from doing what you're trying to do. I think that's really important.

Let's see. Here's another idea. So in this P4 system that I'm trying to build, and I'd probably build it with Turbine or something like Turbine. How do I start? What's the first thing that I want P4 to... What's the first thing I want to be able to build within P4? What's a motivating problem? And so I have all these UI problems that are... The true motivating problems for P4 are 7 GUIs and to do MVC. Those are the true motivating problems for p4 r7 guis and to do mbc those are the true

motivating problems but it might make sense to not start there because uis are complicated higher order and cyclical streams they're really tough so it might make sense to start with pure fp problems like drop the reactive bit again and just just work on like data transformation problems joshua horowitz recently um well he presented it live and then recently published on the internet a project called pain which is is very much in this spirit it's it's very haskally it's data pure data transformations and so maybe i could take his problem statement as my own build like a user interfacey thing for for pure data transformations that's also very live and shows you the intermediate data etc maybe i can even draw inspiration from paint

and then once i've done that i can maybe build up to higher order and cyclical streams the the difficulty in in that strategy is that i'll build something neat then it won't scale up to higher order and cyclical stream so it's it's i kind of have to really have the higher order stuff in mind while i'm doing the lower level things yeah it's hard and i think the key is or like a key realization i'm coming to, is that abstractions are really complicated and they're varied. And that's why visualization is so hard in programming. But if I stick to text as my UI,

then I can represent any abstraction in text. So that's kind of a good cheat. So basically it's the idea of all those other prototypes I keep talking about. You, like Lamdu, for example, you have the text there So that's kind of a good cheat. So basically it's the idea of all those other prototypes I keep talking about, like Lamdu for example, you have the text there and you can have visualizations or like live data annotating the abstraction, the core abstraction.

So that's kind of my current approach somehow. The next section of my list is the multi-node FRP, removing the IOMoned from the backend. But I kind of already talked about it in this podcast, so I'm going to go ahead and leave it at what I said earlier, basically like lifting events from one computer to multiple computers. I'll tease you with one other bit of hand-wavy nonsense. And if you want to know more, I actually have an issue on GitHub Issues for this episode.

It's on my website somewhere. You can find it. You can email me. But I'll just tantalize you with one other tidbit of multinode FRP that I've come up with. So denotationally i have a question for you what is a user what is a user so the first thought i had was users are well this thing you have to create so like on every website i go to i like go and create an account because what's the denotation of creating an account and it hit me stop thinking like a mutable ninny. Yeah, stop thinking like you're programming in

Java. Creating in a thing is very, very mutable. It's a mutable idea. So I threw that away. What is a user? And so I came to the conclusion that a user is a way to identify oneself. It's like an ID. And it's a way to authenticate oneself. It's a way to verify that the thing I say is truly tied to the ID that I purport to have. That's what a user is. And if that sounds familiar, that's because it is. That's a public and private key cryptographic pair. That's like the ideal denotation of a user. It's a private key,

comma public key. It's a tuple. Was your mind blown? So that's what a user is. So if I have a public key and a private key, and I want to set my username, so now set sounds mutable, but basically what I can do is say i can sign a statement saying my username is x with my private public key and then everyone knows that's what my username is and in the future if i say my username is y then they know my username was x and now it's y so so that's what i mean by set and it's it's a stream notion of set you know i'm not setting anything i'm just updating you know the stream has multiple values based on the value of time so anyways um i'm really excited about this abstract notion of user as just a private and public key um if you're creative you'll realize like holy crap

like if that's what a user is then we can say goodbye to all the crazy, annoying notions of creating different accounts for different services. Like we can literally delete that. You go in your browser, you paste your private key, you paste your public key, and then you can go around the internet just trusting that everything you do is identified as you because like your browser just you know has the information to sign all of your actions as you you never have to log in again you never have to create an account again you never have to change your password again you know obviously there's some issues with with security and whatnot but i think it's a really cool cool idea of just getting user is. Cool. Okay. So that is multi node FRP, removing IO from the back end. All right. So another point is version control. I mentioned that that was one of my big problems in order to accomplish this mission. I haven't spent very much time at all thinking about this but i did create

a prototype um actually you know that should probably be p4 but um anyways that one has a name it's a wolf wolf js workflow you can find it on my website futureofcoding.org um it's it's it's a really neat i think exploration of of what version control would look like. It's very fluid. I think I've explained it on this podcast before. I think, yeah, about a year ago. Instead of using Git with normal branches, imagine an infinitely nestable bulleted list. And you're just editing this list as you would a text file.

But it's actually branches of code. Yeah, so part of what I think that enables is collaboration multi-levels deep. Because right now in Git, pull requests are really just only off of master. We don't have multi-level deep pull requests. I think part of the reason is the tools are not fluid at all. You can't merge things. You know, it's just, anyways, that's its own point.

If you're interested in WoofJS Workflow, kind of rewind the podcast to that episode or go check it out on the internet. That's not to say that WoofJS Workflow is the answer to version control for this system. Not even close. WoofJS Workflow is just one experiment. I'd love to see more version control ideas of the future. I've only seen a very small handful. There's this website, like Elements of Change, where someone was focused specifically on the version control problem. I'd love to see more people focus on this problem because eventually I'm going to have to focus on it if nobody else does.

And that would be annoying. But yeah, it's a really, really interesting problem. Hard problem, version control. And yeah, maybe there's been interesting work on it. You know, clearly Git isn't the answer for all time. So if anyone knows of good research on the future of version control, send that my way. I am all ears. It's at this point in the podcast that I'm realizing that you might think that the, you might be confused as to what it is that I'm building, like the goal.

So I've mentioned that, you know, I want this system that's kind of like wikipedia for software where anyone can can change things blah blah blah and or do that we need to remove the i o monad blah blah blah blah okay so so if you got all that then great job you've been listening well but you may be confused because i have this thing p4 and you're like well p4 the thing you want to be that beautiful system the answer is probably not p P4 is just a prototype to point us in the right direction of removing the IOMONAD from user interface construction. Just as WoofJS workflow was a prototype to point us in the right direction for version control fluidity.

They're just prototypes that continue to point me and get me closer and closer to this overall dream platform. Maybe at one day, at one point, this, a given prototype will morph into the dream platform itself, you know, just, I'll just iterate, you know, I'll get close enough, it'll happen that way. But I really don't know, I don't think I'm close enough that P4 will be the one that mutates and morphs its way over the finish line. Okay, so now I'm going to take a pivot and talk about sustainability. So I think it was Jeffrey, maybe it was Ivan Reese.

One of my friends was saying that they were a little bit confused about my life setup. You know, like, it's clear that I, you know, do this podcast because you have ears, you can hear me. And it's clear that I do some research on my website, if you follow my log. But it's kind of unclear how I do these things, if I have a job where I live. So I'll just take a minute to talk about that. Up until two months ago, I lived in New York City for the past three years. I did the coding space for two and a half years. and then I did this for like a year in New York City by myself. And then, yeah, two months ago, I moved to London where I'm speaking to you now,

live from London. It's actually like a live construction site. So if you hear construction in the background, my apologies. I'm right near Buckingham Palace, actually, near Victoria. It's nice. I'm not that excitedingham Palace, actually, near Victoria. It's nice. I'm not that excited about the gloomy weather. It's not fun to run in.

So my girlfriend and I have been talking about fun, warmer, sunnier places in Europe to escape to. So I'll let you know how that goes. So that's where I live. In terms of a job, I have none. No full-time job the way my life is set up is i think about it in three parts i have my research which is the main thing i want to work on my main goal number two i have the podcast which has become increasingly important to me but it's really it was really started with the spirit of you know i'm going to have these

conversations anyways i might as well record them i want to reflect on my own research, I might as well make it a thing that I record and share around and get feedback on. So it's very much like an addendum to the research, which is the core of my work. But, you know, if it continues to grow, and the audience grows, and the quality grows, and maybe it could become more of a central central part of what i'm trying to do because i really um don't believe that i'm the only one with the answer or i'm the one who's going to solve it um and i'm gonna have a bunch of little helpers i i think it really like the whole mission is is that everything should be much more community driven and so so I think the podcast fits, the podcast and the way I've been sharing things

really fits that vision because it's saying, I want feedback on my ideas to make my own ideas better. But if you could take my ideas and run with them and do beat me or do better what I think or whatever, basically go, just do it. You don't have to ask permission.

Just take my ideas and run with them. Fork, fork, fork my ideas. And, and if, if you've, if you convince me, maybe I'll, I'll join your project. You know, that, that sounds great. Collaboration is the way to go. So my research is important to me, but I think the podcast could also gain an importance if it, if it continues to do well and gain a following. And number three is freelance.

The third part of my life is paying the bills. I found a pretty neat gig for my old company, First Round Capital. And so I try to work a few hours there every week and make money to pay the bills. So we'll see how that goes. So the next section that I want to talk about. So speaking of which, so I have these three parts of my life and I've been finding the balancing of them to be hard. In that I really do enjoy all of them, research, podcast, and freelance, for different reasons and in different ways.

Freelance is great. It's like a video game. I earn money. I ship code. It's fun. It's just fun. The podcast, very easy to put a date on the calendar, prep, record, edit, publish, get people excited.

Podcast is really fun. And research, it's hard to get myself to do because research is hard. But I really enjoy doing it, particularly in retrospect. I really feel proud when I do good research. But I find that when I get in the groove of research or podcast or freelance whichever one i don't really want to stop like i i'll do like research only for two weeks then podcast only for two weeks and freelance only for two weeks it's hard to it's hard to do like two days of this two days of this one day of this and that's how i've really like in a given week and that's how i've conceptualized it i want

to do three days of research one day of podcast podcast, one day of freelance, or maybe like two days of research, one day of emails, one day of podcast, one day of freelance, or even better, I'd love to be able to split it up on a daily basis, like the mornings or research, then I do emails, then I do maybe podcast, and then maybe freelance, you know, but I found that forcing myself into a structure like that um makes me end up doing less work because i'm like chafing against these like artificial constraints when instead if i kind of like let myself be drawn to my work more naturally and maybe i'll like watch tv when i should be working but then i'll like get bored of tv and then work like for seven hours into the wee hours of the night so i'll like get more work done if I let myself do it when I want to, which is wonderful.

And it's a great benefit of working from home. But not being able to balance it is a weakness. Luckily, the freelance gig I have is very flexible. They're very, very good to me. So I'm able to do, when it's non-critical, um, I'm able to do the work when I get to it, which is great. And when it's critical, I, I, I may, I can, you know, I can drop, drop the other stuff and work on it. So, so it's fine, but it is something that I have been noticing the, this, this balance is tricky, but, but it's working. It's not to complain too much.

It's all working. I've been getting enough research done. I'm proud of it. My research, my podcast has been, you know, I've been doing an episode or two a month. I'm proud of that. And the freelance currently is the thing that I've been dropping the most of. So I should maybe next week spend spend 20 hours, 10, 20 hours doing just freelance stuff to make some money and keep the freelancers, keep the bosses happy. All right, speaking of money, I was really floored and shocked and really excited to get an email from Amjad of Repl.it. So if you've been listening closely, you will remember that I worked for Repl.it like in February, March, April, basically for like three weeks earlier this year.

But it didn't work out because I only wanted to work like 10 or so hours a week. And they really needed full time people, you know, just the way they it wasn't going to work the way they worked. So, so we just we parted ways. And I hope they found other people full-time. I'm sure they have other full-time people to do that job. And I have found a part-time job that kind of fits my time needs. So that's great. But anyways, I, it was really unexpected to get this email from him saying he listens to the podcast and he wants to support it. He, it seems really selfless. He just, it seems, you know, he says that he wants to, you know, it's partially to encourage people who listen

and are excited about improving programming to, you know, know about Repl.it and work there maybe, or I don't know, content marketing. I don't know how it works. But I think true, like in his heart, he, I think he just thinks his work is valuable and wants to help it along. And, and so he's supporting it with money, but mostly I think the real value is he's supporting it with some, some thought partnership. It was his idea to take episodes and write a, like a few paragraphs of like a blog to summarize them right at the top of the webpage of a new podcast

to kind of entice people to get them in and get them listening to it. And it really helped. One of them in particular, which one was it? I forget which one, but I did that for one of my episodes and boom, front page of Hacker News. First try. I did it for a second and maybe a third one,

and it didn't go as well. But at least one of them. First try. So that was really exciting. And I don't think I would have done that if he didn't suggest it. So that was really great. And another benefit that many of you are excited about is transcripts. The money he is sponsoring me with,

it partly is going towards transcripts so that is really exciting um so yeah so thank you amjad and um and he is is excited he's bullish bullish i think bullish means that he's excited about it he or optimistic he's optimistic that with some some focused effort we can really grow the listenership of the podcast and make it more of a thing and then if i get more listeners maybe we can rope in people uh like startups or bigger companies with more of a budget for sponsorship to sponsor the podcast and then i don't know like if i if i could get a reasonable amount of money for per episode and i did two or three episodes a month like then I could potentially stop freelancing,

which would be, or at least freelance a lot less. So that would be really, really neat. That would be really neat. Then my life setup could just be two things, my research and my podcast. So speaking of growth, I made a bit of a mistake, but I've learned my lesson. So I was approached by this,

well, actually, I kind of approached, anyways, I was connected to this research group in New York City called the Jane Family Institute. They do these wacky research projects. I think right now they're really concerned with universal basic income and the transparency of, or the understandability of AI systems and decision making and discrimination you know pretty hot topics um and so uh i was introduced to them and we we were introduced under the context of maybe you guys could come up with a topic that steve could write a blog about for the new jfi blog jane family institute blog so we had this whole hour-long conversation where i was trying to describe what it is that i do and the research and why it's important and at the end of the conversation or at the end of me explaining it is what i do the guy says have you heard of brett

victor and i was i just like broke out laughed and laughing because you know if like if i knew he knew who brett victor was and if i knew he'd visited dynamic that i would have started there um but i had like backtrack and be like i know this seems like i'm just saying because you brought him up like he's my guy like he he's he's the whole reason we're having this conversation and talking about these things um he was the original person who influenced me a lot so so anyways um i i wrote an article about dynamic land for them that I'm really proud of. I think it came out well. And we put it on their blog. It was the first article their blog launched with.

And I submitted it to Hacker News and nothing happened. Then I got an email from Hacker News saying that they thought that the article had promise. And so there's this new system where at some random time in the next 24 hours, they were going to, there's this new system where some random time in the next 24 hours, they're going to put it on the front page of Hacker News somewhere randomly. And then if it rises up on its own, great. And if not, that was its second chance.

Very excited. So I checked back, you know, every hour, boom, it was on the front page. And I just watched it climb all the way up to the top. It was really, really cool. And it stayed there for the whole day. It was, I think, my most successful post on Hacker News of all time. Really, really exciting. And it sparked a good conversation and it seemed like it was a well-received article.

But here's the mistake. I got nobody from that essay, or almost nobody. Correct me if I'm wrong. If you found this podcast from that essay, please let me know. But it seems like, based on my analytics on my website, on my podcast, nobody went from that essay to my other projects. And this is particularly sad because I'm focused on growth. And in the past, when I was successful in putting something on Hacker News, for example, the Eve, visual history of Eve that I put on Hacker News,

most of my listeners, many of you, I imagine, found me through that post on Hacker News. And so to have 10,000 people visit this essay and have zero people find my podcast is sad. And I did a bad job at my content marketing. So I won't make that mistake in the future. But the essay is still great. And if you're curious about Dynamic Land,

I think this essay, at least in my very humble opinion, I think if you can't go to Dynamic Land, this essay gives you a really good feel. It tries to be visceral and give you a feel for like what it is to be there and the vision. If you want a a more hard tax, like how does the system work at a programming level, go read Omar Rizwan's Map Kit.

Omar was on a podcast. And if you listen to the podcast I did with Omar, you might not have to read the essay because the essay I did is really kind of just turning what Omar said into just recasting it in my own words. I don't really have any new ideas there. I like steal his metaphors. I steal everything he says.

So Omar is great. And his essay is the one to read if you're looking for how does it work. And the how does it work stuff, it's relevant because if you're a programmer, you can kind of think about, think through how it works to understand the vision. But you have to be really careful because someone like Brett Victor and Brett Victor's lab, the deepness of their thoughts is hard to overstate. Like the vision is so rich and so complicated that you really can't. It's so hard to see through the technology to the vision. But that's the whole point. The point is in technology, the point is that they're pointing to this vision that's beautiful,

but far off. And the technology is the best way they can point towards it. So don't get caught up on the projectors in the ceiling. Don't get caught up in all the little details. Just understand the details in order to better see the vision so that's my my one bread victory plea he's always saying things like that all right um all right now back to back to money um i um have been encouraged by a few people recently to start a patreon and i was thinking i was going to do this about a year ago i was inspired by the success of nikki case to do this a year ago but i was convinced otherwise and what i told myself silently was that when when my listeners or whatever i'm not when you guys my my collaborators my friends asked me to set up a patreon that's

when i would do it i would wait for the first person to say, I want to donate to your work. Where do I donate? And someone did. Someone explicitly asked that question. So thank you very much, Ruben. I think his name on Twitter is Ruben Sandwich. I don't know his actual last name. So yeah, thank you, Ruben. So I'm going to go ahead and set up this Patreon probably in December. I'm thinking that it'll be a good project for me to do in the week that I'm home. I don't know, maybe I'll do at some point in the next couple of months. It is a priority. And in combination with people supporting the podcast, like companies sponsoring the podcast, this could really go a long way to allow me to stop doing freelance work and make this work sustainable full-time and long-term.

So I'm really excited about that. Thanks again, Reuben. And yeah, we'll see. We'll see what this Patreon lifestyle will look like. So if any of you are so inclined to contribute, I don't even have the words to say how thankful I'd be. I'm literally tearing up now just thinking about everyday people just giving me money because they value the work I'm doing.

So in other words, there's absolutely no expectation that anyone listening to this would um would give money um there are many of wonderful things on the internet that i benefit from that i don't give money to there are a few that i do give money to uh nikki case um is one uh psycho js is another one it's kind of random uh what what you give money to on the internet because we we all get so much benefit from so many things. But then sometimes somewhere we're just so inspired to support something that we do. So anyways, that is to say, it's only a positive.

Don't feel any obligation to give money if you don't have the means or whatever reason you don't want to. But if you do, I'd just be just be so, so unbelievably thankful. So. So yeah, so that's, that's that. Oh, I guess one relevant quick note, is that when I've given in the past, it's very much out of like, a generosity, like, like, like really a patron spirit, like, I'm like, I want to be supportive. I want, you know, it's just something that's meaningful to me in my heart. And I want to like, you know, part of it is I want to be able to tell

people I give, like I just told you guys that I, who I give to, you know, it's kind of like a signaling thing, but, but more, it's just like, it's, it makes me feel like a bigger person to get to be a small piece of something that I think is, is important and needs to be in the world. So that's like my motivation. And so like the little trinkets or like incentives to like, well, if you give this much, well, I'll give you this kind of swag or whatnot. I think that's kind of not the spirit in which I see it. So I'm not going to waste too much time with those sorts of incentive-y things.

I prefer to just give away everything for free, you know, transcripts for free for everyone. I just want to give everyone everything for free. I listen to Sam Harris's podcast, and he's started recently putting things behind his paywall only for subscribers. And it really bugs me for two reasons one part of why i'm giving him money is so that i think he's someone else i support part of why i'm giving him money is that most of his content not all of his content but most of his content is really good i want it to be out there in the world for people to benefit from and it's like goes against why i'm giving money for him to like block it from some people and then also when he blocks things it makes it a

worse experience for me i have to like jump through all these hoops to get to the um content that only um supporters can get i'd rather just have it be easier and have everyone access to have access to it so anyways if if any of you who are thinking about supporting um would prefer to like get some sort of a benefit for supporting or or if you disagree with this this thesis of of uh generosity patreon blah blah blah please let me know i'm really open to feedback here um yeah basically anywhere anywhere always i'm excited to hear anyone's thoughts i'm like anytime i get an email from a stranger or or someone who's emailed me in the past makes my day um so it goes without saying but especially for this patreon thing i'm a little nervous about it so if you have thoughts i am all ears um okay so i'm realizing now so i'm realizing now that i i've forgotten two sections chronologically so maybe

i'll splice them back into the beginning of this podcast or if i'm lazy you'll get them here at the end so one is i went to splash to present rebels and then i was also there for the whole week and it was really really fun i don't think i've ever had such a fun time uh like in a trip a travel trip i don't like traveling i don't like planes i like had such a fun time, like, in a trip, a travel trip. I don't like traveling. I don't like planes. I like my routine. I like staying at home and having my computer and food.

You know, I like just doing things the way I like things done. And I don't like going to a new spot. I like going to a new spot and then staying there for months, you know, because once I get my setup that I like, I want to benefit from it. But anyways, I don't like traveling usually but splash was amazing I got to meet so many really wonderful people yeah so I I was I was thinking about reading a list of all the wonderful people I got to meet or at least spend time with but that's a little bit crazy but I have that list somewhere on my website so if you're curious about the people,

it's like 20 or 30 people I met and spent time with. So, so cool. And these people are just like Jonathan Edwards and Sean McDermott. Okay, now I'm listing names. But really great, really, really great. And it was fun to get to bump into people from the internet, like Will Crichton, who it's like,

oh, I've read your things. Oh, like I know you from the internet too, great. Like now we're meeting in person total just bumming into internet friends um without expecting to very very fun uh in particular a splash was really great sorry in particular live was really great so the live workshop I think was started by Jonathan Edwards. And it was it just one after another, it was like a day of blowing my mind one talk after another such such high quality. And the internet was very upset that none of it was gonna be streamed. And so I went ahead and got there early and set up my own phone phone as like on like a a tray where you like put food

like waiters will put food on it like a tray and a glass like a whole very very um bootleggy setup and i recorded the whole day um uh yeah i at first i just recorded on my phone but then it turns out that YouTube streaming is much better, so I did that. And yeah, so it's on the internet. You can go to futureofcoding.org slash, I think it's slash notes slash live slash 2018 to get the live 2018 bootleg edition. And most people have a project page, like a paper or a page that summarizes their project

better than the grainy video I recorded. And most people have since re-recorded their talk as a polished video with good audio and whatnot. So definitely don't watch the bootleg version if you can get around it. I think what most people are excited about is Chris Granger gave a talk about the lessons he learned at Eve. Unfortunately, the audio from that is out of sync. I wasn't able to fix it.

So it's broken up into like three parts. So it's kind of annoying. But what's his name? Jeremy Ashkenaz, who is a, I'm a big fan of for many, many years. Creator of CoffeeScript, Backbone.js, Underscore.js, or Lodash, I forget which one he did. And now he's working on Observable HQ. He went ahead and took that video,

took the YouTube transcript and made a observable notebook out of it with embedded pictures from the slides. And he put that on, well, so I put it on Hacker News, nothing happened. He put it on Hacker News and for some reason, then it took off and was on the front page all day. So that was really cool as well to see something that I made in just a few hours

go on Hacker News. Really Hacker News is suckers for Eve. I can put up as much Eve content as I want on Hacker News and you guys will always upvote it. At least it seems that way. It's a cheap way to get on the front page. Anyways, that was fun. And I think that's actually doing that, putting together that resource, was when Ruben asked me to donate, to support my work.

And I think two or three other people also chimed in at the same time. It was when I put together the Live 2018 thing. So that's something that's really important for me to note, that it wasn't until I made it clear that I'm trying to support the community and be a bit of a historian for the community and document things that people wanted to support. support the community like and like be a bit of a historian for the community and document things that people um wanted to support so so maybe um maybe in order to get people excited about my patreon and supporting i need to shift some of my focus to do more more of those sorts of things

so i could shift my my focus from research to documenting and organizing this world. And I think the Slack is part of that and the meetups I'm throwing a part of that. Well, actually, let's talk about that. So since the last reflection, basically right after the last reflection, I had the final future of coding meetup in New York City. We'll we'll have more, but that's, that's the final one after I said, you know, before I moved away, it was really, really wonderful. Josh Horowitz was there. Um, um, Jeffrey lit came down from Boston to attend. Um, uh, Glenn Kaki area was there. Uh, it was just, um cory from eve skyped in to show us what he was working on jason brendan showed us beach it was just really an all-star crew and i i couldn't

have been prouder to have brought it together i i was just like to be honest i was just i i have this anxiety that when i bring so many amazing people together, and I just want it to be like, I want to make the most of everyone's time as much as possible. Because like, it's just such a valuable resource to have all these people in the same place and time. So I really want to make the most of it. So it does make me a little anxious,

but in retrospect, I'm proud. But in the moment, I was, I don't know if I was having the best time. I was mostly just worried about things. Speaking of which, tonight is actually the night of the first Future of Coding dinner in London. So I changed up the format of this one. I've organized it as a dinner at a restaurant. I booked a semi-private room. Everyone had to, before the event, buy a ticket. I set up a thing on eventbrite where you had to like pay me um 45 pounds which is really too much money but that's like the cheapest option i could i could

come up with um but um in the future i'm going to try and do it for free or much much much cheaper or maybe even get a sponsor or something but anyways for this version that's the price and there are 14 of us including me from from London. I'm really excited. I think it's gonna be a great group of people. And later today, I'm gonna, part of what I was saying, like making the most of amazing people, I'm gonna go ahead and maybe put together a seating chart

to make sure that people are seated in a good way. Cause otherwise it's like always awkward. Where do I sit? And what I think I might do is create two seating charts. So, and like halfway through the dinner maybe i'll ask everyone to stand up and go to the second one or maybe even the third one so then you can get to meet different people throughout throughout the dinner and and i can you know organize it you know beautifully mastermind this whole thing i don't know maybe

people will find that annoying but um i'm excited about this about this dinner and yeah and if it goes well i'm excited to do more in london and when i visit new york i'll do more there uh caleb uh who i met at the at the uh at live in boston at splash has taken up the mantle for doing this in boston he created a meetup page so in the past i've always organized these things on the Slack group, but Caleb's trying meetup. Maybe that'll go well and maybe we'll do meetup.com for all the meetups. Who knows? I've thought about it, but I just never got around to it.

And it kind of, with this last part, this last thing, I kind of went the opposite direction. It was like an invite only ticket thing you had to buy for. Meetup is kind of more, you just like press a button and you end up not going probably because it's like a big group and it's a talk you listen to anyways there are a lot of ways to run these things um and i'm excited to have a lot of people experimenting amjad uh of replet has said that he would be open to hosting the san francisco version of this which i think would be really cool um so close, you might as well do it at DynamicLand. Am I right? That'd be cool.

Like if I have, there's Omar Rizwan out there, there's Jan Paul out there. There's a lot of really cool future of coding people out in the Bay. So it'd be awesome to get those guys together. Man, I'd want to fly out. If all those people were getting together to talk about the future of coding,

man, you'd have to fly out. If all those people were getting together to talk about the future of coding, man, you'd have to really hold me back. I'd really want to go. Amjad, wow, that'd be so cool. The Notion people, oh, man, now I'm going, I'm going. I'm organizing this and going myself. So yeah, so it was Amjad's idea that we could turn this into more of a thing. Like I can make a website,

futureofcoding.org slash meetups, meetup. And I could like list links to all the different pages for various cities and the contact people and guidelines for how to host it and how to get your own meetup on this page, things like that. I think that's a great idea. And so that's actually, so i made a list of my i call them this

possible december 2018 regroup projects and that's one of them making that um making meetups more of a thing the patreon is also part of that regroup projects list oh uh i was also going to say that i was recently approached by aiden kaneef on the Slack with an idea that I've also been toying with in my head. But he seems excited about it. Maybe he'll run with it. Or maybe one of you will run with it. Online meetups, I think, could be a cool thing. It's just how do you structure something like this?

It's a tough question. And it's not straightforward. Part of why it's a tough question is that there are so many interesting ways to structure this that you know there are multiple right answers so you just have to pick one depending on what it is you're trying to accomplish um like one way you could do it is you it could be small like four people who meet up every couple of weeks to like you know four independent researcher people meet up to discuss their own research and just get some like social validation and you know time pressure to like actually accomplish things that that's a great idea and you could just do it privately for the full review or you could record it and release it

to the world or you could record it in a live stream and other people could tune in live and like add to comments their thoughts. That's one way to do it. Another way is just a free-for-all. You just post a link and anyone can show up and hopefully, you know, good people show up and you don't get spammers and you have a good group, big group conversation.

It would be neat if you could do it like a party where you could kind of break off into smaller group conversation and rejoin the group. I don't exactly know how that would work. But it's annoying that if you have 20 people in a group call, only one person can talk at any given point in time. That's just a waste of 19 people's creative energy. So it's important to think through these kind of design decisions. Another idea that Jonathan Edwards had was that one person could just hold office hours. Or it could be a group of people who just say, like, you know, if you want to talk to me or talk about your thing, you know, tweet back. And you could kind of build up a schedule.

And you could publicly broadcast the whole thing for everyone to watch. That would be neat um oh aiden had an idea where you could um you could kind of do it as a raffle where um like you do a future programming meetup and only only the presenter gets to talk and everyone else just watches and can contribute in the comments um but then um you know maybe some people are like guaranteed a spot to present their work but like there's one spot that's a um like a a random like pick from a hat spot he says that that's how comedy comedy clubs get uh people to show up um they they make it you know you you show up you watch everybody else and then you you hope for the chance that you get to present so that's cool

and then the people who show up more often are given higher priority in the random waiting or whatever. So that's another cool idea. Anyways, online future of coding meetups, like video, not just the text thing we have now with the Slack. Great idea that I would love to be a part of. I don't, at this very moment,

have the time or motivation to do such a thing. I think you really have to like be clear on what it is you're trying to accomplish. Yeah, but the last thing I mentioned that Aiden brought up, I think it could really be kind of like the live workshop that Jonathan Edwards organized, but like on a more rolling basis

and more like decentralized. So that would be cool to do once a month, once every other month. Finding the right time that people would tune in at different time zones would be interesting. Like 10 a.m. Pacific time, like 5 or 6 p.m. London time. I don't know. So I have a few other December regroup projects I'll just run through. Branding, Amjad suggested a cool logo could go a long way.

The website could definitely use an upgrade in terms of styling, color schemes, navigation. This podcast could use some intro and outro music and a better mic. So in terms of a better mic, this episode, I actually tried to make this mic better. I have this cheapo mic, but it only works when I get really close to it. But when I get close to it, my P's, Peter Piper P's, you know, cause it to flare up.

Anyone who knows about audio stuff will know this stuff. It's kind of new to me. So anyways, I needed to make like a mic filter thing. And so I found like a video to help that online to help me make it out of paper. So I did that for this, this, this recording. So hopefully this is the best audio recording you've gotten so far in this podcast. Maybe I'll buy a better mic, but I bought better mics in the past. I've never found one I like. So anyways, I don't want to waste money on it, but I also want something good.

Hopefully this one's better. Let me know if you have feedback or ideas. Another idea, another December regroup project is reorganizing my systems. The way I take my log is janky. I'm getting really tired of Jekyll. And the way I've been using Git and GitHub Pages is annoying. It works, and I could keep doing it for years, but it could use an upgrade. So another thing that's really important

is Google Inbox is dying in March. So I have a deadline. So I'm not worried that this will never happen because the deadline will force me to do something. But I've been in Google Inbox, I have like these lists that that i like these unorganized lists of things i need to either think about or or research two lists one is for like thoughts and the other one is for um like urls of of interesting projects that i want to look at

and i really they're append only lists i don't really go back and take things out of them so that's one issue. But really, I want these lists to be somehow more public. Probably the right format for these things is they should all be on my GitHub issues. I should just go full hog GitHub issues, because GitHub issues is pretty great. People can comment. There's like a unique URL, I could change the title, I could put them in a Trello board. I could reference them in commits. I should probably just go to GitHub issues. Obviously there are trade-offs.

GitHub issues is a lot slower than just emailing myself things, but maybe I can email myself things and then transfer to GitHub issues later. I don't know. I'll figure it out. Maybe in the past, I had these things just in text and plain text, like in a markdown

bulleted list. You can still see those on my website. They're old pages that are still like that. I haven't deleted them for posterity's sake, but they're kind of a mess. So anyways, I'll figure this out. But that's another thing I could work on as a December regroup project. And relatedly, I do have, I don't know,

20 or 30 GitHub issues already that I never check on. So they could use some love and organization. So anyways, that's that. Already talked about Patreon. Another idea that could provide some income is I could make a future of coding jobs board. I know a number of people who have companies that are trying to hire people

who are interested in improving programming, like Rebelit, my sponsor, but there are many others. So maybe I could like make a job board for those people and then if enough people visit it maybe i could ask companies to sponsor me um to like get higher up on the job board or i could i could ask for a donation like you know this person found you because of my job board you know at a like you know recruiters would charge you 10k i would appreciate a donation of a fraction of that i don't know and and it's up to them they could just say no um whatever it's a silly idea but it's it's it's

it's a thought on the whole the last three months were very very productive and most importantly very uplifting as i've said in the past as long as i keep working on this project even if i'm not using my time that like perfectly productively as long as i keep going as long as I keep working on this project, even if I'm not using my time that like perfectly productively, as long as I keep going, as long as I don't quit, I'll continue to make some amount of progress. And if I work on this project for a long enough amount of time, I'll get there. So it's really a long-term game. So it's not, it's not about, it's not a sprint, it's a marathon for, for real. And I feel that way about my own like excitement and and motivation and i also feel that way in terms of funding like i want a sustainable funding source i don't want to raise

money and then have a three-year timeline like like eve was saddled with i want to i want to do this sustainably because it's a hard problem that's important that i want to stick with for for decades anything else to mention uh i started collaborating with this guy i met on the internet dan canter on this note-taking app chrome extension so basically i realized that i need a way to take notes in a millisecond like i need to be able to press one key command on my keyboard and then be writing a note and i don't want to have to wait one second not even one second and i realized when i did the analysis all of the note-taking apps take three seconds or more some take seven seconds some take 10 seconds to load good like loading a google doc loading even notion takes

three seconds it's just unacceptable i want to press a button and take a note like i need to be able to jot something down immediately and i was only able to find one thing that did it in less than a second but um it wasn't quite what i wanted so anyways we we've started working on this this thing i'm calling it blink note because it you know notes in a blank you know or notes faster than you can blink because it really opens up in a millisecond and it uses the chrome api to do syncing and offline and online it's it's it's um it's right now it's about two or three hundred lines of code um we want we need keep it small, otherwise it won't load as fast. But it's, it's, it's fun. I, and I've been using it to take notes. So we shall see if I continue to

use and build it. Maybe it'll be a thing that other people will find valuable. Maybe I will stop and just use something that already exists. But part of why I wanted to mention this is that it feels relevant that I'm like living the vision. My vision is that people will be able to customize and create their own tools for their own purposes. And that's what I'm doing here with BlinkNote. I wanted something desperately. I built it. I use it. I improve it. I use it. I improve it. I use it. I improve it. It's very, very energizing. I've spent a lot of, there's a lot of time that I would have watched TV or done other relaxing activities that instead I've been coding on BlinkNote. So it feels like a video game.

It's really fun. And it makes me even more excited for my vision where other people will get this kind of energy about their computers. You know, it's, they get to improve their lives with, you know, with coding. So, so cool. Okay, so in terms of next steps, and what I'm going to work on the next few months, until I do one of these things again, I mentioned the regroup projects, maybe I'll do some of those in December. I'm continuing to work on removing the IOMONAD from user interfaces with Turbine and P4. Also, major thing I'll work on. Jonathan Edwards has been really great about helping me pick deadlines far into the future to shoot for so next year there is the angle brackets programming conference uh in april in italy and there is um

there are two different workshops the salon de refuge and px the programming experience workshop so maybe i'd submit to either of those. The Salon, I have to submit on January 7th, and PX, February 1st. Then in June, I have to submit, if I want, I could submit to PPIG, which happens in August in the UK. And then maybe I'll submit again to Splash. I could submit this year to Live or Rebels in June or July.

And the workshop will probably happen at the end of October in Athens, Greece. Or I could try and submit to Onward, which would be a step up for me. It's not a workshop. It's like a real conference. I'd have to submit by mid-April. And yeah, it would happen at the end of August. Sorry, the splash onward would happen at the end of October in Athens, Greece, which is nearby given I live in Europe now. So I'm feeling like my work has been very productive and I'm pulling on a good thread.

So I'm trying to keep, or I'm not worried about these dates being out of mind if i miss them i don't really care that much i'll just catch the next one um as the the picking a date is really a good way to like force yourself to you know buckle down but my research has been good so far i don't i don't feel like i need to buckle down so much. It's good to have these in mind. So if I'm close, so maybe I'll hurry up a bit or whatever. But I'll just catch the next one. I'm not I'm not so worried. Yeah, so yeah, so Turbine P4, the programming experience of removing the IOMONAD from the user interfaces. That's my next thing. And what I'm mostly focusing on, I'll work a bit on this BlinkNotes thing a bit.

I'll continue to think about removing IOMONAD from the backend. And other problems kind of on the back of my mind, but they're definitely in the back of my mind. And this IOMONAD from UIs and the PX of that is on the top of my mind. And yeah, I'm excited to get the opportunity to do this kind of work. Bye!