Building a Visual Programming Language

I spent 20 hours in a single week debugging my Emacs configuration instead of doing real work. That was the week I decided to build CoCube. CoCube is a visual programming language built from the beautiful lessons about extensibility, keyboard UX, and designing software for power users that Emacs taught me, with the parts of Emacs that never worked stripped out.

The extensibility trap

I had a pattern for how I used software.

1. Download a new app to solve problem X.
2. Use said app for a few weeks obsessively.
3. Realize new app doesn't do Y.
4. Find a new app that does Y, ideally X too.
5. Go to step 1.

This pattern wore me down. I wanted software that was open enough to change, but filing feature requests felt pointless. Who is going to listen to one person? I didn't want to build something from scratch in a programming language, but I wished there was a middle ground between "write it yourself" and "live with it."

It never crossed my mind that modifying the software myself was an option until I fell into the open-source Emacs ecosystem. I came away with one idea. If you don't like it, you should be able to change it.

Emacs let me stop the moment I had an idea for something I wanted it to do and implement the feature right then and there. I'd make the change and resume what I was doing without switching tools or waiting for a deploy. These small modifications added up, sometimes completely changing how I worked. I used it for scheduling, journaling, studying, writing, managing projects, and communicating. It became an extension of myself.

The great thing about Emacs was that you could make it do anything. The frustrating thing about Emacs was the constant breakages.

Here is the specific moment I stopped trusting my own system. I had written custom elisp to display org-mode TODO states inline in link previews, so I could see at a glance whether the thing I was about to jump to was still open. The display started returning stale states, and sometimes the whole link would fail to render at all. A task tracker you cannot trust is worse than no task tracker, because you believe you are on top of things, but you are constantly re-checking to see if something slipped between the cracks due to some bug.

I had also been writing whole sections of configuration logic inside my own org files and loading them with a custom startup script that parsed the org tree and evaluated the code blocks it found. It felt clever at the time because my configuration lived next to the prose that documented it, in the same tool I already used for notes. The downside was that the script that read my notes was the same script that configured the editor, and when it broke, I lost my editor and my notes at the same time. The week I spent 20 hours hunting down which of those two disasters was blocking me was the week I decided that the effort wasn't worth the result.

The rigid, restricted software I had used before wasn't perfect, but at least it worked.

What is visual programming?

Visual programming replaces text-based source code with graphical building blocks you connect and compose directly. The idea traces back to research in the 1970s and showed up in commercial form with LabVIEW, released by National Instruments in 1986 so engineers could wire virtual instruments together instead of writing C. Scratch followed in 2007, built by the Lifelong Kindergarten Group at the MIT Media Lab, and taught a generation of kids that programming could be a drag-and-drop activity. Unreal Blueprints arrived in 2014 and let game designers build gameplay logic without touching C++. Each of them answered a version of the same question. Why should programming mean typing syntax into a text file?

Part of the answer is historical inertia. In his 2022 Strange Loop talk Stop Writing Dead Programs, Jack Rusher argues that mainstream programming languages still inherit assumptions from the punchcard era. Long compile-run cycles, programs treated as static files the runtime discards between executions, no runtime introspection, source code trapped in fixed-width text, and a mental model of the computer as something you submit batches to rather than converse with. Emacs does better than most on the language side. Its lisp runtime is live and introspectable, which was the thing that kept me using it for years. The lisp itself runs on top of a character-grid terminal model from the 1980s, though, and that layer has no async or reactive primitives. Every attempt to build a self-updating UI on top of Emacs lisp runs into systemic problems, and the stale TODO state was one of many symptoms.

What CoCube is

CoCube is a visual programming language shaped by both lessons. The Emacs lesson is that extensibility has to be first-class, not bolted on. The inspiration from Rusher's Strange Loop talk is that the substrate you extend should be built for reactive UIs from the ground up, not grafted onto a terminal.

Concretely, CoCube replaces text files as a substrate with a tree of reactive cells that update automatically, the same way a spreadsheet formula does when an input changes. Every interactive element you see in CoCube is a tree of typed cells you can pull apart, edit, and wire back together at runtime. There is no compile step. Changes you make to a component are visible immediately, to you and to anyone else editing the same document. The underlying format is a local-first CRDT. Your documents aren't trapped in CoCube, and the system does not care whether you have a network connection.

A TextBox does more than hold text. Share it with a collaborator, and the same primitive becomes a real-time shared editor. Put it on a node with an EventHandler, and it becomes the start of a small tool you built for a problem nobody else has. The building blocks, called datums, compose the same way spreadsheet formulas compose.

What's next

Right now I'm focused on making the core editing experience feel right. The reactive cell system, text editing, and the component model are the three pieces I'm pushing on. They are close enough to working that I use CoCube every day to build CoCube.

Emacs taught me that extensibility is worth paying for. Rusher's talk made it clear that extensibility on top of a 1970s foundation has a ceiling I had already hit. CoCube is the bet that you can keep the first lesson and replace the foundation.

Try CoCube and tell me where it breaks for you.