REPL + Debugger = REPLugger, a pleasant and scalable live code editor

Hello friends! 😄 In this email I'll be describing my work on a research programming environment, a mix between a code editor, a REPL, and a debugger, which I'm naturally calling REPLugger.

The main summary of the editor is in this 10-minute demo video. You can click the image below to watch and then read on for more context.


As I said in the video above, my experience programming in Flowsheets felt so great that it became my preferred way to manipulate data even though it was a research prototype. But it was clear to me that an environment like Flowsheets only worked for smaller scripts and wouldn't scale to larger projects. Flowsheets' emphasis is on data, but in large projects (like the code for Flowsheets itself), there is too much data to show all at once. Still, I wanted a way to provide concrete feedback with data to programmers since I think this is one of the main reasons programming is frustrating.

Stepping back a little, It's crazy how little feedback programmers get when they program. As my friend Michael Nagle described programming: "You type text into a box and have to guess if it works? What?!" Humans understand systems best when there's a tight feedback loop. If you've ever had a shower where there was a significant delay when changing the water temperature, you know how lack of feedback can make even simple tasks difficult. And programming is obviously much more cognitively complex than adjusting shower temperature!

I made REPLugger to try to shorten this feedback loop, especially for expert programmers. Common criticisms of research programming systems are that they're made for beginner programmers, they only work for toy problems, or they don't provide enough utility for programmers to adopt them. I appreciate these criticisms and share what I think is the underlying concern about research that doesn't impact human experience. To meet these criticisms, I wanted to show a system that a) I wanted to use myself and b) would work in the context of a real, complex project, and c) provided a plausible means for scaling. I think REPLugger accomplishes all these goals and I'm very happy with how it turned out.

  Having a REPL-like experience directly in the editor feels great. So often when programming I just want to answer simple questions like "did the line of code I just wrote work like I expected it to?" Modern-day programming makes answering that question needlessly frustrating.

Like Flowsheets, REPLugger just feels good to use. When programming in a large system, there's so much data and context I need to keep in my head. Having REPLugger keep track of that context for me feels like it frees up some of my thinking capacity.

The REPL-like experience being available right in the editor also encourages me to try things out that would normally be too cumbersome. REPLugger is even better than a REPL in some ways since it has the entire program context built-in. This makes it easy to try things out using the entire state of the running program, not just a small toy environment. And it's easy to fold these experiments back into the larger program, since you never leave the larger program context in REPLugger. Since Flowsheets v1, I've been really excited about what I'm calling "overwrites". Another name for them might be "what-if scenarios". The basic idea is to re-run a program, but instead of letting it run deterministically, the programmer manually overrides certain values in order to test out an idea. Ever since I was a software engineer, I've wanted ways to be able to set up specific scenarios for the program I was working on. Bugs would happen and I had hypotheses about why they were happening, but it was difficult and time-consuming to get the program into the correct state to test my hypotheses, and once I did it was hard to get feedback about the effects of that state. What I really wanted was to be able to modify the system state directly to see if that state would create the bug. With REPLugger, I provided overwrites as a way of giving programmers explicit control over program state. Part of why programming is difficult is because programs have so many potential states. Even though this is one of the main difficulties, most programming tools don't provide ways of working with states directly. It was my aim to lower the barrier to trying things out and validating hypotheses as much as possible.  It's been almost a decade since I was a software engineer, but I'm happy that I was able to demonstrate overwrites as a way of addressing real problems programmers face.


As a researcher, I'm predisposed to favor more ambitious ideas that could have a large impact on the ways programming is done. But from a compassionate viewpoint, I want to reduce the suffering that arises from poorly designed technical interfaces. My aim is human happiness, and I only try to work on things that directly impact programmer happiness. I'm on board with any interventions — large or small — that help people be happier. In many ways, my heart lies with beginners — the jump from 0 to 1 is somehow so much more harrowing than the jump from 9 to 10. However, as someone that's programmed for a decade now, I'm far from a beginner. Observing my own experience programming and the experience of other knowledgeable programmers, I see that experts suffer too, and that is unreasonable.  As I see it, most of the suffering in programming stems from difficulties understanding what programs are doing. Beginners have difficulty understanding the affordances of programming and how they can use those affordances to do what they'd like. Experts have difficulty creating and understanding complex systems they're working on. Both have to construct elaborate models in their heads of how their programs work with little to no feedback from the program itself.

My belief is that providing tools to augment programmer understanding is one of the most important interventions we can make. Specifically, I think concrete feedback and giving programmers tools to quickly try out ideas will leverage existing human capacities and make the experience more pleasant for everyone. My sincere wish is that these interventions reduce suffering and help programmers flourish.