đź§Ş We're running a cheminformatics notebook competition!

Enter by October 4
Case StudyEducation

Why IU Indianapolis uses molab to teach Python

Why IU Indianapolis uses molab to teach Python

This guest blog is authored by Leon Johnson, a Lecturer teaching data science at IU Indianapolis. If you’re using molab for education (or need help to), we want to hear from you: reach out at contact@marimo.io.

It was during the planning stages for our university’s Python camp that I decided to use marimo for the first time in my teaching. I had been eyeing the tool for over a year at that point, and I was so excited for what it could offer!

So, I decided to reach out to the marimo team to ask a few questions about how I could best implement the tool for my use case. Not only did I receive a response by the next day, the email came from Akshay, the CEO himself! His message was kind and sincere, and he proceeded to ask when we could meet to talk about my camp so he and the team could help in a way that was specific to my situation—Akshay was (and is) genuinely committed to making marimo the best tool for our students’ learning experience. I say all of this because I believe very strongly that this says almost all you need to know about marimo and molab.

Nevertheless, I’ll share a bit about how marimo worked for our Python camp. To see the full list of notebooks we provided to students, jump to the end of this blog.

The setup

Our Python camp was a week-long intensive “course” on Python for high school students. During this time, we introduced students to the basics of Python programming, as well as the fundamentals of Natural Language Processing (NLP). Each day would go something like this:

  1. I allow students to explore a notebook that introduces a topic.
  2. We discuss this topic, and I introduce the concepts behind it.
  3. Students work on an exercise that uses this topic by “pair programming” with a partner.
  4. … Rinse and repeat until the day is through.

On the last day of camp, students were asked to apply what they learned in a web app they built.

Enter marimo

I spent full days trying to find the right tool for this camp. I’m a bit particular when it comes to these things, and I wanted to make sure the final choice was something that checked all the boxes. That is, I had some requirements:

  • the coding environment needed to be some kind of notebook
  • everything needed to be completely online, without the need for any local setup
  • there should be some seamless “web app” functionality built into the tool
  • ecosystem issues like package management should be as invisible as possible
  • students should be able to open a URL and “just code”
  • I need to be able to save, share, and collaborate with a TA on a collection of notebooks

I knew Google Colab wasn’t right because it didn’t really have an “app” functionality, and (when needed) package management required the user to understand command-line installs. So, I started with DeepNote. However, after about a week of notebook development and experimentation, I found it to be unreasonably slow, cumbersome, and a bit too crowded from a UI perspective.

Finally, I remembered marimo, a tool I discovered over a year before. At the time, I was unaware they had an “online notebook” option, but once I found out about molab, I was hooked. With each new molab feature I tried, I became more and more convinced this was the answer—and, it was!

Bells and whistles

There are so many great things about molab, but the following features stood out as greatly beneficial for our camp:

Powerful default server instance. Students in this camp were not running computationally heavy jobs by any means, but even still, molab far outperformed the two other options I considered: Google Colab and DeepNote. In both cases, even simple routines took longer to run than when implemented in molab. Speed is incredibly important for this kind of classroom setting, because it creates a more “intimate” relationship between the student and their code. If they have to wait for something simple to run, there is a minute level of trust in Python that is lost.

Easy package install. I felt that a single week was not enough time to teach Python and give students the tools they would need to debug ecosystem errors stemming from versioning, environments, etc. For this reason, I decided students should only be exposed strictly to coding in Python.

The implementation of uv in molab was perfectly seamless, and it was just what I was hoping for when it came to package management. If there was a specialty package that needed to be installed, like VADER, students could just write the import statement, and the install just happens automatically. Or, students could use the UI to make installs rather than worry about how to use the command line.

File persistence. I cannot stress enough how helpful it was to know that datasets uploaded through the file browser side panel remained even after a full spin-down/spin-up cycle. The same goes for packages. I could set up the notebook for the purposes of the lesson, and I knew that students could just load the notebook and run what they need to without any extra setup. In Colab, the user needs to install specialty packages and upload files every time the notebook is spun up. This takes time away from learning, and it requires some background knowledge to understand why. With the persistent storage in molab, I didn’t need to worry about any of that; there were no extraneous questions asked, there were no issues, and we could just focus on coding.

Clean web app UI. It was very important to me that students had the opportunity to build their own public-facing web app. Indeed, sharing their work with others helps students find personal intrinsic value in what they learn, making it more meaningful. With a single URL, students immediately become “builders” and “developers” with the new knowledge they gained.

The app functionality in DeepNote is cool and robust, but it is not nearly as clean as I’d like. The hope was to find something that looked like a single website, without too many frills. With the marimo.ui functionality, students could make their apps look professional, but they could have fun doing it! This mixed with reactive programming made their learning more tangible; on multiple occasions, I saw students visibly enjoying “playing” with their web apps and their notebooks using the UI tools.

Reactive programming

I am an avid user of ObservableHQ, and as such I am a huge fan of reactive notebooks. Of course, for something like JavaScript, this kind of programming workflow is essential. For Python on the other hand, at first, it seems very foreign and at times inappropriate. But, the more I coded in this way, the more I realized that it actually teaches students valuable skills about coding; not the least of which is that a variable holds a specific value, and it cannot hold multiple values.

In a colab/Jupyter notebook, technically, a variable can be “defined” in multiple cells, which sort of communicates something improper. With reactive programming in molab, this cannot happen, and students are forced to really think about what they are doing with their notebook and within each cell. Each variable has a purpose, and changes to any variable must cascade accordingly throughout the notebook. I find this workflow to garner more critical thinking, especially when it comes to “how coding actually works.”

Also, of course, once you get the hang of it, reactive programming is just more fun. :)

Future plans and lessons learned

marimo makes it easier to demonstrate concepts, experiment collaboratively, and help students immediately connect changes in their code to the resulting output. In future camps, I hope to continue to facilitate this kind of hands-on discovery while expanding opportunities for pair programming and shareable student projects. We will continue refining our use of marimo so students can spend less time overcoming technical barriers and more time experimenting, creating, and building confidence. I also plan to use marimo/molab more in my graduate-level courses, where students can refine their Python expertise, and practice as they learn.

Overall, I’m very grateful for this tool and all the passion Akshay (and his team) puts into it. And, of course, I’m excited to use it more and more!

Notebooks

Below is a table of notebooks that our students worked through. Feel free to remix them for your own classes: I hope they’re helpful!

NotebookDescription
Python foundationsCovers Python syntax, control flow, functions, classes, and notebooks.
More Python basicsCovers packages, functions, classes, loops, and iterators.
Markdown in marimoDemonstrates Markdown, LaTeX, plots, and interactive controls in marimo.
Camp Day 1Introduces marimo, pair programming, reactivity, variables, and printing.
Day 1 scratchpadPractices basic Python and marimo controls through small examples.
Camp Day 2Teaches Python basics through exercises, games, and text analysis.
Camp Day 3Builds Markov text generators from tokens, regex, and bigrams.
Camp Day 4Introduces spaCy, sentiment analysis, Word2Vec, and vector visualization.
Camp Day 5Guides students through choosing, building, and presenting a final project.
NLP primerCovers spaCy preprocessing, sentiment analysis, Word2Vec, and visualization.
NLP and generationExplores corpus cleaning, Markov generation, spaCy, and Word2Vec.
NLP exercise collectionPractices tokenization, regex, bigrams, sentiment, and text generation.
Text analysis warm-upsPractices word counts, sentence statistics, and text comparison.
Word-counting promptsProvides short corpora for word-counting and normalization practice.
Word-frequency functionImplements a word counter that reports the top words.
Daily bug huntsReviews core Python concepts through Day 2–5 debugging exercises.
Bug-hunt instructor keyExplains solutions and teaching guidance for five debugging warm-ups.
Interactive bug huntsRuns student fixes with time and output limits.
Alternate bug huntsProvides an alternate set of Day 2–5 debugging exercises.
Six-part bug huntCovers types, grading, indexes, dictionaries, averages, and filtering.
Extended bug huntsCombines daily warm-ups, optional exercises, and hidden solutions.
Advanced bug huntsAdds debugging exercises for logic, dictionaries, filtering, and division.
Broad bug practiceCovers common errors across ten Python topics.
Statistical fragilityDemonstrates false positives in statistics and AI interpretability.