Under review is this website.
I first read this website years ago, and it seems to be rather finished by now, although some future chapters may arise yet. The website details a man discussing computing with an equinoid alien named Ann, and this is inspired by ``Gulliver's Travels''. It's a fascinating set of documents explaining an alternation from the current state of computing, even if none of it be actionable in the present. Regardless, it has been an influence on how I view computing and design, and I recommend reading it.
The first chapter concerns those differences between ``computer systems'' and ``computing systems''. I recall no more if my belief that supposedly-simple human computer systems are actually grotesquely complicated, viewed as a whole, came to me through this chapter or not. The second chapter concerns itself with persistence of information before segueing into the arrangement of systems for achieving it properly; in particular, orthogonal persistence allows a system to be fundamentally simpler while few pieces of the system need be aware of its presence. A related topic further elaborated later is proper abstraction allowing powerful programs manipulating programs to work properly, transparently.
The third chapter deals further with persistence. Session preservation in human computer systems is incomplete and complicated. This is the first chapter noting how human computer systems are divided into ``applications'' without good cause. It's a strange and powerful feeling to separate data from representation, in human computer systems, but this is how the computing systems naturally work; the file path of human computer systems is but a lesser form of what better systems call an access path. I disagree about ``The general answer is that to fix a system that has entered a bad state, you need an external system that can stop the broken system, inspect it, fix it, and restart it.'' yet accept it may always be needed in practicality; this idea is likely from the Lisp Machines, which had such. This is also the chapter detailing what proper virtualization would be; it happens not at that level of machine instructions, but the level of logged changes at whatever level of abstraction be needed.
I often think of that concept in the fourth chapter, software towers. As written: ``Humans can only build software but up. Houyhnhnms can build both up and down.'' I still believe the latter systems can be thought of as being one tower, just as in human computer systems, and it be merely the proper tower has been chosen. It's again but a matter of powerful programs manipulating programs properly.
Kernels, as in human computer systems, are irrelevant, as described in the sixth chapter. That idea of but one kernel enforcing permissions, managing resources, and providing abstractions is obviously silly compared to that idea of multiple kernels doing this in whichever ways be needed, at whichever levels of abstraction be best; further, such a system is more efficient without constant checks done while the programs execute rather than but once where feasible. Again, this may be the source of my belief that a proper system initialization would simply load that current state and do nothing more.
Chapter seven is about platforms over applications. Once again, my belief that video games are done about as well as they can be, unlike other programs, may stem from this chapter; video games needn't interact with a greater system much, are often finite-state machines, and improperly giving commands to one isn't met with an undo system but getting better at giving them. The basic idea is of adding to an existing base, rather than starting anew, and is deeply related to that concept covered by the eighth chapter, communication. The act of copying-and-pasting is called ``implicit communication''. Very interesting is that concept of a meta-program, with virtual terminals being used as an example, a program which functions as an intermediate party and of which no programs need be aware. I'd once experimented with creating such an interface, to abstract and simplify the design of a program I was writing, but the issues posed by the greater language meant it could never work, and I then gave up.
The ninth chapter covers ``build systems''. I believe there should be no such thing as ``building'' software in any way distinct from programming it; the end result should be immediately usable. More interesting are the notes on managing namespaces, if only because I also disagree on its notes about software finalization; it denies the idea of finished software, which I consider to be unreasonable.
The eleventh and final chapter deals with the nature of blame, and forms a good rebuttal against men who would encourage bad tools to be used due to personally enjoying them, despite the havoc wreaked.
It's clear to me that there's no way to turn a human computer system into a proper computing system; a total changing is required. Human computer systems are dominated by a fixation on hardware rather than mathematics; they feature determinism, while making almost none of it usable through any means.
It's good to once again read the writings of a man who understands perfect abstractions can, and do, exist. It's unlike the incompetent filth who deny such things, purely as matter of self-protection.
A major theme of this work is that human computer systems don't provide nearly enough functionality, requiring the constant bespoke reimplementation of many needed things across the system. Another of the particularly amusing ideas in these writings is that of programmer liability, which haunts those incompetent people calling themselves programmers. I'm left with the sensation that a fixation with absolute correctness can entirely eliminate many of the problems described in this website; this may appear to be akin to the solution of all medicine being to eliminate disease, accidents, and genetic defects; still, I'm pursued by the idea of simply getting software right the first time and forever.