Future of Coding - De-Nerding Programming: Jonathan Edwards

Episode Date: March 2, 2019

Jonathan Edwards is an independent researcher working on drastically simplifying programming for beginners. He is known for his Subtext series of programming language experiments and his Alarming Development blog. He has been a researcher at MIT CSAIL and CDG/HARC. He tweets @jonathoda.Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Hello, and welcome to the Future of Coding. This is Steve Krause. So today we have a very special guest on the podcast, someone who does not need much of an introduction for this crowd. Jonathan Edwards is a researcher and community organizer extraordinaire that I'm sure many of you have seen before. He's organized the live programming workshops, the future of programming workshops, and he's very well known for his subtext videos and papers, and also Chorus, which is related. We hear about how those two projects are related in this conversation.

And I'm also really glad in this conversation we get to hear some of his backstory, stuff I didn't know. Jonathan has been working on future of programming topics for decades now. So he's really a wealth of knowledge and experience at doing this, which is why he's been so invaluable to me as my advisor, which many of you know we've been partnering up for the last, I guess, almost a year now. Jonathan has been meeting with me every couple of weeks, every week, every other week, depending on how much feedback I need. It's been amazing to get his direction, having me pick topics to work through and focus down on them, which workshops and conferences to submit to and how

and which conferences to even attend and how to go about it. It's been a wonderful partnership, and I'm quite thankful to have him on my team. So in this conversation, we get some of his backstory about how he originally started a future programming company. I think it was in the 80s. And they sold it in the 90s, late 90s. And then in the early 2000s, began working at CSAIL, Daniel Jackson's group at MIT, where he did his initial subtext papers. Then he moved on to Alex Worth's group at Algon K's CDG. And then for the last two years, he's been independent, like me. And so that's part of why we decided to team up together. And yeah, so we hear about his perspective on trying to improve programming, what works,

what doesn't, his current work, and what he hopes for the future. So before we give you Jonathan Edwards, a quick message from our sponsor. Replit is an online REPL for over 30 languages. It started out as a code playground, but now it scales up to a full development environment where you can do everything from deploying web servers to training ML models, all driven by the REPL. They're a small startup in San Francisco, but they reach millions of programmers, students, and teachers. They're looking for hackers interested in the future of coding and making software tools more accessible and enjoyable. So email jobs at

REPLIT if you're interested in learning more. And without any further ado, I bring you Jonathan Edwards. Welcome, Jonathan. Thanks for having me, Steve. Really excited to have this conversation. Yeah. So I wanted to start at the beginning because you've had a really interesting career and you've done a lot of, you know, you've been working on improving programming. You've been a programmer for a long time and you've been working on improving programming for a while. So I wanted to get like a quick life story or a quick arc of your path as a programmer and also as someone working to improve programming. Okay, the quick arc. Well, I guess I started young, and I started young a long time ago.

I was a child prodigy. I went to college when I was 13, where I ran into the first mini computers. So this was I was 13. This was 1970. And, you know, I sort of fell in love with programming. Immediately, it's just sort of clicked with me instantly. But I think that, you know, I'm one of the oldest young programmers. I mean, in terms of people, when you're starting young like that at 13, 14, and doing so in 1970, there weren't a lot of us, and we only got access to computers through various strange circumstances. So I'd say that's a strange thing about my story.

I did the academic thing for a little bit, but didn't really feel like it was working for me. So I dropped out, got a job, of course programming, which was the only thing I knew how to do, had any value. Sorry to interrupt. You said you did the academic thing. Do you mean you dropped out of college when you were like 14 or 15? Was I 17 or 18 when I dropped out? I almost finished my undergraduate degree. But, you know, I had a lot of personal issues, you know. I was part of this experiment on, you know, precocious, and they just threw me into college at 13, and I was on my own living in the dorms, and no counseling or help or anything. It would be considered – it would never pass any review board today.

It was clearly very questionable practice. I got a little screwed up as a result socially and emotionally. Wow. Wow. Crazy. You seem all right to me. I've had to learn how to simulate being a human. And over the years, I've gotten, I guess, reasonably passable at it. Okay.

So sorry. So continue your story of you left college and you started a company. Is that what you said? Well, I left college. I got a job programming. I was working on Wall Street doing the very first wave of automation of money transfer using many computers, PDP-11s originally. We came in and we replaced teletypes that were previously being used to transfer money around the world so you know this was in the mid mid to late 70s um the very first wave of of of automation really rolling out into into businesses i was um so i was part of that. I started my own company in 1980, doing the same stuff, working on this new technology, the VAX, that was also from DEC, Digital Equipment Corporation, who was one of the big, big computer companies back then. Do you know about DEC? Have you heard of them?

Nope. Okay, right. So after IBM, they were the next big computer company, and they were the mini computers, the PDP-11s and the VAXs, and the Unix was going to invent this sort of next generation database programming language environment for online businesses. Today, it would be called a NoSQL database, but this was in 1980. I mean, the relational databases were just, Oracle was just really starting to hit their stride and it just took over the world. So that whole idea of selling a database clearly became unreasonable, unattainable. So we fell back to our plan B, which was this banking money transfer application that we built on top of this experimental database and just started focusing on that and built a conventional software company in the 80s and the 90s,

slowly built it up and eventually sold it in 98, part of the first dot-com boom when valuations were crazy. So very good timing on my part, pure luck. And I spent a few more years transitioning out of the company, but I've been dedicating myself to research ever since, trying to improve programming, which is really what was driving me all along. I mean, at that company I started, I really did try some crazy researchy ideas, trying to make programming better. It was a crazy idea to try and do research as part of a company starting up, a bootstrap company. It was not an easy experience, but since then I've had the freedom to try and work on ideas. I find it fascinating.

So you fell in love with programming at an early age. And then after you left school, basically your whole life, you've been trying to improve programming, which I think is an interesting... My story is similar in that I fell in love with programming at an early age. And also, I'm trying to improve programming. my story is kind of similar in that like i fell in love with programming at an early age and and also i'm trying to improve programming and there's like a funny contradiction there because on the one hand we love programming so much but but on the other hand we think it needs to change so strongly well yeah so right that is a contradiction and and it's it's like um you know you have the power of the gods right you are you are creating universes out of pure thought right yet it ends up being you're in hell with this

drudgery and this you know stupefying repetitious nature of it you know i think of it as intellectual ditch digging right you you know it's just so repetitive, and so manually intensive. And you do the same things over and over again, except that they're just a little bit different each time. And you have to be brilliant to understand the teeny little differences, right? You know, it's just, it's crazy. And, and it was just always, I had this feeling from the almost the very beginning that we're in the stone age of programming. I mean, clearly, we're not doing it right, right? We're just, we have no idea what we're doing, really.

And that's why I saw this as a challenge. I felt like I was born for this challenge to try and, okay, let's figure it out, right? This is something completely new. We're doing it all wrong. And so this is a chance to make a mark. Another thing I find interesting, almost like a contradiction in your story, is that you were this child prodigy who took to programming so easily. And yet one of your focuses is on improving the simplicity of programming so that more people can do it. And so I'm wondering where that empathy is coming from.

Like, why? Yes. Yeah. Yeah, so you're right. And that's been a major change of direction for me that's taken me a long time, a long evolution. So of course, I started off the same as everybody starts off, trying to make programming better for myself and people like me, meaning professional programmers and, you know, nerdy people that think the way I do. And it just, that was, didn't, I didn't get very far.

And I can't say exactly if there wasn't any epiphany it was just I slowly started trying to think about okay what's really the problem here and I would say I would guess so so the way I put it as after enough decades of programming you start you know we're very bad at consciousness right at reflection and being aware of what we're doing okay and it takes a long time to sort of start to clue in to what's really going on as we think and do things so just after decades and decades of programming and and really trying hard to understand what's going on in my head when I'm programming. That was always my source material. What is going on in my head while I'm programming? And so what are the problems that I'm facing? And I started to realize that, you know, I'm actually not very smart when it comes

to programming. It's really, really hard. And the things that trip us up are all these things we love, our abstractions, right? We build up these wonderful abstractions and we add layers of indirection and so forth. And we had these mathematical kind of patterns to it. And it just bit by bit, I started to realize that this was the problem, that the things we liked about programming were actually the source of the difficulty. I think starting to do UI programming helped because there, you know, it's a slightly, I don't know how to describe it, but you're faced with simplicity more objectively there. You can see that, you know, I built this, this terrible UI, what was I thinking, you know, this is horrible, right, you know, and learning how to simplify things down and realize what's really going on. So those kind of learning experiences just slowly

started to add up for me. And I just started to realize that, that we've made programming hard you know it's it's that um i don't really know how to describe this uh communicate it too well perhaps but um the things we like the most about programming we've overdone it right so there needs to be we're really bad at abstraction and abstract thought and even though those of us who are good at it are the ones that flourish in programming, yet even we don't have the power enough to pull it off, right? We're constantly failing and making mistakes and unable to comprehend what it is that we've just done. So that's the problem. If we could only just minimize this intense intellectual burden of programming, then regular people would be able to

do it, but we'd also be able to do more, you know, that really would become more like godlike powers if we weren't constantly humbled by our own stupid thinking mistakes because we've gotten too fancy. One of my formative experiences was wearing a beeper for a decade. This was before cell phones. Getting beeped in the middle of the night to fix production crashes with billions of dollars at stake gave me a whole different perspective on the value of cleverness in programming.

You know, we love coming up with clever solutions to tricky problems. We especially love clever performance optimizations. But they bite you in the ass at 3 a.m. What the user really wants is reliability, which doesn't come from cleverness. It comes from simplicity. My love of fancy abstractions and inventing new things was basically immature self-indulgence. I was doing it to please myself, not to solve the user's problem. I see a lot of that in our Hocker culture. Make any sense? Yeah, it makes a lot of sense. There's a lot there that I want to unpack and go through.

So there's the other side of this coin. Let me add in the other progression. The other evolution was that I was realizing that this is not a technical problem. It's not completely a technical problem. There's a social problem here too. We've built a culture. Nerdy people like me have built this culture of programming being a nerdism safe space. It's our elite place. And we want to encourage all of these things that are hard because that's what makes us elite and a big deal and worth making all this money we do you know so we've built this culture that's reinforces all the worst habits and and you know i just as i started to try and realize making programming was simpler and presenting these ideas to people i would get the most negative reactions from people, particularly, you know, like, you know, alpha programmers types, you know, really, you know,

these guys are serious. They're the smartest programmer in the room. They hated the idea of making things simpler, right? Just like people in previous generation, well, this is too old for you probably, but COBOL, you know, was the original language which tried to make things simpler. And it was just derided and, you know, being a COBOL programmer was a mark of inferiority. So it's the same sort of thing. And I realized, you know, there's something really fucked up here in our culture that is making things hard. And that's when I really just fell out of love with professional programming, you know, and I realized I'm not going to be able to convince these guys to make things simpler, even though it's in their own interest, right? Because they love it being hard. So I just realized I'm going to have to find a new audience. And that audience is people who

haven't been ruined yet, right? They aren't programmers. They aren't nerdy people. They're the ones that would appreciate making programming simpler. And there's where the big win would be, really, right? Because if we could make programming simpler, so many people would be empowered to do things. And maybe it takes a generation for other people to come along and scale it up and become professional programmers with it. So I've essentially given up on the professional programmers.

I think that that whole technology is fine for infrastructure programming, but we're going to have to come up with something simpler for application programming. Okay. Yeah. Okay. There's a lot there. I'm not sure. So yeah, I'm struggling between wanting to dig into a lot of those things. And also, I want to continue with like, kind of in with your life's arc, because I want you to do what you did with like the first half of your life for like the research half as well because you've had it seems like a decade or so of research maybe

more maybe it's two decades now of research and so I kind of want to get an overview of that as well maybe we'll do that first and then we'll kind of jump into some of the specific things you brought up or what do you or do you have a different idea yeah what do you think oh well sure i think i think it's not a very long or interesting story really because oh okay i'm pretty pretty frustrated with my research career i've um haven't really gotten very far i feel i've um only you know i've thrown out some suggestive ideas and a few people who are sort of thinking along similar lines could read between the lines of what I've been saying and see that, you know, we're thinking along, you know, so I've met up with some other people that share these concerns,

but I wouldn't say that I've actually achieved anything. You know,'s been been a real struggle it's I started off I luckily I ran into I started taking some graduate classes I was thinking about doing a PhD I met Daniel Jackson at MIT and he invited me to sit in with his group and And I did. I worked on his alloy programming language and then moved on to doing my own work. And that was for a whole decade I was there. But I didn't really click with anybody else's research is the problem. What I'm doing is really not mainstream academic research. It's very risky, very blue sky. It's not the stuff that

serious career academics would do. It's career-threatening kind of research. So I've been working alone, and my time at MIT sort of ran up, and I started... Sorry, just to interrupt for a sec. I just would want to just get a few dates on these things. So you left your company in like early 90s and then from when to when? Well, so sold the company in 98. I was still, you know, working there for a few years. And let's see, I started at MIT in 2001.

Yeah, the end of 2000, was it 2002? It was 2002, right. And so I was there for about 10 years in Daniel Jackson's group. Oh wow, okay. So a lot of the early subtext. Yeah, the subtext. My original bunch of papers published at Onward

about subtext, example-centric programming was all there. Cool. And then I kind of stopped really publishing. I started doing demos, videos, and kind of stuff, which are less sticky than papers, so they're less known. But things changed at MIT.

I left and I joined Alex Worth at, back then it was called CDG, Alan Kay's lab in LA. I'd met Alex and we got along and, of course, Alan Kay was actually talking about crazy things like me that I was interested in. Actually trying to change stuff fundamentally. So that was a great opportunity. And I was at CDG, which then became HARC when they moved over to the Y Combinator research. So I was associated with them for a couple of years, but then the lab lost its funding.

They just shut down. And that was, what, two years ago. Yeah, just about two years ago. And since then, I've been completely on my own. I also wanted to get in the timeline, at what point did you start the live conference? I feel like you've been part of a few other conferences as well. So I was curious at what point you started doing that kind of organizing activities. So, right. So as I started to realize that our problems are not just technical, they're social.

We have cultural problems. And, you know, the only way you fix cultural problems is with institutions. And our current institutions, I could rant about this a lot, are broken. Our current institutions are really broken. And this is somewhat, you know, expected because we're such a young field. But on the other hand, nobody's working on fixing things. It's really a bad situation. So I realized that I needed to step up and start to try and improve things. I was unhappy with, you know, as everyone is, you know, all researchers are unhappy with the academic peer review process, right? It just seems to

encourage very safe, incremental work, highly technical, highly focused, but, you know, not too relevant, not too important. And so I started realizing, oh, wait, okay, you know, our solution to a blockage is to route around it. Let's just start our own institution. So I started running workshops. I had the future programming workshop. And this was, oh, I mean, you could look it up. I think it was probably back in 2014 or so. I ran several of these. Just being open to crazy ideas, right? And also trying this new idea that I got from Richard Gabriel of, I did, I was doing this with Richard Gabriel of using a writer's workshop format. So instead of it being like a technical scientific paper, instead, it's more like a literary contribution. And the whole

part of it is to work with the other contributors to improve your work. So it's a collaborative thing rather than a competitive, everyone tearing each other down thing. So I did that for several years. And then the live workshop, I didn't start that that was that was some other people I just sort of, you know, I've been doing live programming. So I was part of that naturally. And then I just started organizing that for the last two years with other people. So the live workshop is not my thing at all, but I've been contributing to it. And it seems to be the thing that has the most momentum at the moment. Hmm. Oh, okay. Interesting. I didn't realize you didn't start the live workshop for some reason. I thought you did. No, no, it was on its own, but now I'm part of it.

So speaking of the live workshop, you were recently somewhat proud to be rejected from your own conference. How was that? Well, you know, I shouldn't talk out of school too much because, you know, I was on the program chair and submitted to my own workshop and the reviews were not good. The reviews, you know, so this is a problem, right? Like I said, I was complaining about the peer review process. We have, we've made it into sort of an Olympic sport, which is super competitive. And there's just all these reasons to tear a paper down, you know, and you know, you know about, oh, did they cite the related work? Did they, you know, um, you know, what evaluation methods were used, blah, blah, blah. So for the live workshop, we, we, we explicitly wanted to avoid that kind of evaluations, but some people just out of habit do that. So you get unlucky with the reviewers you get. Some reviewers are open-minded and others are just sort of looking for reasons to tear you

down. And I try to modulate that process when I'm sharing, but, you know, I had to step aside for my own papers, of course. So that's just how it came out. That's okay. I was going to withdraw the paper anyway because we had enough good – I was just really kind of a placeholder that in case we didn't get enough good submissions, I'd do my own thing. But I didn't want to take time away from other people. So it was really not that big a deal.

But it was kind of funny that I got rejected from my own conference. Yes. Well, yeah, I think, like you said, it's kind of a good sign that there was so much other good content that you didn't need to present your own stuff. It was a really wonderful day,

chock full of inspirational, amazing stuff. Yeah, I'm glad you liked it. I think we should keep it going. It's really nice to get that kind of feedback that people found it inspirational or at least supportive. They feel like they're not all alone because there's a lot of us that see that there's some basic things that need to be addressed about programming and that almost no one's doing it and everyone feels like they're

working alone and that's that's really really demotivating right and so that's why I've been trying to come up with these these events that bring people together and gives them some sort of support. Yeah. And it's really just for myself, right? I mean, this is what I need. I perceiving these problems, I perceiving that programming sucks. So I want to fix it, but I also see that the culture of research around programming is broken and I want to try and fix that just because I need it for myself. I need a community too. So I've been trying to build a community. It's so meta. So programming needs to be fixed, but then the improving of programming

needs to be fixed. How about the improving of the improving of programming? Yeah. Yeah. Well, you know, I mean, we're kind of, we're, I mean, I'm an, I guess I'm an engineer. I'm a problem solver. I see a problem and I feel like I'd like to solve it. Yeah. So before we move on and drill into some of the stuff you brought up earlier, which I'm really eager to do, I want to just briefly get an overview of what your current work is focused on. That's a very good question, and I should have an elevator pitch ready. So, well, so the line I would use at a dinner party is that I'm trying to make programming be like spreadsheeting, right? There's no such thing as spreadsheeting, right? You don't really have professional spreadsheeters, right? It's just normal people learn how to use a

spreadsheet. And programming should be that way. You should be able to pick it up, solve your own problems without being some sort of brainiac super nerd, right? It just should be easy to do. And I'm focusing on those kinds of problems that you would want to do with a casual programming, right? Small scale, simple problems solved simply. And application programming is the word for this. It seems to have fallen out of use, though, right? There used to be this clear separation between application and system programming. Are you familiar with that distinction?

I can guess what those terms mean, but they're not in common parlance for me. Right, exactly. So that's my point, is that it's just fallen out of the whole idea that there should be two sort of domains of intensity of programming. It seems to have been forgotten somehow and coincidentally happened when the internet started to make people rich and i think it's not a coincidence but um so we've forgotten about that there's this whole giant world of people with simple problems that need to build applications and shouldn't require years of training right um and and they shouldn't have to be full-time professionals

at programming to be able to solve these simple problems. We've just somehow forgotten about this entire world. So that's my research, is just to try to revive application programming for the modern world. And you look back at the old examples that worked, and probably COBOL, you know, is the original application programming

language. And as I said, muchly derided, but yet it was actually pretty effective. Visual Basic, you know, HyperCard, things like that. These are all in the past, though, because, you know, there's no way to get rich quick with these things so no one's interested in them anymore it seems so um so so you asked me what is my research so you know in the broad stroke it's making programming simple as simple as possible for solving simple small problems this is not building internet startups it's not building operating not building internet startups. It's not building operating systems. It's, you know, it's not any of this hardcore stuff. It's just simple problems in your own life and in your business that you want to solve. And you just don't want to make

a big deal about it. So the interesting questions is, okay, let's, if we make simplicity be the goal, right, what do we get? Because it never has been the goal. And to make this more precise, I think of the metric as, well, the metric should be learning time, right? I mean, we should actually be able to do experiments, take people who have no programming experience and give them this thing and see how long it takes them to be productive. But as a designer, you need a more useful rule of thumb. And so my rule of thumb is the size of the documentation. It's just think, what would it take to explain this fully? In fact, this is a really good rule of thumb whenever you're designing anything for other people to use. What would it take to explain this? And what I've found is that generally, if it's easier to explain, it's going to be a better solution. So, but think about that.

Think about printing out all the complete reference manuals for this programming environment and then stacking them up and measure how high that pile is. If you did that for our current so-called programming stack, I mean, the stack is enormous, right? It'd be really interesting to try and run this experiment, right? But, you know, it's got to be, you know, 10 feet high. It's got to be 20 feet high, right? I mean, just the man pages for Unix alone, right? You know, and the reference manual for C++, right? The specs, right? Look at the standards for all the W3C standards, right? That's probably six feet right there, you know?

So just think about what it's, the amount of knowledge. And we take this for granted, right? There's a word for this. It's called the curse of knowledge, right? Once you've learned something, you take for granted the effort it took to learn that, and it's impossible to reimagine yourself not knowing it. But the reason it takes so many years for a programmer to become an expert

is that they have to master so much knowledge. So that's what I'm trying to do. I'm trying to let you build applications without having to learn a lot of bullshit. Because it is, it's mostly bullshit. I mean, it's just crazy. How can Unix require 1,000 commands? Why does the LS command require hundreds of switches?

Obviously, no one's thinking about simplification here. They just keep adding on more and more and more. Nobody ever thinks about cutting it down. So this sounds a lot like Brad Myers' natural programming project, similar goals, like taking programming and making it as similar to the way people normally do things. Would you say that that's a good point of comparison or is there a distinction you want to articulate? Well, there certainly are distinctions, but I do agree very much with Brad's whole mission

there. I think that is the goal is that that's probably one of the key intellectual thing we've got to break through. There's also just some engineering technical issues, just figuring out how to do things simpler than they are done now, which isn't any deep issue of human nature. It's just good design. It's just good design. It's just things are crazy, complicated, crazily overcomplicated. They need to be reengineered with an eye towards simplicity. And it's just that nobody's doing that.

Nobody gives a damn about simplifying things because it doesn't help them personally immediately. Right. It doesn't help you ship code. It doesn't help you, you know, your your startup to succeed. It doesn't help you ship code. It doesn't help you, you know, your startup to succeed. It doesn't help you to publish papers, right? Because papers, academic papers are always about making things more complicated, not simpler. You know, so there's no incentive system to make things simpler. So part of it is just a matter of we've got to figure out a way of funding the engineering needed to redo stuff.

You know, we just can't keep adding layers. So I'd say that's the other side of the coin. There's this let's just rethink programming conceptually to make it more natural. And that often comes down to reducing abstraction, making things more concrete. Right. A lot about what live programming is about. That often comes down to reducing abstraction, making things more concrete, right? A lot about what live programming is about. And then there's just, let's just figure out how, you know, re-engineer things. It doesn't have to be any great philosophical impact to it.

It's just re-engineering for simplicity. I'd be curious to, like, dig into, like, how to define simplicity. Because it's kind of an amorphous thing to get a hold of. It's very hard. How do you think about it? It is subjective. And that's why I think of it in terms of feat of documentation. And that's a rule of thumb.

The truly scientific way to define it, like I said, is with clinical studies, right? You know, just give this stuff to people and observe how long it takes them to learn it, right? Because learning time, I would say, is the real metric, right? It's also, you know, it's a touchy, very touchy issue, which is sort of IQ and analytical skills. Clearly, there are differences in analytical thinking skills between people. And the way we've built programming very much favors those of us who are really good thinking abstractly with symbols. Good at math is probably the simplest way to sum it up. And we should, part of the natural programming idea is to de-emphasize mathematical thinking skills in programming.

So there's something, it's not just the time it takes to learn, it's also sort of the mental skill, the required to do it at all. So I think I was trying to answer your question, did I? Yeah, yeah. I think an interesting counter way to look at simplicity would be so the way you described it was as a like the startup cost or like the time it takes for you to learn and then once you've learned you're just doing but I think I guess the other way to think about it is simplicity is the cost of doing any like arbitrary thing once you've already learned so like you treat the learning cost as a one-time cost and you're like, I don't care how long

it takes me to learn it. I just want, once I've learned it, once I've learned the tool, for things then to be simple. So is that kind of the opposite of what you're saying or they're more related? You know, I don't know. I mean, that's, you know, I think that's Rich Hickey's point, right? When he talks about, you know, simple versus easy or something like that, right? I'm uncomfortable. I just feel strategically, I want to focus on the learning phase. Because once you're an expert, you know, you're an expert, right? And everything seems easy in some sense to you.

And we get into, and that's the, okay, here's what it is. That's the mode we're in when we talk about improving programming. Most people are talking about, okay, let's make it better for experts. And, okay, that's a good thing to do and but it's not solving the fundamental problem I feel and it's it's sort of masking the real problem which is becoming an expert so I'm just I've just chosen to focus on the learning phase if we could get people to be become experts you know with a hundredth of the time, that's going

to be an enormous big deal. And the other stuff is sort of more the normal day-to-day innovation that we do, normal stuff that we're good at, right? So it's not something I need to do. It's not something with an enormous impact, I guess the way I'd put it. Interesting. Yeah. Well, I guess they're kind of approaching

the same problem from different directions. You could raise the floor and take normal people and make them programmers, or you can kind of lower the ceiling isn't the right way of thinking of it, but you could take expert programming and slowly bring it to normal people, or you could take

normal people and slowly bring them to programming. I know this is more where you're I mean, I don't want to, I know this is more where you're coming from. I don't want to criticize it. I think it's a totally valid thing to be doing. But I would say that, you know, it just, it feels to me like

sort of a endless cycle of fads. You know, it's the experts just have, I like this, you know, first it was objects, now it's functions, you know it's the experts just have i like this you know first it was objects now it's functions you know i don't know i just um it's not it feels to me like it's a cycle you know of of things and um it's but you know more power to that that's you know we can all we can all help in different directions yeah so the answer to your bit to your question after all this is simply like I'm just choosing to work on that aspect of simplicity because I feel that's the hardest and the least addressed at the moment got it getting getting people

making it simpler to learn how to program. Yeah, so one of the things we point to when we talk about how obvious it is that programming is broken, is that there are things that we're simulating in our heads that computers could just simulate for us, obviously. Like we could be simulating Booleans or whatever. You've done a lot of work in this domain

where you're offloading the simulating work of the human brain the human programmer to the computer yes so it uh part of me is wondering if that's like a reasonable foundation for a way to improve programming uh you you basically instead of looking at um the like the stack of everything someone needs to learn you look at every time someone is doing something in their brain that a computer could do better, and you try and put that somehow into the computer? Yes. What do you think about that perspective? if you've decided to use, you know, sort of nuclear powered programming technology, let's say you're programming in, you know, with continuations and, you know, and like, you know, all these category theoretic abstractions that people love these days. Okay. You know, trying to materialize those in a UI

is a Herculean effort. Okay. Maybe it's possible, but maybe you shouldn't have chosen those super powerful abstractions in the first place that are so hard to visualize. So I'm coming at it from the other way. I'm saying, okay, what would be the easiest to visualize? I'm trying to let the programming experience be the driver of the design rather than abstract considerations of power and expressivity and things like that that we normally tend to think of. I'm finding that really helpful that whenever I come to a problem, I think of, okay, how is this going to look in the IDE? You know, what would be the simplest look in the IDE? Go that way, you know.

So let the direct experience of programming with our tools be the guide and choose the programming language to match that. So at the very least, you have to design them together, right? You have to design the programming experience and the semantics of the language together. And I'm sort of tending to say that, well, actually, the experience is even more important. That should be the strongest vote. Yes. So, that's somewhere, even though, I guess, you and I come from different perspectives, like you alluded to, that is one thing that you and I both agree on, which is quite rare.

The experience, so you have to design, I guess there are a few pieces, but one of them is that you have to co-design the semantics and the user experience at the same time like you can't just pick right um you can't just pick some semantics and then like put a good interface on top of it they need to be built together and then the other thing is that the experience should be somehow driving the semantics um so and you know i mean this this is also interesting. This occurred to me recently. So Brett Victor said the same thing at the end of his learnable programming essay. He basically says, has a giant caveat, says, well, you know, I'm not claiming that any of this stuff I showed you actually works or is actually could work. What I'm saying is that we should redesign programming so that we get such an experience. So that's what I've been saying all along. I 100% agree with that. And

this came up because from your previous podcast, you were talking with Vlad, right, about how Brett Victor inspired him. And I think, you know, I think a lot of people that were inspired by Brett Victor don't understand him or at least understand that statement he made, right? Because a lot of people seem to think you can just reskin programming, right? Let's take it as it is and just slap a much nicer UI on top, problem solved. That's not probably going to be possible. Yeah, well, I guess that's what he did in Learnable Programming. He took Processing.js and he just slapped a better UI on top of it. So when you look at that literally and you don't read that section that you mentioned,

yeah, it's easy to see how people misunderstood. I don't know if you'll find this a useful thing to go through, but I feel like there are two sides to this debate. Or like, usually there are two camps, and then you and I, and maybe Brett Victor are kind of in this middle camp. But it feels like there's the semantic people who write academic papers with Greek letters in them. And on the other hand, they're the user interface people, I guess maybe the live people, who take existing programmatic interfaces and then just slap better UIs on top of them. And so there's this kind of gulf

where there's no one who's thinking about doing both at the same time. Yeah, so you and I are kind of... That's hard. It's no man's land. Yes. Right, so the path of least resistance is to go one way or the other, right?

Is to do UI kind of work or to do this abstract semantics work. And if those were sufficient, that would be great, but they haven't solved our problems yet. And so it's a much harder problem than a lot of people wish or are acknowledging, at least. And I think it's just a growth process. that everyone's first attempt is always going to be a data flow programming language, right? With boxes and arrows or something like that, or a spreadsheet style, again, data flow language. So it's just the natural first try.

But after that doesn't solve all the problems, then we need to move on and start getting deeper. Yeah. So I guess one of the big problems people come to once they realize that, you know, data flow programming doesn't, or what people realize, or so at least for me, I can speak to myself, what got me past the like data flow boxes and wires was i i realized that like uh effects state side effects uh like ah like these things are really you know like these things aren't just a side case like the reason spreadsheets aren't programming is that it doesn't have these side effect things but then if we add the side effect things then we lose a lot of the properties of spreadsheets and so you're kind of bingo. So you've done a lot of work.

Like, there are some of your some of your projects. One of your papers I was reading recently, specifically addresses side effects. So yeah, where is your thinking on this now? That is such a central problem, right? Like, that's sort of, you know, the original sin, right? I mean, it is just such an enormous thing. And I've been hacking at that problem from different directions for a long time because, you know, realizing that, you know, this is the central problem. And of course, functional programming was all about this too, right? They realized that that was the central problem. Unfortunately, they sort of kind of just swept it under the rug in various ways. So if we're going to really confront that, how do we do it? And, you know, I'd say this is very much the big challenge and

an open big challenge in this whole field of trying to improve programming, is how do we deal with state? And I would say I've done a bunch of experiments, all of which were failures, educational failures. I learned a lot in the process, but I haven't solved the problem in any means. And my latest thinking, in fact, is that it's just as I've come full circle back to thinking that, you know what, I'm just going to go with naive side effects. And

what I realized is that basically the programming experience just is much more natural, It seems it just works much simpler in simple cases. If you just let there be naive side effects, right? There's a state and you're mutating it because that's what you're doing, right? In a spreadsheet, you know, you're editing the data, you're editing the formulas, right? There's a state of the spreadsheet, right? Right there in front of you. That's a very concrete, intuitive thing. we're used to living in the real world where we change things change as we make actions on them right it's a very intuitive thing so my latest thinking is to simply go back to naive side effecting on state and then try and manage it you know add on

features that can statically analyze what's going on. And I think I can, because of the restricted semantics that I'm using in subtext now, that I can do a better job than has been done in the past. But did you understand that? Or should I go back over that? Oh, yeah. No, yeah. That makes sense.

I think this is a good opportunity to zoom out and just talk about, so you mentioned that side effects and mutable state was like one of like the central issues. So I'd be curious to get your perspective on what the other central issues are. For example, what comes to mind for me would be, you know, we need to reinvent version control. Git clearly isn't the end-all be-all. Okay, so big problems. So, a really big problem for, a really big problem in my mind is the distinction between the programming language and the database, right? There shouldn't be such a distinction, right? Why is it that for data that's going to live more than just the run of a program versus the data that lives while the program's running, why are those so utterly different,

right? They're utterly, utterly different. Not only is the shape different, but the semantics are different, you know, transactions and queries versus objects. And, you know, so I've never understood why we can't solve that problem. It is actually very hard, right? And, but I think it's something we need to solve. There should just be one data model, right? That works for the program. The idea that there's a database in a programming language just seems to me a big mistake, right?

Agreed. So, but, and that used to be a research topic, actually, back in the 80s, right? It was called persistent programming languages, orthogonal persistency, there was a number of buzzwords around it, but it never really, it never worked. No one ever figured it out. And it just sort of dropped off the radar, and people gave up on it. So I think that's something we need to get back to. Sorry, on that line of thinking, I was going to say, what about the distinction between client and server? I feel like that distinction also is artificial and needs to kind of go away. Do you agree there, too? Yes.

Yes, I do. I think that that one's actually sort of easier, I think. I mean, we see, we can see ways of solving that and people have worked on it. And I'm not sure that it isn't mostly just sort of a technology, you know, inertia thing holding us back there. Although I guess that's holding us back everywhere. But yeah, absolutely. Distributed programming is another one of those long-term holy grails that people have repeatedly tried.

I'm not focusing on it myself personally so much because it doesn't loom that large for the low-end kind of stuff I'm focusing on right now. I used to think a lot more about it, though, and it certainly is another open problem. You also mentioned fluidity of structured editing, right? So that's also a really tough problem. We need to get away from keystroke editing as the fundamental operation on changing a program. We need higher level operations and that requires a higher level user interface. And it's hard.

We actually, keystroke editing is actually very easy. It's certainly easy to learn and well supported. Our hardware supports it. And we have actually, you know, letter keys, dedicated letter keys on the keyboard. It's all there for us. And the whole theory of programming languages has been built up around the idea of syntax. So this is another thing that a lot of people initially realize is crazy, that it's like we're programming as if we're still on punched cards, right?

It's all just, or a teletype, right? And why can't we fix that? That's really hard to see how to do it. I've been trying a long time and it's just hard. So I'm realizing now that we probably should have, in my thought, I should have, earlier in this conversation, back when we were going through your life,

I kind of want to get a timeline and definitions for like, what is subtext? What is chorus? Uh, cause, um, like to me, it feels like the, uh, the subtext is kind of like an umbrella term for iterations of, of prototype experiments. So it's almost like in a, um, in like a TV show. That's exactly. That's all it is. It's become just sort of my brand name that I'm iterating on for my experiments. And it's never been a real thing. I've hit this point where I want to stop doing these crazy experiments and pull it together into a real thing. So Subtex is just kind of a brand name for my research project. And there's been various iterations. I've tried slapping different names on it at different times, but they're just

really sort of just they could have version numbers on them as well but i do feel that i've you know maybe you can give me some feedback on this but i feel like i've um at this point i've failed to build anything that's detailed enough that other people could you know sink their teeth into right so i've done these crazy experiments testing the boundaries of what what's possible and i've learned a lot in the process but i don't think i've taught anybody else anything right because they're just too fragmentary and speculative and sketchy. So my goal at this point is to change mode and to try and consolidate what I've learned and just pull it together into a thing,

a programming system that is complete enough to build some reasonable example applications and could be understood and torn apart by other people. Before we talk about the bringing it together work you're doing now, I want to just do a quick overview of past experiments, just to give people who aren't familiar with your work a sense of the breadth of it all. So I got started, I had this original paper called example-centric programming, which was just this idea let's let's let's make concrete examples front and center right as a way of reducing the abstraction load and then i

and that that was done like with that was like a hack on a java interpreter to show how that might work then subtext was the next paper where i was finally saying okay let, let's reinvent a new programming language. And I would say the key idea in there was this idea of managed copy and paste, which I think was a good idea. I didn't take it very far, and I'm just now getting to the point of being able to get back to it, where copy and paste is a first-class citizen. And it's not an evil habit anymore. It's actually the way we program and we track it and we consider it to be more like versioning of code. But that was more of a think piece. Then I started to dig into specific technical problems. So there was the thing about, like you mentioned, Boolean algebra, right, conditionals, and all the crazy thinking we need to do about, you know, if, then, else,

and all stuff. So I did that thing on schematic tables, which was using decision tables to visualize logic in a programming language, which was interesting, but it's pretty much a dead end. I've never figured out how to integrate that fully in any of my subsequent experiments. So that was just a little strange experiment. Then I said, okay, the big issue is side effects, right? And so let's let's let's take on the biggie and so i spent years with several experiments on managing side effects in different ways i um i finally had a paper or a video called two-way data flow showing one way of of doing that which actually sort of is somewhat you know prefigured all the popular stuff with one-way data flow these days in react kind of things but adding in something for the other direction which is sort of

swept under the rug a lot for the state management again that was interesting um um ultimately didn't totally work. It had problems, but there was some very interesting properties there that I want to try and hold on to. I guess that was like 2014, right? At that point is when I suddenly had started to shift direction to thinking about end users instead of professional programmers. And then I started working what I was calling Chorus, which was

sort of a hyper-cardy programming environment on mobile phones for building social apps, though, focused on sort of build your own Facebook. And I did some, a couple of versions of that. And I learned a lot. And that stuff I think is still what I'm focused on now. It's just that I had some technical problems. You know, the structure editing just did not work at all. And I had some, the whole integration of the database and the programming language was not working out quite right. So I, and that was also while I was at CDG and HARC.

And that's kind of at the end of HARC, I went into a phase of just doing some little crazy experiments about what you could do. One of the key ideas I've had since the beginning was that a program is not just a dead piece of code, whether it's text or tree structure, whatever, but most people think of it as a dead structure that gets magically interpreted. You know, if we put the program, the running program into a database so that you could actually see,

so for instance, where the PC is, right? You know, it's actually part of the data model. What can we do? And there's some crazy things you can do. So reifying programming and direct programming were a couple of videos i showed you can do these weird things like going in and messing with the at with a specific executing instance of the code without modifying the code right so this is idea of a um what did i call it an intervention in that you can actually sort of muck around with a specific example, executing

example as without editing the code, but that creates sort of a gradient, sort of a pressure that, okay, the code is now not matching its execution. How do we fix that? Well, we run these refactorings, which abstract those interventions into real code. So some weird stuff, but I wanted to see what was possible. And that's sort of, you know, more or less takes us up to the, oh yeah. So, and then my latest thing was going back on programming by demonstration. Was if we take the hypothesis that the user and the code should be equivalent, right?

Anything a program can do, a user can do directly, you know, by direct manipulation right there in a graphical interface and vice versa. That anything the user does, it could be recorded and turned into a program. Well, if we take that equivalency as an axiom, what does that dictate about what the programming language should be? And that's when I realized, hey, you know what? That implies naive side effects. That just sort of falls out directly as a corollary of that assumption, that that's the way you have to have your programming language work.

So that's why I believe in that now. And then I came, my latest thing was coming back to the managed copy and paste idea and showing how that might work in a little more detail. And so I guess that brings us to the present day. So yeah, you mentioned that you're kind of bringing it all together and you're trying to make a more concrete version of subtext that people can sink their teeth into. So what's that process like? Yeah, so basically it's time to put up, right? It's time to actually deliver something, at least for me personally.

I just feel like I've reached the point where I've explored lots of ideas and I want to pull what I can together into something that's actually usable and something that I can build upon. It's been very frustrating to keep throwing the stuff away, you know, every 18 months or so

and starting over. So I'm trying to, I want to build something that other people can use. And so I'm actually building, you know, writing up examples and defining a syntax. You know, I've done this in smaller scales before, but I'm just trying to pull it all together. I'm not answering your question very well.

As I guess it's because I'm just in the middle of it, it's hard for me to describe what I'm doing. But I would like to have subtext alpha. I would like to actually have something that I can release, at least to other researchers to play with and get feedback on that is usable. That is you could build comes with a set of non-trivial examples and you could build non-trivial examples yourself. I'm still thinking about the chorus kind of use cases. It's sort of like build your own Facebook

in 15 minutes kind of idea. You know, you should be able to just whip that kind of a social application together. And it has enough of the building blocks built in so that that's just natural. It's very much this document oriented model. I guess I really haven't talked about that too much, but that's also been a thread in my work for a long, long time

that a good way to think of applications is as a document. It's a shared live document. It's like a Google Doc, but it reacts. It's not just passive data that you edit. It actually has logic in it, and it reacts to the changes you make to it and can do things. And I think that's a nice – I guess Chorus was when I first really focused on that idea. So I'm still focused on that idea. It's a simple document-as-application programming environment

smart documents in some sense there are a few companies that meet that description these days like Notion, there's this new one Coda, maybe a few others, what do you think about those? well I think

yeah I think it is an idea whose time has come. And, you know, I'm not the only person who's thought of it, obviously. And I've also been broadcasting this idea. Like I was pushing the Notion guys years ago towards in this direction. I'm really like what they've done. But they're all being smart about it. They're being smart in that they're not doing programming, right? Because that's the kiss of death sort of for complexity. And that's the limitation of all of these. They aren't real full of programming yet.

So they've found sweet spots of use cases that they can handle with various sorts of canned parameterizable components. But that's still all it is. And that's been the bane of every non-programming application development environment. Because people have been doing this forever. People have been trying to solve this problem. I haven't talked about this. I've been pretending like it's been completely ignored, but no, people have been claiming to have let you build applications without programming forever, right? This has been many, many generations of these,

but they never really succeed. And I'm not going to say that I actually understand why they haven't all succeeded. It's a bit of a mystery, but I think the central problem is that they realize that if you go, if you make it full on programming, it just becomes too complicated, right? Especially because what they do is they say okay well we're just going to like put in vb script right into microsoft word or google has google script right that you can put into google spreadsheets right but it's just a full-on programming language there's an enormous abstraction leap at that point enormous complexity leap that many people can't make. So everyone's seen why those things don't really catch on. And so now they've wised up and they're

just not going there. They're not putting a programming language in at all and just keeping it really simple. So that's great, but it's not solving the problem until we get programming. And to me, the problem is that we just don't know how to make programming simple enough, right? Because we make this big leap into just sort of normal vanilla programming the way we all know it. And that's just not simple enough. So I'd say is that we need an intellectual breakthrough here

about how to make programming simpler in order to really pull it off yeah and um just to get a i know it's difficult because you're in the thick of it but just to get concrete about um what you're currently working on when you mentioned subtext alpha and releasing it so people could play with it are should we be expecting a like a you're releasing a compiler and it's a text-based language, or is it going to be more like your earlier subtext demos where it's like a full GUI or a structured editor?

What should we be expecting it to look like, the output of this current work? It's, no, it's a full programming system, a full graphical environment that you program in. And the text shows up on the screen, but there's no text files. There is a textual syntax. It turns out that really, really is a handy way of defining and building a language. But the textual syntax is only designed to support simple examples and test cases it's not

designed to support um building and editing and incrementally modifying code and it doesn't support everything you can do in the language but so there so there is a textual syntax hidden in there but it's going to be. And it's going to be a real programming environment, which raises the bar quite a bit. But that's what's necessary. Just like all of us have a node and wires phase, a lot of us have a structured editor phase. But then some of us will leave it and be like, you know what? Actually, text isn't all that bad. Structured editors are hard.

But you're someone who's stuck with structured editors your entire research career, and you're really insistent that they're like they need to be part of the solution. So I'd be curious to get a sense of why that is. Yeah. So there's a couple of places where we absolutely need structured editing. So maybe one of the most obvious ones is when you think about version control. You do a rename refactoring in your system. Currently, that shows up as a million separate edits in the version control system instead of a rename operation, right? And those million different rename edits conflict with any other change on that line of source code

that occurs in a parallel fork, right? Which is crazy because a rename is in fact completely orthogonal, right? And shouldn't conflict with anything else. So if you're doing keystroke editing, if you're doing text-level editing and your code is text, you're stuck with that. You have to get to a structured editor to capture the fact that a rename is a single operation, and it's recorded as a rename. It's not recorded as a bunch of edits to the code. So that's one example of why we need structured editing.

Another one, a little more subtle, has to do with schema change, which is, this is quite subtle, I guess, but it's a really big problem. When you wanna integrate the programming language and the database together, you have to deal with the fact that, you know,

normally we think of, well, we just edit the code and then you run it, right? You run it and it starts from scratch, right? And you don't have to worry about the pre-existing data, but the database is the pre-existing data, you know? So we've solved that problem by sweeping it under the rug and putting it in the database. But if don't do that then you're editing a running system which has all these running instances of of the data out there and you've got to change it and you've got to capture again like with renaming you need to capture your edits at a higher level in order to do schema change. When you inserting, deleting a field and inserting a new field, right? Is different than renaming that one field, right? To a different name and changing its type, right?

Those are just from a schema change point of view, those are completely different and we got to capture that difference. And we can only do that by capturing high level structural edits rather than keystroke editing. So that's a couple of examples. And it's just also more of a, I got to say, it's more of a religious belief, to be honest. I just think that there's so many, also this managed copy and paste idea, you know, that's something that I need to have an ID to pull off, right?

Because I'm tracking stuff that's no longer in the text of the source. It's sort of an epiphenomenon about how the pieces of the source relate to each other. So I just think there's a whole lot of potential ways we can improve programming, but they are only going to be possible when you have the code is a living, understood structure inside the user interface of the programmer. You know, IDEs are really smart. I mean, look at IDEs. Okay, they've really come a long ways. They're amazingly smart what they do to sort of reverse engineer what's going on in the program and give you smart interaction. So, you know, they've done impressive things.

And I just think we can do even better. I think we will only discover what's possible to do once we go full structure editing. And that opens up the box to many, many new ways of interacting with your code. And many of my experiments are like that, this idea of munging with intervening in the runtime execution of the code. You need a fancy environment to do that. Once we discover those things and figure out what actually works for us, I wouldn't be completely surprised if a lot of that couldn't be retrofitted

into textual programming with enough herculean effort it's just that i'm not hercules you know i'm just one person and i i can't build an eclipse right you know the very first ide eclipse was you know like a hundred person years or something right it was just amazing herculean effort to build the first one i thought so one answer i'm i clearly i'm touchy on this and i'm trying i'm being defensive um but another answer is just that i think that it's going to be easier to uncover and run these experiments and get some results using structured editor rather than trying to cram it into the text editor, even though it might still be possible to cram it into a text editor.

You won't do it because you'll fall into the old ruts, you know, and you won't even think about what's possible if you're just using a text editor. So in a sense, it's a discipline. It's an intellectual discipline. Yeah, so this is maybe the best answer here. It's kind of like, you know, Haskell had laziness as an intellectual discipline on the language design. So, you know, I'm thinking structure editing is also kind of an intellectual discipline to prevent us from falling into the ruts of text editing to open up to what would be possible. Well, I liked earlier when you were admitting that it may be a religious belief, because I feel like that we people trying to improve programming are kind of doing science, but kind of doing design, and it's like unclear when we do something.

It's not science. It's definitely not science. Yeah, it's definitely not science. It's design. Well, like the field is called computer science, so you'd think it'd be science, but I think I guess a lot of things called science, like political science, isn't really a science. Well, that's the old joke.

That's the old joke. Any field that has science in its name isn't one. science. Well, that's the old joke. That's the old joke. Any field that has science in its name isn't one. Yeah, okay, so. I think that the misnaming of computer science has had all sorts of pernicious effects. You know, it's really, really bad. It's not a science, it's not math either. And most of it is what's most properly called design.

Well, so, and so I guess instead of calling it a religious belief, it could just be like a taste thing, like an aesthetics thing. Yeah, yeah. It's a school of thought. It's an approach that works, that's coherent, and is organizing, but it's not necessarily right or wrong versus other approaches. So, on this note, I wanted to touch on the Burbacai group thing that you were working

on, but we don't have to if that's kind of something that's not ready to be talked about. Oh, yes. That's Borobaki. Borobaki, there we go. Yeah, that's kind of a funny, you know, so I'm constantly, I don't know why I do this, but I'm constantly starting various little initiatives trying to see what will, you know, stick to the wall sort of about with other people about trying to just doing community organizing. So that was an idea that hasn't really stuck. Yeah, I don't think we should really. It's not worth going into here.

Okay. The thing that I wanted to touch on was basically what we're talking about already. So there's HCI, Human Computer Interaction, which is like a field of study where they um like will make some improvement and then they'll like test um like how much time it takes uh users to complete a task with an older tool and a new tool um and you know they're like different way like how do we measure how do we make progress in this in this work or maybe there's no way. That sort of distinction of how do we organize our work as a community. Right, so that's the methodological question and I have been thinking about that a lot and that was that Borobaki proposal you ran into.

It's a problem for us, right? We don't have a clear methodology. We call ourselves computer science and so we think, oh, it must be science. Although in fact, most computer science is much closer to math, really. I mean, certainly programming language theory uses a lot of proofs, right? Greek letters and theorems and stuff. The HCI people are scientists and in the sense of psychological science, right? They're measuring the people. And so they want to do experiments to get actual empirical data on what works and doesn't.

But, you know, unfortunately, psychological experiments are very hard to do, hard to get any meaningful things out of. And so, you know, the simplest way of doing it is very shallow sorts of A, B testing, you know, different ways of having UI elements work and how the mouse works and physical aspects of interaction with the computer. But deep semantics like, you know, object oriented versus functional programming right how do you how do you run a test you know an experiment on that very very difficult certainly very difficult at the um in practical terms you know in terms of how much money and time and so forth we can

invest in it you know ultimately you'd have to do a clinical trial like with drugs right you'd have to take people that don't know how to program at all and spend years training them in object oriented and then functional programming and then compare the two and results and it's you know there'd be so much noise it's just you know building it's just almost impossible impractical to do real controlled science there. And so you're left with how do you tell what's good and what's bad, what's working and what's not. And I don't think we have really good answers to those questions. It's something we need to be asking ourselves. What about, you know, whatever has won is best, whatever more people use? the easiest to adopt based on where people are currently.

And that's why we're stuck now, because we're in this dead end of all this existing technology, which it would be too expensive to break free from, and nobody wants to invest that money. And so we'll just keep making it harder and harder. Well, so I'm trying to think about how we make progress as a community. The way it currently happens is like basically there's no methodology and no organization or, you know, there's very little methodology or organization in our little reinventing future of programming community. more like we're all just doing our own little independent work and will occasionally through various venues like your conferences or my slack group will like share things and and talk but it's

it's very much um just like a mess of people doing work and then hopefully i guess the general hope is that one day something or some collection of things will come out of it is is that how you see it just like this big mess or or you you hope that there'll be something more I think sure well this is why I what I call my community organizing efforts right we need to build an institutions which are dedicated to improving programming and this means forums where people can get constructive feedback. So the live programming workshop is a good place. I'd like to slowly start raising the bar there a bit where we have people are expected to actually try and position their work relative to past work and say what they how it's different, you know, what they learned from the previous work and what they're building upon, which we don't do at all currently.

And also try to start coming up with people, having people suggest why, explain why their thing is better not just say hey here it is it's cool right but actually try and make an argument what is better about this why do you think it is and it's not empirical data it's not a theorem but there's still you know reason there is argument right you should we should you know make a a persuasive argument for things. So just sort of raising the bar a bit on these issues to start trying to get more of a positive feedback loop in the research where people are getting feedback and feeding back on other people's work. Because that's what works about science, is the incremental ratcheting nature of it, right? That you're kind of competing,

but you're also cooperating with other people. So I would just like to start building a place where that positive feedback loop of research can occur. And it's not occurring in the existing programming language research venues because they're, you know, they're playing a different game. And it's not a working in industry because they're playing a different game. They just want to ship stuff, right? They want to get things that work. They can't think long term. So normally in our society, academics is the place that is supposed

to take on this responsibility. But for various various reasons they aren't into that right now. So we have to invent our own. I would note that you know other engineering fields also have professional societies, right, which try and oversee the health of the field and invest in education and will even fund research and attempts to reform and redesign existing things. Every other engineering discipline has these professional societies, but we don't. It's really strange. There's no American Programmers Association, right? All we have is the ACM, which is entirely taken over by academics. It's, it's, they, they just have lip service to practitioners, but it's, it's a completely academic thing devoted to the career needs of academics. So there's, we're a young, stupid field, right? We haven't figured things out and we haven't.

And part of the problem is, am I just ranting here? But part of the problem is that we're such a young field, right? That we're not only young in terms of total time we've existed, like 50 some years, but the average age of our practitioners keeps going down, right? Because we're growing so fast that we keep getting new entrants, new young people coming in. And so everybody was born yesterday, right? And so there's so few people that have been around a long time like me, our voices drowned out. And worse, it's almost deprecated, right? People consider old timers to not have anything relevant

to say in this field, you know, unlike other engineering fields where, you know, someone who's built big things successfully for decades is considered to actually maybe know something, but not in our field. So, and it's the elders that traditionally focus on investing back in the health of community and the field as a whole. And so we don't have that feedback loop working yet. We need to work on that. Yeah, it's really hard. We can't really. So one of our problems is we can't really prove that there's a problem. Right. Many people say, hey, there's no problem. You know, it's perfectly fine. You know, I work at Google where I get paid a lot of money. We're doing great shit.

It's all good, you know, and what is your problem, dude, right? And I don't have any answer to that. I mean, people are, a lot of people are just perfectly satisfied with the status quo. A lot of people think that all we need to do is just have better education to teach people how to do this shit. And we don't have any real proof that there's a problem. How do you prove to these people that, no, this is wrong, this is not going to work? It's just an insight. It's a deeply felt belief, but I don't know how to prove it's just an insight it's a it's a deeply felt belief but i don't know how to prove it to people i can just make an argument i can say well look at spreadsheets right look at how people

use spreadsheets right surely there's there's got to be something that's almost as easy to use as a spreadsheet that would let people do things but but I can't prove it until. So, I mean, the way to prove it is by demonstration, by example, right? You know, okay, here it is. We haven't got that yet. We don't have, you know, we can point to HyperCard as a good success case though. So we point to spreadsheets, we point to HyperCard, things like that, but it doesn't seem to convince a lot of people you know I think the real problem ultimately is is we have there's some very hard technical theoretical problems about rethinking the way we do programming and there's

also a lot of just really hard engineering work that needs to be done just to simplify our existing technologies. But ultimately, the real gating factor, the real thing we have to do is it's this institutional problem. It's cultural, culture and institution is what's holding us back. You know, we have a culture of programming, which is really kind of toxic in many ways, but it's, I mean, toxic is a loaded word these days. So I'll retract toxic. I'll just say it is,

the culture of programming is counterproductive. It's not heading us in the right direction. We are, we're foolishly making things worse for ourselves unknowingly. And it's just sort of many of the normal problem, normal sort of pathologies of, of smart young guys, right? Like I was, you know, we're just like kind of too full of ourselves in our smartness. And we need to get a little humility and a little experience about what actually works. But that's easy to say, oh, just wise up, right? That doesn't happen. In real life, the way, as far as I can see, that human civilization progresses

is that we build institutions that try and hand down best practices from the old people that have learned them to the young people who don't need to go through and learn the hard way, right? And so we're really lacking in good institutions. And I think in the long term, that's where we need to solve that problem to really make progress.

We need to have institutions that are concerned with the actual practice of programming, not just publishing paper and getting papers and getting tenure, how to improve actual programming and not just for the people that are full-time programmers, but for everybody that wants to use, that could use this technology. And I'm not in a position to create such an institution, but I'd certainly love to be part

of it if we can somehow get the energy together. Cool. So just to wrap up, I'd like to ask for different ways, or platforms for people wanting to interact with you or your work or the conferences that you're a part of. What are the like links or pointers or email addresses you'd want to have known to people? Right. Well, so, I mean, at this point, your Slack is a good place.

Although you really should get off Slack. Slack really sucks, but it's just a chat app. I hate it. Yeah, I know. It's funny because I also hate it, yet I'm the person running it. So I'm full of empathy for you. Yeah. So your Slack is a good place. And actually, Twitter, following all of us on Twitter, we've got a little community on Twitter going, in a sense.

And all of the events, all the workshops um the live workshop there's also the the programming conference which is is run in europe you know it's angle brackets programming and it's dedicated to the for those of you who can't see jonathan is right now um making angle brackets with his hands in the air because well Well, you can't see it either, but you knew. I know. I've seen you say the word before. Yeah, right. So angle brackets programming, which is a great initiative. It's trying it's an actual conference and journal.

So it's got the trappings of computer science, but it's explicitly focusing on the art and practice of programming i think they call it so to get away from the theory um and and the pseudoscience so um that's a that's a a new thing they're just getting going i i hope they that will gel and turn into a really good place for this kind of work to happen. There's, yeah, and so, and that has some workshops in it. There's a PX workshop, and then there's the Salon des Refusés for the really crazy paradigm sort of think pieces.

So at this point, those are the two main places to go. Onward at OOPSLA, at Splash, it's now called, there's the Onward track, which is dedicated to, again, sort of paradigmatic, crazy ideas is another place that this kind of stuff happens. Although that's tending to mature a bit. And I'd encourage everyone to find a way to be part of the solution rather than the problem. It's hard though. It's really hard if you've got a full-time job or research is not easy. That's definitely one thing I've learned there's a lot of dead ends

you've got to be willing to go down a lot of dead ends one of the things Brett Victor said to me was that you can't do this sort of work if there's anything else that you can do the only way that you're going to do this work is if you can't not do this work it's that

hard yeah that's that's right it's very true I'd agree with that it's it's something you only do this if you have to do it no choice so you know so like now Brett Victor has done a great job of popularizing this stuff most people say they were inspired you know I pred I predate him. So I didn't I wasn't introduced to this stuff by him. I was saying many of the same things. But many people have been introduced to this whole line of thinking by Brett. So and what does that tell us? Does it we need need to work more on getting the message out to a larger audience?

I don't know. Because Brett's not doing this, not doing that sort of evangelization anymore in general, right? He's got his own thing that he's working on, the dynamic land. So that's his thing now that he's doing. So we don't have a really good public figure presenting these ideas, communicating public, you know, what's the right word? Evangelizing, I guess, these ideas. Maybe that's what we need. Yeah. Maybe it's you. Maybe you're the person. Maybe it's me.

Could be. Yeah. Yeah, well, I think you put in the right phrase because an evangelizer is someone who goes around giving talks and for whatever reason feels like nobody would call brett victor's work shallow but there's something like when you um he that's very much point he was pointing us in the right direction of improving programming but he didn't but he kind of like left us to fill in the details um right i think a lot of us like you and me want to fill in those details ourselves and so we're like too busy doing that uh to go around getting talks about why programming needs to be improved so um i feel like yeah i guess that's kind of one of the core problems we need to find someone who's passionate about the

problem and like not really passionate about solving it just more passionate about getting people excited about you know the problem uh almost so i don't know. Anyways. I think it would really help to have a win. It really helped if we had a success story, you know? So yeah, maybe subtext, maybe that'll, maybe that will actually eventually be something that's usable and could be a success story or maybe somebody else's project will get to that point so that would really help yeah that's true it's funny that you mentioned the win because when I was in college I remember looking

around and being like I don't know who but one of these kids is gonna like create a startup and it's gonna be worth a lot of money and it'll be like you know a success you know I'm gonna go to school with someone like that, but who's, who's it going to be? And then it was, and it happened like, you know, a bunch of people started startups. They all failed except this one kid and his second startup, you know, is quite successful. And it was, I don't know, something about it. It was just like, you know, validating that, you know, one of us made it through. And it's funny because in our little community, it feels the same. Like there's, I don't know, a few hundred of us, at least, maybe more, who are like working on these little prototypes that eventually might turn into a system.

And you're right, it would be fun for one of us to like succeed. I guess that was kind of Chris Granger and Eve. They were kind of like the first little mini success story, which was, I guess, validating but also disheartening. Unfortunately, they didn't in the end. Now they're a cautionary tale. But yeah, Eve could have been it. But it's probably not a couple of hundred people, though, in terms of people that are working like at least half time, let's say. Because it's really hard to do this nights and weekends, right?

So people that are working at least half time on new programming technologies and environments, it's certainly got to be less than 100, I would say worldwide. Maybe even much less than that. Maybe 50. Yeah, that's a good point, drawing the line there. There are a lot of people who do this in nights and weekends and kind of dream about it. And they just want to show their demo and get high fives and move on to the next thing or something like that. Right. Yeah, but if you look at people that have done more than one thing, they've come back again with a second try. A lot smaller group of people.

Because it's really hard and and i think it's really true what what you or what brit said that this is painful right it's research is painful and it is so hard not to to to break out of everything you know it's it's so hard um that you can only only try to do it if you if there's something driving you, something really, really driving you. And, you know, with me, it's just an obsession. I mean, I've sort of, you know, sort of it's become my life. This is what I'm doing with my life. But that's all it is.

It's just an obsession. Yeah, well, I'm happy that, at least selfishly, I'm happy that you're obsessed with the same thing I'm obsessed with. It's good to have you on my team or to be on the same team as you. Yeah, thanks. Yeah, thanks. I think it's pulling together. I mean, there is more energy here.

So don't take my cynicism. I've been doing this a while so it's it's probably natural for me to feel sort of fatalistic about everything that oh this is pointless you know but in fact there is an uptick in energy here you know you've added a lot of energy to the group and and a few other people you know I was at the the P pig oh yeah pig. I didn't mention P pig psychology of programming interest group. That's another interesting venue for this kind of thinking, but those guys are doing some interesting stuff. And so, you know, maybe there's a, well,

here I am watching the surfers come in on the surf here. And so, so the apt analogy might be that we have a bit of a swell here building, so we should try and ride it. Yeah, sounds great. It's great to end on a uplifting note there. I feel it too. And I personally, like one of the places or times I felt it most strongly was at your live conference, the most recent one in Boston a few months ago. I just couldn't believe that I was able to sit there the whole day in a chair listening to other people talk and be happy as a clam. Because normally I have trouble sitting still and listening to other people talk. But it was, you know, it was just, it was, it just, I had a strong feeling of momentum. It like, it made me think, you know, get teary eyed about, you know, maybe this is like the

modern day homebrew computer club, you know, where Steve Jobs presented the first Mac. Huh? Yeah. Who knows? Maybe. But yeah, that's, that's great. Well, thank you for, maybe I can, we'll quote you on the marketing literature there. I was able to sit still through the entire thing.

But yeah, there is some energy here. I've been trying these kind of events for a while here and I do think that that last live one had more energy. That's a really good sign and hopefully it's not a fluke and we should just keep pushing. Yeah. Great. Well, um, right. So your Slack, you know, you know, you've got like hundreds of people on there now, right? So that's a real positive sign. I'm really shocked. Are you, are you at all surprised at how popular that has become? Um, well, it's funny because it it's kind of like boiling a lobster.

I just got one or two or five people a week for I guess two years now or a year and a half, two years now. So at no point was it surprising because it just happened so suddenly. So that's good. And I guess, you know, to tie into things we said before, we should think about ways that that could become a watering hole for researchers like us to get some more constructive kinds of feedback. That's something to think about. Open forums, you know, are, you know, there's only so much you can get out of it, right? Like on Twitter, right?

Kind of limited bandwidth. But I think maybe we should, we could think about institutionalizing those writers' workshops that we ran with you and Jeff, right? Yeah. That's what FPW was. Maybe it's time to bring FPW back as part of some local meetups with your for your slack people yeah yeah that's a great idea and i've done a lot of thinking kind of on this and i'm sure both of us and

maybe a few others have done a lot of thinking on other ways to do community organizing here um aiden knief um who i interviewed on the podcast and is in the slack group he has a company optic he he was uh brainstorming with me different ideas around um i think i may we may have talked about it like different um ways to do online versions of those kind of meetups where people from all around the world could um join in and some people could present some people and then others would give feedback, something like that. Yeah. Yeah. I don't know. I think part of what's hard about community organizing is,

is that there's like no rules. You know, you can just, you're like really infinite possibilities and it's really hard to understand what's going to work because like the feedback loop cycle is so hard. Like I had no idea what a 200 person Slack group would be like until, you know, a year or two in. And I was like, wait a second. Slack is not the right medium for this. But now it's kind of not too late. But it's you know, it was hard to predict going in. Never say it's too late because, you know, that's the famous last words, right? It's like, oh, we could have fixed the C programming language, but we already had 50 users, right? You know, and it was unthinkable that we would make a breaking change.

You know, there's always more users to come in the future. So, yeah. Yeah, that's a good point. And, yeah, for Slack specifically, I'm not shy about leaving if I found another platform I liked a lot better. I don't know. I don't have one of those off the top of my head.

I did some research and I wasn't able to find anything. Anyways, we could do this all day. I think I'm going to go ahead and cut it off here at the two-hour mark. Thank you so much for taking the time. This was a lot of fun. Yeah, yeah. Likewise. Thanks for inviting me. And we'll talk again soon. Talk again soon. Bye. All right. Bye bye. Thanks so much for listening. Not many people can make it to the end of a multi hour podcast.

If you enjoy these conversations, I bet you'd fit right into our online community. You can join our Slack group at futureofcoding.org slash Slack, where we chat about these topics, share links, feedback, and organize in-person meetups in various cities, New York, London, San Francisco, Boston, and also Kitchener, Waterloo, and Canada. If you'd like to support these efforts, there are a few ways you can be helpful. I would really appreciate any reviews you could leave for the podcast, wherever it is that you listen. If any episode in particular speaks to you,

I would encourage you to share it with your friends or on social media. Please tag me if you're sharing it on Twitter, at Steve Krause, so I can join the conversation. I also accept support directly on Patreon at patreon.com slash Steve Krause. And as always, I am so thankful for the ultimate form of support, your constructive criticism. So please don't be shy with your advice. Thanks again for listening and I will catch you on the next episode.