#37 - De-Nerding Programming: Jonathan Edwards

03/02/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.

Selected Q&A

Questions and answers have been lightly edited for clarity. They are in their full form in the transcript below.

You fell in love with programming at an early age, but your whole life you’ve been trying to improve programming. There’s a funny contradiction there because on the one hand, you love programming so much, but on the other hand, you think it needs to change so strongly.

That is a contradiction. You have the power of the gods. You are creating universes out of pure thought. Yet, it ends up being you’re in hell with this drudgery, and the stupefying repetitious nature of it. I think of it as intellectual ditch digging. 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. It’s crazy.

I had this feeling from almost the very beginning that we’re in the stone age of programming. I mean, clearly, we’re not doing it right. We have no idea what we’re doing, really. 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. This is completely new. We’re doing it all wrong.” So, this is a chance to make a mark.

What’s the goal of your research?

The line I would use at a dinner party is that I’m trying to make programming be like spreadsheeting. There’s no such thing as spreadsheeting. You don’t really have professional spreadsheeters. 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 brainiac super nerd. It just should be easy to do.

I’m focusing on those kinds of problems that you would want to do with casual programming: small scale simple problems solved simply. “Application programming” is the phrase for this. It seems to have fallen out of use, though. There used to be this clear separation between application and system programming.

My research is to try to revive application programming for the modern world. You look back at the old examples that worked. Probably COBOL is the original application programming language. Muchly derided, but yet, it was actually pretty effective. Visual Basic, HyperCard, things like that, these are all in the past, though, because there’s no way to get rich quick with these things, so no one’s interested in them anymore it seems.

In a broad stroke, my research is making programming simple, as simple as possible for solving simple small problems. This is not building internet startups. It’s not building operating systems. It’s not any of this hardcore stuff. It’s just simple problems in your own life, in your business that you want to solve, and you just don’t want to make a big deal about it.

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

How can Unix require 1,000 commands? Why does the ls command require hundreds of switches? Obviously, no one is thinking about simplification here. They just keep adding on more and more and more. Nobody ever thinks about cutting it down.

The things that trip us up are all these things we love, our abstractions. We build up these wonderful abstractions, and we add layers of indirection and so forth, and these mathematical patterns, and 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.

What are you currently working on?

It’s time to put up. To actually deliver something. I’ve explored lots of ideas and I want to pull what I can together into something that’s actually usable and to something that I can build upon. It’s been very frustrating to keep throwing the stuff away every 18 months or so and starting over. So, I want to build something that other people can use.

I’d like to have Subtext Alpha. I would like to actually have something that I can release, at least to have other researchers to play with and get feedback on that is usable, that comes with a set of nontrivial examples, and you could build nontrivial examples yourself.

I’m still thinking about the Chorus use cases. It’s the build-your-own-Facebook in 15 minutes idea. You should be able to just whip that 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.

Full Transcript

Transcript sponsored by Repl.it

Corrections to this transcript are much appreciated!

SK:

Hello, and welcome to The Future of Coding. This is Steve Krouse. 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.

SK:

I'm also really glad in this conversation we get to hear some of his back-story, 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 adviser, which many of you know. We've been partnering up for the last, I guess almost a year now.

SK:

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, helping 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. I'm quite thankful to have him on my team.

SK:

So, in this conversation, we get some of his back story about how he originally started a future of 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 Warth's group at Alan Kay's CDG. Then for the last two years, he's been independent like me. So, that's part of why we decided to team up together.

SK:

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.

SK:

Repl.it is an online REPL for over 30 languages. It started out as a code playground, but now, it scales up to a full development environment, where you can do everything from deploying web servers to training ML models, all driven by the REPL. They're a small startup in San Francisco, but they've reached 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@replit if you're interested in learning more.

SK:

Without any further ado, I bring you Jonathan Edwards. Welcome, Jonathan.

JE:

Thanks for having me, Steve.

SK:

Really excited to have this conversation.

JE:

Yeah.

SK:

So, I wanted to start at the beginning because you've had a really interesting career and you've done a lot of ... 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 a quick life story or a quick arc of your path as a programmer, and also as someone working to improve programming.

JE:

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, I was 13. This was 1970. I fell in love with programming immediately. It clicked with me instantly. I think that 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. We only got access to computers through various strange circumstances. So, I'd say that's a strange thing about my story.

JE:

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.

SK:

Sorry to interrupt. You said you did the academic thing. You mean you dropped out of college when you were 14 or 15?

JE:

I was 17 or 18 when I dropped out. I almost finished my undergraduate degree, but I had a lot of personal issues. I was part of this experiment on precocious youth, 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, right? It was clearly very questionable practice. So, I got a little screwed up as a result socially and emotionally.

SK:

Wow! Crazy. You seem all right to me.

JE:

I've had to learn how to simulate being a human. Over the years, I've gotten, I guess, reasonably passable at it.

SK:

Okay. Sorry. Continue your story of you left college and you started a company. Is that what you said?

JE:

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 mini computers, PDP-11s, originally. We came in and we replaced Teletypes that were previously being used to transfer money around the world. So, this was in the mid to late '70s, the very first wave of automation, really, rolling out into businesses.

JE:

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 computer companies back then. Do you know about DEC? Have you heard of them?

SK:

Nope.

JE:

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 originally written on DEC machines.

JE:

So, anyway, I started my own company. I had this fairly bizarre, crazy idea I was going to invent this next generation database programming language environment for online businesses, today 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 they just took over the world. So, that whole idea of selling a database clearly became unreasonable, unattainable.

JE:

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 as part of the first dot com boom when valuations were crazy. So, very good timing on my part, pure luck.

JE:

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

SK:

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 early age, and also, I'm trying to improve programming. There's a funny contradiction there because on the one hand, we love programming so much, but on the other hand, we think it needs to change so strongly.

JE:

Well, yeah. Right. That is a contradiction. You have the power of the gods, right? You are creating universes out of pure thought, right? Yet, it ends up being you're in hell with this drudgery, and this stupefying repetitious nature of it. I think of it as intellectual ditch digging, right? 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? It's crazy.

JE:

It was just always I had this feeling from almost the very beginning that we're in the stone age of programming. I mean, clearly, we're not doing it right, right? We have no idea what we're doing, really. 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 completely new. We're doing it all wrong." So, this is a chance to make a mark.

SK:

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. So, I am wondering where that empathy is coming from.

JE:

Yes. You're right. 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 nerdy people that think the way I do.

JE:

I didn't get very far, and I can't say exactly. There wasn't any epiphany. It was just I slowly started trying to think about, "Okay. What's really the problem here?" So, the way I put it is after enough decades of programming, you start ... We're very bad at consciousness, right? At reflection and being aware of what we're doing, okay? It takes a long time to start to clue in to what's really going on as we think and do things.

JE:

So, just after decades and decades of programming, 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 I'm actually not very smart when it comes to programming. It's really, really hard.

JE:

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 these mathematical patterns to it, and 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.

JE:

I think starting to do UI programming helped because it's a slightly ... I don't know how to describe it, but your faced with simplicity more objectively there, and you can see that, "I built this terrible UI. What was I thinking? This is horrible," and learning how to simplify things down and realize what's really going on.

JE:

So, those learning experiences just slowly started to add up for me, and I just started to realize that we've made programming hard. I don't really know how to describe this, communicate it too well, perhaps, but the things we like the most about programming, we've overdone it, right? So, we're really bad at abstraction and abstract thought. 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.

JE:

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. It really would become more godlike powers if we weren't constantly humbled by our own stupid thinking mistakes because we've gotten too fancy.

JE:

One of my formative experiences was wearing a beeper for a decade. This was before cellphones. 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.

JE:

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:00 AM. 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 hacker culture. Make any sense?

SK:

Yeah. It makes a lot of sense. There's a lot there that I want to unpack and go through slower.

JE:

So, there's the other side of this coin. Let me add. The other progression, the other evolution was that I was realizing that this is 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.

JE:

So, we've built this culture that reinforces all the worst habits. As I started to try and realize making programming simpler, and presenting these ideas to people, I would get the most negative reactions from people, particularly alpha programmer types. Really, these guys are serious. They're the smartest programmer in the room. They hated the idea of making things simpler.

JE:

Just like people of previous generations, this is too old for you, probably, but COBOL was the original language which tried to make things simpler. It was just derided. Being a COBOL programmer was a mark of inferiority. So, it's the same thing. I realized: there's something really fucked up here in our culture that is making things hard.

JE:

That's when I really just fell out of love with professional programming, 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, 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.

JE:

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.

SK:

Yeah. Okay. There's a lot there. I'm not sure ... So, yeah. I'm struggling between wanting to dig in to a lot of those things, and also I want to continue with your life's arc because I want you to do what you did with the first half of your life for the research half as well because you've had it seems like a decade or so of research, maybe more, maybe two decades now of research. So, I want to get an overview of that as well.

SK:

Maybe we'll do that first, and then we'll jump in to some of the specific things you brought up or do you have a different idea? What do you think?

JE:

Yeah. Well, sure. I think it's not a very long or interesting story, really, because I'm pretty frustrated with my research career. I haven't really gotten very far. I feel I've only thrown out some suggestive ideas. A few people who are thinking along similar lines could read between the lines of what I've been saying and see that we're thinking along ... So, I've met up with some other people that share these concerns, but I wouldn't say that I've actually achieved anything. It's been a real struggle.

JE:

It started off, 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 I did. Again, I worked on his Alloy programming language, and then moved on to doing my own work. That was for a whole decade I was there. I didn't really click with anybody else's research is the problem, right? 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 research. So, I've been working alone. My time at MIT ran up, and I started-

SK:

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 early '90s, and then from when to when were you at MIT?

JE:

So, sold the company in '98. I was still working there for a few years. Let's see. I started at MIT in 2001 ... was it 2002? It was 2002, right. So, I was there for about 10 years in Daniel Jackson's group.

SK:

Oh, wow. Okay. So, a lot of the early Subtext work.

JE:

Yeah, Subtext. My original bunch of papers published at Onward! about Subtext, example-centric programming, was all there.

SK:

Cool.

JE:

Then I stopped really publishing. I started doing demos, videos, and stuff, which are less sticky than papers. So, they're less known. But, things changed at MIT. I left and I joined Alex Warth at ... back then it was called CDG, Alan Kay's lab in LA. I had met Alex, and we got along. 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.

JE:

I was at CDG, which then became HARC when they moved over to 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. That was about two years ago. Since then, I've been completely on my own.

SK:

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.

JE:

Right. So, as I started to realize that our problems are not just technical, they're social, we have cultural problems, and the only way you fix cultural problems is with institutions. Our current institutions, I could rant about this a lot, are broken. Our current institutions are really broken. This is somewhat 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.

JE:

So, I realized that I needed to step up, and start to try and improve things. I was unhappy, as everyone ... 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 not too relevant, not too important.

JE:

So, I started realizing, "Okay. 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. This was, oh, I mean, you can 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?

JE:

Also, trying this new idea that I got from Richard Gabriel ... 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.

JE:

So, I did that for several years. Then the LIVE workshop, I didn't start that. That was some other people. 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. It seems to be the thing that has the most momentum at the moment.

SK:

Hmm. Okay. Interesting. I didn't realize you didn't start the LIVE workshop. For some reason, I thought you did.

JE:

No. It was on its own, but now I'm part of it.

SK:

So, speaking of the LIVE workshop, you were recently somewhat proud to be rejected from your own conference. How was that?

JE:

Well, I shouldn't suck out of school too much because I was the program chair and submitted to my own workshop, and the reviews were not good. The reviews ... So, this is a problem, right? Like I said, I was complaining about the peer review process, what we have. We've made it into an Olympic sport, which is super competitive.

JE:

There's just all these reasons to tear a paper down, "Did they cite the related work? What evaluation methods were used?" Blah, blah, blah. So, for the live workshop, 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.

JE:

I try to modulate that process when I'm chairing, but I had to step aside for my own papers, of course. So, that's just how it came out. It's okay. I was going to withdraw the paper anyway because we had enough good ... It was just really a placeholder 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 of deal, but it was funny that I got rejected from my own conference.

SK:

Yes. Well, yeah, like you said, it's 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.

JE:

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 is doing it. Everyone feels like they're working alone. That's really, really demotivating, right? So, that's why I've been trying to come up with these events that bring people together, and give them some support.

SK:

Yeah.

JE:

It's really just for myself, right? I mean, this is what I need. I'm perceiving these problems. I'm 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.

SK:

It's so meta. So, programming needs to be fixed. The improving of programming needs to be fixed. How about the improving of the improving of programming...

JE:

Yeah. Well, I mean, 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.

SK:

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.

JE:

That's a very good question, and I should have an elevator pitch ready. So, well, 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 brainiac super nerd, right? It just should be easy to do.

JE:

I'm focusing on those kinds of problems that you would want to do with casual programming, small scale simple problems solved simply. 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, that distinction?

SK:

I can guess what those terms mean, but they're not in common parlance for me.

JE:

Right. Exactly. So, that's my point is that it's just fallen out ... the whole idea that there should be two domains of intensity of programming, it seems to have been forgotten somehow, and coincidentally happened when the internet started to make people rich. I think it's not a coincidence.

JE:

So, we've forgotten that there's this whole giant world of people with simple problems that need to build applications, that shouldn't require years of training ... 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.

JE:

So, that's my research. It's just to try to revive application programming for the modern world. You look back at the old examples that worked, and probably COBOL is the original application programming language. As I said, muchly derided, but yet, it was actually pretty effective. Visual Basic, HyperCard, things like that, these are all in the past, though, because there's no way to get rich quick with these things, so no one's interested in them anymore it seems.

JE:

So, you asked me what is my research. So, 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 systems. It's not any of this hardcore stuff. It's just simple problems in your own life, in your business that you want to solve, and you just don't want to make a big deal about it.

JE:

So, the interesting question is, if we make simplicity be the goal, what do we get because it never has been the goal? 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.

JE:

As a designer, you need a more useful rule of thumb. So, my rule of thumb is the size of the documentation. 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?

JE:

And what I've found is that, generally, if it's easier to explain, it's going to be a better solution. 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 would be really interesting to try and run this experiment, right? It's got to be 10-feet high. It's got to be 20-feet high, right? I mean, just the man pages for Unix alone, right? The reference manual for C++, the specs, right? Look at the standards for all the W3C standards. That's probably six feet right there.

JE:

So, just think about the amount of knowledge. 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. The reason it takes so many years for a programmer to become an expert is that they have to master so much knowledge.

JE:

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, right? Because it is, it's mostly bullshit, right? I mean, it's just crazy, right? How can Unix require 1,000 commands, right? Why does the ls command require hundreds of switches, right? Obviously, no one's thinking about simplification here. They just keep adding on more and more and more, right? Nobody ever thinks about cutting it down.

SK:

So, this sounds a lot like Brad Myers' Natural Programming Project, similar goals, taking programming and making it as similar to the way people would normally do things. Would you say that that's a good point of comparison, or is there a distinction you want to articulate?

JE:

Well, there certainly are distinctions, but I do agree very much with Brad's whole mission there. I think that is the goal, to make it more natural. I think my take on it is that that's probably 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 things are crazy complicated, crazily overcomplicated.

JE:

They need to be reengineered with an eye towards simplicity. It's just that nobody is 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 your startup to succeed. It doesn't help you to publish papers because academic papers are always about making things more complicated, not simpler.

JE:

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. 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, a lot about what live programming is about.

JE:

Then there's just "Let's just reengineer things." There doesn't have to be any great philosophical impact to it. It's just reengineering for simplicity.

SK:

I'd be curious to dig into how to define simplicity, because it's kind of an amorphous thing to get a hold of. How do you think about it?

JE:

It is. It's very hard. It is subjective. And that's why I think of it in terms of feet of documentation. That's a rule of thumb. The truly scientific way to define it, like I said, is with clinical studies, right? Just give the 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?

JE:

It's also a very touchy issue, which is IQ and analytical skills. Clearly, there are differences in analytical thinking skills between people. 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.

JE:

Part of the natural programming idea is to de-emphasize mathematical thinking skills in programming. So, it's not just the time it takes to learn, it's also the mental skill required to do it at all. So, I think ... I'm trying to answer your question, did I?

SK:

Yeah, yeah. I think an interesting counter way to look at simplicity would be ... So, the way you described it was as the startup cost or the time it takes for you to learn, and then once you've learned, you're just doing. I guess the other way to think about it is simplicity is the cause of doing any arbitrary thing once you already learned. So, the learning cost is 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 the opposite of what you're saying, or they're more related?

JE:

You know, I don't know. I mean, I think that's Rich Hickey's point when he talks about simple versus easy or something like that. I'm uncomfortable ... I just feel, strategically, I want to focus on the learning phase, because once you're an expert, you're an expert, right? Everything seems easy in some sense to you. 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." Okay, that's a good thing to do, but it's not solving the fundamental problem, I feel, and it's masking the real problem, which is becoming an expert.

JE:

So, I've just chosen to focus on the learning phase. If we could get people to become experts with a hundredth of the time, that's going to be an enormous big deal. The other stuff is 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.

SK:

Interesting. Yeah. I guess they're approaching the same problem from different directions. You could raise the floor and take normal people and make them programmers or you can ... 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.

JE:

Yeah. I mean, 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 it feels to me like an endless cycle of fads. It's the experts just have ... "I like this" ... first, it was objects, now it's functions. I don't know. It feels to me like it's a cycle of things, and you know, more power to that. We can all help in different directions.

SK:

Yeah.

JE:

So, the answer to your big question after all this is simply, 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. It's getting people, making it simpler to learn how to program.

SK:

Got it. Cool. 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. 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 a human brain, the human programmer to the computer.

JE:

Yes.

SK:

So, part of me is wondering if that's a reasonable foundation for a way to improve programming. Basically, instead of looking at the stack of everything that we need 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? What do you think of that perspective?

JE:

Yes. Well, yes, completely. But I just feel that, if you've decided to use, you know, "nuclear-powered" programming technology, let's say you're programming with continuations and all these category theoretic abstractions that people love these days, okay? 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.

JE:

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.

JE:

And 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? What would be the simplest look in the IDE? Go that way." So, let the direct experience of programming with our tools be the guide and choose the programming language to match that.

JE:

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 tending to say that, "Well, actually, the experience is even more important." That should be the strongest vote.

SK:

Yes. So, 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, that the experience ... I guess there are few pieces. One of them is that you have to co-design the semantics and the user experience at the same time. You can't just pick some semantics and then 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.

JE:

I mean, this is all so interesting, and this occurred to me recently ... Bret Victor said the same thing at the end of his Learnable Programming essay. He basically has a giant caveat, says, "Well, I'm not claiming that any of the stuff I showed you actually works or actually could work. What I'm saying is that we should redesign programming so that we get such an experience."

JE:

So, that's what I've been saying all along. I 100% agree with that. Well, this came up because from your previous podcast, you were talking with Vlad about how Bret Victor inspired him. And I think a lot of people that were inspired by Bret Victor don't understand him or at least understand that statement he made, because a lot of people seem to think you can just "re-skin" 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.

SK:

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, it's easy to see how people misunderstood.

SK:

And I feel like ... 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. Usually, there are two camps and then you and I, and maybe Bret 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 then on the other hand, there are 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. So, there's this gulf, where there's no one who's thinking about doing both at the same time. So, you and I are in this no man's land.

JE:

That's hard.

SK:

Yes!

JE:

Right. So, the path of least resistance is to go one way or the other, right? It's to do UI 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. So, it's a much harder problem than a lot of people wish, or are acknowledging at least.

JE:

I think it's just a growth process. So, that is a problem in LIVE that everyone's first attempt is always going to be a data flow programming language with boxes and arrows or something like that or a spreadsheet style, again, data flow language. 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.

SK:

Yeah. So, I guess one of the big problems people come to once they realize that data flow programming doesn't ... or what people realize, or at least for me, I can speak to myself, of what got me past the data flow boxes and wires was I realized that effect, state, side effects, I was like, "Ah! These things aren't just a side case."

SK:

Like, the reason spreadsheets aren't programming is that it doesn't have the side effect things, but then if we add the side effect things, then we lose a lot of the properties of spreadsheets.

JE:

Bingo!

SK:

Yeah. Bingo! So, you've done a lot of work ... some of your projects, one of your papers I was reading recently specifically addresses side effects. So, where is your thinking on this now?

JE:

That is such a central problem, right? That's the original sin, right? It's such an enormous thing. I've been hacking at that problem from different directions for a long time because realizing that this is the central problem, and of course, functional programming was all about this, too, right? They realized that that was a central problem. Unfortunately, they just swept it under the rug in various ways.

JE:

So, if we're going to really confront that, how do we do it? I'd say this is very much the big challenge, an open, big challenge in this whole field of trying to improve programming. It's how do we deal with state. I would say, my, I've done a bunch of experiments. All of which were failures ... educational failures, I learnt a lot in the process, but I haven't solved the problem in any means.

JE:

My latest thinking, in fact, is just I've come full circle back to thinking, "You know what? I'm just going to go with naïve side effects." 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 naïve side effects, right? There's a state and you're mutating it, because that's what you're doing, right?

JE:

In a spreadsheet, 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 things change as we make actions on them, right? It's a very intuitive thing.

JE:

So, my latest thinking is to simply go back to naïve side effecting, on state, and then try and manage it. Add on features that can statically analyze what's going on. 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. Did you understand that or should I go back over that?

SK:

Oh, yeah. 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 one of 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 we need to reinvent version control. Git clearly isn't the end-all be-all.

JE:

Okay. So, big problems. So, 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 is running, why are those so utterly different, right? They're utterly, utterly different. Not only is the shape different, but the semantics are different, transactions and queries versus objects.

JE:

So, I've never understood why we can't solve that problem. It is actually very hard, but I think it's something we need to solve. There should just be one data model that works for the program. The idea that there's a database and programming language seems to me a big mistake.

SK:

Agreed.

JE:

And that used to be a research topic, actually, back in the '80s, right? It's called persistent programming languages, orthogonal persistency. There was a number of buzz words around it. It never really worked. No one ever figured it out, and it just dropped off the radar and people gave up on it. So, I think that's something we need to get back to.

SK:

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 go away. Do you agree there, too?

JE:

Yes. Yes, I do. I think that one is actually easier, I think. I mean, we can see ways of solving that, and people have worked on it. I'm not sure it isn't mostly just a technology 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.

JE:

I'm not focusing on it myself personally so much, because it doesn't loom that large for the low-end stuff I'm focusing on right now. I used to think a lot more about it, though, and certainly, it's a big, another open problem.

JE:

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. It's hard. Keystroke editing is actually very easy. It's certainly easy to learn, and well-supported. Our hardware supports it, and we have, actually, letter keys, dedicated letter keys on the keyboard. It's all there for us.

JE:

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 realized is crazy. It's like we're programming as if we're still on punched cards or a Teletype, right? 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.

SK:

So, I'm realizing now that we probably should have, and my fault, I should have, earlier in this conversation, back when we were going through your life, I should have ... I want to get a timeline and definitions for what is Subtext, what is Chorus because to me, it feels like Subtext is an umbrella term for iterations of prototype experiments. It's almost like, in a TV show ...

JE:

Exactly. That's all it is. It's become just my brand name that I'm iterating on for my experiments. It's never been a real thing. In fact, that's my goal at this point, I feel, is I've hit this point where I want to stop doing these crazy experiments and pull it together into a real thing. So, Subtext is just a brand name for my research project.

JE:

There's been various iterations. I've tried slapping different names on it at different times, but they're really just ... They could have version numbers on them as well. I do feel that I've ... Maybe you can give me some feedback on this, but I feel like at this point, I've failed to build anything that's detailed enough that other people could sink their teeth into, right?

JE:

So, I've done these crazy experiments testing the boundaries of what's possible, and I've learned a lot in the process, but I don't think I've taught anybody else anything 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 learnt 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.

SK:

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.

JE:

So, I got started. I had this original paper called Example-Centric Programming, which was just this idea, "Let's make concrete examples front-and-center as a way of reducing the abstraction load." That was a hack on the Java interpreter to show how that might work. Then Subtext was the next paper where I was finally saying, "Okay. Let's reinvent a new programming language."

JE:

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. That was more of a think-piece.

JE:

Then I started to dig in to specific technical problems. So, there was the thing about, like you mentioned, Boolean algebra, conditionals and all the crazy thinking we need to do about if-then-else, and all that 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.

JE:

Then I said, "Okay. The big issue is side effects, right? So, let's take on the biggie." So, I spent years with several experiments on managing side effects in different ways. I finally had a paper or a video called "Two-Way Data Flow" showing one way of doing that, which actually somewhat prefigured all the popular stuff with one-way data flow these days in React things, but adding in something for the other direction, which is swept under the rug a lot for state management.

JE:

Again, that was interesting. Ultimately, didn't totally work. It had problems, but there were some very interesting properties there that I want to try and hold on to. So, that was 2014, right? At that point is when I suddenly had started to shift direction to thinking about end users instead of professional programmers.

JE:

Then I started working what I was calling Chorus, which was sort of a HyperCardy programming environment on mobile phones for building social apps, focused on, sort of, build your own Facebook. I did a couple of versions of that. And I learnt a lot. That stuff I think is still what I'm focused on now. It's just that I had some technical problems: the structure editing just did not work at all, and the whole integration of the database and the programming language was not working out quite right.

JE:

That was also while I was at CDG and HARC. 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 to tree structure or whatever, but most people think of it as a dead structure that gets magically interpreted. If we put the program, the running program into a database so that you can actually see, for instance, where the PC is, it's actually part of the data model. What can we do? There's some crazy things you can do. So, Reifying Programming and Direct Programming or a couple of videos so you can do these weird things like going in and messing with a specific executing instance of the code without modifying the code, right?

JE:

So, there's this idea of a ... What did I call it? An "intervention" that you can actually muck around with a specific example, executing example, without editing the code, but that creates sort of a gradient, a pressure that, "Okay. The code is now not matching its execution. How do we fix that?" Well, we'd run these refactorings, which abstract those interventions into real code.

JE:

So, weird stuff, but I wanted to see what was possible. That more or less takes us up to the ... Oh, yeah. Then my latest thing was going back on programming by demonstration. If we take the hypothesis that the user and the code should be equivalent ... anything a program can do, a user can do directly by direct manipulation right there in a graphical interface, and vice-versa ... then anything the user does could be reorded and turned into a program.

JE:

Well, if we take that equivalency as an axiom, what does that dictate about what the programming language should be? That's when I realized, "Hey, you know what? That implies naïve side effects." That just 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. Then my latest thing was coming back to the managed copy-and-paste idea and showing how that might work in a little more detail.

SK:

So, I guess that brings us to the present day. You mentioned that you're 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?

JE:

Yeah. So, it basically it's time to ... It's time to put up, to actually deliver something, at least for me personally. I just feel like I've reached the point of, 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 this stuff away every 18 months or so and starting over. So, I want to build something that other people can use.

JE:

So, I'm actually building, writing up examples and defining a syntax. 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. I guess it's because I'm just in the middle of it. It's hard for me to describe what I'm doing. I would like to have Subtext Alpha. I would like to actually have something that I can release, at least to have other researchers play with and get feedback on that is usable, that comes with a set of nontrivial examples, and you could build nontrivial examples yourself.

JE:

I'm still thinking about the Chorus use cases. It's sort of the build-your-own Facebook in 15 minutes idea. You should be able to just whip that social application together, and it has enough of the building blocks built in, so that that's just natural.

JE:

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, as a shared live document, 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. 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 document in some sense.

SK:

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?

JE:

Well, I think it is an idea whose time has come. I'm not the only person who's thought of it, obviously, and I've also been broadcasting this idea. I was pushing the Notion guys years ago in this direction, and I 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 because that's the kiss of death, sort of, for complexity. That's the limitation of all of these. They aren't real, full-up programming yet.

JE:

So, they've found sweet spots of use cases that they can handle with various canned parameterizable components, but that's still all it is. That's been the bane of every non-programming application development environment. 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 let you build applications without programming forever. There's just been many, many generation of this, but they never really succeed.

JE:

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 make it full on programming, it just becomes too complicated, especially because what they do is they say, "Okay. Well, we're just going to put in VB script into Microsoft Word", or Google has Google Script that you can put into Google spreadsheets, 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.

JE:

So, everyone's seen why those things don't really catch on. 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.

JE:

To me, the problem is that we just don't know how to make programming simple enough, because we make this big leap into just normal vanilla programming the way we all know it, and that's just not simple enough. So, I'd say that we need an intellectual breakthrough here about how to make programming simpler in order to really pull it off.

SK:

Yeah. I know it's difficult because you're in the thick of it, but just to get concrete about what you're currently working on. When you mentioned Subtext Alpha and releasing it so people could play with it, should we be expecting you 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 a full GUI or a structure editor? What should we be expecting it to look like, the output of this current work?

JE:

No, it's a full programming system, a full graphical environment that you program in. 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 building and editing and incrementally modifying code. It doesn't support everything you can do in the language. So, there is a textual syntax hidden in there, but it's going to be hidden. It's going to be a real programming environment, which raises the bar quite a bit, but that's what's necessary.

SK:

Just like all of us have a node-and-wires phase, a lot of us have a structured editor phase, but 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 need to be part of the solution. So, I'd be curious to get a sense of why that is.

JE:

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? Those million different rename edits conflict with any other change on that line of source code that occurs in a parallel fork, which is crazy because a rename is, in fact, completely orthogonal and shouldn't conflict with anything else.

JE:

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.

JE:

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 want to integrate the programming language and the database together, you have to deal with the fact that ... Normally, we think of, "Well, we just edit the code and then you run it," right? You run it and it starts from scratch, and you don't have to worry about the pre-existing data, but the database is the pre-existing data.

JE:

So, we've solved that problem by sweeping it under the rug and putting in the database, but if we don't do that, then you're editing a running system, which has all these running instances of the data out there, and you've got to change it. 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.

JE:

Deleting a field and inserting a new field is different than renaming that one field to a different name and changing its type, right? From a schema change point of view, those are completely different and we got to capture that difference. We can only do that by capturing high level structural edits rather than keystroke editing.

JE:

So, that's a couple of examples. It's just also more of a, I guess, I'd say it's more of a religious belief, to be honest. I just think that there's so many ... Also, there's managed copy-and-paste, idea. That's something that I need to have an IDE to pull off because I'm tracking stuff that's no longer in the text of the source. It's an epiphenomenon about how the pieces of the source relate to each other.

JE:

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.

JE:

IDEs are really smart. I mean, look at IDEs. They have really come a long way. They're amazingly smart what they do to reverse engineer what's going on in the program and give you smart interaction. So, 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.

JE:

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. I'm just one person, and I can't build an Eclipse, right? The very first IDE, Eclipse, was 100 person years or something. I mean, it's just an amazing Herculean effort to build the first one.

JE:

So, one answer, I clearly am touchy on this, and I'm being defensive, 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 a 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, and you won't even think about what's possible if you're just using a text editor.

JE:

So, in a sense, it's a discipline. It's an intellectual discipline, yeah. So, this is maybe the best answer here. It's like Pascal had laziness as an intellectual discipline on the language design. So, I'm thinking structure editing is also an intellectual discipline to prevent us from falling into the ruts of text editing, to open up to what would be possible.

SK:

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 unclear when we do something ...

JE:

It's not science. It's definitely not science. Yes. It's definitely not science. It's design.

SK:

Well, the field is called computer science, so you'd think it would be science, but I guess a lot of things are called science, like political science isn't really a science.

JE:

Well, that's the old joke. That's the old joke. Any field that has science in its name isn't one.

SK:

Yeah. Okay.

JE:

I think that the misnaming of computer science has had all sorts of pernicious effects. It's really, really bad. It's not a science, and it's not math, either. Most of it is what's most properly called design.

SK:

So, I guess, instead of calling it a religious belief, it could just be a taste thing, an aesthetics thing.

JE:

Yeah. It's a school of thought. It's just an approach that works, that's coherent, and is organizing, but it's not necessarily right or wrong versus other approaches.

SK:

So, on this note, I wanted to touch on the Bourbaki (BEHR-buh-KAI?) group thing that you were working on, but we don't have to if that's something that's not ready to be talked about.

JE:

Oh, yeah. That's Bourbaki (BOHR-bah-kee).

SK:

Bourbaki.

JE:

That's a funny ... I don't know why I do this, but I'm constantly starting various little initiatives trying to see what will stick to the wall with other people ... just doing community organizing. So, that was an idea that hasn't really stuck. I don't think we should really ... It's not worth going into here.

SK:

Okay. The thing that I wanted to touch on was, basically what we were talking about already. So, there's HCI, Human Computer Interaction, which is a field of study where they will make some improvement, and then they'll test how much time it takes users to complete a task with an older tool and a new tool. Like, how do we measure? How do we make progress in this work, or maybe there's no way. That distinction of how do we organize our work as a community is what I wanted you to touch on.

JE:

So, that's a methodological question. I have been thinking about that a lot, and that was that Bourbaki 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 think, "Oh, it must be science." Although, in fact, most computer science is much closer to math, really. Certainly, programming language theory uses a lot of proofs, Greek letters and theorems and stuff.

JE:

The HCI people are scientists in the sense of psychological science, right? They're measuring people. So, they want to do experiments to get actual, empirical data on what works and doesn't. Unfortunately, psychological experiments are very hard to do. It's hard to get any meaningful things out of it. So, the simplest way of doing it is very shallow, sorts of A/B testing, different ways of having UI elements work and how the mouse works and physical aspects of interaction with the computer, but deep semantics like object-oriented versus functional programming, how do you run a test and experiment on that? Very, very difficult.

JE:

Certainly, very difficult at the, I mean practical terms, in terms of how much money and time and so forth we can invest in it. 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. There'd be so much noise. It's just almost impossible, impractical to do real controlled science there.

JE:

So, you're left with, how do you tell what's good and what's bad, what's working, and what's not. I don't think we have really good answers to those questions. It's something we need to be asking ourselves.

SK:

What about whatever has won is best, whatever more people use?

JE:

Well, clearly, nobody believes that, right? That's "worse is better." That's whatever has a pathway in the marketplace to adoption by being 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. So, we'll just keep making it harder and harder.

SK:

So, I'm trying to think about how we make progress as a community. The way it currently happens is, basically, there's no methodology and no organization, or there's very little methodology or organization in our little reinventing, future of programming community. It's more like we're all just doing our own little independent work, and we'll occasionally through various venues like your conferences or my Slack group will share things and talk, but it's very much just 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 that how you see it just like this big mess or you hope that there will be something more structured?

JE:

Well, this is what I call my community organizing efforts, right? We need to build institutions which are dedicated to improving programming. 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 people are expected to actually try and position their work relative to past work and say how it's different, what they learned from the previous work, and what they're building upon, which we don't do at all currently.

JE:

And also try to start coming up with, having people suggest why, explain why their thing is better, not just say, "Hey, here it is. It's cool," but actually trying to make an argument, "What is better about this? Why do you think it is?" It's not empirical data. It's not a theorem, but there's still reason. There's argument. We should make a persuasive argument for things.

JE:

So, just 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, the incremental ratcheting nature of it that you're kind of competing, but you're also cooperating with other people.

JE:

So, I would just like to start building a place where that positive feedback loop of research can occur. It's not occurring in the existing programming language research venues because they're playing a different game. It's not a working 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.

JE:

Normally, in our society, academics is the place that is supposed to take on this responsibility, but for various reasons, they aren't into that right now. So, we have to invent our own. I would note that other engineering fields also have professional societies, 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.

JE:

That's really strange. There's no American Programmers Association, right? All we have is the ACM, which is entirely taken over by academics. They just have lip service to practitioners, but it's a completely academic thing devoted to the career needs of academics. So, we're a young stupid field, right? We haven't figured things out, and we haven't ...

JE:

Part of the problem is ... Am I just ranting here? Part of the problem is that we're such a young field 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 because we're growing so fast that we keep getting new entrants, new young people coming in. So, everybody was born yesterday, and so there's so few people that have been around a long time like me. Our voice is drowned out and worse, it's almost deprecated, right? People consider old timers to not have anything relevant to say in this field, unlike other engineering fields where someone who's built big things successfully for decades is considered to actually maybe know something. But not in our field.

JE:

It's the elders that traditionally focus on investing back in the health of the community and the field as a whole. So, we don't have that feedback loop working yet. We need to work on that. It's really hard. We can't really ...

JE:

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. It's perfectly fine. I work at Google, where I get paid a lot of money. We're doing great shit. It's all good. What is your problem, dude?" And I don't have an answer to that. I mean, 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, right?

JE:

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 to people. I can just make an argument. I can say, "Well, look at spreadsheets. Look at how people use spreadsheets."

JE:

Surely, there's got to be something that's almost as easy to use as a spreadsheet that would let people do things, but I can't prove it until ... I mean, the way to prove it is by demonstration, by example, right? "Okay. Here it is." We haven't got that yet. We don't have ... 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.

JE:

I think the real problem, ultimately, is there's some very hard technical, theoretical problems about rethinking the way we do programming. 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 is this institutional problem. It's culture and institution is what's holding us back.

JE:

We have a culture of programming which is really toxic in many ways. Toxic is a loaded word these days, I'll retract toxic. I'll just say the culture of programming is counterproductive. It's not heading us in the right direction. We're foolishly making things worse for ourselves unknowingly. It's just many of the normal pathologies of smart, young guys like I was, we're just too full of ourselves in our smartness. We need to get a little humility, and a little experience about what actually works.

JE:

That's easy to say, "Oh, just wise up." 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 learnt them to the young people who don't need to go through and learn the hard way. So, we're really lacking in good institutions. I think in the long term, that's where we need to solve that problem to really make progress.

JE:

We need to have institutions that are concerned with the actual practice of programming, not just publishing 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. I'm not in a position to create such an institution, but I would certainly love to be part of it, if we can somehow get the energy together.

SK:

Cool. So, just to wrap up, I 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 links or pointers or email addresses you'd want to have known to people?

JE:

Right. Well, so, I mean, at this point, your Slack is a good place, although, you really should get off Slack. Slack really sucks, it's just a chat app. I hate it.

SK:

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.

JE:

Yeah. So, your Slack is a good place. 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, the live workshops. There's also the <Programming> conference, which is run in Europe. It's "angle brackets Programming". It's dedicated to the-

SK:

For those of you who can't see, Jonathan is right now making angle brackets with his hands in the air because-

JE:

Well, you can't see it either, but you knew.

SK:

Haha, I've seen you say the word before.

JE:

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, and the pseudoscience.

JE:

So, that's a new thing. They're just getting going. I hope that will gel and turn into a really good place for this kind of work to happen. So, 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 think-pieces.

JE:

So, at this point, those are the two main places to go. Onward! at OOPSLA, at Splash it's now called, is the Onward! track, which is dedicated to, again, paradigmatic crazy ideas, is another place that this stuff happens. Although, that's tending to mature a bit.

JE:

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 got a full-time job. Research is not easy. That's definitely one thing I've learnt. There's a lot of dead ends. You got to be willing to go down a lot of dead ends.

SK:

Yeah. One of the things Bret 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.

JE:

Yeah. That's right. That's very true. I'd agree with that. You only do this if you have to do it. You have no choice. Now, Bret Victor has done a great job of popularizing this stuff. Most people say they were inspired. I predate, so 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 Bret.

JE:

What does that tell us? Do we need to work more on getting the message out to a larger audience? I don't know. Because Bret is not doing that sort of evangelization anymore in general. He's got his own thing that he's working on, DynamicLand. So, that's his thing now that he's doing. So, we don't have a really good public figure presenting these ideas... what's the right word? Evangelizing, I guess, these ideas. Maybe that's what we need.

SK:

Yeah.

JE:

Maybe it's you! Maybe you're the person.

SK:

Maybe it's me. 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 ... Nobody would call Bret Victor's work shallow, but there's something ... He was pointing us in the right direction of improving programming, but he left us to fill in the details.

SK:

I think a lot of us like you and me want to fill in those details ourselves, so we're too busy doing that to go around giving talks about why programming needs to be improved. So, I guess that's one of the core problems. We need to find someone who's passionate about the problem and not really passionate about solving it, just more passionate about getting people excited about the problem, almost. So, I don't know. Anyways ...

JE:

I think it would really help to have a win. It would really help if we had a success story. So, maybe Subtext, 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.

SK:

Yeah. That's true. It's funny that you mentioned the win because when I was in college, I remember looking around being like, I don't know who, but one of these kids is going to create a startup, and it's going to be worth a lot of money, and it would be a success. I'm going to go to school with someone like that, but who's it going to be?

SK:

Then it happened. A bunch of people started startups. They all failed, except this one kid, and his second startup is quite successful. I don't know, but there's something about it just validating that one of us made it through. And it's funny because in our little community, it feels the same. There's, I don't know, a few hundred of us at least, maybe more, who are 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 succeed. I guess that was Chris Granger in Eve. They were the first mini success story, which was I guess validating, but also disheartening.

JE:

Unfortunately, they didn't in the end. So, now, they're a cautionary tale, but yeah, Eve could have been it. But you know what? Probably not a couple of hundred people, though, in terms of people that are working at least half-time, let's say, because it's really hard to do this, nights and weekends.

JE:

So, people that are working at least halftime 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.

SK:

Yeah. That's a good point, drawing the line there. There are a lot of people who do this in nights and weekends and 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.

JE:

Right. 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 I think it's really true what Bret said that this is painful. Research is painful, and it is so hard to break out of everything you know. It's so hard that you can only try to do it if there's something driving you, something really, really driving you.

JE:

With me, it's just an obsession. I mean, 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.

SK:

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.

JE:

Yeah. Thanks. 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 probably natural for me to feel fatalistic about everything that, "Oh, this is pointless." But in fact, there is an uptick in energy here. You've added a lot of energy to the group, and a few other people. I was at the PPIG. Oh, yeah, PPIG. I didn't mention PPIG, Psychology of Programming Interest Group. That's another interesting venue for this kind of thinking. Those guys are doing some interesting stuff. So, maybe there's a ...

JE:

Here I am watching the surfers come in on the surf here, so the apt analogy might be that we have a bit of a swell here building. So, we should try and ride it.

SK:

Yeah. Sounds great. It's great to end on an uplifting note there. I feel it, too. I personally ... 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 listening to other people talk. I had a strong feeling of momentum. It made me think, get teary-eyed about, maybe this is the modern day Homebrew Computer Club where Steve Jobs presented the first Mac.

JE:

Yeah. Who knows? Maybe. That's great. Well, thank you for ... maybe I will quote you on the marketing literature there: "I was able to sit still through the entire thing!"

SK:

Ha!

JE:

But yeah, there is some energy here. I've been trying these kind of events for a while here, and I just think that that last LIVE one had more energy. So, that's a really good sign. Hopefully, it's not a fluke and we should just keep pushing.

SK:

Yeah. Great.

JE:

And your Slack, you've got hundreds of people on there now, right? So, that's a real positive sign. I'm really shocked. Are you at all surprised at how popular that has become?

SK:

Well, it's funny because it's kind of like boiling a lobster, I just got one or two or five people a week for I guess a year and a half, two years now. At no point was it surprising because it just happens so steadily.

JE:

Yeah. So, that's good. I guess 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, something to think about. Open forums, there's only so much you can get out of it, like on Twitter. Limited bandwidth, but I think maybe we could think about institutionalizing those writer's workshops that we ran with you and Geoff, right?

SK:

Yeah. That's good.

JE:

That's what FPW was. Maybe it's time to bring FPW back as part of some local meetups with for your Slack people.

SK:

Yeah. That's a great idea. I've done a lot of thinking on this. 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. Aidan Cunniffe, who I interviewed on the podcast and is in the Slack group, he has a company Optic. He was brainstorming with me different ideas around ... I think we may have talked about it, different ways to do online versions of those kind of meetups, where people from all around the world could join in, and some people could present, and then others would give feedback, something like that.

SK:

I don't know. I think part of what's hard about community organizing is that there's no rules. There are really infinite possibilities, and it's really hard to understand what's going to work because the feedback loop cycle is so hard. I had no idea what a 200-person Slack group would be like until a year or two in it. I was like, "Wait a second. Slack is not the right medium for this," but now it's kinda, not too late, but it was hard to predict going in.

JE:

Never say it's too late, because 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, and it was unthinkable that we would make a breaking change." There's always more users to come in the future.

SK:

That's a good point. Yeah. For Slack, specifically, I'm not shy about leaving if I found another platform I liked a lot better, but 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.

SK:

Anyway, I think 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.

JE:

Yeah, likewise. Thanks for inviting me, and we'll talk again soon.

SK:

Talk again soon. Bye.

JE:

All right. Bye-bye.

SK:

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 in to our online community. You can join our Slack group at futureofcoding.org/slack, where we chat about these topics, share links, feedback, and organize in-person meetups in various cities, New York, London, now in San Francisco, Boston, and also Kitchener-Waterloo in Canada.

SK:

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 @stevekrouse, so I can join the conversation.

SK:

I also accept support directly on Patreon at patreon.com/stevekrouse. 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.