Future of Coding - Reflection Thirteen - Independent mentorship

Episode Date: August 27, 2018

My research recap episodes are back! This is the first I've recorded since the end of 2017. I discuss my new mentor-mentee relationship with Jonathan Edwards, my upcoming new paper on functional reactive programming, my move to London, my longer-term goals, and other various musings about abstractions, monads, and data ninja playgrounds. futureofcoding.org/reflections/13Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Hello and welcome to the Future of Coding. My name is Steve Krause. So today we are getting back to the reflection episodes that I swore off a few months ago but I've decided to return to. So if you're really paying attention you will have noticed that I think was after research recap episode nine, which wasn't nine in the list. Let me see. That was episode 18 of the podcast. That's when I stopped doing research recaps and just did interviews from that point on. And my plan was to maybe talk about my research a bit in the beginning of interviews, but I didn't do that in part because it felt, I don't know, like slightly rude to preload someone's interview with my thoughts about myself. Like, you know, if someone wanted to share an interview with their

mom or their friends, and like the first 20 minutes were just me talking about myself, it just seemed a little bit strange. So I've decided to resume doing these, definitely at a less frequency than I had been doing them before, maybe once every other month or less. I don't know, maybe more. We'll see what people think about them. In the past, I didn't get such great feedback from these episodes. Mostly people were excited about my interviews, partly because when I do an interview, it gets shared with the interviewees audience, and so I get a lot of attention from that. But these episodes are just shared with my people, so I guess that's less attention. But anyways, I got some recently good feedback, in particular from Kevin Lina, who mentioned these episodes in a

recent newsletter email he sent out. And so that's pretty solid encouragement. So thanks, Kevin. And here's an episode for you. So however, despite not doing these episodes, I have done three other reflections, 10, 11, and 12, in written format on my website, futureofcoding.org slash reflection slash 10 or 11 and 12. I'll link to those in the notes for this episode. I also have in text the notes for this episode on my website as well, futureofcoding.org slash reflection slash 13. And I think I'll also link to it in the episodes page of my website. So that's a bunch of logistics. Alrighty, so it's been a while since I last gave an update on this podcast. So I don't want to go through 10, 11, 12 so much. Just the quick summary is I had some trouble doing research for a few months there, maybe two or three. I was worried about the financial sustainability of this work.

I was feeling very lost, undirected. And so I kind of stopped, maybe thought I was going to get a job. Luckily, didn't do that. Started doing some really great freelance work for a future programming company called Dark that's making like a back-end tool structured editor thing. It's really cool. And so they've been contracting me to do some research for them. And that's been just an amazing way to get back into this work and get really excited about it. And it also alleviated some of my pressures of finances. I worked for a few different companies. Now I have another gig working for First Round Capital, which is really great. It takes the financial burden off and gives me

some time to do some real engineering work and also the time to do this research. So now I'm back in it. But really, one of the main things that's happened since I last gave one of these episodes is I have a mentor, like an official advisor, kind of like you'd see in an academic context. His name is Jonathan Edwards. I imagine a lot of you have heard of him. Hopefully, I'll get him on the podcast soon for an interview, because he has, as many of you know, a lot of amazing things to say. And I'll get him on the podcast soon for an interview because he has, as many of you know, a lot of amazing things to say. And I don't know how well this will come out, but we've thought about having maybe the meetings that he and I have where he gives me feedback on my work.

We thought about maybe recording some of those meetings or parts of those meetings and putting those on this podcast as well, because I think it could be a really interesting, um, you know, experiment, you know, interesting data and context for people who, who are just really curious about this work and how research is done. Livestreams and, and share open sharing. It's like a weird, weird concept, but, um, but it works. Like I have a friend, uh, Glenn Chiacchiere, um, and also, um, Jeffrey Litt, who just love watching Jonathan Blow, you know, coding. He's just like a master of coding. You know, I'm not, I'm not a Jonathan Blow, you know, coding. He's just like a master of coding. You know, I'm not a master of research by any means, but just watching people do their

work in public, it's just offers such a great opportunity to learn from other people. So maybe we'll do that. So Jonathan and I have had three meetings so far. One in June, one in July, and one in August. The first two were of Google Hangouts, and the last one was in Boston in person at a coffee shop. And they were excellent. And in between the second and third meetings, Jonathan's given me some really excellent feedback on this paper that he's been mentoring me through. So we've had some really solid interactions just in

the first three months. So most of what he helps me with is just focusing on one problem, really fleshing it out as a full paper, and figuring out where to submit it to and the deadlines and just shepherding me through it, giving me feedback on the process, yada, yada. So that essay, I'm submitting it to Rebels, R-E-B-L-S, which is a workshop at Splash. I'm submitting it as an in-progress paper. It's six pages long. It's kind of hard to summarize. One thing about this paper is that everyone, literally every single person who I've explained it to or has read it, pretty much strongly disagrees with it, including Jonathan Edwards. Yet, I'm very proud of it, and I think it offers a really cool perspective.

It's a paper that argues against the Elm architecture, which is also used in Redux and CycleJS, Ununify, and others. I'm really glad that I finally buckled down on this one specific problem and really fleshed it out. And this definitely wouldn't have happened if Jonathan weren't advising me through. Part of where this particular issue came to the forefront of my mind is when I worked for maybe two weeks at this company called Replit, and it had this very large Redux application. And it was just very frustrating to kind of get a sense of how things

were working. And so that's where a lot of this inspiration came from. So I think it took me about two months, part-time, like half-time, you know, 20 hours a week to make this essay happen. So I guess one month full-time, I think it was a little bit less than that, but we can just say that as a reasonable estimate. At the end there, it took me like 10 hours or so just to convert it from Markdown to LaTeX. That was really frustrating and took such a long time. So I'll learn for next time that maybe I should start in LaTeX for something that I have a feeling will turn into an academic paper. But yeah, I'm glad it is done. And I will hear back September 25th if it goes, if I get it. When I submitted last week, it said, you know, like your submission number seven. So that can't be, so they probably don't

have too many papers. They extended the deadline another two weeks to Rebels, likely to get more papers, but it's hard to imagine they're gonna get that many more papers in the next two weeks. So likely I'll get in to this illustrious group of people, but if I don't, you know, I'll find something else to do. And even if I don't, I will likely still attend Splash. I'm looking on finding ways to financially make that make sense. But Jonathan Edwards has really encouraged me to attend. So here, I wanted to mention a few more things about Jonathan Edwards. So at our last meeting, we agreed to slightly more formally enter into a mentor-mentee advisor relationship where he would where we'd talk every two or four weeks depending on how much work I'm able to get done he'd advise me on what to submit to what to write about and he would help review my papers

potentially on some of them he'd contribute enough to merit being a co-author on some of my papers. Potentially on some of them, he contributed enough to merit being a co-author on some of my papers, which sounds great to me. As he explained, in the academic circles, single authored papers are like almost a red flag. So it's like nice to have more than one mentor, more than one person on the paper. And his name carries a lot of weight. So, you know, I would really be honored to have him co-authororing papers with me. And, you know, Jonathan is interested in more of a group, like a group of people who could get together and work together, almost like an independent research organization. So the two of us, him as an advisor, me as kind of like a grad student, that's kind of mimicking what academia has.

But it could be neat to have a few more people in this like little rebel research computer science group. But we don't want to like move too fast, you know, we want to take it slow. And like a good next step, a good first milestone would be for us to co-author a paper in a reasonably serious place, such as Onward! which is part of Splash in 2019. So we have a good amount of time for that. I think he said like May or so is like the deadline for those essays or those papers. So that could be a really great next step. But then, yeah, it would be neat if we could add another person or two to this group, and maybe I could collaborate with them, or we could all collaborate. I don't exactly know how it would work. Of course, you know, financial sustainability is always a question. Like, one way to go about it is to do it, you know, where everyone pays their own way. You know,

I found my own funding. Jonathan has his own funding. You know, people, if people want to work with us, maybe they too can find their own funding, and eventually, I guess, if we're that successful as, like, an independent lab, maybe someone somewhere would get us funding, or maybe we're able to one day apply for our own funding, but, or maybe find some other way, like, run a conference or something, but in the meantime, I think it's just gonna be Jonathan and I, and I'm very excited about it. Here, I had a few other notes. He, oh. He's really great at telling me which papers to read and which not to read. He's like an encyclopedia as far as that goes. He urged me to apply to the full week of Splash so I'm excited for that. Oh one

topic that Jonathan and I often talk about is the co-design of programming language interfaces. So usually you have, on the one hand, the interpreted school, like Smalltalk and Scratch and Brett Victor and Alan Kay. This is very much the West Coast school of computer science. And then the East Coast school, and then the East Coast is more compiled things. This doesn't entirely make sense, but, you know, like Haskell's all the way East, I guess even more East than the East Coast, and a lot of the small talk people are West Coast, I guess. I don't know, it doesn't really make sense, the geographic ideas, but it does a little bit. Anyways, a lot of people are either compiler writers or interpreter writers.

And as I mentioned in my last podcast with Omar Rizwan, when you go to design an interpreter or a compiler, it kind of changes the way you think about things. And so most people are biased on one side or the other. But Jonathan Edwards is maybe one of the only people who really tries to straddle it completely and be one foot on each side, one foot on semantics and the one of the only people who really tries to straddle it completely and be one foot on each side, one foot on semantics and the model of the programming language and the other foot on the UI of it. And I think I'm trying to follow in those footsteps, really try and straddle the line and co-design the language towards the UI, design towards each other. And so to give you a

broader perspective, that's kind of what I'm doing with this paper for functional reactive programming. I'm arguing against the Elm architecture, but not just for its own sake. I'm not trying to articulate for a better architecture that we should use with React. I'm really looking for the semantics for a user interface construction environment.

And once I have the semantics, then I'll work a little bit more on the user interface and on semantics. You kind of have to go back and forth and grow them together. To make a little more specific, I'm working up towards maybe something that looks a lot like Scratch. MIT's Scratch programming language for kids, but more functional reactive. So the semantics of it will be very different. And the reason I need to work on semantics first is because I don't really think there's a great semantic foundation for functional reactive programming yet.

I found this reflex library, which is pretty good. It gave me enough intuition to go from there, but I think I'm going to need more work on semantics, and then of course, a ton of work on the user interface, the visual metaphors, all of those things that scratch as well, but I'm going to need of do an entirely different thing for, for my, for, for functional reactive Scratch. All right, so that's Jonathan Edwards and my paper, and I gave you a little preview of FRP Scratch, which I wasn't planning to talk on until later on in this episode. Here, I want to

talk a bit about independent research and how this whole thing with Jonathan Edwards kind of got started. So Nadia, I really don't know how to pronounce her last name, Engelbart. Let me check. Nadia Engelball. Maybe I'll have her on the podcast one day and she'll teach me how to say her name. She has had a really large positive impact on my work. A lot of her, I've been following her, you know, like most of us since she kind of came on the scene out of nowhere talking about the sustainability of open source. Then she went on to work at GitHub. They snatched her up like after a year of her blogging. And then she's now at Protocol Labs doing research. So she has a really great setup and she has a wonderful voice.

And yeah, so I've been following her for a while. But recently, she just published an article on independent research, the idea of a gentleman scientist, which is exactly what I'm trying to do, which is what Jonathan Edwards does. And she kind of puts it in a historical context. This has been going on for a long, long time, and it's really helped me explain to myself and others what it is that I'm trying to do here with this independent research, and it connected me to Philip Guo, who's really been taken with this idea. He sent me, he has a five-part audio series on independent research, which was really great. And that series actually inspired me to turn what was then just like a blog post about functional reactive programming

into the paper I submitted to Rebels. And it also inspired, I didn't realize this until later, that essay and Philip Guo inspired Jonathan Edwards himself to, uh, to mentor me. Um, I think the way Jonathan put it was if independent research is going to work, we need independent advising, independent mentoring. And so, so, uh, he's living it and I, I really appreciate it. And I really appreciate Nadia and Philip's, uh, efforts there because they have really directly impacted me. Um, one thing that I've learned, uh, from Philipip you'll see this in the conversation we had that'll be on his podcast maybe i'll repost it on my podcast um is he there really is no free lunch um it's not like researchers in in academic institutions have it so much easier than i do

they too have to work to fund their research. They just teach where I'm doing freelance software work. So if you have a normal engineering job, that's the way you earn money and then on your free time, you can do research. There's really no free lunch. I guess, you know, maybe Nadia, who now works at Protocol Labs, maybe she has it pretty good.

She gets paid full time to do the research she wants. But I imagine even she has, you know, constraints with that gig. You know, maybe maybe not maybe she has it has good really unless you're independently wealthy you're gonna have to do work for money some way somehow so uh so anyways I mean I mean this to to say how um I'm happy with the setup I have now. And to be clear, that setup is freelance. So I am still freelancing for Dark, doing research for them in my free time. I may also start doing some essay writing for them. I'm also really, really excited to have a gig at First Round Capital. I work really well with those guys. They have me working on a

project that I can pretty much own myself, but it's really important to them. So they're happy to invest in making it better and squashing bugs. So it's really great. I can work when I want and do my research when I want. So that's all great. And I also picked up a third kind of part-time gig at the Jane Family Institute. They're paying me to write essays for their new blog. And it's really, I'm kind of too busy to pick up a third job, especially if I'm going to write an essay about dynamic land. And so I went ahead and I did it and I'm really glad that I did. I think it came out well. I'm excited about it. I think it explains the importance of an institution like dynamic land to a more lay audience. If you're a technical audience and you want to understand dynamic land, Omar Rizwan, who I just interviewed my podcast, he's got you covered.

Listen to the episode. And also he has a wonderful blog, a wonderful essay on the topic. So, so he's got you covered. If you're technical. And also, he has a wonderful blog, a wonderful essay on the topic. So he's got you covered if you're technical. If you're not technical, I wrote more of a journalistic piece that hopefully will come out in the next few weeks. And so I'm happy with his freelance lifestyle. I only get to work maybe 20 hours a week on my research, which is a bit of a bummer. It's not much, and I'm trying to do big stuff, but it's sustainable. I can do it really indefinitely. So I'm excited about that for now. And maybe if I get tired of freelance down the line, maybe I'll find some other setup. I know my buddy, Paul Chisano, eventually got tired of the freelance and research lifestyle and he raised money and started a company. Maybe that's for me.

I don't think that's for me. I don't, I don't love that, that style, but, um, but maybe, maybe we'll, we'll see if I, if I, um, have an idea that's VC fundable one day. Uh, okay. So other, other updates. I, uh, my girlfriend and I have decided to move to London, uh, which is really exciting. Uh, it's not a, it's not a done deal yet because I still need to get this visa thing situated. It looks like, as far as we could tell, the only option I had is to get this exceptional tech talent visa option that they have because I don't have a sponsor and a few other options don't work for me. That was really the only one that works and I'm lucky that they have that. It's a really great option. If I get it, then I really can work for who I want and stay there for five years. And then

after that, I can probably stay longer. So anyways, I applied under the exceptional promise category for young people who one day will have exceptional tech talent. And I took the analytics from this podcast and the Slack and my website and some nice tweets that people said about me and put them all together. Wrote an essay explaining what it is that I do. Jonathan Edwards sent a really nice letter of recommendation. I sent it over to the UK and they approved the first part. So I was endorsed as having technical promise. 60% of people get this, so it's not that impressive.

And now I'm just kind of trying to convince the British government that I'm not a felon. I sent them my fingerprints and all that stuff. And so hopefully in the next few weeks, I'll hear back. I'll get this visa. And then we'll move over hopefully early October. So I'll be in London, in Europe. So hopefully I'll get to spend more time with my European tech friends out there. I know there are a lot of people actually. However, in London, I really just have one friend at this point, one confirmed friend, Stefan Lesser. So I'm really eager to meet people in London. If you're in London, please reach out. If you have friends in London, send them my way. I'm doing this new thing where I ask everyone I know or everyone I like if they have friends that they think I'd like in London.

And one by one, you know, everyone has, you know, one friend, you know, I guess not everyone, but some people, most people have one friend, at least in London. And I'm getting these people lined up. So maybe I'll not be so lonely out there. So I appreciate your help there if you know people. So the podcast and the Slack have been going really well, I think, in the past month. Up until this past week, it really seemed like every day a new person or two is joining the Slack. And Stefan Lesser has actually been doing a great job of instigating really interesting conversations on there. So that's been fun to see. But I think people join

when I publish new episodes, and they find this podcast, they find my website, and they find that little link, and they join the Slack. So I haven't published an episode in a few weeks. So hopefully, now that I'm publishing this episode and the one before, that'll re-instigate that. I have a bit doubts if Slack is the right platform for these kind of conversations. People have been floating the ideas of a wiki, but it's unclear what a specific future of coding wiki would have that the real Wikipedia doesn't have. If you go on Wikipedia's list of visual programming languages, it's unbelievably comprehensive, and each one is linked to a page that explains what it is.

So Wikipedia is a pretty good wiki itself. So on the other hand, Slack is kind of conversational. It'd be neat if these conversations were more threaded and topic-based, but that already exists too. There's tbh.cool.discuss or something like that. Jason Brennan has a chat system set up. I forget, through Spectrum maybe it is. I don't know, maybe through Discord. I forget what platform he uses, but it's on these topics and it's threaded. That alternative already exists. People can pick what they want. I run the Slack, so I hang out there.

But I imagine he has some cool conversations where he's at. So that's that. I'm not going to do much more than just post it and see what happens. You know, I've been seeing really interesting discussions on dev.to these days, which is like Facebook, but for developers. I don't really get it. I've also, you know, as some of you have seen, I'm really enjoying Twitter these days, having a lot of great conversations there. I've been hearing good things about Mastodon,

particularly from Andre Staltz and Paul Fraze, people like that. I haven't yet taken the plunge and joined, but hopefully that'll happen soon. I'm curious what's going on there and what I'm missing. All right, enough about my social stuff. Let's talk about some deeper topics here. So the last time Jonathan Edwards and I met, we set some nice pleasantries, and then there was a pause in the conversation, and he looked at me and he said, okay, so what's your goal? And I loved it. It was, you know, a really great question, and it's a really great way to start. When I was teaching coding to kids, that was really usually the key issue. They'd forgotten what it was that they were trying to do. That, you know, they weren't, like, they were lost in the programming of the

thing, but the main reason they were lost is because they forgot what they were trying to do. They had a top-level goal, and in order to do that, they had a sub-level goal, and then another sub-level goal, and they lost track of how they all connected to each other, and they'd fallen apart. And so they asked me for help, and I was like, well, what is it that you're trying to do?

And they kind of looked at me blankly. Anyways, it's really important to focus on your goals. And Jonathan Edwards is really wonderful at helping me with that. So I think I have a pretty solid answer at this point. My short term goal is to have a functional reactive scratch, as I was mentioning earlier in this episode. And so, so scratch is MIT built this thing, Mitch Resnick, the lifelong kindergarten group at the MIT Media Lab, they built this thing. Some people describe Scratch as a mix between, you know, as if Alan Kay and who is it, maybe Seymour Papert had a baby, something like that. I've since learned that Alan Kay was directly influenced by Seymour Papert. So it's really kind of in the line of Seymour Papert had a baby, something like that. I've since learned that Alan Kay was directly influenced by Seymour Papert. So it's really kind of in the line of Seymour. So Seymour invented Logo, and then Logo kind of begat Scratch, or Logo begat Smalltalk, and Smalltalk

begat Scratch, something along those lines. But what I'm trying to build is also going to be similar to small talk in in some ways so it's similar to scratch in the ways that scratch is amazing kids can just immediately pick it up and start building really complicated games but it'll be similar to small talk in the ways that i hope it'll be more real like adults will use it to build adult apps not not just kids building it for games maybe to start it'll be a game framework, but a game framework isn't a great idea because Scratch already has games covered. So it could be neat if I built a functional reactive framework that's as easy to use as Scratch, but you can use it to make apps like web apps or mobile apps. So those are open questions.

But I think at the very least, just taking exactly Scratch as it is and the target users, kids, and making it more functional reactive, there are people who I think would use that. And it's kind of a dumb answer, but there are people who really enjoy teaching functional programming concepts to kids. Of course, there's the

bootstrap people at Brown University who teach Racket to kids, which is a dialectic lisp. They have this like Big Bang model of computation, which is similar to React in a lot of ways. And then in Canada, there's Christopher Anand, who was on this podcast, who teaches Elm to kids. Also on this podcast, I had... What's his name? Oh yeah, Scott. Um, Scott Mueller was on this podcast talking about teaching Elm to Kids as well on the West Coast. Um, I think there are like a bunch of us teaching Elm to Kids. Actually, Christopher Anand, um, who I mentioned a second ago, he has an iPad app, a structured editor for kids to use Elm to make games. And it's really

wonderful, all that they're doing. But I think if you look at that iPad app, or you look at the materials that Christopher Anand uses to teach kids, it's really telling. You know, the reason I don't like the Elm architecture and why I wrote that essay, there's a section of the app that we just encourage kids not to edit. It's like, you know, this is where gravity is implemented. It just doesn't come together. That's kind of how the Elm architecture is. But that's what I'm trying to fix with an FRP scratch. So it'll be FRP, kind of like Elm, but more FRP.

Elm isn't really that FRP. Elm more inherits from synchronous programming languages than functional reactive languages. Elm has this really cryptic blog post where they explain how they never really were about functional reactive programming. They were more about these synchronous programming languages like Lucid and Lucid Synchron and Estereo, which are more in other

domains. Anyways, so if I built this thing, at the very least, people who want to teach functional reactive programming to kids would use it. But of course, that is not the real ambition. The ambition is for everyone to use it, but you need a first audience. And so kids isn't a terrible one. Maybe game programming for kids, maybe app building for kids. But maybe I could just jump right to adults if I could find like a niche for it to be good at. It remains to be seen. And Jonathan Edwards was really pushing me to focus on this and have good answers to those questions. And I think it's great to have answers to those questions, keep one eye on the horizon and all. But it's a little bit premature, because I'm not

exactly sure. You know, I'm still far away from having something that's even usable. So I want to get there first. And I'm not too worried about building a thing to which there's, you're building a solution to a problem that doesn't exist, because my ultimate goal here is to build a user interface for user interface construction. And user interfaces are unbelievably important. So much, so many of the photons that are hitting our eyes these days come from the user interfaces of our technological devices. They really make up so much of our reality. And despite them being virtual pixels, we treat these pixels, most of us,

as being as fixed as the atoms in our world that are actually fixed and hard to change. And these are the tools that we think with. And not allowing everyday people to customize the tools they think with to their own ideas and democratizing the creation of tools to think with to the world, I think is really holding us back. Another way to think of it is, just take one example in the future of programming so structured editors

editors where you're editing a syntax tree and not editing the text of a program these are unbelievably complicated programs to build we've been working on these programs for decades and decades and none of them have come even close to the fluidity of text editing that is astounding after all this effort, and we

haven't even come close, these two Israeli guys working on Lamdu, like a Haskell-like structured editor, they've been working on it since 2012, 2010, and they've made a lot of great progress, and what they've done is really impressive, but it's still not as good as text. You know, these things take such a long time. And this is just one problem. But if we had a language, like what I'm trying to build, or an environment that made the construction of user interfaces really, really possible

for everyone and easy for everyone, in a powerful way, I think it could change things. It could really democratize the creation of tools to think with um i think it's it's really uh of paramount importance this project uh and so who my first audience is and how i get to a place where it's like the ultimate user interface construction tool these are all really important questions but the prerequisites are prerequisites and they're important in their own right so um my eyes are on the horizon in the right direction, and I know I'm tacking in the right ways.

I'm not sure exactly how I'll get there. There's a lot that remains to be seen. Okay, so longer-term goals. There's this idea that Rommel, R0ML, at Rommel, some of you may have heard of Rommel before. He's on Twitter, at Rommel. So he has this term, liberal software, that I've been really enamored with. Basically, we have free software, which is similar to open source software. Basically, it's the idea that if you're using a software project, you should be able to

modify the source code yourself. And open source is similar to that. Open source is more about reading the source code. It's not about changing the source code of projects you use. It's more about reading the source code and copying and pasting parts of it into projects you use, or just using someone else's thing in your code and not paying them. That's kind of what open source means today. But free software is about, you you know if I'm using a word

processor or an operating system and I wanted to work differently I could just change it because it's running on my machine and so I can change the code running on my machine but free software is not enough anymore because software isn't running on our machines think about Facebook and Google these are all services Twitter they're all LinkedIn, you know, a lot of these social services, but even just big services, they all run other servers elsewhere. And so even if these companies made their code open source tomorrow, there are two major problems to allowing us to actually change the code. So of course, we could use their

copy and paste some of their code to our applications to make them better, but there are two real impediments to us changing the apps that we use. So the major impediment is that they're giving us the code but not access to modifying the runtime. So if I want to change the way Facebook works, like they won't let me edit the way their servers work, they won't let me push code to their repositories. Just read it. And for good reasons. Yet, this is a real impediment to changing, you know, to free software. And so he's called this idea of the access to editing of the runtime environment liberal software.

And there are a ton of security concerns, a lot of concerns. Security is maybe the least of them that need to be solved in order to make this feasible. But it's a worthwhile goal. I think that the social web, Mastodon and all those things, because of its decentralized nature, that really, I think, is a great tactic to solving the problem of liberal runtime software. But another key problem, the angle that I've been focused on, is the comprehensibility of large software projects. When you open source something like Google Docs or Microsoft Word or Facebook, it's useless to everybody. Only people whose full-time job it is to understand and maintain an application like that can actually modify it.

Unless you build a system with comprehensibility in mind such that people can casually in the course of using an application modify it that's the ultimate goal almost like every app you use on your phone or your your your computer has like another layer or another view kind of like inspect element you could just pop over and i want this even on the phone because phone doesn't have an inspect element. You just pop over and move things around and change them. And of course we'll need really good permissioning systems so that, you know, maybe it only changes it for you or, um, people who accept your changes or yada yada. Um, but, but that, that's the ultimate goal, uh, that like, you don't have

just like a dumb little settings menu. You have this unbelievably expressive menu to customize things. And if you just think hard, if you put on this lens in your daily life, you'll come in contact with a million little things that you want, full programmatic expressibility in your daily apps. But they don't compose, they don't allow for that like i want you know i have my my family and friends some of my friends on find my friends on my iphone i want you know when a friend leaves this place but but you know it's coming close to me but not you know like i want like a really complicated expression for you know when

to let me know my friends are coming close you know about to arrive at my house so i can prepare um it's not you know not going to change the world this application i could just ask them to let me know my friends are coming close you know about to arrive in my house so i can prepare um it's not you know not going to change the world this application i could just ask them to text me but they're like little things that would be really neat uh to just have programmatically uh in the applications that i use and so that's kind of the world we're going towards this liberal software composability of apps we we're really getting rid of apps, breaking down those barriers and having a more computing environment somehow, which is similar in some respects

to like the small talk operating systems. But I really kind of, to be honest, always hated the looks of those things. The nested windows, the context menu, the right clicking, they always kind of bugged me. But that's not to say I know how to do it better. All right. So let's just talk a bit about some other key problems towards this vision

or just things that are on my mind. Just for interesting, they're interesting. So collaboration on code this is like a really big problem i uh i put out uh this work wolf js workflow you know here let me make a note to myself um wolf js workflow on homepage i'll make a note to myself to put that on the homepage so it's a little bit more accessible. I did it actually to attend a conference Jonathan Edwards put on about a year ago. I may have mentioned it before here.

It's a really cool way to think about collaboration. It's similar to Git in that there are branches. One way to describe it is that it's got the commit message reverse. So you first explain what you're going to's got the commit message reverse so you first explain what you're going to do and the subtask of what you're going to do in the subtask so you kind of put out a you you construct this branch structure in your ide about um all the problems you have to solve and the sub problems and the sub problems and the sub problems and then you you go to one of those tasks and you edit the code and each task has a has like a fork of the code

and when you're done with the task you had done and it merges it up into the parent and then you can work on other subtasks or you can even stop and go go work on an independent task and it keeps your code all kind of um branched and forked and and isolated from each other part of what's really excited about this is um like I was saying before, it really keeps you on the money. You know what you're currently working on, how it fits into a broader context and how that fits into a broader context.

This app kind of looks like Workflowy or Dynalist, if you're familiar with those tools. And another thing that's really exciting about this is it enables multi-level pull requests and collaboration. Right now, if you want to help me with my application, you can submit a bug, you know, you can see a bug and you want to submit a pull request to it. You can do that, but it's just one level collaboration. You have to do the entire pull request yourself. How neat would it be if I could start a pull request, but kind of outline it and you could do some of the subtasks, someone

else could do some of the subtasks, the subt do some of the subtasks the subtasks are those subtasks and so it really enables multi-level collaboration obviously in practice this is going to be harder than I'm making out to be even just like a prototype of this was impossible to build you can still play with it with js.com workflow but it's very buggy. It doesn't really work. But that's a problem. That's another problem that's going to have to be worked on at some point by somebody. But I'm putting it off for now. Another problem that will have to be worked on eventually is the authentication and permissioning,

basically back-end stuff. Firebase kind of does that for me right now, but we have to do much better than that. Speaking of Firebase and databases, I think that's a good way to transition into this other topic that I've become a little bit obsessed with. That is very, very, very hard to describe. So I'm just going to talk around it and hopefully it'll build up a picture in your head. So if you think about databases, so one of the main ideas about SQL, how it came about, was this idea of data independence.

So in two different ways. One, data independence from the representation on the file. So you can describe your data in a more abstract way and the programmer never has to worry about where in files it's split up. So that's one data independence. And then the other one, the one I'm more talking about,

is path independence. So if you have in JSON or in a Mongo database, if you have nested data that really goes deeply nested, what you're going to have to do in order to make it performant is you're going to have to have that data in a bunch of different formats in a bunch of different ways. And so there'll be a lot of different paths to get at your data. You can go through the posts list, or you can go through the authors list, and you can get the same data multiple different ways. And so what SQL has done is created this denormalized form, or maybe it's actually

normalized form. I always get it confused. I think normalized means everything's kind of orthogonal. So that would make more sense. So what I mean by this phrase that I'm not sure if I'm saying the opposite of what I mean, is that the data is only stored once, and there's really only one way to get at it. If you want a certain kind of data, there's exactly one way to get at it you know if you want a certain kind of data there's exactly one query to get at the data you want there is no more than exactly one query um and it didn't really occur to me why this was so important um but it kind of is you know i was writing an app um and i had structured it in json in one, in a nested way, but it turns out that then I had to apply all these transformations

to get it into another format to display it in some other way. And it was very frustrating. I was like, why does the choice of data structure matter here? I just want the most abstract way, the most essential way to store this data and then forget about it.

I'll want different views over that data, but I't want to have to like mess with the data structure i just want to like apply views transfer you know on top of it so uh it got me thinking you know like we have a whole class in computer science called you know algorithms and data structures and both of those things are really way too low level to be focused on. Algorithms are, you know, ways to carry out high level goals, like sorting a list. You know, it's very easy to describe what sorting a list is, you know, I want a list that has the same amount of elements as the input list and the same exact elements as the input list, but the order has changed such that each element is less than or equal to its neighbor, given such given an input sorting function as well, let's say.

So it's very easy to describe what sorting is. And then in a different language, like an implementation layer, we can come up with a lot of different sorting algorithms. But who cares about those things? That's kind of below our level of abstraction. It's below the level we care about sorting, I would argue. So part of where I'm getting at with these ideas is Brooks's idea of essential versus incidental complexity, or essential versus accidental complexity. Essential complexity must be abstract. It must be abstract it must be singular it must be being not doing so that's another related concept being versus doing so functional programming is being and imperative programming is doing it's a phrase i really love and i'm sure i read i didn't

come up with it myself i'm sure i read it somewhere i just i've looked and i can't find it anywhere the the words being and doing aren't great Google keywords. So if anyone knows where that comes from, please let me know. But let's unpack that a bit. So imperative programming is doing. So when you, every line of an imperative program is, you know, store some value into a memory address, go to the next line of the code, maybe do this line if this is the case, don't do this line if this isn't the case, call this function, make some HTTP requests, put something into a file, all doing.

It's instructions all the way down. But functional programming is much more like math. It's much more like being. X is twice Y. There's no doing there. It's just a relationship. You can never change X. X is always twice Y. And Y likely is just a constant because that's mostly how functional programming works. But then, of course, you wonder, well, I want things to change over time. I can't just have these transformational programs. Functional programming really shines well for transformational programs. You have one input and one output, and you just do some transformation on top of it.

But what about reactive programs, programs that have to respond to various inputs over time? So in the past, the way we did things like that was, you know, like, you know what? We just need imperative programming. We need like an escape hatch. We need the IO monad to just let us go ahead and add characters to the terminal one by one or mutate the DOM nodes one by one. But then Colonel Elliot came along and was like, you know what? No, we don't need that.

We can build a better abstraction and get around this IO monad thing. It's not that monads are bad, it's that the IO monad is bad. And that's a really key concept here. Connell has this unbelievably amazing blog post, Will Functional Programming Be Ever Liberated from the Von Neumann Architecture? And it's a pun on, Will Programming Ever Be Liberated from the Von Neumann Architecture? Which was a Turing Lecture Award.

I think Backus did it. Amazing lecture. You should read both essays multiple times. I've read both multiple times, and I still need to read them more. There's just so much wisdom in there. I really think about those essays, particularly Connell's, really every day. He talks about removing, taking IO out of a programming model and into the implementation layer. So that's what I was talking about before with sort, for example. And it sounds like I'm kind of obliquely referencing dependent types. You know,

I can describe a list and describe certain properties of that list in types. And then another layer, describe like algorithms. So that's kind of related, but I'm not a dependent types expert. So I'm not sure how related that is. So anyways, back to my analogy. So functional reactive programming is a way to specify reactive systems without any doing. It's all being. You describe the relationships between various entities that change over time in a declarative way. No being necessary. It's really, really beautiful once you get that. And the way he does it, one is this notion of continuous time.

But that's not really necessary because a lot of what happens in reactive systems is discrete time. You have events that occur at one point at a time, and they change things. So even though continuous time was a big part of it, the main thing that FRP does to me is it shows me that we can have declarative semantics for something that really seemed like it would have to be a doing. I think here's the crux of it. The reason that it seems like we're always going to need doing is because a lot of our APIs require it. So the DOM API requires you to mutate nodes by hand. It wasn't until we had React that we realized, oh, wait a second, I don't have to do the jQuery.

I can just describe it to React, and React is just jQuery as a service. It'll go and do the DOM mutations for me based on this virtual DOM thing. But whatever, that's an implementation detail. What we really have here is we have this new layer of abstraction. So React can be the doing, and below it we have Virtual DOM.

So React can be being, and Virtual DOM can be doing. So this begs the question, what are other places where we currently need doing, but if we just had a better abstraction layer, it could be being? And so one place that comes to mind is HTTP requests. It's a really good HTTP request, file read and writes, databases. These are all kind of related things. And it seems like we need doing in order to access them. But that's just a function of how they're built. HTTP requests are basically the equivalent of jQuery. You're like manually going to the server and telling it one thing at a time.

Think about that. When I realized that, I was like, holy crap. It's profound. Maybe it's more obvious to other people. But for me, I think I realized it in the shower. And I was like, holy crap. HTTP is jQuery. Database calls are jQuery.

File read and writes, jQuery. Putting holy crap, HTTP is jQuery. Database calls are jQuery. File reading writes, jQuery. Putting characters in the terminal, jQuery. It's all way too low level and we need higher level abstractions. Now, what are those higher level abstractions? I don't know. I'm not kind of an Elliot. And even if I were, you need a lot of time to think through these abstractions. And maybe other people already have some of this work somewhere else. And if you know about that, please let me know. But these are really wonderful research questions that maybe one day, soon, I'll get to tackle once I've figured out my user interface construction stuff. I think as far as databases go, Datomic, the Rich Hickey's database database company thing is a really cool architecture and

it jives with this functional approach you know you save all the data basically for forever you know you could delete it but the conceptual model is a database is a collection of events it's very reacty in that way but But if you think about it, the datomic model is actually similar to the Elm architecture in ways that I don't like. So I've also thought about ways to get around that and make it even more, I don't know, abstract and explicit.

But it's really its own problem that I'll have to deal with it another time. But at the very least, what this new attitude has given me is confidence to really embrace abstract declarative functional programming. Because in the past, I would look at those things and be like, yeah, they're great for batch programs, but... And I would list the things where you need the IOMONAD for, and I hate the IOMONAD. Not because I don't get MONADs, but because it's not functional programming. It's the programming I don't like. That's what Connell Elliott is trying to tell you. Anyways, now I can

look at those places in functional programming languages where you need the IOMONAD and say, you know what? That's just for now. We're going to find ways to build better abstractions to get over that. On the front end, you're not going to have to make API calls to various services. You're just going to describe what data you want and what data needs to be persisted. And someone else somewhere down the level of abstraction will figure out how to actually get the data where it needs to be in order to fulfill your wishes. But you're not going to have to manage that yourself anymore. Okay, and so there's this, that's my I won't edit obsession thing. But relatedly, I have this other idea about abstraction and canonicalness, which is not really a word and definitionalness, again, not really a word. So the idea is, if you have something that's abstract enough, shouldn't it be singular?

If I have the essential complexity of an app or a concept in my hands, shouldn't it be the only one? If I have an idea and it's fully specified in some abstract form, in that same encoding, of course, if you have a different encoding, a different language, you can have a different representation. But in the same encoding, if you're able to come up with a different way to say the same thing, I feel like there's some information that's not being communicated into the encoding. The encoding is somehow lossy.

So, for example, 2 more than y. 2 plus y. You know, that idea is equivalent to y plus 2. It's also equivalent to a lot of other not fully reduced ideas. But fully reduced, 2 plus y and y plus 2, that's about as good as you get so i think a fully abstract form to express that idea is the set of x plus two or two plus x you know you have to have them both to to explain the idea or you say like you know x plus two and addition is associative but basically you need in your encoding to explain this is it like this is the one representation

um because if there's more than one representation and you don't have that data in the representation itself it leads to all sorts of weird things like you know how you know let's say two people are working on the same project and they do the same thing but in two different ways and now they have to figure out whose is better no it should it should be the same, or the computer should somehow know that the two things are equivalent. You're not being abstract enough somehow. So that's part of the idea. You may be asking, like, why do I care about this? It's hard to say. Just for years now, I've been really obsessed with the idea of

canonicalness. Like, ideas, they're one place. And you can't talk about canonical-ness without talking about hashes. I love hashes. It's one of my favorite parts about Git and GitHub. Hashes, you know, every version of every file I've ever worked on has its unique hash. Commits have hashes. It just, I can highlight lines on a hash. It's just so great to be able to refer to exactly what I'm talking about and never have it change. So I think it would be neat if the same thing could be true about more things. Paul Trisano's language, Unison, has a really cool system for its naming convention. So every language I've ever heard of uses text-based names and namespacing in order to specify what you're talking about.

But his system uses identifiers, like most user interfaces. So when you're talking about a function, you're talking about a specific thing. And if someone changes a function, they're talking about a different thing. So it's hash based identity. So it's not name based. So if someone pushes a new version of a library or function within a library, you don't you don't pull that automatically, your hashes in your code will refer to the old hashes. The names, you know, there'll be names like superficially on top so you're not going to be reading hashes in your code but under the hood that's that's how it's represented represented and if you if you do want to update to the new hash you can and it'll take you through

whether or not it type checks and and those sorts of things um but i just love this idea that code is hashes like i don't have to worry about versions and names and pull. Like, I can literally send, if I want some code to run on some other server, I send them a hash. One single hash. And that hash, if they don't have the code for that hash, it goes to some server, maybe mine, maybe some centralized NPM-ish thing. And it says, you know, give me the definition for this hash. You know, recursively. And so it'll sync based on

what hashes I already have locally and what hashes I don't. It'll just send me all the data I need to run this program. And all of a sudden, I'm off into the races. There's no resolving that needs to happen. It's canonical.

You know, it's just, it's hashes. So anyways, that's another idea I'm thinking about. Like, how do we make programming more abstract, more canonical, more hashy? All right. This is a bunch of rants. I hope you're having fun.

I'm having fun. One final little ranty topic. So I played a bit in my research for Dark with Wolfram, the Wolfram language notebook, and also Observable HQ. And, you know, I really had a lot of fun in both. Um, I also played a bit with APL, uh, Rommel has taught me a bit of APL. Um, and I've been doing some spreadsheet work and also, um, I've really been inspired by Glenn Chiacchiere's flow sheets, demos, and his recent essay on the humane representation of a code library. And so I've been thinking about this notebook infrastructure and it's okay, you know,

it's a lot of fun, but there's just so much more it could be, so much better it could be. I've seen a lot of hints of that recently. And so I've just been getting excited about this idea of, I've been calling it a data slice and dice ninja playground. I think that could be a really fun thing to work on. Kind of be like a lot like Excel or a lot like a Python or Observable HQ or Wolfram Notebook or Tableau or Looker. You know, it's a way to pull in data, slice and dice, join it, graph it, that sort of thing. A lot of people work in this problem, but really only Glenn Cacchiari is working on it in a way that I'm pumped about. But he, as many of you are sad to know,

is leaving this field. You know, he worked in this field for a couple of years and produced some amazing work. He worked at Scratch, he worked at Dynamic Land and the lab that it was before it was Dynamic Land. But, and he has a lot of wonderful things to, he's learned a lot of things and he has a lot of wonderful things to communicate into this world of future programming.

But he's moving on getting his degree in counseling or psychology. I'm not exactly sure which one, but he's going to be, you know, he's really switching fields entirely, which is, you know, sad for us, sad for us, but, you know, happy for him and his patients because he's, I'm sure he'll be great at it and he seems to enjoy this new role. But anyways, he's got this wonderful idea of flow sheets, which he's turning into a business. I forget what the name of the new one is called.

But it's similar to Yahoo Pipes in spirit. But anyways, hopefully he's able to build something cool that we can all use and at the very least learn from. But I do feel like there's a hole here that he's created. He's produced all these wonderful ideas about where we can go with a tool like this. But I don't know how much of it he'll be able to realize on his own

now that he has all these new responsibilities. Okay, so that's the Data Ninja Playground. I'm not going to go too much into how I think it could be better on this episode. I'm just not feeling like it right now. I'll put some notes in this episode to take you to where I have some thoughts on that. The short of it is we need to show both the data at all times, for sure, and the code, mostly. So you maybe hide the code sometimes.

But if you really want to see the data and the code, you you maybe hide the code sometimes but you really want to see the data and the code you should be able to hide them when you want and the relationships between them and of course it should be reactive more being less doing um so so that is that all right so let's just chat uh briefly about the next few, the future. So I think in the future work section of my FRP paper that I submitted to Rebels, that pretty well explains what I'm going to be doing the next few months, maybe the next year, maybe longer. Who knows how long I'll be able to stick with this line of inquiry. At some point, maybe I'll admit defeat and find another way to attack this problem. Who knows?

But anyways, to give you a brief summary, I have found through this Haskell library reflex some pretty good semantics for functional reactive programming. And in order to make the next step, I need visual metaphors. So why do I need visual metaphors. So why do I need visual metaphors? Functional reactive programming is hard, very, very hard. It takes even smart people a long, long, long time to figure it out. Even a bastardized, you know, simpler form of it like Elm or React still takes a long, long, long, long, long time to get your head around and learn. So that's a problem,

but I'm making it even worse because I'm not only taking a simplified version of FRP, I'm taking the whole bonanza. I'm taking cyclical and higher order, which means streams can reference themselves and streams can contain other streams. I'm taking the whole bonanza and I'm throwing it at people. And I want it to be easier than than what they had before so you know maybe there's a way to do this in text i don't think so i think this is going to require a real legitimate notation uh diagrams something something i don't know i have an image up here in the episode notes if you want to see kind of where my head's at um but like i think jonathan had said, like, I kind of have to be Leibniz here. Like, I have to, like,

invent a notation, invent visual metaphors to simplify this problem. And, you know, because Newton invented calculus, but it wasn't until Leibniz's notation that really, there were a whole bunch of problems that existed that just disappeared with his notation. Notations can really solve problems. Think about Arabic numerals versus Roman numerals. Notations really can conceptually make things so much simpler. So that's what I'm going to be working on the next few months. Hopefully, I can stick with this problem. It's going to be hard.

And more than hard, it's just hard to make progress on a problem like this it's very i think zero to one it's not like i can i like know what i'm building i have like a mock-up and i'm like slowly coding my way towards it this is like i'm gonna need inspiration i'm gonna have like a lot of nothing to show for myself except for bad drawings until i have like good ones you know it's it's it's gonna be hard it's almost like proving a mathematical proof it's just it's hard taxing mentally exhausting like proving a mathematical proof. It's just, it's hard, taxing, mentally exhausting work. So anyways, that's what I've set myself up for. And I'm kind of excited about it, but I also know that it'll be tricky.

I bought myself an Apple Pencil. It's quite a splurge, but I'm excited about it for this new phase of my research. And yeah, that'll mostly be what my research is focused on. Maybe I'll continue working on the semantics a bit. So I figured out that I like Haskell's Reflex. Maybe I'll play a little bit more with Reflex to learn how it works. Maybe I'll try and implement it in JavaScript to understand it better. Maybe I'll use CycleJS or my own little event propagation network.

Because that's the kind of structure you need if you want to do cyclical functional reactive programming. So that might give me some inspiration or at least give me something to do when I'm stuck on the drawing aspects of things. And if I'm really stuck and bored or whatever, I won't force myself to do this work. It's better to just keep moving than it is to get stuck and not do anything. I pretty strongly believe that. So some of these other topics that I mentioned here, like the D&D Ninja Playground or the Anti-IO Monad, maybe I'll pick up one of those and put this FRP thing on pause if, this FRP thing on pause if, if, um, emotionally I need to do that. So that, that all remains to be seen. Um, so yeah, so that's, that's what's been going on with me the last two months and hopefully the next few months. Um, for the next

week or so, things are gonna be a little busy this week. I'm on vacation next week. The next few weeks I'm packing up to leave to go to London, then I'm gonna move in London. So I imagine, and I have a few part-time gigs I'm juggling, so I imagine I'm gonna be pretty busy. So maybe I won't get as much done as I usually do the next month or two, but I think I'll get some good work done. I'm excited to get back the Rebels paper soon, in a few weeks, and incorporate those feedbacks, and I hope I get in. Either way, if I get in or if I don't,

I will package up my paper into a talk and put it on YouTube. Maybe I'll read it on the podcast, but it's tough because it's very visual, so I'll do my best. So look out for that in the next few months. I am excited to resume these reflection episodes. I think I'm going to call them reflections instead of research recaps going forward. I'm excited to resume them, but we shall see. Maybe I'll do another one. Now it's August. So maybe I'll do another one in October

or November. We shall see. Um, and I think that is it. Um, oh, if anyone has any free time, give me, give me some love on iTunes, five stars, or, you know, however many stars you think I deserve. And, um, a nice note would be good. Uh, always, Always helpful to be extra discoverable. And that's it. If you're listening and you want to chat, reach out. It always makes my day to hear from people who listen and get value from these things. I don't ask for donations.

All I ask for is a nice word here and there. So I'd appreciate it. All right. Thanks for listening, and I'll catch you guys soon.