There was a ton of little problems involved with getting all this to work smoothly, but now that it does work (besides some bugs I'm sure), I'm most curious about what programming is like with this kind of tool, so I'll say a bit about why I think this system is interesting. Personally, I think one big thing that separates pleasant and joyous notebook experiences from depressing and confusing ones is scale. When notebooks stay small (<15-20 cells usually) they can be lovely environments for writing and inspecting programs. When notebooks get big, they get hard to navigate, hard to reorganize, and hard to build on. Lots of new notebook interfaces have tried to redesign notebooks in order to make them better at these last three. The idea of this system came about when I realized we already have an interface that does these latter things pretty well: regular IDEs and text files! Rather than try to make notebooks more like text files (e.g. by fixing the order of the cell execution, having variables be by default scoped to each cell like psuedo-functions, etc), I wanted to explore whether just making it as easy as possible to transition between a notebook and a text file would address many of the problems notebook users have. If they could keep their programs in python files, modules, functions, and classes, but be able to jump into a notebook as the need arose without any overhead, maybe notebooks would never need to get big enough to run into the problems that we see users have. Beyond that, building this system also showed me that there are some interesting things notebooks can do once they can just be ephemeral interfaces on some parts of a program. Because the program's stack frames are the data your notebook-on-demand interface is built on, rather than the organization of your program text in a file, we support navigating your code by traversing up and down your stack, filling in the right state to your notebook kernel. We can also let users save values while the program executes to inject later (to test out arguments from multiple invocations of a function interactively, for example, without having to re-run the whole program). I think both of these would be horribly confusing in a regular notebook, but because the user's program can live safely in a text file, the notebook-on-demand interface can (I want to argue) focus on being a good inspection/composition tool for small bits of a program, which opens up some interesting possibilities I think! Would love any thoughts/feedback/reactions! I'm also running a study on how folks program with this tool for my PhD (which mostly involves just using it for a few weeks and then nerding out about programming interfaces with me for an hour or two, with a $60-$100 gift card!). If that sounds interesting or you know a python programmer who might find this useful, I would really appreciate the help! All the info is in the readme. Thanks ❤️

@Konrad Hinsen Yes! I think the basic idea is very reminiscent of how smalltalk does it. Most of the implementation challenge was figuring out how to make this work smoothly within Jupyter's architecture, but it wasn't a mystery that giving python users a way to insert an interactive environment in the middle of their program would probably have some good uses. Personally, I'm most interested in thinking about how python programs change once we also know that we can open that 'same' program as a notebook. Using nod for my own work, I find myself making little bespoke debugging and visualization environments for individual functions, since markdown cells are converted to comments and cell breaks are converted to new lines. I can leave in code which generates a rich output (like a data table), but just comment it out when I send it back to my source file (I'm thinking of more elegant ways to do this, but for now commenting isn't too painful). So if Nod is doing anything new (and maybe it isn't!), it might be the combination of a smalltalk-style debugging/composition tool with a notebook interface, and thinking about functions as little micro-notebooks.

@Tom Larkworthy oh cool! Yes, totally agree — I think theres a real "whole is greater than the sum of the parts" effect here — being able to move flexibly between environments gives you a way of interacting with and thinking about your program that feels different than either environment alone.