Hey everyone! I'm Eric, I'm a PhD student in Human-Computer Interaction at UC Berkeley. I study scientific researchers and how they learn things about the world with programs, and think about how to design new programming languages/tools through long term collaboration with domain experts. I have a love/hate (but mostly love!) relationship with notebook programming, and have spent the past few years thinking about other ways notebook programming could work. Happy to be here 🙂

Welcome! I'd love to know more about your work because I belong to the species that you study: I am a researcher in computational biophysics. I love/hate notebooks as well, though the hate is directly more specifically at Jupyter for various reasons. My main criticism about notebooks is not the tools themselves but the widespread belief that they are "the future" of whatever, rather than just a first step on the road towards digital communication in science.

very cool! Its nice to meet you. One of the problems I think notebooks suffer from right now is that they're asked to do multiple contradictory things. One one hand, they are iterative, exploratory, debugging/composition/ bespoke visualization environments for scientific programming and data analysis. On the other hand, they are supposed to be authoritative scientific documents which demonstrate how to reproduce a result and publicly shared. While I think its very interesting to explore the relationship between these goals, at least in my experience they lead to very different kinds of programming, and its not clear to me that supporting users in either of these goals is best done through a single environment, which often ends up being a compromise between the two. For example, a defining feature of Jupyter notebooks is a manual control flow of the cells — the user can execute the snippets in each cell in whatever order they choose. In the small scale, this is great — users can write a few lines and then run just those lines to see the result, users can experiment with alternative programs by running cells in different orders, etc. But as soon as we want notebooks to be authoritative documents where we report on science to the community, these features are seen as problematic, leading to "mess" that needs to be "cleaned" or prevented all together (as some alternative notebook systems try to do, like Observable). But I think a danger in making notebooks too clean and streamlined is that you remove all the features which made notebooks compelling iterative, exploratory programming environments in the first place, and we're instead just trying to make notebooks that feel more like a traditional text editor. My notebooks work has been trying to figure out other ways out of this, that give users the real benefits of notebooks as exploratory programming interfaces while also avoiding the "conversion" process of a "working" notebook to a "publishable" notebook, which are, at least in my experience, very different kinds of documents with different purposes. In my first project, I wanted to think about how to give the user the freedom to experiment in an interactive computing environment in the small scale (aka small neighborhoods of cells), while giving the notebook as a whole a bit more structure (thats a very abstract way of putting it, but I think just seeing the interface will communicate much better how it actually works). Right now I'm working on a project which tries to think about notebooks as temporary environments on regular, non-notebook, textual programs. I'm calling it a Notebook-on-Demand because I want to figure out if we can get many of the benefits of notebooks as interactive programming environments while still having our programs live in regular text files, calling a notebook only when needed for interactive visualization, composition, and debugging. One of the most interesting things about this project for me has been realizing that once we unload the responsibility of the notebook interface to actually contain the entire program we want to run (or at least be the entry point to call other functions), and instead think about how to make a great programming interface for composing/visualizing/debugging a single function, we can do some fairly interesting things. In the repo I linked, you can see that we now display a callstack navigator of your program in the notebook and allow you to save variables from your program execution to insert manually in your notebook state. I think these would be really confusing if you put these in a regular notebook! But because our program text in a traditional IDE is the place where the program can be organized, the notebook can focus on just the things it does well.

they're asked to do multiple contradictory things

Exactly! And I agree with you that they are much better as an interactive interface than as a unit of publication. At best, notebooks have been used as executable supplementary material to publications. And I also agree that the two envisaged use cases for notebooks have contradictory requirements. Which is why I am not optimistic about various intermediates that move a bit more towards publication, such as Quarto. My own work has concentrated on the publication end, and what I came up with doesn't look like a notebook at all. For a description, see my contribution to the Substrates 2026 workshop. And have a look at the other contributions as well, including @Tom Larkworthy's story of Lopecode.