Probably computers were a mistake. But here we are.
Language for Document Layout
These days I am mostly writing code in Zig, which strikes a balance between accessibility, simplicity, and power that appeals to me. Someday I'd like to get back into writing plain C, once I feel more confident and capable working with memory in this way.
The Zig Language home page
Gemini is a smaller and kinder way of sharing documents over the internet.
Devine Lu Linvega on Plan 9
Plan 9 is not a product, it is an experimental investigation into a different way of computing. The developers started from several basic assumptions: that CPUs are very cheap but that we don't really know how to combine them effectively; that good networking is very important; that an intelligent user interface is a Right Decision; that existing systems are not the correct way to do things, and in particular that today's workstations are not the way to go.
Using Plan 9 from Bell Labs, by Francisco J Ballesteros
These lecture notes use Plan 9 from Bell Labs to teach a first (practical!) course on operating systems. The system is easy to use for programmers, and is an excellent example of high-quality system designand software development. Studying its code reveals how simplicity can be more effective than contortions made by other systems.
Uxn is a little forth machine with 32 instructions. It was designed with an implementation-first mindset with the goal of targeting salvaged computers, the distribution of Uxn projects is akin to sharing game roms for any classic console emulator.
I'm making a little game in Uxn to explore how it feels:
Ideas & Experiments
A new way to organize programs
For some time now I've been telling people about a little hack I use for understanding strange codebases. When I am interested in learning about a new codebase, I skim its git log until I find a tantalizing tag or commit message, like say "version 1". Invariably version 1 is far simpler than the current version. The core use cases haven't yet been swamped by an avalanche of features and exceptions. The skeleton of the architecture is more apparent. So I focus on this snapshot, and learn all I can. Once I understand the skeleton I can play changes forward and watch the codebase fill out in a controlled manner.
But relying on the log for this information is not ideal, because the log is immutable. Often a codebase might have had a major reorg around version 3, so that reading version 1 ends up being misleading, doing more harm than good. My new organization lays out this time axis explicitly in a coherent way, and makes it available to change. The sequence of features is available to be cleaned up as the architecture changes and the codebase evolves.
LineDrive was developed by Maneesh Agrawala, Chris Stolte, and Christian Chabot at Stanford University, and they describe their system in a 2001 paper if you’re interested in the details. What is most interesting to me is the creators’ inspiration for LineDrive: hand-drawn route maps. While most online mapping services were, and still are, patterned after paper road atlases, LineDrive was designed to look like what you might quickly sketch on a napkin.
[Imp is a] live environment for working with structured data across multiple devices, blurring the lines between database and programming language.
Petnames: A humane approach to secure, decentralized naming
Names must be human-readable in order to be widely used. Unfortunately, while DIDs and Tor .onion addresses are decentralized and globally unique, they are not human readable. How can we build user interfaces that real users might actually use? In this paper we provide an overview of petname systems, a way of mapping human readable names to cryptographically secure names.
On the design of text Editors
GNU Emacs / N Λ N O is a set of configuration files for GNU Emacs such as to provide a nice and consistent look and feel. It is based on design principles I described in the article "On the design of text Editors" that is available on arXiv.
The polygons of Another World
There is a playful way to study the architecture of computers of the past. Find a piece of software you know well and try to find out how it was ported to these machines you don't.
A good choice would be DOOM. id Software's 1994 mega-hit has been ported to everything. It is designed around a core with no layering violations. It is usually easy to find and read the implementation of its six I/O sub-systems.
An other choice would be Eric Chahi's 1991 critically acclaimed" title "Another World", better known in North America as "Out Of This World" which also happens to be ubiquitous. I would argue it is in fact more interesting to study than DOOM because of its polygon based graphics which are suitable to wild optimizations. In some cases, clever tricks allowed Another World to run on hardware built up to five years prior to the game release.
The Make-A-Lisp Process
So you want to write a Lisp interpreter? Welcome!
The goal of the Make-A-Lisp project is to make it easy to write your own Lisp interpreter without sacrificing those many "Aha!" moments that come from ascending the McCarthy mountain. When you reach the peak of this particular mountain, you will have an interpreter for the mal Lisp language that is powerful enough to be self-hosting, meaning it will be able to run a mal interpreter written in mal itself.
μ, A modular approach to audio programming
The title of the course is “A modular approach to audio programming”. I know it’s silly, but it pretty much describes the goal of each lecture—we try to understand the complex theory of digital audio as a progression of independent minimal working examples. Instead of building a monolithic application, we write multiple small, standalone programs in C that can possibly interact with each other.