I started off this year pledging a two-to-one ratio of effort going toward marketing versus engineering, but I also just spent the last two solid months writing code. By that logic, I shouldn’t touch programming again until after Halloween. That’s almost certainly not going to happen, but I feel like I’m in a place to start thinking about marketing again.

By marketing, of course, I mean not promotion and selling—​although those activities are important—​but rather answering the question of “who is going to buy the darn thing?” But this in turn demands an answer to what “the darn thing” even is. My instinct is to channel, for what it’s worth, Malcolm Gladwell’s “perfect Pepsis”, and declare that there are in fact multiple darn things, but I would like to find a way for it to also be one darn thing—​some sort of unifying theme.

Major Project Milestone

Here is the high-level dependency graph I’ve been using to plot what I need to get done and to track progress. Green things are completed targets. Red things are blockers. It’s just dot for now because that’s all I have time for, but I imagine a view with this kind of information eventually in Sense Atlas.

The core of my technical work for the last three years has been an application server called Intertwingler, which has been slow to proceed for a number of reasons. Aside from the project itself being an extremely all-or-nothing proposition with no direct way for it to earn its own money, these include client work, trying to live a semi-ordinary life, and the occasional side quest. There was also the realization around the cusp of this year that Intertwingler really needed to be two things, and that splitting it in two would not only be the right technical move, it would make both pieces a lot easier to talk about. Each, you see, appeals to a different audience, and one part could be used separately from the other. But one big reason is that there was a huge, indivisible, non-negotiable, non-deferrable, non-delegable task that needed to happen to move the project forward. Surprisingly some of the most punishing code I’ve ever written, in terms of density of architectural decisions per written line. Also boring as hell, and with a result that can’t be seen, but only felt. If you’ve tried to load Sense Atlas (which runs on Intertwingler) at all in the last six months, you will have become painfully aware that it was missing any form of internal caching. Well, I just spent the last two months writing the Rolls-Royciest possible caching infrastructure from scratch.

I’m still working out the kinks, but Sense Atlas is quite a bit snappier than it was a day ago. Intertwingler uses a transformation pipeline—​a rather innovative one if I do say so myself—​to do a lot of its heavy lifting. Most of those transformations are pure functions, and therefore are particularly well-suited to caching. I am monitoring it still but it all seems to work; at this point we are very much in bang-to-fit territory.

Anyway INB4 “why didn’t you just use an off-the-shelf cache module”: because what I’m doing is sufficiently different that no off-the-shelf solution existed.

Also INB4 “why didn’t you just AI it”: because the bottleneck was not code (it’s only a few thousand lines), but rather me determining, in precise detail, what I wanted the code to say. I’d have had to do that whether I used Claude or not, though I did use it to help concentrate some of the desiderata, and debug some third-party C.

What this means, though, is that Intertwingler is (finally) very close to release candidate status. The caching infrastructure completes the core design. There are a couple other items outstanding, but they can—​and really should—​be implemented as modules. What’s really next for Intertwingler is to clean out all the dead code, gin up a proper test harness, package it up, and ship it.

And then, the immediate next step is apparently to saw the thing in half. But I promise at least one actual proper release before I do that.

In the interim, I’m excited to work on—​and with—​Sense Atlas again, it having been so bogged down as to be unworkable. I’m also pretty jazzed about being able to get the rest of my Web properties running on Intertwingler, including my personal site, which has been waiting for a proper CMS-with-Dorian-characteristics for eighteen literal years. And hey, if you have anything custom you want done, just holler. We don’t have to wait for a shrinkwrapped product for that.

What Motivated This Endeavour

In moments like these, it’s good to step back and recall what the thing you just spent all that effort making is really even for. I can actually trace it back to a sharp dissatisfaction around how we make websites, echoing some of Ted Nelson’s louder complaints about how the Web only manages to do one kind of link, that only goes in one direction, and that breaks all the time.

That might be a good place to land, but I think I can go back even farther. My essential conviction is that the computer is woefully underutilized as an expressive medium, because we’re so bogged down by technical details that we keep reverting back to simulations of pre-computer media: text—​that may as well be a print-out, of which this newsletter is an example—​images, audio, and video. My central criticism is that the idiosyncrasies of computers and software are mainly used to ship these forms around—​and maybe to embellish them at the margins—​rather than as an integral part of the experience. The exception, of course, is games, but those tend to simulate entire worlds, and so even video games often only engage with the medium in a sort of arm’s-length, incidental way.

A strong exception is puzzle games, and the reason why will become apparent in a moment. I’m not counting purpose-specific interactive fiction platforms because they’ve had half a century to expand beyond their niche, and they simply haven’t made it. I also anticipate there will be pushback about CG in movies, but I’d argue that all CG really does—​and AI image generation for that matter—​is merely make directors’ wild ideas financially tractable. You could—​and people do—​print the latest Star Wars or Marvel movie out to film stock and thread it through an old-timey projector, and it will work the same as any other movie.

Computers have lots of idiosyncrasies, to be sure, but there are two related ones in particular that I tend to focus on. The first, of course, is interactivity—​and I mean that in a really fundamental way. You act on the computer in some fashion—​push a button or whatever—​and it does something in response. It’s actually a non-trivial effort to arrange affairs so that your inputs, and the computer’s responses to them, compose into a coherent grammar that genuinely empowers you as a user. So you not only construct a mental inventory of what you can do, but you make the fundamental cognitive connection—​some might say agentic—​that enables you to say “I did that.” This is an editorial choice on the part of the software author, of the kind that since before even the first installation wizard, to either treat the user as fundamentally a sapient agent in control of their own destiny, or otherwise as a patient, whose role is reduced to clicking “Next” or “OK” or “I accept” or whatever, while the computer, ultimately, carries out its true owner’s agenda.

It took me nearly 40 minutes at a conference to try to describe the information econophysics of computers versus media that preceded it. Also wow, this talk is nine years old.

The second idiosyncrasy of computers that I want to surface is harder to articulate. It has to do with the mechanics of how you find information. I’m sure we all know how categories work—​kind of like containers for concepts. Well, there’s a flipside to categories, and that’s associative, analogical, that-reminds-me-of kinds of relationships. My argument, which I gave as a conference talk nine years ago, is that the physical and economic characteristics of analog media constrain its geometric and topological properties, in ways that make it extremely difficult to deviate from a pattern of information being arranged into large, opaque chunks, and in strict sequences and hierarchies, of exhaustive, mutually-disjoint categories. The computer eliminates this constraint by shrinking the basic unit of information to about as small as it can go, giving each elementary unit its own address, and then using a persistence-of-vision effect to sidestep the limitations of paper, by amortizing the inherent complexity of information structures over time. You can then invoke its interactivity to alter your path through this space, or even change its structure.

The technical term for categories is extension, and associative relationships is intension. My argument is that for the entire history of history—​that is to say, ever since writing was invented—​extension has been much cheaper to represent in media than intension. What computers do is make intension cost the same as extension. Hence the title of the talk.

Anyway, a computer is just a fancy zoetrope.

People focus on computers being digital, or even electronic, but I believe the other most important feature unique to computers, that complements their interactivity, is random access. It is precisely the fact that an instantaneous jump from anywhere to anywhere else costs the same minuscule effort—​and to have those locations be extremely fine-grained—​that is underutilized. Or rather, we use this fundamental capability all the time under the hood, but it isn’t woven into the everyday computer user’s experience nearly as much as it could be.

While random access was something of an engineering expedient, interactivity was not initially an obvious characteristic of computers, and people had to fight for it. A fascinating account of this history is Waldrop’s The Dream Machine.

I suppose with a claim like that, I should tackle why you would want to. It’s fundamental to why I created Intertwingler, and what is apparently emerging as an entire stack of software to support this endeavour. In matters of communication, where the purpose of communicating is instrumental, that is, to faithfully and efficiently transmit information, we have to read way too damn much raw content—​or watch, or listen, or whatever—​per unit of information extracted. We also have to write too damn much, because what we’re often writing—​and therefore mostly reading—​is slightly varying formulations of the same basic messages, with certain details added or removed for different audiences.

My basic thesis, then, is that in matters of instrumental communication—​i.e., you’re not reading for fun—​is that you shouldn’t have to read something if you’ve already read it. You definitely shouldn’t have to write something if you’ve already written it. And if there was a way to marshal these tiny slices of information—​potentially down to the individual sentence, phrase, or word—​and move them wherever they needed to go, then readers could skip over things they were already familiar with or that weren’t germane to them, and writers could stash details behind a click, and generally reuse material. (Which, in turn, readers are free to skip.) This would enable you to understand more while being made to read less, and convey more while having to write less. That is why I made Intertwingler—​and particularly Sense Atlas, the pilot product on top of it.

When you give an individual concept its own address, you can collate its synonyms, you can put it in relation to other concepts, and, when backlinks are automatically taken care of, you can see everything that references it.

There is the additional bonus that referencing information rather than copying it contributes to its overall integrity, because you reduce the number of unaccounted-for copies out in the wild. That means there’s less stale information out there for people to trip over, not to mention less of a chore to track down.

I have furthermore found that when you reduce information to chiffonade, it’s basically unmanageable unless you put it into some sort of formal structure. This—​at least in my implementation—​makes it de facto FAIR data, meaning that computers can locate and operate over it directly, in addition to human consumption.

How to Imagine the Unimaginable

I don’t really “do” fandom, but the closest I come to being a fan of somebody (who’s still alive) is Bret Victor. He is somebody who has truly mastered the computer as an expressive medium, and is never shy about using capabilities that only a computer could provide, to get his message across.

A little over a decade ago, Victor penned a monster of an essay, titled What Can a Technologist Do About Climate Change? In 12,000 or so words, in his idiomatic style, he steps through a carefully-organized set of domains, with interactive examples, illustrating where people who know how to make things can intervene on the problem of climate change. At one point, he writes this:

The goal of my own research has been tools where scientists see what they’re doing in realtime, with immediate visual feedback and interactive exploration. I deeply believe that a sea change in invention and discovery is possible, once technologists are working in environments designed around:

• ubiquitous visualization and in-context manipulation of the system being studied;
• actively exploring system behavior across multiple levels of abstraction in parallel;
• visually investigating system behavior by transforming, measuring, searching, abstracting;
• seeing the values of all system variables, all at once, in context;
• dynamic notations that embed simulation, and show the effects of parameter changes;
• visually improvising special-purpose dynamic visualizations as needed.

Bret Victor, op cit., § Languages for Technical Computing

I recently re-watched his talk Inventing on Principle, where you can see numerous examples of what he is talking about.

Bret Victor is indeed very good at these things. In fact, if I had one remark about his work, it’s that the bulk of it consists of one-offs—​it would take a lot more work to make them generalizable. It’s not fair, though, to raise that observation to the level of criticism, because what he has already accomplished is far more than enough work for one person. A gap remains, however, in how the underlying data is represented, packaged, shipped around, and generally managed. The prescription is straightforward: Publish data with a consistent structure and transparent semantics, and make it directly addressable on the network, so the next Bret Victor doesn’t have to burn his one brief life on earth schlepping it into a usable shape before he can perform. That’s where I come in.

Once again, INB4 AI: Yes, you may be able to use a large language model to track down this or that dataset and transform it into some format you can use, and maybe they might get good enough one day that you can trust that what comes out of that process is perfectly isomorphic to what went into it with zero transcription errors. But wouldn’t it be nice if the state of the art for data quality was such that you didn’t have to?

For what it’s worth, Victor actually devotes an entire chapter to this. It’s the one with the same title as this newsletter: Media for Understanding Situations. In it he poses the question: “what if there were an npm for scientific models?” What, indeed? How would you even go about making something like that? I have ideas, but I’ve already written over 2,200 words of my own at this point.

What I will say, though, is that it’s wild that in 2026, scientists aren’t just encoding their mathematical models into computable formats as a matter of course. Why do we still have to peel them out of inscrutable PDF academic papers that we have to track down on shady Dark Web sites if we want to use them? Why did it take Bret Victor two months (I asked him how long it took) to compile all the supplementary materials for his essay? Part of the reason, as he remarks, is of course the cartel of academic publishers, but another—​which he also notes—​is that our writing tools still largely consist of glorified typewriters. My remark here is that you can’t even begin to address a problem like this until you can guarantee a substrate of:

• arbitrarily small information resources,
• each directly addressable on the network,
• where the addresses are durable, so links don’t break,
• where links between resources go in both directions,
• where the data syntax conforms to open standards,
• with transparent formal semantics for resources and the links between them,
• and cryptographic integrity,
• and traceable provenance,
• and, importantly, fault-tolerant availability.

Intertwingler doesn’t do all of those things—​yet—​but it definitely does all but the last two (and a half), and the ultimate goal is indeed to do them all. You can very much think of it as an operating environment where the goal is to make it a hell of a lot easier than baseline to do Bret Victor-style demonstrations. Or, you know…

Imagine an authoring tool designed for arguing from evidence. I don’t mean merely juxtaposing a document and reference material, but literally “autocompleting” sourced facts directly into the document. Perhaps the tool would have built-in connections to fact databases and model repositories, not unlike the built-in spelling dictionary. What if it were as easy to insert facts, data, and models as it is to insert emoji and cat photos?

(op. cit.)

…right into my veins. Though again, to pull off something like that, you’d need a uniform interface for the data. I just spent a shitton of effort determining how such an interface ought to behave, and then I went and wrote it up and called it Intertwingler. I then took a prototype I had written years before, scraped the front end off the back end, slapped it onto an instance of Intertwingler, and called it Sense Atlas. The product that will eventually be my job for the rest of my life is basically a handful of stylesheets and some JavaScript in a trenchcoat. I could not have done that without a critical level of data portability. Now, my own development agenda diverges a little bit from “your word processor autocompletes facts”, but the plumbing is there if I ever wanted to go in that direction.

There’s an argument to be made that AI skirts around this requirement, particularly the high-end, so-called “deep research” products. Only that their output keeps turning up full of bullshit. I know this is talking my book, but I frankly don’t see how these systems are redeemable without a backbone of deterministic data.

I spent a couple months this year consternating about AI—​whether anybody would care about what is ultimately a straightforward piece of infrastructure for reliably representing information, whether my life’s work is dead on arrival. I’m still trying to figure out the totality of how I want to engage with it. I stand by what I wrote recently about AI, how the technology (not to be confused with specific commercial products) is genuinely useful in abductive situations, and it will (often) generate satisficing code that is beneath you to write yourself. Nevertheless, I’m still maintaining my long position on boring old deterministic computation.

Deterministic systems will always be simpler, cheaper, and more reliable than artificial neural networks. It doesn’t matter how accurate AI gets, because it’s competing with perfect. It doesn’t matter how cheap AI gets, because it’s competing with e-waste. The way chatbots currently function to procure reliable information anyway, is to pipe out to deterministic code and databases. I don’t know how they skip over that part. A world without deterministic information systems is a funhouse mirror of confabulation. I don’t see how anything works in it long-term.

The thing that makes neural nets non-deterministic—​I mean, besides the deliberate injection of randomness—​is that the model weights are statistics, which are a lossy representation, but a representation nonetheless, of real empirical data. Everything else about those systems—​including the process to derive those statistics—​is deterministic. If determinism wasn’t important, you could just vibe up the model weights themselves and not pay all that money for training.

Something I think about often, when I contemplate the work that went into Intertwingler and what I’m tentatively calling The Wholeness Stack (more on that another time), is how above all else it’s a synthesis of open standards. Part of why it took twenty years to materialize is that it uses a succession of specifications that hadn’t been written—​or probably even thought of—​when I had my first daydream about it. I actually just integrated one that was finalized three weeks ago.

Importantly, my work doesn’t hinge on any arcane technique that incinerates millions—​or billions—​of dollars in capital to be effective. In principle, the ingredients have all been there for 40 years, give or take (although, you know, contemporary CPU/​RAM/​storage/​networking capacities are nice). What changed, over the years, is that people got sufficiently organized to spell out the various details with enough precision that one unassuming Canadian—​largely in my spare time—​could just read the specs and write the code.

The computer is a uniquely potent medium for understanding situations. Computers also do very well as surrogates for authority, doling out answers by fiat. People will choose the register according to what they value.

Comprehension is important to me. Understanding situations, and helping others understand situations, by making media for understanding situations, is where I excel. Make things, make sense has been my motto for the last twenty years—​since before this odyssey started—​and I mean it.

I have also apparently done no small amount of making infrastructure for making media for understanding situations, and I can scarcely believe I’m strongly considering making infrastructure for that infrastructure.

At any rate, if there’s something you need to understand, and especially if you also need other people to understand it, and Bret Victor is busy, then I’m your guy.