#33 - Reflection 14: /about

08/24/18-11/28/18

If you haven’t been following my research journey, this episode is a great place to join! I recap 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 the software they use in the course of using it.

This mission would cause the following changes, in order of increasing importance:

1. All software will be co-created by decentralized communities, rather than centralized groups or companies.
2. Through the power of crowd-sourcing, the quality of all software will become much higher than existing software.
3. All software will be much more composible, interoperable with other pieces of software.
4. All software will be arbitrarily customizable, allowing for bespoke, tailored experiences.
5. 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.
6. 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:

1. Rid ourselves of the IO Monad, replacing it with better abstractions for whole systems.
2. Create a better programming experience for the complex abstractions we create to avoid IO.
3. Reimagine version control for a world where software looks very different than it does today, with many, 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 Elliott’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!

Transcript

Transcript sponsored by Repl.it

00:00:00

Hello and welcome to the Future of Coding. This is Steve Krouse. 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 until today, which is basically the end of November, of 2018 for those of you who are tuning in to this episode far into the future.

00:00:34

And now a message from our sponsor. Repl.it 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 a future of coding and making software tools more accessible and enjoyable, so email jobs@repl.it, if you're interested in learning more.

/about

00:01:06

Okay, so it has been a really great three months. Instead of going through the three months chronologically, I'm going to start with my new about page, futureofcoding.org/about, and 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 Krouse. 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

00:01:52

Me. Hi, my name is Steve Krouse. 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 afterschool computer science program, IMACS. Through learning Logo, Scheme, Java, and Haskell in middle and early high school, at IMACS's self-paced and nurturing environment, I became a computational, mathematical and introspective thinker. I became very good at school, especially mathematics and physics.

00:02:44

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 Bret 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 math-phobes, 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.

00:04:03

So with these thoughts in mind, in July 2015, I co-founded The Coding Space in a New York city based afterschool program, where we taught kids to code in a self-paced environment, in a very similar spirit to IMACS. 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 and 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 transition, 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, et cetera.

00:05:05

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 have this brand-new programming language and everything will 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.

00:06:07

Then in the summer of 2017, I was approached by Irvin Hwang, 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 our 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/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. And I learned many other things and met some really wonderful friends that I'm still friends with to this day at just that initial meeting. So, 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.

00:07:05

It's been incredibly valuable. 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, in email, in Slack, with excitement and ideas of their own. My framing for this project has gone through a number of turbulent stages, Bret Victor wannabe, total disheartenment, irrational exuberance, et cetera, et cetera, but I have recently, as a 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 we'll feel more like a system in the Excel or Smalltalk sense, than a text-and-compiler-based programming language.

Mission

00:08:04

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 need a 100% of people, because even today, not 100% of people in the world can read and write. Not even a 100% of people will know how to use a computer or a smart phone. I guess I'm talking about a lot more, like maybe 90% of people will have the ability if they so choose, or whatever. 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.

00:09:00

Anyways, when I say all people, that phrase that needs to be pinned down more. I need more nuance there, but directionally, I mean a lot more people than now, like order of magnitudes more people. So, like maybe 100 times or 1,000 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 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.

00:09:53

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.

00:10:30

Number four, all software will be arbitrarily customizable, allowing for bespoke tailored experiences, and so I spoke ... 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 would 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.

00:11:10

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. 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.

00:11:55

And the goal here, to be clear, is not that I want more people 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. 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.

00:12:29

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 laypeople. 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, "I wonder what would it be like if gravity was a little bit stronger, or a little bit weaker. Or the strong nuclear force, I wonder what the world will look like if I tweaked that a bit." You never wonder those thoughts, because you know you have no control over them.

00:13:16

And similarly, you've never wondered ... Well, maybe those of you listening to this podcast have, but most people, 99.9% 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 imagined them to be. 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 ... Laypeople 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.

00:13:56

I remember reading like a history of the women's suffrage movement, and I was shocked to learn that the early suffragettes had to convince women that they wanted the right to vote. It wasn't like a natural thing to want, and I think that 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.

Thesis

00:14:29

Alright. So, now my thesis. My current angle on this whole mission is most influenced by Jonathan Edwards, Out of the Tarpit, Conal Elliott, Bret Victor, and Paul Chiusano. There are many, many, many hundreds of others who have influenced my thinking here, but I don't want to list 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.

00:15:05

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. If we're gonna 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 the change and then get back to whatever it was that you were doing. I'm envisioning 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. So, let's just talk about comprehensibility for a second, and why it's so bad.

00:16:09

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 little contributions to the code, not just the documentation. So, you download the repository. You figure out the build script. You probably just quit after you try installing it, and it breaks because of some dependency it 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 1,000 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.

00:17:03

So, that's why comprehensibility is so important, because our code ... In order to make a change to an app that I use every day, I'm going to 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've heard me describe how hard it is to understand an unfamiliar codebase, you think that, you know, "Let's just give up. This is impossible," but I don't think so. I think as long as we keep our eye on the ball of comprehensibility, we should be fine.

00:17:43

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, the view from the user, if only the user were made to see the implication of all things. Okay, so now this is a really important point, but it's a little bit hand-wavy. I'm getting this incidental and essential complexity initially from Fred Brooks, but it's also referenced in Out of the Tarpit.

00:18:22

All right, so point three is also a little bit 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. But math is pretty good. Something like the lambda calculus is pretty much as close as 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 is also seems kind of random, but it's the best I can think of that represents essential natures of computation.

00:19:07

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.

00:19:43

So in other words, basically what I'm getting at is we need to, point five, rid ourselves of the IO monad and replace it with better abstractions for whole systems. So, now Conal Elliott has a really, really wonderful post, Will Functional Programming Ever be Liberated From the von Neumann Architecture? 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 IO monad. And I think part of why it's hard to understand is that Haskell people aren't honest about what it is. The IO monad 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.

00:20:24

But Conal Elliott shows us how we can do better than the IO monad, and he showed how with FRP. Functional reactive programming, he argues, and I would agree, is a way to do side effect-y 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-y things happening, your computer doing stuff, 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.

00:21:03

So, this essay argues that we should be able to extend that idea of getting rid of the IO monad and replacing it with better abstractions for whole systems to the entire world of programming. 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, so FRP is all about removing the IO monad from user interface construction, but then what about all the rest of programming?

00:21:35

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. Before FRP, we used jQuery. Before React, for example, you used 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 a state, and boom, it does a jQuery for you, automatically, so you don't have to dirty your hands with the IO monad, 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.

00:22:40

So now let's apply that same kind of thinking to every other part of programming. 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. Okay, now I'm going to say that again. Files, 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.

00:23:22

So, maybe you want some data to be saved somewhere. 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 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, like, open a connection to a database in order to get those things persisted.

00:23:51

I could talk about it for a while, but so point number five is we need to rid ourselves of the IO monad, so FRP's 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 realtime multiplayer games? What about a cloud app? How would you do all these things without the IO monad, without explicitly making a request to a database?

00:24:24

In other words, we're blurring, very, very much so blurring, the line between frontend and backend from 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 now 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.

00:25:12

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 cloud-based click event, that like everyone can get access to, and then sum over, then count the clicks in that thing. This is a hard thing to explain, and partially it's 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, in my log and other places. So anyways, that's point number five, rid ourselves of the IO monad.

00:25:47

Point six, we must have an editing experience that's lively and fluid. The mathematical abstractions we'll need to rid ourselves of the IO monad and build denotative languages scare people, partially because they're UI things, partially because the abstractions are complicated. So, this is a very difficult UI problem, to build this programming experience around denotative languages, but it's tractable. It may be one of the most complicated user interfaces ever created itself, but it's possible to build.

Vague Dream Programming Language System

00:26:21

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 Lamdu, early Unison prototypes, Luna, Isomorf, et cetera. 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.

00:27:05

Okay, so web-based. 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 backend, to do some processing or whatever. Maybe one day it'll compile to web assembly, I don't know. 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: Silicon Valley makes things, and everybody else uses them.

00:27:54

There are a lot of peer-to-peer internet projects happening now, like Dat and Beaker Browser, some Blockchain- y 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.

00:28:30

So anyways, that's one reason, and another reason is I was recently given a tour of Pharo, and The Glamorous Toolkit, by Tudor Girba, and 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.

00:29:00

So, if you have ever seen the Alan Kay STEPS project or maybe early SmallTalk 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 texts 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 blurring the line between apps but we're having strict lines on types.

00:29:54

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 gonna take immutability seriously, we really got to take it seriously. But on top of this immutable expression-ey world, I guess we'd probably need a mutable naming system. So 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 it's still my website so I want whoever wants the newest version of I have my website to get the new version, not the old version. 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 don't quite know how that'll work out. Open research problem.

00:31:00

Next bullet. 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 code. Like your code is just running all the time in pieces, there's no such thing as running code any more than there's running or pausing a Google Doc. 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 think I like that metaphor for this; you have code and it just runs or, if something refers to it, it's on the screen or in use somewhere, it'll run. So you have to kind of disconnect it or something if you want to stop.I'm very vague on this sense but it feels important. Of course we don't want people to not be able to stop code that needs to be stopped. You know, we'll allow that. But I think the metaphor of, " 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.

00:32:06

The way I think about this, it's kind of like your 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 an app platform he calls Beach where that's kind of the metaphor, of an open, infinite canvas.

00:32:36

All right, the last bullet. Actually I have two more. Working on something new doesn't break anything existing. Changing a definition only produces a new definition, but you are given the option to update old hashes to the new definition if you wish. So it's like kind of a factoring tool. So if you have a whole connected tree of definitions and you change one in the middle, it'll say there are a lot of things that depended on this old hash, do you want to create copies of all of 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.

00:33:23

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 my computer and data from elsewhere, or Cloud data. Computation can happen anywhere you want and maybe you have to put your credit card or something in the code somewhere in order to make the computation happen on someone else's computer or in the Cloud, something like that.

Four Big Problems

00:33:54

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 gonna make them explicit now. So number one is ridding ourselves of the IO monad. And now sub 1a is user interfaces, 1b is back end users' databases. Basically we wanna rid the IO monad 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 being 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 IO monad, 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.

Killer app

00:35:05

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 it's own world, kind of like Squeak or Pharo 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, I think it was Microsoft, had a spreadsheet app, Lotus Notes. I don't know if it was Microsoft, maybe it was IBM's. There was a new operating system that was created and then Lotus 123 is why people bought it. And so, for the Internet people, say, 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.

00:36:22

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 super power. 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 really like a kit of, you know, I get incoming emails, I can drag them to wherever I want, elsewhere in my computer, I can reply to emails in a nested thing somewhere else. 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.

00:37:15

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 we all want, is something where we can build our own workflow that merges all the tools that run our life to suit us best.

00:37:39

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. It really, really hurts and then now I finally have learned to not trust Google or 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 gonna 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 crowd sourced development platform and that's what we're trying to build here. That's the whole mission.

How is this different from X?

00:38:45

Okay. Now I have a, "How is this different from X" section. Kind of messy but basically I compare my vision, my dream system to Unison, Luna, Isomorpf and Dark, because those are also Haskell inspired structure editor things. The main difference between what I want to build and 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 computing environment, in the Pharo 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 dream tool to write abstractions over IO because that's gonna be necessary. So a one way to handle it as we could use the IO monad, like Haskell maybe, and lower levels. We could have a few different levels. I don't really know, that's an open question.

00:39:56

Okay, so. So that's my about page. Thanks for bearing with 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.

Explicitly Comprehensible FRP

00:40:48

Okay. So now let's go a little bit more chronologically. So in the past few months, they've been good, I'll start with that. I ... So let's pick up where I left off. So, the last reflection I was just putting the finishing touches on my paper about FRP that I was gonna submit to REBLS, explicitly comprehensible FRP. So, good news, paper was accepted. 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 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 a 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've happened. So thank you Jonathan. And also, thanks to my friends who joined for that feedback session. Geoffrey Lit, Ivan Reese, Joshua Horowitz, and Johnathan Edwards for organizing it. And thanks Glen Chiacchiari for his notes separately.

00:42:00

All right. 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's on the Internet, the slides are on the Internet. Futureofcoding.org/papers/something. If you just type futureofcoding.org/papers you'll get there. Or if you just go to the futureofcoding.org, it's right at the top. I'll just do a quick summary.

00:42:50

Basically, I complain about the Elm Architecture. It was started in Elm but it has since gone on to inspire React's Redux, Vue's vuex and CycleJS's Onionify. So the thesis 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.

The Elm Architecture

00:43:11

Let me describe the Elm Architecture briefly. It's characterized by a single state tree where all of 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 some 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 a state, and an event, from the view and updates the view. It's immutable but it's updating the view, it's producing a new value of the state one tick forward in time. So, if you have a counter, the initial value of the state would be counter zero, that would be passed to the view which would make a button with zero in the button. The button would have a unclick event, it would emit at an increment event and then the reducer would say, "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.

00:44:42

So the industry of user interface people, especially in Silicon Valley, have kind of circled around this Elm Architecture single 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 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.

00:45:46

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 that to be possible, you need to be able to really quickly determine which parts of this large codebase 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 or tens of thousands or millions of lines long, 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.

Higher order and cyclic streams

00:46:48

So, what's the alternative?, you ask. Thanks for asking. So I think the alternative is to go back to 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 Elm 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 high order and cyclical streams. And those really aren't around in very many places.

Fluid Haskell Chimera

00:47:31

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 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 show or whatever ... because I use a Chromebook so I can't compile it unless I'm 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. 10 seconds between feedback loop cycles, it's a nightmare, even just for things like syntax errors.

00:48:24

So, as an aside, after this project, actually 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 letme know. I'd love to get that set up. But luckily I found a good alternative which I'll talk about in a second.

00:49:15

So, anyways, back to Explicitly Comprehensible FRP. If we use higher order and cyclical streams we can regain the comprehensibility of radial functional programming. In other words, when you read some code you can be sure that the definitions are 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, for piecemeal comprehensibility in a quick way.

Turbine

00:49:58

Okay, so that's Explicitly Comprehensible FRP, in a 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 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 Friis Vindum, 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 two seconds. I still need help setting up typescript but I was able to install it without typescript for two seconds, or very quickly, and then on every key stroke it'll reload the page, like instantly. It's so quick to compile and run it. So, for that reason alone, it warns me about syntax errors, it warns me about silly errors. It's just so much, so much better.

00:51:30

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 likelittle 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 IO monad 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.

00:52:18

There's this wonderful project called 7GUIs, which is kind of to do on VC but even more legit instead of just TodoMVC there are seven tasks. I'd really love TodoMVC because it embodies a lot of what's hard about UI programming. But 7GUIs is also good. So maybe I'll build some 7GUIs things or play with the TodoMVC 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, I don't know, things like that. Next steps.

P4

00:53:00

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 you remember that programming experience thing I was mentioning before. So once we removed the IO 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 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 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've 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 then the third prototype was a structured editor for Javascript, which I called Rose. The first two I called Cycle v1 and Cycle v2 and then this is P4

00:54:22

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 where I said that I was going to be working on visual metaphors for streams full time.

00:54:53

The main reason was that it's quite difficult to build a editor that is direct manipulation-ey, you know, it looks like buttons and 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, I need to be able to put any expression there, fully nested as deeply as possible. So basically what you realize is , basically I just want to expressions everywhere and occasionally some of the expressions could be represented as UI but you need to be able to get rid of the UI and just put another expression there. So that's kind of like Bret Victor's scrubbing idea, so you have a regular programming interface but then the numbers can be scrubbed.

00:55:52

So that that's kind of where I'm at now. We have a regular programmatic interface but then, 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 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 interact with, maybe, but right now I'm thinking, again, they could be like annotation to the code, to illustrate how the expressions are working but you have text based expressions, that's 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, Lamdu, Isomorph, Dark, Unison, etc.

00:56:50

Okay. Yeah, and 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 straight forward. The term 'live' comes to mind, live programming. It's a term that we use a lot, Sean McDirmid 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 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 a loading icon or something, just to tell you that the action you took had a semantic meaning. Helps you feel heard.

00:58:00

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 type languages that I've worked with, they allow you to write code, and you hit a button, and then they yell at you. It's like the compile button is like the yell at me now button, which is really an annoying button.

00:58:25

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 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. 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. If that's the selling point, they're just reminders. They should be off to the side. They shouldn't prevent you from doing what you're trying to do. I think that's really important.

00:59:10

Let's see. Here's another idea. 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? Like 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? I have all these UI problems that are ... The true motivating problems for P4 are 7GUIs and TodoMVC. 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 their reactive bit again, and just work on like, data transformation problems.

01:00:07

Joshua Horowitz recently, well, he presented it live, and then recently published on the internet, a project called Pane, which is very much in the spirit. It's very Haskelly. It's pure data transformations. So maybe I could take his problem statement as my own, build like a user-interfacey thing for pure data transformations that's also very live, and shows you the intermediate data, et cetera. Maybe I can even draw inspiration from Pane.

01:00:34

Then once I've done that, I can maybe build up to a higher order and cyclical streams. The difficulty in that strategy is that I'll build something neat, then it won't scale up to higher order and cyclical streams, so I have to really have the higher order stuff in mind while I'm doing the lower level things. Yeah, it's hard.

01:00:58

I think a key realization I'm coming to is that abstractions are really complicated, and they're varied. 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 a good cheat. Basically, it's the idea of all those other pros that I keep talking about. Like lambda, for example. You have the text there, and then you can have visualizations, or live data annotating the abstraction, the core abstraction. That's my current approach somehow.

Multi-node FRP

01:01:41

The next section in my list is the multi-node FRP, removing the I/O monad from the backend, but I kind of already talked about it in this podcast, so I'm gonna go ahead and leave it at what I said earlier, basically 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, or you can email me, but I'll just tantalize you with one other tidbit of multi-node FRP that I've come up with.

01:02:24

Denotationally, I have a question for you. What is a user? What is a user? The first thought I had was: Users are, well, this thing you have to create. So like on every website I go to, I go and create an account. What's the denotation of creating an account? Then it hit me. Stop thinking like a mutable ninny! Stop thinking like you're programming in Java. Creating in a thing is very, very mutable. Is a mutable idea, so I threw that away. What is a user?

01:02:57

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, public key. It's a tuple. Was your mind blown?

01:03:31

That's what a user is. If I have a public key and a private key, and I want to set my username, so in a set, it sounds imutable, but basically what I can do is say, I can sign a statement saying, "My username is X", with my private and public key, and then everyone knows that's what my username is. In the future if I say, "My username is Y", then they know my username was X and now it's Y. That's what I mean by set. It's a stream notion of set. I'm not setting anything, I'm just updating. The stream has multiple values based on the value of time.

01:04:13

Anyways, I'm really excited about this abstract notion of a user as just a private and public key. If you're creative, you'll realize holy crap, 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. We can literally delete that.

01:04:33

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 your browser just has the information to sign all of your actions as you. You never have to login again. You never have to create an account again. You never have to change your password again.

01:04:52

Obviously there's some issues with security and whatnot, but I think it's a really cool idea of just getting back to the root of what a user is. Cool. Okay, that is multi node FRP, removing I/O from the backend.

Version Control

01:05:14

Another point is version control. I mentioned 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. Actually, that should probably be P4, but anyways, that one has a name. It's a WoofJS Workflow. You could find it on my website, futureofcoding.org. It's a really neat, I think, exploration 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.

01:05:51

Instead of using Git with normal branches, imagine a infinitely nestable bulleted list. You're just editing this list as you would a text file, but it's actually branches of code. 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 masters. We don't have multilevel deep pull requests. I think part of the reason is the tools are not fluid at all. If you're interested in WoofJS Workflow, rewind the podcast to that episode, or go check it out on the internet.

01:06:33

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 in the future. I've only seen a very small handful, there's this website - like Expressions of Change - where someone was focused specifically on the version control problem. I'd love to see more people focus on this problem, 'cause eventually I'm gonna have to focus on it if nobody else does, and that would be annoying.

01:07:06

But it's a really, really interesting hard problem, version control, and maybe there's been interesting work on it. 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.

Prototyping towards the future of coding

01:07:29

It's a this point in the podcast that I'm realizing that you might be confused as to what it is that I'm building, the goal. So I've mentioned that I want this system that's kind of like Wikipedia for software, where anyone can change things, blah blah blah. In order to do that we need to remove the I/O monad, blah blah blah blah blah. Okay.

01:07:52

So, if you got all that, great job, you've been listening well. But you may be confused 'cause I have this thing P4, and you're like "well, is P4 the thing you want to be that beautiful system?"

01:08:03

The answer is "probably not", P4 is just a prototype to point us in the right direction of removing the I/O monad 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.

01:08:25

Maybe at one point, this given prototype will morph into the dream platform itself. 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.

Sustainability

01:08:45

Okay, so now I'm gonna take a pivot and talk about sustainability. So, I think maybe it was Ivan Reese, one of my friends was saying that they were a little bit confused about my life setup. It's clear that I do this podcast, 'cause 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 kinda 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 two months ago I moved to London, where I'm speaking to you now, live from London. It's actually 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 excited about the gloomy weather, it's not fun to run in, so my girlfriend and I have been talking about a fun, warmer, sunnier places in Europe to escape to, so let you know how that goes.

01:10:00

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 wanna work on, my main goal - number two, I have the podcast - which has become increasingly important to me, but it was really started with the spirit of, "I'm gonna have these conversations anyways, I might as well record them, I wanna 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 an addendum to my research which is the core of my work. But if it continues to grow and the audience grows and the quality grows, maybe it can become more of a central part of what I'm trying to do. 'Cause I really don't believe that I'm the only one with the answer, or I'm the one who's gonna solve it, and I'm gonna have a bunch of little helpers.

01:10:56

I think the whole mission is that everything should be much more community-driven and so I think 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 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 my ideas. And if you convince me, maybe I'll join your project, that sounds great. Collaboration is the way to go."

01:11:36

So my research is important to me, but I think the podcast could also gain an importance if it continues to do well and gain a following.

01:11:48

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.

01:12:10

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 harder 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.

01:12:58

But I find that when I get in the groove of research or podcasts or freelance, whichever one, I don't really wanna stop. I'll do research only for two weeks, then podcasts only for two weeks, then freelance only for two weeks, it's hard to do two days of this, two days of this, one day of this in a given week. And that's how I've conceptualized it. I wanna do three days of research, one day of podcast, one day of freelance. Or maybe 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 daily basis, the mornings are research, then I do emails, then I do maybe podcast, and then maybe freelance. But I found that forcing myself into a structure like that makes me end up doing less work, 'cause I'm chafing against these artificial constraints, when instead, if I kind of let myself be drawn to my work more naturally, maybe I'll watch TV when I should be working, but then I'll get bored of TV and then work for seven hours into the wee hours of the night, so I'll 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.

01:14:15

Luckily the freelance gig I have is very flexible, they're very, very good to me. So, when it's non-critical, I'm able to do the work when I get to it, which is great. And when it's critical I can drop the other stuff and work on it, so it's fine.

01:14:35

But it something that I have been noticing, this balance is tricky. But it's working. Not to complain too much, it's all working. I've been getting enough research done, I'm proud of it. My podcast, 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 10, 20 hours doing just freelance stuff to make some money and keep the bosses happy.

01:15:10

Alright, 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'll remember that I worked for Repl.it back in February, March, April ... basically for like three weeks earlier this year, but it didn't work out because I only wanted to work 10 or so hours a week and they really needed full-time people. It wasn't gonna work the way they worked. So we parted ways, and I hope they found other people, I'm sure they have, other full-time people to do that job, and I have found a part-time that kind of fits my time needs. So that's great.

01:15:56

But anyways, it was really unexpected to get this email from him saying he listens to the podcast, and he wants to support it. It seems really selfless. He says it's partly to encourage people who listen and are excited about improving programming to know about Repl.it and work there, maybe. I don't know, contact marketing, I don't know how it works.

01:16:26

But I think, in his heart, I think he just thinks his work is valuable and wants to help it along, and so he's supporting it with money, but mostly I think the real value is, he's supporting it with some thought partnership. It was his idea to take episodes and write a few paragraphs of 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!

01:17:03

I did it for a second and maybe a third one, 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.

01:17:17

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.

01:17:30

So, yeah, so thank you Amjad. And he is excited. He is bullish? Bullish? I think bullish means he is excited about it. Or optimistic. He's optimistic that, with 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, like startups or bigger companies with more of a budget for sponsorship, to sponsor the podcast, and then, I don't know, if I could get a reasonable amount of money per episode, and I did two or three episodes per month, 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.

01:18:19

Speaking of growth, I made a bit of mistake, but I've learned my lesson. 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 Jain Family Institute, they do these wacky research projects, I think right now they're really concerned with universal basic income and the understandability of AI systems in decision making and discrimination, pretty hot topics. And so I was introduced to them, and 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 Jain Family Institute blog.

01:19:02

Then 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 Bret Victor?"

01:19:15

And I just broke out in laughing, because if I knew he knew who Bret Victor was, and if I knew he'd visited Dynamicland, then I would have started there. But I had to backtrack and be like, "I know this seems like I'm just saying it because you brought him up, but he's my guy. He's the whole reason that we're having this conversation and talking about these things. He was the original person who influenced me a lot."

01:19:38

So anyways, I wrote an article about Dynamicland 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. And then I got an email from Hacker News, saying that they thought that the article had promise, and so they had this new system where some random time in the next 24 hours they're gonna 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 exciting.

01:20:18

So I checked back every hour. Boom! It was on the front page, and I just watched it climb all the way 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.

01:20:36

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 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.

01:21:26

But, the essay is still great, and if you're curious about Dynamicland, I think this essay, at least in my very humble opinion, I think if you can't go to Dynamicland, this essay gives you a really good feel, it tries to be visceral and give you a feel for what it is to be there and the vision.

01:21:43

If you want a more hard tacks, how does the system work at programming level, go read Omar Rizwan's MapKit. 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 recasting it in my own words. I don't really have any new ideas there. I steal his metaphors, I steal everything he says.

01:22:09

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 through how it works to understand the vision, but you have to be really careful, because someone like Bret Victor, and Bret Victor's lab, the deepness of their thoughts is hard to overstate. The vision is so rich, and so complicated that it's so hard to see through the technology to the vision, but that's the whole point. The point isn't technology, the point is that they're pointing to this vision that's beautiful but far off, and 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. That's my one Bret Victory plea. He's always saying things like that.

Patreon

01:23:11

Back to money. I have been encouraged by a few people recently to start a Patreon. And I was thinking I was gonna do this about a year ago, I was inspired by the success of Nicky Case to do this a year ago, but I was convinced otherwise, and what I told myself silently was that when my listeners or whatever, when you guys, 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 the say "I wanna 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 @RubensSandwich, I don't know his actual last name. So thank you Ruben.

01:24:01

So I'm gonna go ahead and set up this Patreon, probably in December. I'm thinking that'll be good project for me to do in the week that I'm home. I don't know, I'll do it at some point in the next couple of months. It is a priority, and in combination with the people supporting the podcast, companies sponsoring the podcast, this could really go a long way to allowing 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 Ruben. And we'll see. We'll see what this Patreon lifestyle will look like.

01:24:38

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 it everyday people giving me money because they value the work that I'm doing. In other words, there's absolutely no expectation that anyone listening to this would give money. There are money 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. Nicky Case is one. Psycho jazz is another one. It's kind of random what you give money to, on the internet. 'Cause 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.

01:25:31

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 so unbelievably thankful.

01:25:45

So yeah, 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 a generosity, really a patron spirit. Like I wanna be supportive, I want ... it's just something that's meaningful to me in my heart and I wanna ... part of it is I wanna be able to tell people I give, like I just told you guys who I give to, it's kind of like a signaling thing, but more it makes me feel like bigger person to get to be a small piece of something that I think is important and needs to be in the world. So that's my motivation, and so the little trinkets or incentives to "well, if you give this much, 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 gonna waste too much time with those sorts of incentivey things. I prefer just give away everything for free. Transcripts for free for everyone. I just wanna give everyone everything for free.

01:26:53

I listen to Sam Harris' podcast and he's started, recently, putting things behind his paywall, only for subscribers, and it really bugs me for two reasons.

01:27:00

One, part of what I'm giving him money is so that he, 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 if it goes against why I'm giving money for him to block it from some people. Then also when he blocks things it makes it a worse experience for me. I have to jump through all these hoops to get to the content that only supporters can get. I'd rather just have it be easier and have everyone have access to it. Anyways, if any of you who are thinking about supporting would prefer to get some sort of a benefit for supporting, or if you disagree with this thesis of generosity Patreon, blah, blah, blah. Please let me know. I'm really open to feedback here or, yeah, basically anywhere. Anywhere and always I'm excited to hear anyone's thoughts.

01:28:00

Anytime I get an email from a stranger or someone who's emailed me in the past makes my day. 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. Okay, so I'm realizing now that I've forgotten to 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. One is I went to SPLASH to present REBLS 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, 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. I like just doing things the way I like things done and I don't like going to a new spot. I like going a new spot and then staying there for months because once I get my setup that I like I want to benefit from it.

SPLASH

01:29:04

Anyways, I don't like traveling usually, but SPLASH was amazing. I got to meet so many really wonderful people. Yeah, so 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. If you're curious about the people, it's like 20 or 30 people I met and spent time with, so, so cool. These people are just like Jonathan Edwards and Sean McDirmid. Okay, now I'm listing names, but really great. Really, really great. Then 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, I know you from the internet too, great. Now we're meeting in person. Total, just bumping into internet friends without expecting to very, very fun.

01:29:51

In particular LIVE was really great. The LIVE workshop, I think it was started by Jonathan Edwards and it's just one after another. It was a day of blowing my mind. One talk after another, such, such high quality, and the internet was very upset that it, none of it was going to be streamed and so I went ahead and got there early and set up my own phone as like, on a tray where you put food, waiters would put food on it. A tray and a glass. A whole very, very boot leg-y setup and I recorded the whole day. Yeah, 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.

01:30:49

You can go to a FutureOfCoding.org/, I think it's /notes/live/2018 to get the LIVE 2018 bootleg edition. Most people have a project page, a paper or a page that summarizes their project better than the grainy video I recorded and most people have since rerecorded their talk as a polished video with good audio and whatnot. 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 you 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 three parts, so it's kind of annoying. What's his name? Jeremy Ashkenas who I've a big fan of for many, many years creator of CoffeeScript, Backbone.js, Underscore.js. Now he's working on Observable HQ.

01:31:53

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. 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 upload 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 for, to donate to support my work.

01:32:44

I think two or three other people also chimed in at the same time. It was when I put together the LIVE 2018 thing. 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. Maybe in order to get people excited about my Patreon and supporting I need to shift some of my focus to do more of those sorts of things so I could shift my focus from research to documenting and organizing this world. I think that Slack is part of that and then the meetups I'm throwing are part of that.

Meetups

01:33:30

Well, actually let's, let's talk about that. Since the last reflection, basically right after the last reflection, I had the final future of coding meetup in New York City. We'll have more, but that's the final one after I, before I moved away. It was really, really wonderful. Josh Horowitz was there, Geoffrey Litt came down from Boston to attend, Glen was there. Corey from Eve Skyped in to show us what he was working on. Jason Brennan showed us Beach. It was just really an all-star crew and I couldn't have been prouder to have brought it together. I was just like, to be honest, I was just, I have this anxiety that when I bring so many amazing people together and I just want it to be, I want to make the most of everyone's time as much as possible because it's just such a valuable resource how all these people in the same place and time.

01:34:33

I really want to make the most of it. 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. I changed up the format of this one. I've organized it as a dinner at a restaurant. I booked it a semi private room. Everyone had to, before the event, buy a ticket. I set up a thing on Event Brite where you had to pay me 45 pounds, which is really too much money, but that's the cheapest option I could come up with. 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.

01:35:18

Anyways, for this version that's the price and there are 14 of us, including me 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, making the most of amazing people. I'm going to go ahead and maybe put together a seating chart to make sure that people are seated in a good way because otherwise it's always awkward. Where do I sit? What I think I might do is create two seating charts and halfway through the dinner, maybe I'll ask everyone to stand up and go to the second one or maybe even the third one. Then you can get to meet different people throughout the dinner and I can organize it beautifully. Mastermind this whole thing. I don't know, maybe if it will, people will find that annoying.

01:36:02

I'm excited 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. Caleb, who I met at LIVE in Boston at SPLASH has taken up the mantle for doing this in Boston. He created a meetup page. 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. It kind of, with 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 press a button and you end up not going probably because it's a big group and it's a talk you listen to you. Anyways, there are a lot of ways to run these things and I'm excited to have a lot of people experimenting.

01:36:56

Amjad of Repl.it had said that he would be open to hosting the San Francisco version of this, which I think will be really cool. So close, you might as well do it that in England. Am I right? That'd be cool if I could, 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 are getting together to talk about the Future of Coding. Man, you'd have to have to, you don't have to really hold me back. I'd really want to go. Amjad wow, that'd be so cool. The Notion people.

01:37:36

Man, now I'm going, I'm going. I'm organizing this and going myself. Yeah, it was Amjad's idea that we could turn this into more of a thing. I can make a website, FutureOfCoding.org/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. That's actually, so I made a list of my, I call them possible December 2018 regroup projects and that's one of them making that, making meetups more of a thing. The Patreon is also part of that regroup projects list. Oh, I was also gonna say that I was recently approached by Aidan Cuniffee on the Slack with an idea that I have also been toying with my head.

01:38:30

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 just, how do you structure something like this? It's a really, 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 there are multiple right answers, so you just have to pick one depending on what it is you're trying to accomplish. One way you could do it it it can be small, like for people who meet up every couple of weeks to like, four independent researcher people meet up to discuss their own research and just get some social validation and time pressure to actually accomplish things. That's a great idea. You could just do it privately for the four of you 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 add to comments their thoughts. That's one way to do it.

01:39:30

Another way is just a free for all. You just post a link and anyone can show up and hopefully 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 can kind of break off into smaller group conversations then 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. It's important to think through these kind of design decisions. Another idea that Jonathan Edwards had was that you could just, one person could just hold office hours, or it could be a group of people who just say if you want to talk to me or talk about your thing tweet back, and you can kind of build up a schedule, and you could publicly broadcast the whole thing for everyone to watch. That would be neat.

01:40:24

Aidan had an idea where you could kind of do it as a raffle where a future program we meetup and only the presenter gets to talk and everyone else just watches and can contribute in the comments. Then maybe some people are guaranteed a spot to present their work, but there's one spot that's a random pick from a hat spot. He says that that's how comedy clubs get people to show up. They make it, you show up, you watch everybody else and then you hope for the chance that you get to present, so that's cool. Then the people who show up more often are given higher priority in the random waiting or whatever. That's another cool idea.

01:41:12

Anyways, online Future of Coding meetups, like video, not just the text thin 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 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 on a more rolling basis and more like decentralize-y. 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:00 AM Pacific time, 5:00 or 6:00 PM London time. I don't know.

December Regroup Projects

01:42:21

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. In terms of a better mic, this episode I actually tried to make this mic better. I have this cheapo mic, but it would only works when I get really close to it, but when I get close to it, my Ps, Peter Piper Ps, cause it to flare up. Anyone who knows about audio stuff will know this stuff. It's kind of new to me. Anyways, I needed to make a mic filter thing and so I found a video to help that online to help me make it out of paper. I did that for 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 and 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.

01:43:07

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. Another thing that's really important is Google inbox is dying in March, so I have a deadline. 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 this, these lists that I, these unorganized lists of things I need to either think about or research. Two lists. One is for thoughts and the other one is for URLs of interesting projects that I want to look at. They're append only lists. I don't really go back and take things out of them. 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.

01:44:14

I should just go full hog GitHub issues because GitHub issues is pretty great. People can comment. There's a unique URL, I can change the title, I could put them in a Trello board, I can reference . I should probably, we should probably just go to GitHub issues. Obviously there are trade offs. GitHub issues 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 in, just in text in plain texts, like in a markdown bulleted list. You can still see those on my website, my old, yeah, they're old pages that are still like that. I haven't deleted them for posterity's sake but, but they're kind of a mess. Anyways, I'll figure this out. That's another thing I could work on as a December regroup project.

01:45:08

Relatedly, I do have, I don't know, 20 or 30 GitHub issues already that I never check on. They could use some love and organization. Anyways, that's that. Already talked about a Patreon. Another idea that could provide some income. 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 Repl.it, my sponsor, but there are many others. Maybe I could make a job board for those people and then if enough people visit it, maybe I could ask companies to sponsor me to get higher up on the job board or I could ask for a donation. This person found you because of my job board, you know. Recruiters would charge you 10k, I would appreciate a donation of a fraction of that. I don't know, and it's up to them. They could just say no, whatever. It's a silly idea, but it's a thought.

01:46:14

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 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. It's really a long-term game. It's not about, it's not a sprint, it's a marathon, for real. I feel that way about my own excitement and motivation. I also feel that way in terms of funding. I want a sustainable funding source. I don't want to raise money and then have a three year timeline like Eve was saddled with. I want to do this sustainably because it's a hard problem that's important that I want to stick with for decades.

Blink Note

01:47:00

Anything else to mention? I started collaborating with this guy I met on the internet, Dan Kantor on this note taking app Chrome extension. Basically I realized that I need a way to take notes in a millisecond. 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. I realized when I did the analysis, all of the note taking apps take three seconds or more, some takes seven seconds, some take 10 seconds to load. Loading a Google doc, loading even Notion takes three seconds. It's just unacceptable. I want to press a button and take a note. I need to be able to jot something down immediately. I was only able to find one thing that did it in less than a second, but it wasn't quite what I wanted.

01:47:49

Anyways, we've started working on this thing. I'm calling it Blink Note because it notes in a blink, or notes faster than you can blink because it really opens up in a millisecond and it uses the Chrome Sync API to do syncing, and offline, and online. Right now it's about 200 or 300 lines of code. We need to keep it small, otherwise it won't load as fast, but it's fun. I've been using it to take notes. We shall see if I continue to use and build it. Maybe it'll be a thing other people will find valuable. Maybe I will stop and just use something that already exists. Part of why I wanted to mention this is that it feels relevant that I'm living the vision.

01:48:32

My vision is that people will be able to customize and create their own tools for their own purposes. That's what I'm doing here with Blink Note. 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've watched TV or done other relaxing activities that instead I've been coding on Blink Note, 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. They get to improve their lives with coding. So, so cool.

Next Steps

01:49:15

Okay, so in terms of next steps and what I'm gonna 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. Continuing to work on removing the IO monad from user interfaces with Turbine and a 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. Next year there is the <Programming> conference in April in Italy and there are two different workshops, the Salon de Refuge and PX, the programming experience workshop.

01:50:02

Maybe I'd submit to either of those. The Salon I have to submit on January 7th, and PX February 1st which happens in August in the UK and then maybe I'll submit again to SPLASH. I could submit this year to LIVE or REBLS 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 October in Athens, Greece, which is nearby, given I live in Europe now.

01:51:06

I'm feeling like my work has been very productive and I'm pulling on a good thread so I'm trying to keep our, 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. The picking a date is really a good way to force yourself to buckle down, but my research has been good so far. 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 so worried.

01:51:32

Yeah, so, yeah. Turbine, P4, the programming experience of removing the IO monad from the user interfaces. That's my next thing and what I'm mostly focusing on, I'll work a bit on this Blink Notes thing a bit. I'll continue to think about removing IO monad from the backend and other problems kind of on the back of my mind, but there are definitely in the back of my mind and this IO monad from UIs and the PX of that is on the top of my mind. Yeah, I'm excited to get the opportunity to do this kind of work. Bye.