berto.com

Origin

In 2019, after 2 years working in the Rows.com platform (then dashdash.com), I realized that we were building more than a spreadsheet. We’re building a translator.

Our Rows editor is, essentially, just a bunch of rectangles (cells). Users can write a language into them, which is the spreadsheet language. This language includes values and formulas, and other visual notations like data formats and colors. When users write stuff into the cells, we automatically generate a code representation of the user’s input in the front end, in the back end, and we also have a method to keep both ends synchronized. Our computation engine consumes this technical notation and performs any necessary calculations, sending results back to update what the user sees on the editor.

In reality, it’s a bit more complicated than that. Behind the user input, there is an amalgamation of code, structures, and applications. Some of them exist locally in the browser and app, whereas others work in the cloud. It’s hard to separate what belongs to a particular spreadsheet and a particular computation from what is shared between spreadsheets and belongs to the platform as a whole. This is because the platform was designed to provide a service to the user, without any particular belief on wether the architecture of our systems can provide value.

But then I thought: what if we generated a human-readable representation of the spreadsheet, sitting between the grid interface of the editor and the several layers of technical code? We were already using some of it to describe bugs. A1: 5 can represent a cell with a literal of value 5. A1: =2+2 =>5 is a cell with a formula that results in the same value, 5. With such a notation we no longer force the user to interact with our spreadsheet language via only our interface, instead we create a contract for interactions. Human readable. Human editable. We would keep the table interface, but we’d also offer the human-readable representation of the spreadsheet. At a minimum, I thought, this would allow the spreadsheet community to create scripts that generate all kinds of spreadsheets.

So now we would have separated 3 layers: UI, human-readable code, and the all the technical stuff translated from the human-readable code. But we could take it one step further. Having the 3 layers meant that we would need an engine to translate this human notation into the actual code that executes for that particular spreadsheet. The engine that translates between the layers is the interesting piece. We could open it to the world.

In a way, all of this isn’t that different from Markdown, or other tools like Excalidraw and Mermaid. A class of programming languages for end-users. So I started generating all kinds of human-notation languages on my mind.

The goal of Full-Stack Markdowns

To build systems where human readable notations get translated into code.

The Problem

The Solution

Use cases

FSMDs should allow for many solutions.

Concepts