What did Ngnghm (which I pronounce “Ann”) think of Urbit? Some elements in Ann’s descriptions of Houyhnhnm computing (which I pronounce “Hunam computing”) were remindful of the famous Martian system software stack Urbit: both computing worlds were alien to Human Computing; both had Orthogonal Persistence; and both relied heavily on pure deterministic computations to minimize the amount of data to log in the persistence journal (as contrasted for instance with the amount of data to manipulate to compute and display answers to end-users). What else did Houyhnhnm computing have in common with Martian software? How did it crucially differ? How did they equally or differently resemble Human systems or differ from them? Ann took a long look at Urbit; while she concluded that indeed the three approaches were quite distinct, she also helped me identify the principles underlying their mutual differences and commonalities.
In my various professional endeavors, I had to deal a lot with build systems: programs like Unix Make, Common Lisp’s ASDF, or Google’s Bazel, but also package managers like rpm, dpkg or Nix, with which developers describe how to build executable software from source files. As the builds grew larger and more complex and had to fit a wider diversity of configurations, I particularly had to deal with configuration scripts to configure the builds, configuration script generation systems, build extensions to abstract over build complexity, and build extension languages to write these build extensions. Since the experience had left me confused, frustrated, and yearning for a better solution, I asked Ngnghm (or “Ann” as I call her) how Houyhnhnms (or “Hunams” as I call them) dealt with these issues. Could they somehow keep their builds always simple, or did they have some elegant solution to deal with large complex builds?
Once again, Ann wasn’t sure what I meant, and I had to explain her at length the kind of situations I had to deal with and the kind of actions I took, before Ann could map them to processes and interactions that happened in Houyhnhnm computing systems. And her conclusion was that while Houyhnhnms computing systems certainly could express large builds, they didn’t possess a “build system” separate and distinguished from their normal development system; rather their “build system” was simply to use their regular development system at the meta-level, while respecting certain common constraints usually enforced on meta-programs.
In our discussion about the difference between Human applications and their Houyhnhnm counterparts (I often pronounce “Houyhnhnm” as “Hunam”), I was intrigued by claims Ngnghm made (I usually call her “Ann”) that communication was much easier between activities of a Houyhnhnm computing system than between applications of a Human computer system. I asked Ann to elaborate on this topic.
It was easy to agree that Human computer systems made communication something much lower level than it could be. But Ann also argued that Humans had very poor algebras and interfaces for users to combine processes. Just what kinds of communication could there even exist besides the ones that already existed on Human computer systems?
My previous discussion with Ngnghm (or Ann as I call her) left me baffled: I could somehow understand that Houyhnhnms don’t have the concept of an Operating System Kernel (note that I pronounce “Houyhnhnm” “Hunam”); and I could vaguely guess how each of the many aspects of a Human kernel could correspond to a family of software patterns in a Houyhnhnm computing system, at various levels of abstractions. But while I could visualize these patterns individually, it was less clear to me what the big picture was when these smaller compile-time, link-time and runtime abstractions were put together. So I decided to approach their software architecture from the other end: what do end-user applications look like in Houyhnhnm computing systems?
I was baffled again, but not surprised anymore, to find that Houyhnhnms don’t have a notion of application. Granted, there are simple cases where Human applications have direct counterparts in Houyhnhnm computing systems. But in the general case, Houyhnhnms don’t think in terms of standalone applications; they think in terms of platforms that they extend with new functionality.
I admitted to Ngnghm (whom I call “Ann”) that I was perplexed by Houyhnhnm computing systems (I pronounce “Houyhnhnm” like “Hunam”). To better understand them, I wanted to know what their kernels, libraries and applications looked like. There again, he surprised me by having no notion of what I called kernel or application: the way Houyhnhnm systems are architected leads to widely different concepts; and for the most part there isn’t a direct one-to-one correspondance between our notions and theirs. And so I endeavored to discover what in Houyhnhnm computing systems replaces what in Human computer systems is embodied by the operating system kernel.
Ngnghm, or Ann, examined how manual persistence was managed underneath Human computer systems, and contrasted with how Houyhnhnms (pronounced “Hunams”) automated its implementation. This led her to more general remarks about the compared architectures of Human computer systems and Houyhnhnm computing systems: Houyhnhnm computing systems can and do go meta, which to them is notionally down (not up, as some Humans would have it). Going meta allows Houyhnhm computing systems to enjoy qualities not found in Human computer systems, that can’t go meta.