Probably computers were a mistake. But here we are.
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.
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.