Colab notebooks

A funny thing about Colab notebooks is that they’re ostensibly designed for literate programming, but in reality tend towards either messy blobs of code or simplified GUIs built out of forms. It’s like the early days of film — nobody knows how to use this medium fully.

I have a terrible number of thoughts on the subject. But I will try to restrict myself to possibly novel or useful ones.

First problem: situating the Colab notebook in a workflow. It’s easy to get coding. Not as easy to import packages and environments. Even harder to generate production code. So it’s like the Danger Room for most people — a playground, not the real thing.

Problem 2: situating yourself inside the notebook. It’s hard to keep track of state, and as soon as you start running cells out of order it’s easy to get in trouble. Some kind of introspection tools would be great here. (Also predictable time limits 🥺)

Colab is like a pantomime of literary programming. It has the part where you mix text and code, but we sort of already had that — it’s comments. What it doesn’t have is the tangle/weave protocols.

In Knuth’s original vision for LP, your source is text and code mixed together. And from that you “tangle” code files and “weave” documentation. The reason you can run cells out of order is supposed to be so that you can tell a story about your code. Programs are literature.

I am pretty impressed with nbdev. I used it to build a library and even with my amateur knowledge it was pretty straightforward. It’s still pretty rough but I can sense that it is gaining momentum. It allows you to tangle and weave from a folder of NBs.

But Colab doesn’t merge well with this process. G expects you to stay caged in their pseudo-file system and access your VM through a limited set of magic commands. I have heard no rumors of Google implementing tangle/weave, although I’m open to hearing some.

Because of Google’s file sharing/copying protocols, it’s easier to share the notebook itself than a finished library or script. And because of Google’s built-in version control, there’s not a culture of forking and merging. Just infinite forks, or invisible in-place edits.

So right now there’s like a zine culture around these notebooks. There’s a low threshold for entry. Like zines, there’s also a hard limit to how well they can communicate over multiple minds through time.

But they’re so vital! As in filled with life force. As in, they have the juice. A whole new era of art has just begun —and you can be a part of it! If you can stumble through this confusing interface full of inexplicable code.

But there’s still a coordination problem. An all-fork society continually fragments and mutates, but best practices are not merged back into the trunk. There is no sacred timeline. This is what things like version control, package management, even file folders are meant for.

AFAIK it is possible to use nbdev in Colab, but not easy. I think it was who was building this? But it should be a core feature of the platform. As should something like GitHub’s network graph, and a way to explore and publish to PyPi. pip install is not enough.

We need an entire workflow, that starts with somebody sharing their code, through to your development of that code, and the option to merge it upstream. With explorability and introspection at all stages. Until then we are in the silent film era.

With that attitude 😇

View original