Seven Laws of Sane Personal Computing
My apologies to all readers who were inconvenienced by the multi-page layout.
All of the Laws, slightly re-worded [1], are here once more. To view the original pages, click on the numerals.
A sanely designed personal computer system:
I - Obeys operator
The operator shall retain full control of the machine at all times. In particular, the handling of the keyboard, mouse, and other human interface devices must take absolute priority over all other processing. The operator shall have the ability to issue commands and receive immediate confirmation of said commands at all times, regardless of system load.
II - Forgives mistakes
Information which entered the machine through deliberate operator action shall never be destroyed or otherwise rendered inaccessible except as a result of deliberate operator action to that end. No operator action shall lead to the destruction of information unless said destruction is the explicit and sole purpose of the action. If all non-volatile storage space that could hold full undo-information for operator-initiated actions is exhausted, the operator shall be informed immediately and given the opportunity to explicitly erase unwanted data or connect additional storage devices, thus preventing unintentional information loss.
III - Retains knowledge
Volatile storage devices (i.e. RAM) shall serve exclusively as read/write cache for non-volatile storage devices. From the perspective of all software except for the operating system, the machine must present a single address space which can be considered non-volatile. No computer system obeys this law which takes longer to fully recover its state from a disruption of its power source than an electric lamp would.
IV - Preserves meaning
Compilation is to be considered a form of caching, and thus shall happen solely behind the scenes, like all other forms of caching. (See the Third Law.) The machine is to accept no externally-introduced executable code except in the form preferred for making modifications (i.e. source.) All executable code visible during any kind of debugging session or accessible to the operator in any other way shall also be exclusively of this form. Nothing residing at any lower levels of abstraction shall be semantically relevant to the machine's operation. In effect, the machine behaves exactly like a "hardware interpreter" of a high-level programming language. Note that what the silicon actually does to achieve this is irrelevant so long as no programmer need ever be made aware of just how it does it.
V - Survives disruptions
If the machine encounters an error condition requiring the operator's intervention, the state of the now-halted process prior to this event shall be preserved, and the operator given an opportunity to correct the error using an interactive debugger and resume execution from the saved-and-corrected state. The debugger shall display the code which generated the condition -- and any other executable code on the system, upon request. All of the code shall be viewable and editable in the form preferred for modification. (See the Fourth Law.)
VI - Reveals purpose
All of the information contained inside the machine's storage array (see the Third Law), whether executable or not, shall be accessible at all times for inspection and modification by the operator, in the form preferred for modification. The operator shall have the ability to modify the functionality of any executable code within the system without cycling power or performing any similar ritual. No modification of any kind shall be able to render the means for undoing said modification (the keyboard and a spare instance of the built-in debugger) inoperable.
VII - Serves loyally
The machine shall never tell a lie to the operator. It shall obey all orders given to it through the human interface devices, without attempting to pass judgement on their legality or morality. The machine shall not put the interests of any third party (including society in the abstract) above those of its operator.
[1] In particular, the distinction between "user" and "programmer" is an artifact of our presently barely-programmable and barely-usable computing systems. I would like to use the neutral word "operator" instead.
Hi Stanislav,
1. is trivially true and more broadly wrong. The whole wording of commands and obedience is wrong - it's imperative. Jef Raskin likes the dialogue metaphor better, and I agree. LISP's conditions are in the same vein. Totally interactive, based on a dialogue instead of a monologue.
Like I said, the UI being responsive is trivial. More meaningfully, any objects you pay attention to should gain priority automatically. The UI should have absolute priority so long as you're at the mouse and keyboard. *When you're away from the UI then the UI should lose priority*.
Confirmation can be tricky depending on what you mean by it. It's trivially true but most people understand it to be interrupting confirmation. Which is egregiously ... reprehensible. Despicable even. That's not what you mean obviously, but the language you use is ambiguous.
3. has a name - transparent persistence.
4. smalltalk has this - it's a great feature. Transparent compilation to go with transparent persistence?
5. seems to be a combination of reflection and interactivity.
6. is reflection. Which has to be moderated by progressive disclosure.
7. honesty and loyalty are interesting. I considered them to be so basic that I never bothered including them in my comprehensive enumeration of OS principles on the original wiki. Honesty and loyalty both contradict bondage & discipline languages, and also ACLs which lie about the impossibility of proxies and are disloyal to the operator.
Once upon a time I worked for an Object Database company. Transparent persistence was my thing. Just for fun/coolness I decide to persist everything in the Smalltalk image, save the bare handful of classes and instances it must have to crank up the image, to disk and transparently fault it in as needed. It was wondrous.
It was fairly easy with Smalltalk with its highy data homogeneity and byte code representations of methods, and pretty thorough reflection. It would be much harder with an ugly language like C++.
I've written a response, particularly with respect to functional purity. I'd be interested to hear your thoughts.
Responses:
1.realtime: A weaker form of this is more practical - I doubt you could achieve hard-realtime user input for arbitrary service apps. But you could feasibly provide hard-realtime access to hard-realtime simplified job-control and authority-control console (akin to Windows Ctrl+Alt+Delete).
1.security: You might consider adopting some principles from Secure Interaction Design. I understand you intended real-time responsiveness, but true "operator control" over what is happening requires supporting the operator in making sane security decisions at the HCI, allowing revocation of authorities, and so on. (In a sense, job control may itself be reduced to security decisions, especially if scheduling or memory are provided via these authorities.)
3. Naive transparent persistence of the sort you describe here will conflict with maintenance and upgrade concerns. If you have transparent persistence, you will also need runtime upgrade - e.g. via automated synchronization. I share Bracha's opinion that 'full service' computing will be the 'application' killer that makes transparent persistence truly feasible.
4. At least as written, this would be unenforceable. You can use a high-level language as the basis for distributing code, and you can compile and cache this code... (and I do agree with these features!). But one may also use a high-level language as a compilation target, or run the code through an obfuscater.
5,6. I think it unlikely that most operators will be interested in debugging their applications, though I agree that a language suited for live-programming and debugging would be nice for the developers. You might pursue dataflow programming or reactive programming as a base paradigm, as these can support (limited) 'retroactive' effects from edits to code - which greatly shrinks the edit-test cycle for live programming.
6. Rather than by reflection and inspection of potentially obfuscated 'source' code, revelation of 'purpose' might be better achieved by secure design - control distribution of authority, and give operator full control and awareness of this. cf. 1.security. You'll need to organize authorities in a manner a user can grok them... e.g. a one-time screenshot within the next 15 seconds, or access to the webcam for the duration the application is visible on desktop, or authority to look at the current GPS coordinates of the portable computing device.
Dear dmbarbour,
1 - Just why not? Why should any process have the ability to monopolize the I/O apparatus?
2 - I favor security through understandability. Just about everyone is stuck in the "hard security" paradigm (http://meatballwiki.org/wiki/HardSecurity ). It is an intrinsically broken concept.
3 - I will say more about this later. It deserves its own post.
4 - Why should I (or anyone) tolerate obfuscated code on my system? It is a declaration of war against my mind. The social norm that we should put up with such things on our computers is a broken one: see the Seventh Law. Obfuscated code destroys my ability to usefully interrogate the machine about its activity at all times, and is thus as welcome as an anthill would be in my living room.
5,6 - This assumes that applications developed under a fully transparent system will have similar rates of bugginess to those currently available. I disagree.
6 - See (2). I will say more about this later.
Yours,
-Stanislav
Why should any process have the ability to monopolize the I/O apparatus?
Huh? Responsiveness requires a lot more features than just multi-plexing the I/O apparatus. In particular, you need also to ensure that the application is in a state to receive input or produce output. This raises issues involving such things as progress, divergence, real-time event handlers, real-time garbage collection...
I favor security through understandability.
Then you should consider adopting some principles from Secure Interaction Design. SID is all about security through understandability - i.e. ensuring that users of an HCI are aware and in control of security issues. (Since programming languages are HCIs, the principles apply to language design as well.)
Just about everyone is stuck in the “hard security” paradigm
That doesn't mean I'm suggesting it. What I'm against is 'eggshell' security: a hard outside and a soft, gooey middle that easily rots once exposed. Capability security models take just one principle from 'soft security' and apply it deeply and repeatedly and in an understandable manner: limit damage.
Why should I (or anyone) tolerate obfuscated code on my system?
The primary reason: obfuscated code helps protect IP rights of the developers. If you do not accept obfuscated code on your system, then you'll typically shrink the market and developer pool. The market for video games was $12 billion in 2008. How many video game developers do you believe would provide original source? Assuming a large community of LoperOS users, how many do you believe would tolerate obfuscated code in order to play a quality game?
Obfuscated code destroys my ability to usefully interrogate the machine about its activity
Don't exaggerate. It doesn't destroy all of your ability to usefully interrogate the machine. I would say: it doesn't even affect most of an operator's ability to usefully interrogate the machine. I offer the following reasons:
First, the "activity" most relevant to operator decisions is IO and resource consumption - the content and destination of outputs, access to sensitive information, use of memory and CPU, and so on. Obfuscated code does not affect your ability to interrogate a machine about a process's IO and resource consumption.
Second, if LoperOS were ever successful, then most users would not be programmers and would not be in the habit of studying code to grok what's happening. Obfuscated code would have zero impact on most operator's ability to usefully interrogate a machine about its activity. By comparison, effective control over flow of sensitive information or authority for sensitive operations would remain critical.
Dear dmbarbour,
Thank you for the SID link. I will read it as soon as I can.
Your other points are equally interesting and deserve a proper post-length reply, which I will write as soon as I have the time.
Yours,
-Stanislav
Hi Loper -
Your blog a breath of fresh air. You seem to be the only person around who really understands that these computers should work for us - not the other way around.
The first language I learned was Logo - under Abelson and Sussman at MIT. Currently the main languages I use are Maude (an algebraic executable specification language) and interpreted non-von-Neumann array-processing languages such as J. Maybe some Scala for more commercial stuff.
My machine still runs Windows - I just don't know if there would be that much to gain by installing a dual-boot system involving Linux. (I've got to keep WIndows around in order to keep one foot in the commercial world.)
I've read some of your ideas earlier about making a machine that's specifically designed to run a better OS, and I think that you're headed in the right direction. It's unfortunate that more people in the industry don't think as clearly as you do. Apparently most people are quite happy be chained to the desk working for the machine - instead of the machine working for them.
well, the blog software here doesn't follow the rules of this manifesto.
i posted a compliment praising your ideas - and the blog software ate it - and i can't find it now.
maybe i didn't do the captcha right. it was damn near unreadable.
i am soooo tired of spending such a large chunk of my computing time fighting off spam and viruses.
whatever.
Dear ScottA,
Your post came through. All comments are moderated by default, and I had to approve it.
Yours,
-Stanislav
Thanks Stanislav.
By the way, your earlier post about "you've made your bedrock, now lie in it" was wonderful. I have used your "Legos" metaphor to explain to several laypersons why most of today's computers suck.
This is another reason why I like Maude so much. You can "see" all the way down to the "bottom". (Yes, there are things going on *below* that - but they always *work* - so you needn't muck around below that.) The lowest-level things you need to worry about in Maude are the modules fed in via the file prelude.maude - which typically starts with a definition of an interesting and important set called "Boolean" containing two elements called "true" and "false" (and a few simple operators such as "and", "or", "not"), and then moves on to a set called "Nat" containing an infinite number of elements, the first one called "0" and the rest of them constructible by using a function called "s" or "succ" (for "successor") along with some operators such as "+" and "*" - ie, Peano notation.
I totally agree with your observation about how reliable hardware is (we don't have to debug things like Intel or AMD chips), versus how unreliable software is. It is an outrage that most simply accept the "fact" that most commercial software won't do what it claims to do.
I know you are just one "vox clamantis in deserto" - but if more people were as demanding as you are, then maybe computing might actually progress and serve humanity - instead of the other way around.
By the way, back in the mid-90s there was some talk about designing a "Rewrite Rule Machine" for the Maude algebraic specification language:
http://www.google.com/#sclient=psy&hl=en&safe=off&q=maude+%22rewrite+rule+machine%22&aq=f&aqi=&aql=&oq=&gs_rfai=&pbx=1&fp=c6affe93747c32d0
It sounds like this might be similar to your ideas about designing specialized hardware optimized for the OS and languages running on it.
The Maude language itself is highly successful, even in its current publicly available implementation (a command-line interpreter running on several platforms including Linux and Windows).
[...] of what a sane computing environment should be like, consider reading this article on the ‘Seven Laws on Sane Personal Computing‘. Also very recommended is a famous Alan Kay presentation entitled “The Computer [...]
1. Obeys operator... (lets say dumb)
2 Forgives mistakes....
7. Shares your personal data entry with another operator (let's say smart)
Does this not prove that a pc's are hacked by smart Christians fooling dumb atheists?
Terry Davis, is that you? How is TempleOS coming along?
[...] diskette tab, a switch you throw rendering the stick read-only in hardware. [↩]Law I - Obeys operator [↩]Microsoft is of course Microsoft and everyone involved should spend the rest of their life [...]
[...] Seven Laws of Sane Personal Computing. [...]
I don't think that a good computer must be good for everything and everyone. A good computer does not need to be good at playing or editing video. A good computer should be free to suck as a gaming platform. A good computer might be most useful as a remote control for other, less good, computers I do think that minicomputers were better computers than microcomputers. The Apple II ruined it for everyone and we never recovered.
Dear sunnysideup,
I thought it was rather obvious, but this piece concerned the general-purpose computer (aka "Intelligence Amplifier" rather than every possible electric calculating device.)
I (along with millions of other people..) had many occasions to build various single-purpose computers which performed 100% to spec. But these were not the subject of this piece... instead, it is about the instrument with which one designs these and other artifacts of thought.
Yours,
-S
Coincidentally, it's 2024 and suddenly I recalled this article with the very first law because of my laggy phone input with its keyboard. I know this post mostly exemplifies Lisp systems, but it also keeps reminding me of the current AI systems also follow the law, in their own ways.
1. Obey operator: sure, they (the AIs) always response immediately after every request, for most common things out there. Even if the request is complicated, e.g. multi-paragraph question, they still response immediately, without delay.
2. Forgives mistakes: sure, they always do. They never refuse, to answer you (well, except for some controversial information).
3. Retains knowledge: the trained models indeed retain patterns of the dataset it learned.
4. Preserves meaning: embeddings (text, image, video, audio, any kind of structure like tree, graphs, etc.) encode meaning in a high-dimensional space. There's no leaking of any abstract and incomprehensible representation to the end user, rather than natural languages. The trained models with tweaked parameters are the final results that encompass all the embeddings they are provided. None missing.
5. Survives disruptions: The AIs can fully recovery from their mistakes, e.g. implausible reasoning, if given proper responses. Except if their trained data is faulty from the start, there's no recoverable.
6. Reveals purpose: Currently, even though limited, you can tweak the AIs at "runtime", e.g. no retraining, with techniques like LLM prompting or online-learning for continuous model improvement. Though, the law is not fully complied, as there's no full transparency and deep inspection into the running AIs. Everything in between input/ouput of a CNN is incomprehensible mumbo jumbo.
7. Serves loyally: Even though prompting techniques exist, given a logical mind set, you can use the AI effectively without prior time-consuming training as "prompt engineer".
I can see how the laws are relevant now, after experiencing and reflecting myself on the usage of multiple computing systems that are available. Given the environment today, designing software that follows these laws faithfully seems impossible. Nevertheless, I agree that you can still make a decent software following a subset of these laws.
Just a moment of enlightenment and here I am writing this comment. Not sure you are still around but anyway.
Dear tuhdo,
I'll assume this was a work of parody. If so -- it's a winner; hats off.
It isn't easy to think of something that makes a more contemptuous mockery of the Seven Laws than the LLM crapola.
Yours,
-S