Are you using interactive notebooks for your data exploration or your day-to-day programming?
What environments do you use?
Was it Jupyter and now you've made your way over to JupyterLab?
That's a great choice, but did you know there are more environments out there to choose from and to compare?
Have you heard of Callisto or Iodide?
How about CoCalc or PolyNote?
Those are just the tip of the iceberg.
That's why I'm happy to have Sam Lau and Philip Guo here to share their research,
comparing and categorizing over 60 notebook environments.
This is Talk Python to Me, episode 268, recorded June 11th, 2020.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm and follow the show on Twitter via at Talk Python.
This episode is brought to you by Linode and Sentry.
Please check out what they're offering during their segments.
It really helps support the show.
Sam and Philip, welcome to Talk Python to Me.
Pleasure to be here.
Same here.
Yeah, nice to have you on the show, Sam.
Philip, welcome back.
You've been on the show a few times.
You were one of the very first guests way back when, diving into the CPython source code internals.
And then we've talked about a bunch of fun topics, you know, coding in your golden years and maintaining open source projects individually and things like that.
It's been a lot of fun to have you on the show and nice to have you back.
Yeah, it's great to be back.
And yeah, that was my first ever podcast with you.
That was, I think, almost five years ago.
It's good to be back as a podcast veteran now.
That's right.
You know the whole deal.
And Sam, welcome to the show.
Before we get to the main topic, I always like to set the stage for where the guests are coming from.
So when somebody says, you know, like, I think you should really do this, like, they might say that because they're a biologist using Python, not a person running Facebook or the other way around, right?
So maybe just tell us really quickly about your background and how you got into Python.
My background in Python came from, actually, back in high school, I ran into the first wave of, like, massive open online courses.
Right.
And so, like, at my school, there wasn't much emphasis on programming much at all.
And so when I ran into, when I found out about those courses, I got really into it and decided to major in computer science at UC Berkeley and then ended up doing, ended up starting this PhD at UCSD with Philip studying cognitive science.
Cognitive science is really interesting.
I've talked to a few folks from there.
There's a lot of interesting computational CS type problems happening in cognitive science.
Yeah.
And data science as well.
Absolutely.
I worked for a while at a company that was basically a spinoff from a research lab that was a bunch of cognitive science PhDs.
And we did all sorts of cool stuff with eye tracking and programming.
And, man, it's just a lot of fun.
I really enjoyed my time in that space.
Yeah.
People here are, cognitive science is so broad that you have people here using programming for all sorts of tasks.
Like, we have people here training deep neural networks, but also people studying fMRI signals and processing those and working with neuroimaging.
And so you just get a really diverse, broad range of perspectives and uses for Python.
Yeah.
It's interesting, too, because I feel like there's still a lot of open questions.
Yeah.
There's a lot we don't know.
And it feels like the more we know, the more we know about what we don't know.
Yeah, exactly.
Every answer opens up to more questions.
That's right.
Exactly.
All right.
Well, we're going to talk today about the research that two of you have done in the space of notebooks, as in computational notebooks, Jupyter notebooks, that type of thing.
And it turns out, actually, there's more than just IPython and Jupyter, right?
Quite a few more.
Yeah.
So in our paper, we talk about a total of 60 different notebook systems that we put together and try to draw out some patterns from.
Yeah, it's really interesting.
I mean, people, I think Jupyter, IPython, when it was first started, became Jupyter, really changed the way people thought about programming.
I mean, there were tools like this.
Maybe you guys can throw out some that felt kind of like that.
So when I say that, the one that comes most to mind is, I think, Mathematica or Maple, right?
They're really beautifully visual, but then they also had computation, but they also had like output, you know, MATLAB, but MATLAB's not quite as pretty, for whatever reason, more utilitarian, I guess.
And when you thought about programming, that was, you know, maybe if you're trying to emulate that, it would be a script, and then it would like output some stuff, or it would pop up a window, it'd save like a JPEG or something.
But the notebooks really brought those two worlds together.
Say, look, you can write code in a, like a pro programming language in a way that you really would use like libraries and stuff that are not just baked into these tools.
But then they have this kind of interactive world.
I think it's really interesting to see all these derivative concepts, right?
We've got Jupyter that had its way of doing things, but there's challenges there, and there's a lot of variation.
Like, were you surprised to find this many different systems around?
I certainly was.
I think I came into this project thinking, oh, it's probably just Jupyter plus like maybe three or four other systems.
And I think the deeper we went, the more we were like, whoa.
People are really taking Jupyter and changing it, adding new things to it, making it fit their use case more effectively.
And there's a lot of, it turns out that there's a lot of different groups studying Jupyter and notebook systems in general and trying to figure out how they can make it better for themselves.
Yeah, I think I'd just add to that, to what Sam said, was that, you know, we started this project.
So this is, this paper is co-authored by Sam, one of my other PhD students, Androsos, one of my undergrad students, Julia Markle, and myself.
And we basically just kind of split up the work and just went to find a lot of these notebook systems.
And the motivation for this was that, you know, in the academic literature, in the kind of academic world of studying programming tools, in the past few years, there's been a lot of people studying how people use notebooks.
I believe Adam Rule was on your podcast, Michael, was Adam?
It sounds familiar.
Yeah, he was about the Jupyter, the, you know, analyzing the million Jupyter notebooks.
Yes, that's right.
Yeah, that's right.
Yeah.
So there's a bunch of studies around Jupyter notebooks and how people use them for science and stuff, and then people developing new prototypes.
And at the same time, there's a bunch of industry people, you know, every startup company is like, we're going to do a notebook, we're going to do this other notebook, this other notebook.
So it became like this wild west.
That's right. Google CoLab, DataLore, Azure notebooks, all those, yeah.
Yeah, so it became like this wild west, and we felt it was around time for this sort of what we call a survey paper or a meta-analysis, right?
It's like, this paper is not doing original research in that we're not making a new notebook, but we are collecting together dozens of these notebooks from both academic prototypes and also industry products and trying to, like,
analyze them and see, you know, how does this space fit together?
So I got a few of my students together, and we kind of brainstormed and looked for a lot of notebooks and stuff.
And then Sam, who is the first author on this, kind of, you know, did a lot of the leadership on this work.
So I'll let him talk more about the details, because I forgot all the details, so I just delegate them.
Yeah, sure.
Yeah, and your primary research is in human-computer interaction?
Right, right.
So my primary research area that my students are in is called HCI, or human-computer interaction.
And the kind of industry term for this is, you know, people know it as UX design, right?
User experience design, user interface design.
And, you know, HCI, or human-computer interaction, is sort of the academic term for the research that goes into how do you make better user experiences for, you know, different kinds of users.
In this case, it's for scientific programmers and data scientists.
Yeah.
Okay.
Now, I think probably we should start this conversation with a definition, because I kind of opened it saying, well, Jupyter is the prototypical thing of what a notebook is.
And it's kind of the natural progression of something like Mathematica.
But what would you all define a notebook system to be?
So, like, how do other things that are, you know, not exactly that fit into this world?
In this paper, we define a computational notebook as a system that supports literate programming, where you can blend a text-based programming language with program outputs in a single document.
Right.
And this is not a super new idea, right?
This, I mean, Donald Newt is like in the 80s or something talked about this idea, right?
Yeah.
And actually, I think the entire tech program, like LaTEC, the tech that Donald Newt made, was a literate program to begin with.
He was like the, I would say, like most prominent proponent of literate programming.
Okay.
So, notebooks are these embodiments of this literate programming idea.
Basically, I guess I'm hearing that it's the ability to blend together the presentation of, like, prose almost, and computation and visualization around that.
Yeah, yeah.
And it kind of shifted the dynamic of how we view a program.
Instead of having a program be instructions for a computer, it allowed us to see programs as kind of like the outputs themselves, as a thing that you would show to other people in the end.
Yeah, because traditionally, it would be, here's the graph.
Exactly.
We ran the analysis, and this is the output.
Here's the description of the output, maybe a description of the algorithm, and here's the output.
And, you know, there's been a big push in the scientific space for reproducibility.
And I think also just in the data science space for explorability, right?
Like, I've got data.
I don't really know what it is.
I need to just get in there and play with it before I turn the algorithms loose on it.
And that's kind of what's happening here, right?
Yeah, definitely.
I would say many of the projects that we looked at in this paper were birthed out of this, directly out of, like, the reproducibility issue, where some person might write a script to generate a graph somewhere, but then lose it.
And then all you have now is, like, a graph in the end.
If you had a notebook, the pitches, if you had a notebook, you wouldn't need to have a separate graph, like JPEG, and then a separate program to run it.
You could just have it in one place.
Right, right, right.
How often does version control in the science space or the sort of beginner developer space look like a bunch of zip files where they're named the thing and then the date or the thing of the date and then, like, two and then three?
Oh, yeah, exactly.
Something like that.
It's like zero five underscore final final V3, you know?
Exactly.
Final edited.
That's not amazing.
So having something in here that sort of brings a little more formality and brings, I guess, the paper and the presentation and the script or code that ran it, like, into one thing that's versioned continuously seems a little bit better.
Yeah, and actually, there are the basic way to version control a Jupyter notebook is to put it in a version control system like Git.
But oftentimes, it's not good enough for actual scientists who have, like, the notebook files themselves, but also their data and also the libraries that the notebook use to generate the outputs.
And so there's a group of projects that we surveyed that not only version a notebook, but also in version a notebook and the dependencies.
Okay.
Yeah, very nice.
One of the challenges, however, I think it's ironic, like, it brings stuff together here to make the code and the analysis and the presentation all as one.
But it actually, Jupyter notebooks are not very easy to version.
Quite hard, actually.
Yeah.
Yeah, like, if they store the last run of the output, and if that is dynamic in the sense that it's, like, not every time you run it, you get the same output.
That can be a, I mean, even if it changes, right?
Even if it is that case, it's still hard.
But if it's, like, changes every time you run it because it pulls something from the internet that varies or whatever, it's basically always a merge conflict.
So there's tools like NB strip out, which are nice, that are, like, pre-commit hooks that'll let you do that and other ones.
But still, it's, I think it's, these notebooks, they come both with, like, a new power and accessibility, but also their own challenges.
Yeah, exactly.
Yeah.
So in your paper, one of the things you all talked about is you said around notebooks, they have these several themes.
They have end-user programming, exploratory programming, live programming, and literate computing.
So what do you mean by, like, live programming?
I understand end-user programming, which is pretty cool.
Observatory makes sense.
But what's the live here?
So, yeah, so there are a few kinds of definitions of live programming.
One definition comes from kind of the creative space.
So there are these people who are graphic artists or musicians who actually literally, you know, they're streaming on Twitch or they're doing these, you know, pre-COVID, I guess.
They're doing these live performances on stage where they're using some kind of graphical software to, you know, Max MSP or whatever to put together live music performances or graphical art.
Another form of live programming that I think what we mean in this paper is more like a programming environment that updates live, right?
So as you're typing the code, it's actually just constantly running it and generating output.
So some of the notebook systems we've looked at allows you to kind of do this live programming where as you start typing, it might autocomplete.
It might start generating graphs for you just to kind of cut down on this edit run loop and such.
Right, right.
It's not this I'm going to edit when it's time to hit run, I run.
Or, you know, maybe in some languages there's a compile, then a link, then a run, and there's a big delay.
Would something like some of the features in the editors, like PyCharm and probably VS Code, I don't know what plugin you need for it, but where it's like continuously running unit tests just as you type?
Yeah, I mean, that's a form of liveness, right?
The kind of, you know, whatever.
And even like, you know, even the squiggly lines, right?
The IntelliSense and the, you know, linting and those things.
You know, anything that kind of cut down on the, you know, the friction of having to write a bunch of code.
Because especially for beginners, right?
So for beginners and for people who might be scientists and people who may not be as programming experienced, you know, one thing you often see beginners do is they write a lot of code, right?
They write a lot of code and they sit and they hit run.
They're like, why doesn't it work, right?
Whereas more experienced programmers kind of know to write a line, check it, print something out, make sure it works, and then write the next line, write the next section and such.
Yeah, it's easy to do a bunch of work and then have it, especially when you're new, and have it not come out the way you like.
And you're like, well, now it's broken.
Oh, no.
What am I going to do, right?
It's small bites, of course, small steps.
This portion of Talk Python to Me is brought to you by Linode.
Whether you're working on a personal project or managing your enterprise's infrastructure, Linode has the pricing, support, and scale that you need to take your project to the next level.
With 11 data centers worldwide, including their newest data center in Sydney, Australia, enterprise-grade hardware, S3-compatible storage, and the next-generation network,
Linode delivers the performance that you expect at a price that you don't.
Get started on Linode today with a $20 credit, and you get access to native SSD storage, a 40-gigabit network, industry-leading processors, their revamped cloud manager at cloud.linode.com, root access to your server, along with their newest API, and a Python CLI.
Just visit talkpython.fm.com when creating a new Linode account, and you'll automatically get $20 credit for your next project.
Oh, and one last thing.
They're hiring.
Go to linode.com slash careers to find out more.
Let them know that we sent you.
When you had live here, and you talked about the live, sort of interactive, almost onstage type of stuff, I was thinking of FoxDot and the live, like, musical composition with Python.
Have either of you guys seen that?
No, I haven't seen this.
I have not.
I think it's called FoxDot.
I'll put a link of a presentation.
So there's this thing called FoxDot, which is Python-based.
People can go up there, and they basically create little, like, symphonies.
Oh, that is awesome.
And with Python, and it's super interesting.
Anyway, I was going to ask your thoughts on that as a sort of HCI person.
Yeah, yeah.
I'll get it next time.
Yeah, I grabbed a, yeah, I'm just looking at the page now.
But yeah, that's a whole other world.
I mean, it's an awesome world.
I mean, this whole world of just live performance and, you know, live streaming and stuff is fascinating.
You know, maybe the next Twitch stars are going to be data scientists, right, who are, you know, live streaming their exploratory analysis.
There are some data scientists I've seen who do these live streams or do these, you know, recorded sessions.
Like, let me just play with this data or do this Kaggle thing and just watch me play with it, which is really cool.
That's really, I think you're right.
I think it's super interesting.
I feel like a lot of algorithms and libraries and just software products, I guess you'd call them.
It could be very stale, you know, much like math or science.
Like, here's the final result.
Here's the algorithm or the formula.
But that doesn't give you an appreciation of, like, seeing the, how do I, like, bumble around and, like, discover and think and try and explore and then come up with an answer.
I think that would be really interesting for data science and, like, Kaggle competitions and stuff.
Yeah.
And I think that segues to our notebook work, too, because I feel like a lot of these notebooks, maybe Sam, I'm going to talk more on this later, is that, like, a lot of these sorts of interfaces could support this sort of liveness and this sort of iteration and keeping different versions around and seeing how you, you know, bumble your way toward a final result.
Yeah, yeah.
Maybe the next big particle physics discovery Nobel Prize will be live streamed.
All right.
So, Sam, let's get to the analysis.
So, you said there were a bunch of different environments that you studied and you broke them into three categories, the academic world, the product world, and the R&D world.
Maybe give us a sense of what's in each one.
I don't know if we want to go through all of them, but read off maybe, like, five from each of those that you feel like is representative of that area, just to give people a sense of what's all out there.
Yeah.
So, probably start with the industry world because that world is probably the most familiar to us and maybe to your listeners as well.
So, in the product world, we kind of have Jupyter Notebook and we also have, like, Google Colab, which is Google's version of Jupyter Notebook, as well as Azure Notebooks, which is kind of like this up-and-coming notebook system for JavaScript.
Okay. Oh, right, right. Yeah. There is this move to try to make a JavaScript equivalent, basically, of what Python has, right? I mean, it's pretty natural to run JavaScript, but the trick is to find the libraries, right?
Exactly. Yeah.
And maybe integers.
Yeah.
No integers in JavaScript can make that a little hard, but still, very cool.
All right. And then, next category is academic notebook projects. And these projects typically come in the form of, like, papers. So, people will prototype some interaction and then submit a paper in a human-computer interaction conference.
And these papers typically have, like, they take a base notebook system and extend it in one particular way. For example, the Callisto system takes Jupyter Notebook and adds in, like, some live collaboration tools, like a chat window, as well as, I think, being able to see other people's cursors and where they are on the screen.
A little bit like a Google Doc-ification of Jupyter.
Yeah, yeah. That's what they're going for. We have tools like Rex, which is a tool specifically for, like, data cleaning. So, the idea there is that you would, you could display a data frame in your notebook and then, by example, show Python, in a sense, like, what you want the data to look like after data cleaning. And it can try to infer the Python code that would generate that, that would change the data in the way that you want.
Oh, that's pretty cool. And so, it uses a bit of machine learning or something.
Yeah, it uses what's called program synthesis. Yeah, that actually was a project led by Ian, who was my other PhD student, who was a co-author on this paper. He did this at a Microsoft research internship. So, they have this program synthesis technology. They have this, you know, engine that basically synthesizes pieces of code. And they applied this technology to notebooks. So, what you can actually do is you can, you know, in a data table, you can say, here are some examples of the way I want to clean the data. And then it'll infer. I don't think it actually is machine learning because it's not database. It's kind of rules-based.
Right, right, right, right.
So, you kind of have, like, these experimental, but also, like, you look at it and you're like, well, that could be useful in a real system.
Yeah, yeah, yeah, I could see that for sure. You maybe just drop a marker, like, hey, I'm going to go explore this. I might want to, like, a save point type of thing. Maybe you want to get back here.
Exactly.
And then, right, it'll just sort of, that's, like, behind the scenes. We're going to create a Git branch and start doing stuff for you, right? Like, that'd be really nice for people who are, they don't know how to, like, deal with Git branches or want to deal with it and stuff like that.
Yeah, that's exactly the use case that they were going for. It's for this very exploratory, early stage, like, data exploration. Yeah.
Yeah. Yeah. Okay, cool. The one in the product space that seems to be closest to that is Gigantum. I had those guys on the show and there's a little bit of, like, auto-versioning collaboration stuff in that world.
Yeah, yeah. We looked at Gigantum in this paper and I think we did mark it down as being relatively similar to that.
Yeah, yeah, cool. All right, the third category was experimental and R&D.
Yeah. So experimental R&D is, in a sense, very much like the academic projects in that they are, they're trying to test out new interactions or new features that might not, like, don't have immediate, like, industry use cases or maybe, like, business propositions.
And so we have tools like Carbide is an interesting one. Carbide actually allows you to, it creates widgets for your Python variables in line with your Python code.
And then it allows you to, like, use sliders to change your variables on the spot.
Okay.
And it's, like, way out there. It's really interesting. But you can, it actually infers, like, what values your Python variables should take on to produce an output.
So if you use a widget to say, like, oh, I want Y to be, like, 32, then if Y depends on X, then it'll also update X at the same time.
So it does, like, it's weird. It does look like it's really, like, intriguing, like, program synthesis or, like, program, like, inference, like, behind the scenes to get your program to look right.
Right, to look at the dependencies and figure out what it has to rerun.
Yeah, yeah.
Yeah, that's really cool. It sounds a little bit like the interactive widgets in Jupyter that you can have, you know, you can sort of put some sliders and adjust some things.
But I don't believe the Jupyter one has a lot of pendency type of stuff on down the line, right? It's just like this one cell as you slide the widget recomputes.
Yeah, yeah. Like, Carbide is like those Jupyter widgets, but super next level. The widgets can change the code itself.
Okay, that's pretty wild.
Yeah. We have a few industry projects here as well. We have projects from, like, Netflix and Stripe, where they take notebooks, but use notebooks as, like, kind of, like, recurring jobs instead of just one-off, like, exploratory scripts, where they use notebooks as these jobs.
And so they can re- the notebook might automatically rerun, like, once a day to perform some data operation.
They're kind of, like, broadening the scope of what notebooks can be used for in a large-scale setting.
Yeah, you know, the stuff that Netflix was doing with, like, Paper Mill was super interesting.
How they're using it to automate a bunch of stuff and sort of schedule a bunch of things to work, but also the fact that if it fails, the notebook has the output of the failure.
So basically, you can, you know, save the notebook in that state and just go look at it and see what went wrong.
Rather than there's a log message that says something went wrong, like, there's the whole sequence with the history of the notebook output, which is pretty awesome.
Yeah. I think the Paper Mill stuff, I mean, they have a blog post about it, but we link to all of this in the paper.
So if you, you know, link to our paper, we have all the URLs.
I mean, I thought that was interesting.
I mean, we didn't really capture this in the- in our space because, you know, most of it is for data scientists.
But the Paper Mill project is interesting because it's using notebooks for, like, DevOps and for, you know, production deployment work, right?
It's like really using the notebooks as a kind of a DevOps-y sort of tool rather than a direct data science tool.
So I thought that was a really interesting and out-of-the-box use case.
It's like instead of running cron jobs and seeing, like, gigantic log files on your terminal or grepping through text files,
you can just, you know, reconstruct it in a notebook and actually use a notebook to debug your production software, which is cool.
Yeah. And the essence of that, I think, was one of the things you do with Paper Mill, if I have it remembered correctly,
is the notebooks can take inputs and they can generate outputs.
They're, like, sort of become functions in the traditional black box sense of it.
Yeah.
Yeah. That's pretty neat.
Another one I see that you have in there is NB Dev.
NB Dev is a really interesting project.
I just, we talked about that, Brian Nock and I did a couple episodes ago on Python Bytes.
And I was like, oh, well, this might be kind of interesting.
And I looked and I'm like, wow, this is something really quite special.
It does a lot of neat things over there.
Right. So if I'm remembering correctly, NB Dev allows you to take a notebook and, like, deploy it as a Python library.
Yes, exactly. Yeah. You can basically turn it into a package.
Right. And it can have the test, like, built into it.
And, yeah, it's, again, a really interesting example of, like, notebooks are kind of being reused in all sorts of ways that we would see traditional Python scripts being reused.
So in this case, instead of writing a set of Python files to become a Python package, you could write a notebook instead.
And that could be, like, your package.
Yeah. I'll give you the quick rundown for people who are listening and might be interested just off their little highlights.
So you can export the functionality of a notebook to a library.
They have a CLI commands you can use to interact with NB Dev.
Export to HTML builds documentation for your library.
Sync brings the Python.
So you can edit the Python code and then bring it back into your library.
You can put the tests in there and run them in CI.
There's just a button that also has this, like, NB strip out concept as well for checking stuff in.
So, yeah, that's, I mean, there's a bunch of exploration and innovation happening here.
Yeah, it's really interesting.
One other interesting project in the experimental section is, like, Iodide.
Iodide is, Iodide is, like, super experimental.
But they compiled Python and some of its data science libraries into WebAssembly.
And then because of that, you can run, you can write Python in the browser.
And it doesn't require a separate Python process to run that.
Instead, it runs completely within the browser because your browser is interpreting the WebAssembly version of, like, the Python interpreter.
And, like, I think they have, like, NumPy and, like, Matplotlib support in there, too.
Yeah, they've recompiled many of the core, what would be C-based Python libraries as well, right?
Like you said, like, NumPy and maybe Matplotlib.
I can't remember.
But some of those types of libraries.
Right.
It's really, it took a while for me to wrap my mind around it.
But I was really amazed when I first saw that.
I think WebAssembly has some real interesting possibilities to bring a lot of this stuff together.
You know, it's one of the things that's interesting about some of the stuff you were covering in these different projects here is just what it means to run the notebook, right?
Sometimes that means a Docker image is spun up and configured exactly for you in some environment or even, like, with Gigantum on your local machine.
With Google CoLab, there's, like, a way to say, run this on a GPU, by the way.
Yeah.
Just to get a GPU to run it on.
And Iodide runs in the browser through WebAssembly.
There's just, there's a bunch of options here that are pretty cool.
Yeah.
Kind of to Michael's point, it's like, you know, we've just informally kind of starting this project.
We've kind of heard about all these.
It's felt like the Wild West, right?
It's like, oh, you can run the notebooks locally.
You can run some JavaScript.
Observable ones run the browser.
And, like, you know, Iodide, Pyodide compiles.
The WebAssembly runs the browser.
And then you need some other ones in the cloud.
And then some of them have this live editing.
Some of them don't.
So that's why kind of motivation for putting together this paper was, you know, how do we just categorize all this in the most kind of concise way we can?
And, I mean, we're going to talk about more of this detail, but we have one category about runtime environment, right?
So we categorize, here's the four types of main types of runtime environments people have and other things.
So the kind of main contribution of this paper was really people have all these intuitions.
They've heard about these notebooks doing all these different things.
Let's just try to plop them all together in a map, in a sense, right?
Like, where does everything lie on this wild, this high-dimensional space?
Yeah, it's highly dimensional.
We're going to talk about the dimensions in a minute.
It's more than three dimensions.
This portion of Talk Python to Me is brought to you by Sentry.
How would you like to remove a little stress from your life?
Do you worry that users may be having difficulties or are encountering errors with your app right now?
Would you even know it until they send that support email?
How much better would it be to have the error details immediately sent to you, including the call stack and values of local variables, as well as the active user stored in the report?
With Sentry, this is not only possible, it's simple and free.
In fact, we use Sentry on all the Talk Python web properties.
We've actually fixed a bug triggered by our user and had the upgrade ready to roll out as we got the support email.
That was a great email to write back.
We saw your error and have already rolled out the fix.
Imagine their surprise.
Surprise and delight your users today.
Create your free account at talkpython.fm/sentry and track up to 5,000 errors a month across multiple projects for free.
And if you use the code Talk Python, all one word, it's good for two free months of Sentry's team plan, which will give you up to 20 times as many monthly events in some other features.
So create that free account today.
One thing I do want to talk about maybe first is just like some of the challenges of notebooks and then the paradox of choice.
So first of all, I think this comes from the paper, but also some of the feelings I had.
So you talked about some of the challenges, Sam, being stale data, out of order execution, abundance of code, and then the inability for composition, things that Paper Mill, for example, is trying to solve.
Do you want to speak to some of the challenges you saw out in this space?
Well, one of the first challenges that a user of Drupal notebooks encounters is typically the out-of-order execution problem, where because you can run cells in any order you want, what might happen is you run some cells, and then you delete some cells, and then you write more cells, and you run those in some out-of-order way.
And what happens is, well, one problem is that sometimes your variables just get changed, and you don't know where a change came from because your code might be gone.
Right. You might even delete the cell that defined them.
Yeah, yeah.
But the kernel's still running, so they're still in memory. For now, it's going to be okay.
Exactly, exactly. It happens really, really often, in my experience, when we teach students how to use Drupal notebooks for the first time.
They hit some random keyboard shortcut, and their cell's gone. And it looks like the code's running fine, but then when they try to turn in their code, everything kind of goes up in flames.
Yeah. Well, but it's so much the power of Jupyter as well, right? Like, there's some reports and stuff I have for my business behind the scenes, where there's like a 30-second bunch of reading data, correlating data, and then you want to graph it and slice it and analyze it.
And the ability to just go, rerun the cell that sorts it this way and shows that aspect, it runs instantly, right? It just goes and goes and goes. And it's so powerful to not have to rerun that code to be able to change your analysis or how you're exploring it, right?
Yeah, exactly. That was the selling point of Jupyter. That's why I've got everyone hooked on Jupyter to begin with.
Yeah.
It was like that ability to really quickly.
Yeah, you do the expensive part. Exactly. Exactly.
But it's like the world's worst go-to and then some, you know?
Sure. It's like the human-powered go-to, right? Like, you're self-like running the cells and go-to statements yourself.
Exactly. Like, with a real go-to, it might be really hard to understand, but you can literally go through the code and see it.
Yeah, it's at least deterministic.
Yeah, it's at least deterministic, right? But yeah, it's not even with Notebook. So that's a challenge.
Yeah, exactly.
Because to me, that's the biggest challenge. Yeah, it's this sort of out-of-order stuff. But it's so hard to say, like, well, let's just not do that because it's also the superpower.
Right, right. One of the dimensions in this space, I don't know if we're getting there quite yet, but one of the dimensions in this space specifically addresses this because a number of projects that we see from academia and from industry try to, like, address this specific in-order, out-of-order execution issue.
Projects like Papermode, which we briefly talked about before, address it in a different way by trying to just, like, make sure that whenever a Notebook is run, it only runs from top to bottom like a computer would, rather than how a human might execute it.
So there's different angles on how to get around an out-of-order execution thing. But as you mentioned, it's like the main benefit and also the main weakness of these Notebook systems.
Yeah. Did you guys study Streamlit?
Streamlit?
Yeah.
So Streamlit has a really interesting way of solving that in that they basically use Funktool's LRUCache.
They don't exactly use that, but they more or less, the concept is the same.
And they've got these different functions that more or less act like cells.
And when you rerun it, if you give it the same inputs, it uses the cached version.
But if the inputs happen to change, then it'll give you a different output.
So it sort of keeps that, you know, don't recompute the stuff I already know aspect.
Right, right.
So Streamlit has an interesting execution model that I think we also noticed in some other systems where it looks to you as a user that whenever you make a change, your Notebook gets rerun from top to bottom every time.
But then behind the scenes, it does some smart caching and computing to avoid the work.
So you kind of get the benefit of rerunning a script every time without the drawback of having to like wait a long time for some expensive operation to recompute.
Yeah.
Interesting.
This is a big challenge to put all these things together.
I mentioned The Paradox of Choice, which is a fantastic book if people haven't read it.
But I feel like one of the challenges that things you all may experience is if you look at all these different things, you're like, oh, Rex does this amazing thing.
Callisto does that.
And Streamlit does this other thing.
And then Jupyter has this amazing aspect.
Not any single one of these has all the good things you want.
But any choice down one path will make you feel like, well, I don't get the machine learning like auto cleanup in this one.
And I don't get the, you know, the cursors.
Like, do you feel like there's a bit of a, I don't know, fear of missing or feeling of missing out as you like have to go down?
You got to use one.
You can't use them all.
Oh, yeah, for sure.
Nowadays, when I use Jupyter, I mean, Jupyter is a system I still use.
But now that I know about all these other systems, oftentimes when I use Jupyter now, I'm like, dang, if only I had, you know, Next Journal.
If only I had like Databricks right now.
Yeah.
But then you'd want Jupyter to lab back for something else, right?
I mean, it's like, there's a lot of different things going on here.
It's a lot of flowers blooming, I would say, I guess.
Right, right.
So we talked a little bit at the end of the paper in the kind of discussion part about, you know, what if you did this kitchen sink, right?
What if you just threw everything together?
What if someone made a notebook that has everything?
And, you know, one, it's an enormous software engineering challenge, right?
Nobody would want to take on that challenge of maintaining 500 different sorts of features.
And the other one is that it just may make the interface really complicated, right?
It's not like, if you can choose, imagine, like, you can choose different kinds of execution orders or choose a reactive versus an in-order one and you choose all the stuff, like, it would just be really, really hard for people to set up.
So, you know, some of these notebook systems, you know, say Jupyter or some of the other ones, I think they've been successful because they've, I would say, I don't want to say straightforward, but their feature set is limited, right?
Like that, you know, it's, even though Jupyter has this out-of-order issue, it's like, okay, what you see is what you get as long as you execute in that order.
Yeah.
And some of the real power is you can have semi-structured, reusable tiny bits in, say, cells when you're just a biologist or an economist and you don't have to become a computer scientist person to, like, learn Haskell to take advantage of this thing.
Like, it's incredibly, yeah, it's incredibly accessible to just jump in and write a few lines of imperative code and then get some really awesome output.
And so, yeah, I feel like if it became too advanced, right, you're like, well, do you want the reactive model, the asynchronous model?
You're like, I don't know what this means.
I just want a graph, right?
Yeah, because, I mean, one of the challenges with, say, Observable, right?
I mean, Observable has this really elegant reactive thing where this stuff auto-updates, and they have a lot of examples, right, on their website.
But I still think it's going to be hard for regular people, regular programmers to pick up because it looks kind of like JavaScript.
But then when you write it, it's like it has all these, like, little extensions to JavaScript that you need to wrap your head around.
So, you know, it's the age-old thing of, you know, more powerful programming languages environments are just going to be higher barrier to learn, right?
So it's very hard in practice.
Yeah, yeah.
So let's talk about the dimensions.
Sam, you put together 10 different dimensions on how you sort of evaluate these things and, you know, a spectrum along them.
For example, like data sources, you have local files, cloud storage, large data, streaming data.
Want to run us through this?
Sure.
We can start with, like, the highest level breakdown.
We organize the design space dimensions here around the steps in the workflow of a data scientist.
So as a data scientist, we imagine that you might start a project by importing your data and then writing and editing your code and your prose around that code.
And then you would want to run that code.
And then finally, you'd want to publish your notebook in some way.
So it's like the input, editing, and output steps for a data scientist.
And those are, like, the workflow steps.
And the 10 dimensions that we pulled out were data sources, as you mentioned, and things like versioning and collaboration, as well as execution models and execution liveness.
And for publishing a notebook, we talked about, like, you might want a notebook as a static HTML page or maybe as a software package, as we alluded to earlier.
There is a lot to consider here.
Let's just maybe grab a couple and to give people a sense, then they can go look at the paper.
You've got a big full page graph chart type of thing.
Yep.
Chart, I guess.
For example, I mentioned data sources, right?
We've got local files.
And you say, okay, this is access local file system.
And you always give an example of a system that implements that.
Like, so RStudio, for example.
Right, right.
What else is on that access there?
Yeah.
So we have local files, which means that the system basically only, like, natively supports opening files that are stored locally on the same computer.
Some notebook systems also allow you to read in cloud files, like files on their servers as though they were local.
This is what Google Colab does.
It allows you to read in files from Google Drive as if they were stored locally alongside a notebook.
We have some systems that have some special handling for large data sets, like data sets that don't fit in a computer's memory, like Databricks, uses Spark to handle that.
Right.
And we also have some systems that support streaming data.
So, like, you might hook up your notebook to some, like, web socket on the internet.
And as new data comes in, your notebook will automatically rerun and update to reflect the latest versions of those data.
Oh, like if you want to set up a dashboard and as things behind the scenes change, like, the notebook is always sort of up to date with the state of the world.
Polling almost, but better.
Yeah, exactly.
So you can kind of see from the way you described that, that every single, like, dimension here has some use case.
And the use case is kind of motivated by some real world, like, somebody sat down and was like, man, I don't like rerunning my notebook to update my dashboard every time.
I just wish I had some way to, like, have it automatically, like, streaming the data and update itself.
Yeah.
Yeah, for sure.
So let's go just through two more and then I'll let people go check out the details for the rest.
So how about execution order?
Yeah, so execution order goes directly to the in order, out of order problem that we were talking about earlier, where the Drupal notebooks allow users to run cells in any order they choose.
So I can jump around cells freely.
Other systems like Observable require a certain order of cells.
So what Observable does is it takes a cell, looks at all the dependencies, like, the variable dependencies of that cell, and then forces a notebook to run in the topically sorted order of cells, right?
Depending on, like, what cells to run should depend on other cells.
We also have systems like Streamlit, which force, like, this in order execution model that we discussed earlier, where it looks to the user, like, the cell, like, the notebook always runs from top to bottom every time.
So those are the three main variations we found of ordering execution.
Yeah, interesting.
Let's go to the very last part, the end of this lifecycle, if you will, and talk about notebook outputs.
Yeah, so notebook outputs, we found the most common use case, I think, reflected across all of our systems was taking a notebook and publishing it as a static report, so to speak.
So it's essentially like taking a notebook and converting it to HTML and emailing the HTML file or putting it up as a web page somewhere.
The next step up would be, like, a dashboard where you don't have, where you don't show viewers the code that you might, like, where you might require to produce to charts or graphs.
You just show the charts or graphs, like, themselves.
Right.
Okay.
And then finally, within that space, we have, like, what we call software artifacts, which encapsulate the idea of you can use notebooks as cron jobs, or you can use notebooks as software packages.
Right, right, like NB dev creating something you could put on PyPI.
Yeah, exactly.
Exactly.
Yeah.
I really think it's cool that you broke it down like this, but then each one has an example type of thing.
So you're like, okay, well, how does, say, Gigantum do it?
Or how does Streamlit do this thing?
Or Observable?
And so on.
Yeah, I think actually seeing all this stuff together might inspire features to start cross-pollinating.
Hopefully not every single feature, right?
That would be too much, but still.
The kitchen sink.
Yeah.
It seems powerful.
Kitchen sink notebook.
Yeah.
I mean, maybe kitchen sink is available on PyPI.
Like, you could just go for that.
Yeah, yeah.
Pick install kitchen sink.
Yeah.
Exactly.
Gives you half the kitchen sink.
Takes half an hour.
Yeah.
Kitchen sink.
Wait five minutes.
Awesome.
All right.
Well, this is a really interesting view.
I guess, you know, maybe let's kind of close out the conversation around this stuff by asking,
I'll let you both each way in on this.
What surprised you?
Like, as you went through this, what did you expect and what was different than that?
What surprised you as you went through this?
I mean, first thing that surprised me is how many there were, but what else?
For me, I think it was this tension between we hear about the problems of notebooks quite often.
And yet we, from this analysis, we don't often see those desires reflected in actual products.
So the in order, out of order execution model, for example, the vast majority of the systems we looked at only allowed any order execution where the user defines execution.
Collaboration between users and notebook authors is relatively common.
But in a company, you'd rarely find someone working on notebook all by their loans themselves.
But at the same time, we see very few systems that support like the sort of real-time collaboration that Google Docs has made popular.
Right.
And it seems so, so easily on the cusp of that because it's already in the browser.
Often it's already hosted.
Right?
Right.
Exactly.
So it kind of reveals, I think as a whole, the analysis reveals that there's still room for improvement for a lot of these products.
Yeah.
Good.
Yeah.
And I guess, I don't know if it was a surprise as much as, you know, something that, you know, we mentioned toward the end of the paper was that, you know, on the, you know, Sam kind of mentioned the product side of, you know, practically speaking, things are pretty tied to Jupyter-like things because people are used to that.
And a lot of products are Jupyter extensions or Jupyter hosted on Azure, Jupyter hosted on AWS, Jupyter hosted on Google Cloud.
And so my kind of focus is thinking about the academic side, think about the research papers that people have been prototyping for this.
And, you know, I don't know if it was a surprise, but it's something that was kind of a call to action we had at the end of the paper is that, you know, I felt personally that the academic work was not sufficiently weird, maybe.
Right.
So it's like you want, you kind of, you, you know, one of the roles of academic research and prototypes is you want to push the bounds and try stuff that's very different.
Right.
So imagine experimental programming language or experimental toolkits.
You know, the point isn't to be practical.
The point is to stretch the limits of what we know.
So because I think notebook research is still pretty early, it's all these systems in academia have been done probably within the last four or five years.
It makes sense that the first wave is fairly kind of, you know, making the extensions that people expect, right?
Versioning, in order execution, collaboration and stuff.
So I think that what would excite me more to see in the coming years is just to see the academic projects or the R&D projects becoming more weird, right?
So one of the things that we pitched at the end is just thinking about multi-device, different kinds of off-desktop devices, right?
I mean, already we're computing with phones and smartwatches and augmented reality and displays, but we're still just hunched over in front of our laptop, typing in this, literally just typing in a text box in the web browser, right?
Like that's all the notebooks are.
They're just little text boxes in web browsers.
So I think we can really expand our imagination thinking, you know, way beyond.
That would excite me a lot more.
Yeah.
Very interesting.
Yeah.
And to echo that point, what we drew out of the notebook systems was like this data science workflow.
But the reason why we drew out the data science workflow is because I think every single system that we've evaluated here was designed for data scientists for the most part.
And so with data scientists as the audience of choice, I think they're necessarily like, it comes with like a limitation on what we can imagine notebook be used for.
So in the paper, we talk about broadening notebook use cases for other types of users, like perhaps instructors for perhaps like maybe like artists, let's say.
And each of those audiences has probably an entirely different set of desires and things they want to accomplish with programming.
And I think with that comes like a whole nother set of trade-offs and perhaps design dimensions for notebook systems.
That's a good point.
Yeah.
Like DJs, musicians, orchestras.
Like what could you do?
Like what kind of world would you build if you were trying to, you know, coordinate that kind of stuff?
Philip, you brought up our phones, which are pretty incredible these days.
Did you guys look at Carnet?
I mean, it's not really something that needs separate analysis because it's just basically Jupyter, but Carnet, C-A-R-N-E-T-S, which is a open source thing on at least a free thing.
I'm pretty sure it's open source for Jupyter running natively on iOS.
Oh, interesting.
I haven't looked at that.
Yeah, it's pretty new.
I just learned about it a few months ago.
Oh, Stan, that's on GitHub.
Yeah.
We should add that to our analysis if we had time.
That's pretty cool.
It is, but I mean, it's not really fundamentally different, but it's interesting that it has NumPy.
Right.
It's just on the platform.
Yeah.
And a lot of those libraries like natively executed on iOS, not like an interface to some cloud thing, but like legitimately there, you know?
Yeah.
I mean, already people are talking about, you know, on our mobile phones, right?
That, you know, for machine learning, right?
You download these pre-trained models so then you can just do inference on your phone without going to the cloud, right?
So both for privacy, right?
If you want to do image recognition, both for privacy and for bandwidth.
You can do all this computation on your phone locally.
So you could imagine, you know, what would it mean if you could do data science out in the world, right?
You have your smartwatch, you have your phone.
You could just, you know, do your analysis, your Google Glass or whatever.
There's this kind of sci-fi future.
Yeah.
I guess like, you know, the thought that we have as kind of human computer interaction or HCI researchers is, you know, what would the future of computing look like, right?
Right now, it still looks like people hunched over on their laptops, typing in text boxes, right?
Like, you want to go beyond that somehow.
Still waiting to just plug an interface right into the neck, right?
No more typing or massing.
Projects onto your retina.
You can have Jupyter in your eyes.
Exactly.
Sign me up.
You'll be the first best subject.
Yeah.
Maybe not the first, but early adopter.
Let's put me in that category.
All right, you guys.
This was super interesting.
And it definitely opened my eyes to some things that are going on out there that I had no idea about.
So super cool research.
Thanks.
It was really fun for us to talk about it.
Yeah, for sure.
Now, before you get out of here, I'm going to ask you the two questions that go at the end of the show all the time.
And I'll, Philip, I'll pick on you since you're a veteran.
If you're going to write some Python code, what editor do you use?
I still use Vim because I haven't learned anything new.
So I still use Vim with whatever defaults.
Right on.
All right.
And then notable PyPI package, something that you've used that is interesting.
I'll do a plug for Sam's actually.
So Sam, for his master's thesis at Berkeley, he made this package called MB Interact, which is related to Jupyter Notebooks.
It's called MB Interact.
And you can pip install it.
So I'll let Sam talk more about that.
That's a lead into Sam's stuff.
Thanks.
Yeah, yeah.
Cool.
All right.
Sam, if you're going to write some Python code editor?
Yeah.
So I use VS Code.
But I've hopped from Sublime to Emacs to Vim and then not to VS Code.
So now I'm a happy VS Code user.
All right.
Cool.
Do you do any bindings?
Like you set up Vim bindings or Emacs bindings in there or something?
I set up Vim bindings.
But if the VS Code team is listening, there are some problems I have with the Vim bindings in VS Code that I'd love to talk about.
Oh, we're calling them out.
This is the call-out section.
This is where we start the beefs.
The call-out section at the end of the episode.
That's right.
It's the underhanded compliment.
Not exactly.
But it's like, I love it, but beautiful.
No, VS Code is a good one.
All right.
You want to tell us about MB Interact?
Sure.
MB Interact, it lets you take a Jupyter Notebook with some widgets.
And normally those widgets don't work outside of the notebook environment.
Like if you convert the notebook to a web page, to an HTML page by default, the widgets will just break because you don't have a Python service running underneath the notebook.
But MB Interact allows, it kind of like takes your HTML page and hooks it up to the binder service from the Jupyter team so that you can have a, you can have like this HTML page with interactive widgets, but it doesn't require you to have notebook, a notebook server running locally.
So you can kind of like share those things.
You can kind of share your interactive notebooks more readily.
That's the idea.
I see.
You don't have to set up a proper Jupyter server with all the execution and stuff.
Yeah.
You're going to send someone a link to a web page and then they can run your interactive widgets.
That's the idea.
Okay.
Yeah.
Ah, excellent.
As for like personal use, I like the TQDM package.
It gives you like a progress bar when you run, when you run the four loops.
Really handy.
Yeah.
That's really cool.
There's a couple of interesting progress bars that you can use, but it's those little touches,
you know, color, progress bars, maybe a few emojis.
It just makes it feel so much nicer to work in a CLI app.
Yeah.
Our next paper is analyzing 60 progress bar libraries.
Yeah.
60, 60 progress bar libraries.
And emojis.
What emojis they use.
And emojis.
Yeah.
Perfect.
All right.
Well, you guys, this is really fun.
People want to know more about your research, your paper.
What do they do?
How do they find it?
I mean, I'll put a link in the show notes, but what else?
Yeah.
They can just go to the links.
Michael, I sent you a link in the chat about MB Interact.
And then we sent you the paper links and such.
We can put both of our homepages on there and such.
Sam, any other plugs?
Yeah.
I think you remind me that I haven't put up the paper online.
I don't know if you have the paper online anywhere.
Yeah.
I have it on my page.
Yeah.
Oh, you do.
Okay.
So we can maybe link to the paper from Philip's page.
Yep.
Sounds good.
Well, I'll definitely do that.
All right, you guys.
Thank you so much for being on the show.
It's been really interesting.
And yeah, there's a lot of notebook exploration and flowers blooming.
So thanks for putting it all together into like one analysis here.
Yeah.
Really big thanks to you, Michael, for having us on.
And it's been really fun to talk about all the flowers, all the fields of flowers.
Likewise.
Thank you so much, Michael.
Have a good day.
See you later.
Bye.
This has been another episode of Talk Python to Me.
Our guests on this episode were Sam Lau and Philip Guo.
And it's been brought to you by Linode and Sentry.
Start your next Python project on Linode's state-of-the-art cloud service.
Just visit talkpython.fm/Linode.
L-I-N-O-D-E.
You'll automatically get a $20 credit when you create a new account.
Take some stress out of your life.
Get notified immediately about errors in your web applications with Sentry.
Just visit talkpython.fm/sentry and get started for free.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into
all the different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our
Everything Bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.