← Software Engineering Daily
Software Engineering Daily
Reinventing the Python Notebook with Akshay Agrawal
00:46:04
Interactive notebooks were popularized by the Jupyter project and have since become a core tool for data science, research, and data exploration. However, traditional, imperative notebooks often break down as projects grow more complex. Hidden state,
Loading summary
Transcript66 lines
- [00:00]
A
Interactive notebooks were popularized by the jupyter project and have since become a core tool for data science, research and data exploration. However, traditional imperative notebooks often break down as projects grow more complex. Hidden state, non reproducible execution, poor version control ergonomics and difficulty reusing notebook code in real software systems make it hard to move from exploration to production. At the same time, sharing results often requires collaborators to recreate entire environments, limiting interactivity and slowing feedback. Marimo is an open source next generation Python notebook designed to address these problems directly. Akshay Agrawal is the creator of Marimo and he previously worked at Google Brain. He joins the show with Kevin Ball to discuss the limitations of traditional notebooks, the design of reactive notebooks in Python, how Marimo bridges research and production, and where notebooks fit in an increasingly agentic AI assisted development world. Kevin Ball, or K. Ball, is the Vice President of Engineering at Mento and an independent coach for engineers and engineering leaders. He co founded and served as CTO for two companies, founded the San Diego JavaScript Meetup, and organizes the AI in Action discussion group through Latent Space. Check out the show notes to follow K. Ball on Twitter or LinkedIn or visit his website K Ball LLC.
- [01:39]
B
Akshay, welcome to the show.
- [01:41]
C
Thanks Kevin. It's great to be here.
- [01:43]
B
Yeah, I'm excited to get to talk to you. Let's start out with a little bit about you. So can you give a quick background of who you are and how you got to our topic today? Where you got to with Marima?
- [01:54]
C
Sure, happy to. So my name is Akshay. I've got a background in computer systems but also machine learning research. I spent a little bit of time at Google Brain. This was a while ago, back when Google Brain existed before it was taken over by DeepMind. So this was 2017-18. I worked on the TensorFlow team and then after that I went back to Stanford to do a PhD in machine learning research and and through that experience and my time at Google I realized what I really enjoy doing is building open source developer tools for people who work with data. So after my PhD in 2022 I started working on Marimo and Marimo is it feels like a next generation open source Python notebook and it is a notebook. But as we'll talk about in this episode, it's different than traditional notebooks in many ways. It's reproducible, it's stored as pure Python so you can version it with a git, execute it as a Python script, and share it as an interactive web app too if you want to.
- [02:53]
B
So let's maybe look into that. Right. I feel like notebooks have been a part of the Python ecosystem for a while and when they came out, like there was this big breakthrough of like, oh my gosh, I can do this kind of interactive exploration of data and then share it and like do all these different pieces. What's wrong with the state of notebooks? Why, Marimo?
- [03:11]
C
Yeah, it's a great question. And traditional notebooks, like Jupyter notebooks and things like them I think have been extremely useful in like research and education. And I use Jupyter a lot during my own PhD. So my thesis was on vector embeddings. Now I would make a lot of low dimensional plots of high dimensional data after doing some dimensionality reduction. Right. So lots of scatter charts and stuff like that. And it was really, really useful to do that in like a Jupyter notebook because I needed to run code and then see what the results of my algorithm were. And there was a back and forth between you as the algorithm developer and your data. Right. And so that's great. There's nothing wrong with that. The issues that I ran into and that others have run into with these traditional notebooks are a few. There's a few issues and I think it comes down to like maybe two or three. So one, like the one that sort of really trips up many people, myself included, is this idea of hidden state. So in a Jupyter notebook, and I'm using that as shorthand, but just like the default experience of a Jupyter Notebook using the IPython kernel, it's an imperative paradigm, right? Like you run a cell, it mutates memory, and then you run another cell and then it mutates memory. And what you're really doing though, is oftentimes once you get past the just exploratory phase, you're kind of writing a program even in a notebook, right? But because it's imperative and because Jupyter doesn't know how your cells are related, you may one run cell, then forget to run other cells that depended on that cell, and then all of a sudden the code on your page doesn't match the variables in memory. And this can lead to lots of Myself, I would do things like I would delete a cell and then it would delete some variable that I forgot was defined in that cell and it was still in memory and other code referred to that variable. And then four hours later I would realize I just had a bunch of inconsistent state and I would restart my Notebook restart my analysis. And so this broad idea of hidden state is one thing that I think is really challenging that I wanted to solve with Marimo. And then other things include the ergonomics of using notebooks as part of modern software projects. The default file format for Jupyter notebooks is great for communication because it stores not just the code, but also your plots and things like that and in a single JSON file. But it makes it difficult for any kind of software engineering like task, right? Because you don't Want to version base64 data with Git. It's just not going to work. Right. And then also you might want to reuse some code you wrote in a notebook, in another notebook or a Python module, but you can't really. Those aren't Python files. So then you have the issue where I've been guilty of this. You duplicate your Jupyter notebook 40 times and then it's just a total message. So that was another thing I wanted to solve. And then finally, the third thing has to do with like, shareability and like sort of interactivity. So on the one hand, Jupyter notebooks are really great because you have plots, you have code, you have visuals. This is document you can share out. But if you share out some analysis or some research investigation with a collaborator, they need to also have Python installed and Jupyter installed in order to like interrogate your results. Right. Like they might want to say, like, if I change some parameters, how might this plot change? And that feels kind of unfortunate. I mean, as a matter of practice, my PhD advisor couldn't do that, right? And he would have questions and then I would have to go back and change things. And so with Marimo, we wanted to make it so that any notebook could also really easily double as like an interactive web app where like, you can promote any variable or anything to like this UI component, like a slider or something, so that people could for themselves just interact with the document and see how results would change.
- [06:54]
B
So if I'm hearing you properly, I'm going to play back. So two of these things sounded like essentially saying traditional notebooks or Jupyter notebooks or whatever were in a lot of ways just kind of a fancy repl. They're a repl environment that has a UI baked in and is able to be a little bit more approachable in interweave plots and interweave descriptive text and things like that. But they have all the drawbacks of a repl in the sense that it's not really meant to be something that's packaged and duplicated. It's your exploring and as you said, having a dialogue with your data. And what I'm hearing is you want to keep that vibe of dialogue with your data, but kind of bring this up into first world software development. Like, hey, this is reproducible, it's data driven, it's state, it like keeps track of all the things. It's not me hacking away in a repl somewhere.
- [07:45]
C
Yeah, that's exactly right. And like, I think one of my teammates, I'm remote Trevor, we were just talking about this the other day, and the model of just a repl works well, as long as it's just you sort of working on that notebook like no one else. But as soon as you bring in a second person, or even the second person can be you a day from now, right? Yeah. You kind of want some guarantee, some reproducibility. Yeah, that's exactly right.
- [08:10]
B
All right, so let's maybe talk then about how you solve some of these problems. And I'm particularly interested in kind of understanding what is the execution model that you're adopting that is not just this sort of imperative replacement.
- [08:23]
C
Definitely. So in designing Marimo, we took inspiration from other projects as well. And the two biggest ones are these other really cool notebook systems for other languages. So Pluto Jal for Julia, which in turn was inspired by observable for the JavaScript ecosystem. And what those two notebooks are and what Marimo is at their core, they're what are called reactive notebooks. So reactivity is sort of the alternative to this imperative style of notebooks. And so what this means is, say in a Marimo notebook, if you run a cell, say that cell defines some variable X, when you run that cell, Marimo then by default will automatically run all the other cells that read the variable X. And so it reacts to your code execution of one cell to keep the outputs of the rest of the notebook in sync with the action you just took. The way that this works is that there's no runtime tracing involved and instead Marimo basically just statically reads the code of every cell that you have and determines what are the variables it defines and what are the variables it references. And from there it just builds this dependency graph and it's kind of like Excel in some sense. Right? It's not magic. And we have configuration, so automatic execution may not be even desirable for all notebooks, especially if some downstream cells are going to take a long time to run. So you can make the executor, like we call it, lazy so that you run a cell and then Marimo will just mark the affected cells as stale, but it won't run them automatically, but it'll give you one button that you can push to bring all your code and outputs back into sync. So that's the core thing. And so that can minimize hidden state. And also as you play with it, you also find that it actually enables you to do data exploration a lot faster because like you just change a variable value, hit Enter and then you see everything change and et cetera.
- [10:17]
B
Well, and this is a paradigm that I think web user interface frameworks have very much gone towards is this kind of reactive model. I think Vue did it first and you see Svelte and React and all these folks like taking this very data driven reactive model. And it does allow very fast and easy keeping things in state. So looking at that dependency graph, then how much overhead does that end up creating or like, are there any things in Python that are hard to statically analyze? I'm not super deep on Python in particular. I know some languages, it can actually be hard to trace the dependencies.
- [10:50]
C
So on the question of overhead, it's like totally negligible. Python has a built in AST module that you can use to do static and semantic analysis of code. And like most heavily used libraries in Python that's implemented in C. So it's really fast. So the overhead is negligible, especially because it's static analysis. So it's like we parse and analyze once and then every other execution there's no overhead. So yeah, you don't notice that. And in terms of what is hard, I guess the scope is the static analysis itself is the semantic analysis is that difficult. And I think what we chose to do is to there's two approaches you could take to making at least two approaches to making a reactive notebook. In Python. What we did is our data flow graph is based only on variable definitions and references. So like I mentioned, a cell defines a variable X. You run that cell. We run all our cells that read the variable X. That's easy to implement faithfully. For the Python language, you could take another approach which would not be based on definition references, but just on memory access. And for example, you could say, if my cell mutates or touches some variable, if this cell appends to some list, I'm going to run all their cells that read that list. That's extremely hard to do reliably. And so we explicitly don't try to do that at all, because you can't. It's impossible to do just static analysis in Python. So then you're going to have to start tracing user code and you are invariably going to miss like it's impossible to implement that 100% correctly. And then you get into an uncanny valley when a user runs a cell and they won't know what else is going to run. So we're just really upfront, we're like, hey, we only track variables, definitions and references. So if you mutate things, go for it, but be aware that we are not there. That's an escape hatch, Right?
- [12:40]
B
Right, exactly. If you're mutating things, make sure you do an assignment afterwards so that we know exactly.
- [12:44]
C
That's exactly right. And you know the benefit of this is that like the rule set's exceedingly clear to the user. Right. Like they can understand it. It's like a sentence long. And then also it encourages the users to write like functional code. Right. Which especially for like data driven stuff, machine learning, it's kind of what you want to do anyway. So that's good. I think like one of our users described it as gentle parenting or something like we nudge data scientists, machine learning engineers, et cetera to write just generally good code.
- [13:15]
B
There's a lot of value in that. I actually, I was a slight aside, but I was hearing somebody describe, they said if LLMs generate no other value, they have dramatically upgraded the quality of code coming out of graduate schools.
- [13:28]
C
That's fair, actually. Yeah, I like it.
- [13:32]
B
Okay, so let's keep going down this road. So now you have instead of immutable repl, you have a well defined dependency graph. And you mentioned the next thing was around sort of reproducibility and not checking in these massive binaries or things like that. So how does Marimo handle treating this stuff as code?
- [13:51]
C
Yeah, so that's a great question. So the dataflow graph gives you some amount of reproducibility insofar as that you can't run a cell and then forget to run some other cell. Like Marimo will just run it for you or mark it as still and really loud if you've done something sort of, I guess, yeah, it just won't let you step out of its reactive execution model. So that handles like reproducibility and execution in some sense. And then I'll get to the file format. I guess it is related actually. But Marimo does have sort of an optional built in package management system that's like powered by the UV package manager. So if you opt into it, when you import a package, Marimo will detect that. Import a module, resolve it to a package, prompt you if you want to install it, and if you do, it'll add it in a comment block at the top of the Python file. Python has a standard called PEP723 for this. So basically we'll document all the packages your notebook has used, and then the next time you run that notebook, we'll use the UV package manager to create an isolated virtual environment, install just those packages, and then you're off to the races in this sort of reproducible package environment. So we handle that as well. But the reason that was an easy feature for us to add is that we actually decided to store our notebooks as Python files instead of as these JSON files that sort of jupyter has historically used. And the way that this works is each cell is represented as like a function. There's like some decorator to like demarcate. Like, this is like a cell that's going to be going into the notebook and you can think of each cell as a function mapping the variable references it uses to the definitions it creates. And at the bottom of the notebook there's a Python. You can do an if name equals main guard, which is like, when you run the script, that's what's going to run. And so there's an if name equals main guard that will then say app. Like it will run the Marima notebook and the cells in a topologically sorted order. So basically all that to say, you can go to the command line, say Python my notebook py. It'll run it as a script you can even parameterize with CLI args.
- [15:56]
B
You're already though, getting to a place where now this stuff is pluggable because it's just Python code. You can import the functions to wherever you can do what have you. So before we dive down that road, which I am interested to go down, the implications there. What, if anything, is lost by storing it as Python rather than this sort of proprietary format?
- [16:16]
C
Yeah, so there's definitely something lost. So the main thing that's lost is by default, when you're using jupyter, not only is your code, but like your plots, for example, like, are stored as base 64 encoded data in the file, so that you can just like put it on GitHub and like, you can immediately see a record of your analysis. So I actually think the IPython notebook file is a really valuable artifact. I just don't think it should be the artifact that your development is centered around. And so what we do to sort of bridge the gap is that there's a configuration setting that you can turn on which will basically automatically snapshot your Notebook as an IPython notebook alongside the Python file. So like there's a little underscore, underscore marima directory and you'll save like my notebook ipynb in there alongside your Python file so that you can try and get the best of both worlds. There's other things that we ended up having to sort of implement our own versions of because for example, one thing that's nice about a jupyter notebook file format or like just something that stores the outputs is that when you load up the notebook like you can see the previous run's execution without running the whole thing, if that makes sense. Right. Whereas we start from just a Python file and that file doesn't have those outputs. So we implemented our own sort of like session cache which is stored in some sort of directory that is hidden from the user. And so to replicate some of these nice features that flat file format did provide.
- [17:43]
B
That makes sense. Well, and since you have the dependency, you have all the variables already like labeled, you know what you need to save.
- [17:50]
C
Exactly, yeah.
- [17:53]
A
In mobile application security, good enough is a risk. Guard Square uses advanced multi layered code hardening techniques and automated runtime application self protection and mobile application security testing combined with real time threat monitoring to deliver the highest level of mobile app security. Discover how guardquare brings all these together to provide mobile app security for your Android and iOS apps without compromise at www.guardsquare.com. why is there always a meeting bot in your Zoom call? Blame Recall AI. Recall AI powers the meeting bots and desktop recording apps behind products like Cluli, HubSpot and ClickUp. They handle the hard infrastructure work capturing clean recordings, transcripts and metadata across Zoom, Google Meet Microsoft Teams in person, meetings and more so developers don't have to build it themselves. If you're building a meeting, note taker or anything involving conversation data, Recall AI is the API for meeting recording. Get started today with $100 in free credits at Recall AI Software. You know Fidelity is a financial services leader, but did you know that inside Fidelity is a community of technologists working together to shape the future of finance and tech. Fidelity is always investing in tomorrow. From emerging tech to cutting edge tools that will transform what comes next. Their technologists are encouraged to keep learning so they can expand their skill sets, explore new ground and stay ahead of this rapidly evolving industry. And right now, Fidelity is hiring technologists to join their team. Fidelity Technologists get the best of both worlds. Startup energy that's grounded in the stability of a financial institution. That means support resources and amazing benefits. Bring your skills to a culture where you're empowered to dream big and build the tech that drives an organization and makes a real impact on people's lives.
- [19:53]
C
Lives.
- [19:53]
A
Find out more@tech.fidelitycareers.com that's tech.fidelitycareers.com Fidelity is an equal opportunity employer.
- [20:04]
B
Okay, so I want to come back to the UI widgets because that was a thing you talked about as well, and I think that's interesting. But this has like brought me into this question or discussion topic around how notebooks fit into the broader software development life cycle. Because I think one of the things I have seen in places where IPython notebooks were tended to be used before is they were heavily used by, for example, a data scientist or data science team. They were used for data exploration. And then if you wanted to then take something that was there and package it for reuse or embed it in a product or whatever, it was like a whole effort porting new code, all these different pieces. But to me it sounds like this Marimo file is literally just Python. Once you have something that works, you could use it.
- [20:51]
C
Yeah, yeah, that's correct. So you can, and we do in many of our own sort of internal utilities that we write for our team. Just like internal tools. They happen to be in Marimo notebooks that are reusable as Python files. You can even say, like, from my notebook, import my function, from my notebook, import my class. Like that syntax kind of just works. There's like some details. The function needs to be pure so that it serializes correctly. Which, by the way, ends up, you end up writing better code. Right? So this is. And so yeah, you totally can. And so it really does blur the boundaries of what you can use a notebook for. Which I think is really exciting because, like, we see like all kinds of use cases from the traditional data science and research use cases to like backend engineers, like emailing us, telling us like, yeah, like we're doing our data pipelines with RIMA notebooks just because we can.
- [21:37]
B
And so I want to hear more about that because, yeah, my experience has all been notebooks. It sort of often research, ML, data science communities, and then that's its own thing. So how are you seeing the integration happening? When do you choose? If you have one of these backend engineers, when are they using a notebook? Why would they choose to do that over something else? And like, what is the process there.
- [21:59]
C
Yeah. So I think there's at least two reasons, one that we'll touch on with like the interactive components that you alluded to earlier. But even without that. So I think often when making like simple data pipelines, like, you know, not super complicated ones, but simple ones, it can be helpful to prototype a data pipeline in a notebook because similar to like what I was mentioning of having a back and forth with your data, right? Like you write some code, you see if the data is put into the shape you want it to be in. Sometimes it's easier to do that with visual inspection. So, yeah, because these are do with visual inspection, it can be nice to do it in a notebook. But a notebook's also a good choice because with data pipelines the job runs and it can be nice to just have a report alongside it to see, like what was the shape of the data that day, et cetera. Right? So it's nice to prototype as a notebook. But now with Marima, not only is it nice to prototype as a notebook, it's also really easy to just run it as a cron job or as a script. Like you don't need to reach for sort of other tools that orchestrate IPY and B files. You just say python, my job, py, whatever, right? It's just a Python script. So that's one area where we do see sort of natural usage.
- [23:13]
B
So this already is getting me to a place that I'm curious, right? So often if I'm doing a big data analysis job, I will want to do something interactive on a subset of my data and then I'm going to want to run something async when I do the full data, because it's going to be big, slow, expensive, what have you. But maybe I want that same visualization, right? I want that report right in there. So, like, is there an easy way within Marimo? And maybe I'm just missing something obvious to be like plug. Okay, right now we're using this local subset of data for this one. You're going to do a remote call, fetch it from here. You're going to do what have you. Can you plug into those? Like, I want to run my big data off in the cloud somewhere Async fast or slow, but get it back into my notebook.
- [23:55]
C
Yeah, you totally can. So it's not necessarily productized, but we have a number of primitives and so one primitive you can use. So Marimo is a notebook, but it's also a library that you typically only use in the Marimo notebook. So you can import Marimo Esmo into your Marimo notebook and you get some primitives. One of those primitives is am I running inside in an interactive session or am I running as a script? And so you can just use mode running in notebook to parameterize where the data is being fetched from. And I think that would do what. What you're asking, essentially. Or you could use that to do what you're asking.
- [24:29]
B
I'm also wondering about. Yeah, can I. Well, maybe this comes back to the publishing side, publishing things as web. So maybe we'll come back to this. But I'm thinking like, okay, I've run this on my temporary thing. I still want my interactive view, even though I'm running this asynchronously. Can I run it async and still publish the web version of Marimo so I can see the report at the end or something like that?
- [24:49]
C
Yes. Yeah, you can do that too. That is from the cli. We have like a Marimo export and then choose your file format of choice, such as HTML. So Marim export HTML that will run it as a script, but also generating an HTML report at the end.
- [25:07]
B
Got it. Oh, that's super cool, right? So what I'm hearing then, just thinking about life cycles here, right? It's like, okay, I'm tinkering with it, I'm exploring it. I'm running it locally as a notebook subset of data. I have this flag. I say, okay, I think this is ready. Put in my flag saying, when you run as a script, run against this source instead of that source. And then I run it generating an HTML report that looks the same as my notebook. Lets me go and look at it, do what have you.
- [25:32]
C
Yeah, yeah, yeah, that's correct.
- [25:33]
B
That's really cool, digging into that shareable web side of it. So what is interactive? What does that web generation look like? Can I still go and tinker with cells or change things? Like, what is the output starting to look like there?
- [25:48]
C
Yeah, so interactivity in Marimo starts, let's say, in an interactive edit session. So you're working on your notebook, you're in browser or VS code. Wherever you're using your notebook, we do have a VS code extension as well. So I guess just taking one step back, Repls are like. Everyone thinks of a repl as interactive, right? Because it is, right? Like you run a cell and then you see what happens. You run something else. In notebooks, traditionally, when you want to see what happens when you change a value of some variable, you have x equals 5. Then you hit backspace and you change the value of x to 6. Then you hit shift enter and then you hit shift enter a bunch more times. Then you see what the new thing looks like. And then you go back to the. Then you hit backspace x equals 7 and then you do it again and again. And it's very tedious. And that's the kind of thing any normal person would be like. There should be some UI element to control the value of that variable. So in Marimo you can import Marimo as MO into your notebook. And then the MO UI module gives you access to a bunch of different UI elements ranging from the very simple to like sliders and text inputs and dropdowns, to sort of more complicated ones, like interactive scatter charts, like selectable scatter charts and things like this. And the way that it works in Marimo is that you can assign a uielement to a variable. So like X mo UI slider. Then when you output that variable in the notebook, so if you may X the last expression of the cell, Marimo will display the slider. Then if you scrub the slider, then what Marimo will then do is then automatically run all other cells that refer to the variable X. So it hooks into the reactive execution system. And then every UI element has a value attribute that gives you the value that was assigned or like associated with it on the front end, gives it back to you in Python. And so just like that, with no callbacks required. Now you have like user interface interactivity in your notebook and you can use that to say, speed up data exploration. But as you can imagine, you can also use that to make like really simple interactive data apps or web apps, whatever you want to call them, right? Like any kind of internal tool. And so that's another big use case of Marimo for different folks, different sort of, I guess, pathways. Some people will just use the UI elements to speed up exploration. But as well, just like, you know, I was just on the phone with like a, I guess I have to speak about them anonymously right now. They're a big Marimo user, they're like a very well known sports team and they're using like Marimo for a bunch of like analytics and stuff. And they've made like a bunch of Marimo apps that like you type in a player's name and you see a big table of a bunch of stats about that player, et cetera. And it's just like fancy interactive web apps that they deploy on an internal site for the rest of their team to use. And the way that works in Marimo is that any Notebook from our CLI, you can type the CLI marimoreun mynotebook py and it'll serve it as a read only web app. Code cells are hidden and then now some non technical stakeholder can interact with your data. And so you were mentioning backend engineers and surprisingly to me, we talked to this one company, we have a case study published in our blog about them. Their name is taxwire. They were like, yeah, all our backend engineers, we all use Marimo on a weekly basis. It's because we make all these internal web apps about this tax software we're building and its use cases. And then we embed it inside our internal Next JS app and it just makes our lives easier. I'm like, okay, cool, that's awesome. And honestly, that's not something I anticipated as a use case when I first started making Marimo right after my PhD. But it was really cool to hear people being empowered by that.
- [29:30]
B
That's awesome. So I think what I'm hearing too with this is like you could decide which variables you're exposing via UI versus which are loaded from somewhere versus how you're managing all of that. So if you had this example of loading up a whole bunch of data, I mean, I guess your sports example is that it's got a whole bunch of data in the backend but lets you configure which player you're looking at, maybe which slice of data you want to analyze based on.
- [29:56]
C
Exactly. Yeah, that's exactly it. And I guess the value of the notebook here in this case, because it may not necessarily be obvious, it's just that it's like this progression from I just have some data here and I don't really know what it is and I'm just playing with it and then like, oh, actually there's something useful here. And like, okay, now I want to expose this to other people and it just like you can just like stay in the same tool and just like incrementally like abstract it a little bit and promote things to UI elements and then add some explanatory text. It's just like a really seamless path. Whereas like if you had never opened a notebook to look at your data in the first place, it might be hard to then, you know, think about, okay, what is a react app? I'm going to write to like, I don't know, empower the rest of my team because like, I don't even know what's in the data. So I Don't even know what to make. And so I think that's what the value in the notebook is. Just making it really easy for you to first get a feel for your data and then from there making it really easy to make a tool that's good enough for you and your colleagues and yourself.
- [30:55]
B
Yeah, that is super valuable. I mean, I have an example where I've just whipped up some internal scripts to analyze things for me, but it outputs in text because I think in text. If I had thought ahead and used a notebook, suddenly I could share it much more easily with different folks. Another question that I have in this is, I think one of the things that's going on in the software development world right now is things are changing incredibly rapidly. Right. We've got LLMs, copilots, agentic tools, all these different things. Is there a similar transformation going on in the sort of data and data programming worlds? Or how are you seeing notebooks fitting in with this kind of new industrialized coding era we're getting into?
- [31:39]
C
Yeah, I think there is a similar transformation. It's a few different ways. So give one example. So one of our users is like a very large public company and they told us they have hundreds of Marimo apps deployed internally. And they said what made it really easy for them to adopt Marimo and the reason they adopted it so quickly was because it turns out Claude is like really good at writing them because it is a pure Python file format. It's like all these things you can get around but like, well, I guess Jupyter notebooks aren't interactive by default anyway, so you can't make web apps with them. But with, yeah, Remo being a pure Python notebook, Claude can write it easily. It can also run the notebook as a script to check if it's doing the right thing. We also have like a Linter CLI tool called Marimo Check, which will like report any errors it finds, like with the syntax of how the notebook is stored. And honestly, I use cloud also to make really quick internal things where I would have made a Marima notebook by hand. Now I have Claude help me make a Marima notebook of it and it does a good job, especially compared to earlier in the project's lifecycle. Marimo is now, I think popular enough that it's in distribution, so it works pretty well. I guess that is more similar to how Claude is just speeding up software development in general. Right. In terms of for data specifically or for ML research specifically. I think that people are still figuring out. I was just talking to Someone on my team and he told me that he's seen a bunch of VC things out early this year saying 2026 is going to be the year that AI and agents revolutionize how we work with data. So I'm like, I told him to send that to me because I haven't seen one of those yet. But I guess people are talking about it. I just, I'm not too familiar. I think like DataBricks says that 80% of something something databases are created with agents but I think that's like neon or something.
- [33:37]
B
And so I mean it's, it's sexy right now to say okay, we're going to use, this is going to be revolutionized with AI. I do feel like software development is the one place I am actually seeing that play out. And so yeah, kind of interesting to see how that happens. Where. Go ahead.
- [33:54]
C
I was just going to say I think that the basic things that I think many people have been trying, like maybe just being quietly integrated in a bunch of products but like text to SQL type of things like schema discovery, like it seems natural that some form of that will benefit from code generation and sort of agentic workflows. But I guess we'll see, yeah, we'll see if these predictions end up being true.
- [34:16]
B
On this sort of forward looking prediction side, what do you see as sort of the frontier in terms of use of notebooks, data access, data exploration, that sort of world and what kinds of stuff are you working on internally to address it?
- [34:31]
C
The frontier and that's a good question. Frontier is always hard to opine on because well, it's the frontier. So I can talk about what we're working on and I'll see if I'll back out and see if any of that is going to be getting us to the frontier. So let's see. So some amount of work we have like a good amount of work is like sort of we're close to parity with the Jupiter and Collab ecosystems where we're not at full parity. So we do honestly have like a good amount of parity work that we're doing like getting Marima working seamlessly inside of Jupyter Hub which is like a multi user hosted sort of Jupyter deployment that many universities use. We also have a free hosted notebook that's like similar to Google Colab, called Tongue in Cheek. It's called Molab Mo for Marima.
- [35:17]
B
Nice.
- [35:18]
C
And so we're working on that quite a bit this year. I guess one thing in terms of Frontier, so we have A speculative project which I don't exactly even know what exactly it is. And we're part of the project is to figure out what it is, but it's driving Marimo headlessly, like potentially with agents. There was this paper that came out recently that someone on my team sent me that I've so far only skimmed the headline and intro, but it's something to do with like instead of using. I think the claim of the paper was that Python repls or repls in general can be very valuable ways to like dynamically create context for LLMs or agents. And in that paper I think they use a jupyter kernel as like the thing that the LLM has access to. And so we actually did some. One of our engineers did a lot of work to like sort of modularize Marimo towards the end of last year. So we're getting close to a place where like you can use the kernel headlessly without our ui. And one project that he's really interested in exploring is like, well, what if you gave an agent access to that kernel? Could that somehow speed up whether it's data exploration workflows or research workflows? We're not exactly sure, but it seems like that could just be a really valuable primitive, like a sandbox in some sense for agents to have. So I'll give you guys one example. And this is not related to necessarily headless, but enabling agents to work more effectively with data. So in Marima we have a built in AI assistant sort of system. And one thing that you can do is when you write a prompt, like for generating some code, you can tag a variable, say like a data frame. And when you do that, we inspect the data frame, see its schema, get like sample values, et cetera, and dynamically generate context to give the LLM. And now you have code that's specialized to the data at hand, which is more useful than say if you're using cloud or cursor and yeah, so they won't know what's in the data frame unless you explicitly tell them. That's just one way that you can make, I guess, empower agents with runtime information. And I guess that's one thing that we want to explore more this quarter.
- [37:30]
B
Yeah, no, it's super interesting to kind of think about that because there's a couple different pieces that stand out to me. So one is the fact that you have kind of the dependency graph already mapped becomes quite interesting in terms of showing just the relevant context to the agent. Right. So you might say, hey, you're Changing something down in this one cell, but you don't actually care about that. Instead of forcing the agent to absorb the context of all the different steps, you could say, like, register which step in the graph you're interested in. We'll do all the computation. Here you go, here's the output. I do wonder, I feel like there is some sort of interesting opportunity here in terms of just like, showing it the right things at the right time. Do you have a concept of lints or correctness checking on cells? So, like, you've got this dependency graph you're going through and maybe a step three or four ways down, it's like, oh, this is outside the bounds of what could be valid, so something must be broken upstream.
- [38:24]
C
Yeah, yeah, we do, we do. We have a checker or a linter that will check your entire program for like, semantic correctness as well as, like, syntactic correctness. So there's a couple of rules that Mirima enforces to make sure that your graph remains like a dag, basically, one of which is you can't have cycles across cells, which I think is sensible. Although I recently learned that Excel has a feature that you can turn on in Settings to enable cyclic calculations. And then you choose like, the number of iterations you want it to go until convergence. I got a spreadsheet that was all ref errors. I'm like, why did you send me the spreadsheet with all referers? Look, no, no, no, you have to enable fixed point iteration. Anyway, sorry, this is a digression. We don't allow that.
- [39:07]
B
There's a lot of value in keeping it to a dag.
- [39:09]
C
I'll say, yeah, so Marima has to be a dag and we enforce that. That's one rule that we check. And the other is actually you can't redefine the same variable across multiple cells. And the reason is we actually allow you to reorder cells for like, presentation purposes. There's also like column view and stuff. So those are the two main semantic things that we check for.
- [39:27]
B
I was also wondering though, in terms of like, data range validations, right? So, for example, you have a dependency of a set of different computations and you might know something about the shape of the data and say, like, okay, this data needs to actually be in this shape. If not flag something and don't keep going or what have you.
- [39:45]
C
Oh, that's super interesting. Yeah, we haven't explored that.
- [39:48]
B
The reason I think about that is with agentic coding, which we've been diving down in, the more you can programmatically deterministically limit the sort of scope of possibility and then give that feedback to the agent the more it's able to independently iterate.
- [40:02]
C
Yeah, that's very interesting. There's a lot of things we could play with, but that does sound interesting.
- [40:08]
B
So you mentioned in Marimo you have these things as functions with decorators around it and you're already building in this kind of some amount of static analysis, some amount of linting and things like that. What hooks do you expose to your end users in order to kind of plug into that?
- [40:22]
C
So right now to be honest, we don't have the biggest extension API surface area in terms of extension points, not in the file format, but we have standardized on this protocol called any widget for building like third party interactive widgets. The developer of any widget Trevor Mans, actually works at Marimo now. And so that's one way that you can plug into Marimo. You can also hook into our display protocol for objects. Like we support the IPython display protocol, but we also have some additional hooks. And then in terms of the file format itself, like you can actually write Marima notebooks by hand in VIM or whatever your text choice.
- [41:02]
B
How did you know I used vim?
- [41:04]
C
Well if you're holding software engineering daily, this is my, this is my guess. But so you, you can do that. That's not an extension point but it is designed well so that like you actually still. The file format will guarantee you still get like code completion intellisense and all these things like, but we haven't opened up an actual like. Put another way, Jupyter is famously I think well designed in terms of like the internal protocol. Like there's like the kernel protocol, they have a wire protocol, they've got a bunch of things that like third party developers can hook into. We haven't done that yet just because it was too early for us to. I think things are just moving really quickly. It's starting to change. We now have our own still internal but semi public APIs for ourselves because we're now consuming Marimo in many different ways. And I think eventually over time this will evolve into like some of these will be opened up to the public. But right now it's I guess in terms of the dag, it's like our file format specification is public and fixed and so people can target that with co generation tools. But that's about the extent that makes sense.
- [42:09]
B
Cool. Let's look a little bit actually at any widget. You mentioned that as one of the Places that you plug in, it's an open source, you hired the developer or whatever the sequence. I'm a big fan of that type of thing. What is it, how does it interact with the reactive data model that you have and are there any constraints or things to know going into it?
- [42:30]
C
Yeah. So I'm going to caveat this by saying that Trevor is a far better spokesman for any widget than I am but I will try to channel and he was just on I think talk Python with me and had a great hour long conversation about any widget. But it is both a spec and a tool set for making like reusable widgets. I think really focused on for using them in interactive notebook environments. And so what any widget was born from my understanding is from talking to Trevor is. So Trevor also has a PhD and sort of in the biocomputation space was originally his focus and he found himself having to make widgets for all kinds of sort of domain specific tasks in the Jupyter ecosystem. And they were kind of really difficult to build and maintain and test. Like web programming has advanced a lot in recent years and like ipython widgets had not kept up. And so I think sort of out of some of those difficulties and frustration like Trevor sort of built any widget to like make it a lot easier to implement and maintain these widgets and also to make it a lot easier for like different frontends to consume them. Like so before any widget if you made some kind of domain specific widget that worked in Jupyter lab then you would have to go and then customize it to work in Colab and then also make sure it worked in the VS code extension. And now by like making the spec like you can make in any widget, just make it once and because people have agreed to support it it'll kind of work anywhere. And so that's been really valuable and it was really valuable for us. So like my co founder Miles discovered any widget pretty early in its life cycle and he was like oh, we should use this. I'm like I never heard of this. It was my original. He's like no, no, no, it's really good. It was a really good bet because I think it has emerged as the standard for interactive notebooks and in terms of hooking into a reactivity model it's actually quite nice. So basically any, any widget you can wrap it in a mode, ui, dot, any widget wrapper and then it basically binds it to our reactivity model and makes it into Just like any other UI element that's first party in Marimo. Yeah. So it hooks into the dataflow graph in the same way. And I think that the value of it is, I mean, people make all kinds of really, really cool widgets. And, like, we just, like, there's no way that, like, us as, like a team of seven would be able to satisfy everyone. But, like, widgets that were originally developed for Jupyter, there's a scatter plot widget called Jupyter Scatter, which lets you see like 10 million points on a scatter plot really efficiently and zoom in, zoom out, et cetera, that now works in Marimo today. And it's also reactive, which sort of gives it superpowers that you might not have had in traditional notebooking environment.
- [45:17]
B
Got it. So, yeah, it looks to me like it's essentially a vanilla JavaScript spec that if you meet that, then you can wrap it up and it'll just plug in. You have a wrapper. Jupyter has a wrapper. Other folks who support this have a wrapper and it'll just kind of work anywhere.
- [45:32]
C
Yeah, yeah. And we're going to be focusing a lot on any widget this quarter as well. One of our employees, Vincent, he runs our YouTube channel and does a bunch of things he never ceases to amaze me, like how far he can get with Vibe coding. These, like, really cool. Any widgets, like, I don't know, he Vibe coded this. Any widget for robotic simulations with this humanoid person, I don't know, it's really cool. So it really allows you to expand your imagination and get creative.
- [46:00]
B
Nice. Well, we're getting kind of close to the end of our time here. Is there anything we haven't talked about yet that we should talk about before we wrap?
- [46:10]
C
I think we've covered all the basics, so I guess we didn't really talk about Marimo's origins. And then I could talk a little bit about his origins and then a little bit about where we're going, like, at least in the next few months. So I started MARIMO after my PhD, like I mentioned, out of both appreciation for notebooks and frustration with them. And I actually originally got funding from a national lab at Stanford. It's a lab called slac, which is a particle accelerator or lab. And there are a bunch of scientists who use Python and, like, had basically the same gripes as I did. And so they were really excited to sort of partner with us to bring, like, a new open source programming environment into the world. So we have our roots in academia in that sense. And this quarter, one thing that we're really interested in doing is, like, engaging a lot more with universities to help them try out Marimo for education, help support them, like, incorporate it into their classes. Because I really do feel like that combination of reactivity and interactivity can really just make concepts just a lot more intuitive. It's just somehow, if you learn some new numerical algorithm, it's just so much easier to just change a parameter and see what happens, as opposed to just abstractly think through it. And in fact, Marima's main inspiration, Pluto, for the Julia language. It was originally designed exclusively for education and still actually is advertised in that way. It was at mit, where it was designed for a computational thinking class. And I don't know, it's just something I care a lot about and something that we really want to support. So to the extent anyone in your audience is in the intersection of software engineering and education and you find Marimo interesting, please try it out. Or better yet, reach out to me and my team. We would be happy to chat with you guys and support you. All right, let's call that a wrap.