“Useless” Projects Are Never Completely Useless

Not every personal project needs users, revenue, or a clear path to production.

Sometimes its only justification is a question you cannot quite let go of: how does this work underneath?

Some time ago, that question led me to take a compiler-building course. I did not need to build a compiler at work, and I did not have a product waiting to launch. I was simply fascinated by the idea that a text file could become something a machine could understand and execute.

Along the way, words that had once belonged to other developers’ vocabulary became concrete: lexer, tokens, grammars, parser, AST. I gradually understood that a compiler does not “read code” the way we do. It turns source text into increasingly explicit representations, until every piece has a place and a meaning.

That curiosity led to Codexivo, a small programming language designed for people whose native language is Spanish. The idea was straightforward: before dealing with the syntax and conventions of a production language, a learner could focus on logic itself. Variables, conditions, loops, functions, and basic structures — expressed in familiar words.

It was not a project with an immediate professional use. It was a way to learn by building.

The original story is still there in Building My Own Programming Language, followed by the post about its tokens. And yes: that first series stopped right when it was about to reach the parser. Years later, that unfinished thread became the prologue to this one.

The code for that experiment is still available in the Codexivo repository.

The value you cannot measure at the end

While I worked on Codexivo, the visible goal was the language: define keywords, recognize symbols, build expressions, and give them meaning. What remained was something else entirely: a way of looking at text.

A program stops being a block of characters once you learn to see it as a structure.

Source code
    ↓
tokens
    ↓
parser
    ↓
syntax tree
    ↓
a model that can be traversed and transformed

That mental model is easy to overlook when a project is paused. From the outside, Codexivo could have looked like one of those projects that never “amounts” to anything. It had no users, did not solve an urgent pain point, and did not become a company.

But curiosity projects do not always deliver value in the same shape as a product. Sometimes they deliver intuition. And intuition stays with you.

Years later, a problem that looked unrelated

Later, I encountered a completely different need: processing legislative documents.

The starting point was a Markdown file containing the text of a law. The goal was not merely to render it nicely on a page. It was to work with it: query it, locate specific parts, identify changes, and eventually consolidate amendments.

The need looked like this:

Plain text
    ↓
processable structure
    ↓
operations on the law

The connection arrived almost immediately: this looks suspiciously like building a compiler.

Not because a law is executable code, but because it is not free-form text either. It has its own grammar. Its elements recur, follow conventions, and occupy a position within a hierarchy:

Law
└── Title One
    └── Chapter I
        └── Section One
            └── Article 1
                ├── Paragraph
                ├── Item I
                └── Item II
                    └── Sub-item a)

A program has keywords, identifiers, expressions, blocks, and scopes. A law has titles, chapters, sections, articles, paragraphs, numbered items, sub-items, references, and numbering. Both require context for their parts to make sense.

At that point, it stopped being “a long Markdown file.” It was a structured language that needed to be interpreted.

From AST to ALT

The first consequence was natural: if I could identify the structures that make up a law, I could turn them into legislative tokens.

Article 254.
    ↓
ARTICLE(254)

TITLE ONE
GENERAL PROVISIONS
    ↓
TITLE(ONE, "GENERAL PROVISIONS")

A parser could then place each token in a tree by using the element type, hierarchy level, indentation, and preceding context. That is how the ALT — Abstract Law Tree — emerged.

Legislative Markdown
    ↓
Lexer
    ↓
Legislative tokens
    ↓
Parser
    ↓
ALT

The ALT does not aim to replace the original text. It represents the logical structure the parser understood. In other words: it is not the law as it happens to be laid out on a page; it is the law as a system can traverse it, query its nodes, and reason about its relationships.

The unexpected connection

The knowledge needed to start that legislative parser did not come from the legal world. It came from a course taken out of curiosity and an educational language with no commercial urgency.

Codexivo did not have to become a successful product to be useful. It left me with a mental model: when a problem looks like text, it is worth asking whether it is actually a language with structure.

That is the real usefulness of many “useless” projects. They do not always produce something you will use tomorrow. Sometimes they produce a new way to recognize problems.

And years later, in front of a document hundreds of pages long, your brain says:

Wait. I have seen something like this before.

Building the ALT solved how to understand a law. Soon, however, a much harder question appeared: understanding a law is not the same as being able to version it.