MY MANIFESTO FOR A BETTER COMPUTING SYSTEM

[gusl]

This morning I woke up pissed off because Windows rebooted overnight, forever erasing some notes I had. This motivated me to refine my ongoing manifesto, so it could be LJed. The ideas here are obvious, but it looks like they have escaped pretty much EVERYBODY who ever designed large computing systems.

I used to dream of starting a system from scratch, and writing all my programs for my system, so that over time it would develop into an optimized environment for its user (i.e. me). For a while, I had faith that Linux with all its open-source goodness, had done that most of the work for me, and all I would have to do was implement my ideas. Unfortunately, I never became well-versed enough with the system to find out if that was going to be possible. A year or two ago, I ran into the TUNES website, and realized that I wasn't the only one with a dream. In fact, these guys have been way ahead of me for a long time. Anyway, I think it's a good idea to write down *MY REASONS* for wanting a different approach to human-serving cybernetic systems (i.e. personal computers).


If you know of any systems implementing my ideas or solutions to any of my concerns on a Windows platform, please leave a comment. My goals fall short of Faré's goals. (btw, this website is definitely worth checking). Faré actually calls his ideal "computing liberalism" (in the sense of "libertarianism"), and accuses present systems of computing statism / conservatism, but I fail to see the analogy.


How computing systems should be, but aren't:

User control over the machine
All I want is to be able to access all inputs and outputs of my machine, with suitable abstractions. This shouldn't be too hard, as there already exist thousands of drivers out there for most data media, both input and output. Yet, it never seems trivial for the programmer to access these ports. Many of my frustrations have had to with finding graphics and sound libraries for different languages.

Programs should be written flexibly
As a rule, analysts and programmers can't predict how their users will want to use their system. People who spend a lot of time using the same program end up becoming experts at it, but at the same time, they eventually run into a wall, and can't improve their efficiency further. This is when they start noticing the limitations of the program. Thus, programs should be written in fine-grained open-source modules, so that they can be easily customized. Compilation and packaging shouldn't protect users from acessing internal functions of a program. The user should be able to EASILY change how the system and its programs do anything.

Meta-programming and Scripting
People today do many repetitive things on their computers. In fact, we have developed typing/clicking scripts in our heads to get through these annoying processes. This is a sign that the user and the system are not communicating properly. It is an incentive for the user to enter input without thinking, which can be a dangerous thing. The user already has to sort out his own problems: communicating with the machine shouldn't be another problem on his mind (even if this communication problem tends to consist of dumb, busy work). Through meta-programming and scripts, users would be free to optimize their actions. In Windows, there exist scripting options, e.g. Unisyn AutoMate, but since 99% of programs have closed interfaces, it becomes a huge pain in the ass to program scripts to click in the right spot on the screen given the right conditions, etc, etc.

Program Editing at Run-time
Users should be able to change the programs they are using at run-time. The current paradigm of edit-compile-run does not allow this. I think some people at TUNES are trying to solve this with a Lisp-like language. Programs would run by constantly interpreting their script. Any changes on this script would be reflected in the program's execution. Voilà.

Backtracking
A history of the state of the system (and all subsystems, e.g. individual processes) should be kept. It should be easy to go backwards and forwards through all user actions. It should be easy to combine aspects of different historical states.

The System Should Always Listen to the User
User input processes should have absolutely first priority. A frozen system is inexcusable. A command to end a process should be obeyed immediately.

Consistent Programming Interfaces (TUNES: Unification)
For the programmer, as well as for the user, there should be no difference between accessing something from memory or something from the hard disk. I can probably come up with similar examples.

Files and Stuff: Where Things Are
On my ideal system, files, objects, etc on disk/memory are multiply indexed for search purposes, each index as specified by the user, and there may be many directory trees, if this is found to be convenient. Files are not inside directories: everything is shortcuts. To each file, the user can attach information of any structure, which is searchable in a virtual "database of files". See AskSam.

Orthogonal Persistence
Files should be saved automatically as you type them. If you're not sure you want to commit to your changes, you should work on a copy. A user's work should never be lost due to not saving it on time!

End Modal Dialogs
Remember: the user is the boss. Modal dialogs prevent the user from accessing the information they need. I often need to close them and check the info I need before I can re-open them and finally do what I intended to do.


IDEAS ABOUT MEDIA / SOME USEFUL USER AIDS:

Planning of User Activities
Program to assist the user in planning his to-do list and specifying his goals
(chunked tree of goals, subgoals, etc. with most details unspecified, kinda like the "MS Project tree")

Let the user organize his current processes as he desires. Imagine a user doing 3 unrelated jobs at once, each involving a browser, an email message and a document editor. Most interfaces would organize the processes by application, which makes no sense. The user can get lost trying to find his precious window, because it is not in the right place.

Diagram Maker: Simple application for editing arbitrary structures (usually special cases of Graph) as a diagrammatic aid for the user. Maybe it could work as a semantics for the content. Maybe these documents coule be considered as records for search in super-queries

Links between applications: all we have today is Copy / Paste. Dragging should be encouraged.

In some programs, actions or commands can be awfully hard to find. It should take only keystroke to search for a command. Shell-command interfaces can be a good alternative to menus or pop-up lists.

Customizable interfaces: Self-Editable Programs
As part of optimizing his experience, the user should be allowed to change menus, shortcuts, etc. from within the program's normal interface. By holding a special key, the user can preview what an action will do, and change it if desired. Maybe SmallTalk does something similar to that.

I welcome any questions, comments, suggestions, etc.

Addition:

RELATED LINKS:

Windows Annoyances

Dertouzos: Author of "The Unfinished Revolution"

David Gelernter: THE SECOND COMING — A MANIFESTO


Comments by John McCarthy

"Unfortunately, the making of computer systems and software is dominated by the ideology of the omnipotent programmer (or web site designer) who knows how the user (regarded as a child) should think and reduces the user's control to pointing and clicking. This ideology has left even the most sophisticated users in a helpless position compared to where they were 40 years ago in the late 1950s." -John McCarthy

Comments

[pyran.livejournal.com]

This is very, very interesting, and as soon as I get some more time (such as when I'm not about to go off to bed) I plan on following all of the links, something I suspect will take awhile. :-) However, at first glance one issue immediately springs to mind: customizability vs. ease of use.

Most of the problems that I see with most applications (including, I must admit, programs that I myself write) stem from the issue of who you're writing the app for. In a very broad sense, there are two basic types of users in the world: the ones who want to customize everything until it's just perfect, and the ones who are pretty much happy with the app as it comes (I'm over-generalizing deliberately -- for the most part even those people who fall somewhat in-between and customize using options/settings are generally happy with the app out of the box, with only a few exceptions). The more customizable a program is, the more complicated it inevitably gets, and the more complicated it gets, the more overwhelming it is to users who are generally happy with how the app functioned right out of the box. So a major issue is how to make an application as customizable as possible -- even, as you point out, to the extent of being able to change core functionality -- without making it so loaded with customizable scripts and options that it's overwhelming to the average user.

I call this the "Grandmother Test". If my grandmother can look at a program and stand a reasonable chance of learning how to use it, the application can be assumed to be useful in the mainstream. If not, it should be targeted primarily at power-users.

As an aside, I think this is one area in the Windows-Linux-Mac debates that is often overlooked by one camp or another (although I find it most often overlooked by the Linux camp). One reason Macs are popular is that the OS is so simple to use that anyone can figure it out pretty quickly. On the other side of the spectrum is Linux, which is so configurable as to be able to become nearly anything, at the cost of ease-of-use -- learning how to use it is not necessarily a simple task. Unfortunately, Windows isn't much of a middle ground: it tends to go 80-20 towards ease of use; that is, it is not quite as easy to use as a Mac, but nowhere near as customizable as Linux.

This may have turned out to be more long-winded than I had intended, but my point is that in the quest for greater customization of applications towards the user, it should not be forgotten that the perfect program that is nigh-impossible to learn to use and customize correctly is effectively useless.

Once I get a chance to follow up on all of the links, I'll add more thoughts here as I think of them.

[gustavolacerda.livejournal.com]

I'm glad you're interested. I love to spread these computer revolution memes.

If you consider programs as static, then indeed, there exists a dichotomy of ease-of-use vs customizability. But, ideally, the program (at least the visible part of the program) evolves with the user. Whenever a user runs into a "wall" (as described in my post above), he could either unlock the advanced options he wants or write his own commands (hopefully in an intuitive visual language tying program variables to "user variables" in obvious ways).

Seriously, a small FAQ about how to optimize the commonest use cases would be a huge improvement in many existing applications. I kinda feel like my suggestions are an extra luxury, given what's missing today.

The reason some programs are hard for the beginning user, e.g. your grandmother, is that they give the user too many choices, and it becomes hard to find the simplest commands.

Maybe the above statements don't apply to some kinds of programs. Can you help me think this through?

[pyran.livejournal.com]

Absolutely I'll help think this through -- I think the ideas you've presented are very, very good, although there are still some major hurdles that need to be cleared for them to really be able to take hold.

I've begun reading some of the links you provided, and I find TUNES especially intriguing. However, I'm still having a hard time with one thing: the assumption is that the average user can do all of this.

You're absolutely right -- often the reason people think a program is over-complicated is that they are presented with far too many options. Hell, look at MS Office -- let's face it, the settings screen for damn near everything is overwhelming. However, is it really any better to present the user with an entire language to allow them to change a program? If people wanted to script everything, they'd all be programmers. Most people have neither the time nor the inclination to do so. However, what if the application could make these changes transparently? Really, you'd just need baby steps -- change small things one piece at a time. Take an example: if the user constantly needs to be prompted to save their work on exit, and they always click yes, then why not auto-save on exit? A little pattern recognition by the app would go a long way towards transparently customizing a program, in much the same way a Tivo records some TV shows without prompting based on what it thinks you would like to see.

There is something to be said here for inertia. Many people don't care to customize a program, as they don't really give a damn what it does, provided that it does what it's supposed to. So often if you're going to customize a program, there shouldn't be prompting and scripting. Of course there should be an option to do so, but once again, take my grandmother: if you ask her to write a script to change stuff, she'll say no. But if the program does what she wants it to do without her prompting, she'll be thrilled.

So my point is that perhaps there shouldn't be an explicit wall for a user to run into -- if an app gets to a point where the user is stuck, the app isn't really doing its job. Instead, the app should be constantly adjusting to accomodate the user, all the while giving the user the ability (e.g., through scripting or whatnot) to make large-scale, non-trivial changes if necessary.

Or am I going too far here?

[gustavolacerda.livejournal.com]

I am trying to bridge the gap between user and programmer. I tend to become a power user at anything I use long enough (i.e. I become restricted by my tools, no longer by my ability), and I guess the only way to improve one's tools is to be a programmer in some form or another.

A user who isn't willing to be a programmer (i.e. work on his tools), should accept the tools he already has (either that or depend on somebody else's help). Programming doesn't necessarily have to involve messing with ugly code in a text form. In fact, given a smart enough environment, one can program by demonstration (see Henry Lieberman), by answering questions, or using some graphical programming language (though I haven't heard of the latter two)(granted, text-based programming is the most powerful, at least for now). The idea is to allow laymen to be programmers without too much effort. But all of this is far from a satisfactory solution to my concerns.

I guess my goal is to create (development) tools to help people to improve their (application) tools. But this requires the application to be written in specific nice ways.

However, what if the application could make these changes transparently? Really, you'd just need baby steps -- change small things one piece at a time. Take an example: if the user constantly needs to be prompted to save their work on exit, and they always click yes, then why not auto-save on exit? A little pattern recognition by the app would go a long way towards transparently customizing a program, in much the same way a Tivo records some TV shows without prompting based on what it thinks you would like to see.

I, for one, like my programs to be predictable. I don't want them learning my behaviors without my control or supervision, since they could learn wrong behaviors. Besides, some user behaviors may be too complex to be figured out statistically. Not only that, but some improvements (probably the most important ones) involving adding new concepts, and are inherently more complex than changing a yes/no setting (such as "Save Automatically?"), and would require a new *programmed* module for modeling the new concept (dumb example: you want to improve Notepad so that it uses multiple fonts on the same document, you would have to re-create the concept of font (in this case the font becomes a property of each character, instead of the document): the program will never learn that by observation).
Basically, you can't get away from logic.

But then again, yours is a good idea in some cases. Maybe the program could warn the user before using its new, learned behavior. Microsoft sometimes does this, but without warning: remember how only the most used apps in would show in Windows XP's Start Menu, unless you clicked for more? I hate that.


Or am I going too far here?

No. It's only too far when you lose sight of what you are doing there. ;-)

I want to study more cases of "walls", and see where my theories need more work.

Learning and reversibility

[fare.livejournal.com]

I, for one, like my programs to be predictable. I don't want them learning my behaviors without my control or supervision, since they could learn wrong behaviors.

One simple solution to this problem is in reversible computing, not unrelated to the "backtracking" feature you mentionned: never learn any behaviour that isn't reversible, and have the learning be reversible itself. Hence, you can undo any change that was brought by the program learning something, and you can undo this learning and prevent it from happening again. This adds the "control and supervision" you need before you may accept learning. On the other hand, special care should be taken to avoid the user committing a change that means more than he thinks, or otherwise being confused by reversible changes that would nonetheless corrupt results of computations in a subtle way. In other words, learned behaviour should never alter misleadingly the perception by the user of the underlying documents being manipulated.

[jetcat.livejournal.com]

> Orthogonal Persistence
> Files should be saved automatically as you type them. If you're not sure you want
> to commit to your changes, you should work on a copy. A user's work should never
> be lost due to not saving it on time!

i don't really know anything about programming, but i'm one of those few ppl who isn't satisfied w/ either Windows/MacOS or linux. as such, i have one windows box and one linux box. i have copies of certain files on both systems--those that i like to be able to read/update on both systems, and those that are important enough that i want them backed up, but more accessible than if i were to burn them to cd, for example. anyways, i've always thought it would be REALLY nice if when i have the two (or multiple) computers networked, i had the option to say that i want to have certain files "linked," so that when i make (and save) changes to the file on one computer, the copy of the file on the other computer is automatically updated and saved. would this be possible?

[selfishgene.livejournal.com]

Cool ideas, Gus.
I like that whole list; especially the part about frozen systems. I drives me crazy when I type a sentence and the screen stops echoing my characters for 5 seconds while some other processes gets control. I thought preemptive multi-tasking was supposed to stop that issue.
One (hardware) thing you didn't mention was larger screens. I think a lot of hassles will go away when we have cheap flat panel screens, preferably concave to allow constant focal length. I would like a screen literally as wide as my arms can reach. This kind of screen will allow users to simply drag stuff into or our of the central focus but still be able to look at items on the periphery.

[gustavolacerda.livejournal.com]

There was a time when I was obsessed about using an array of screens, each representing a different desktop, like Unix's multiple desktops feature. I was using several full-screen applications at once, and that would have spared me a lot of clicking. It's surprising how hard it is to implement such a simple idea.... like all the other "obvious" ideas here, I guess.

[simonfunk.livejournal.com]

Hey, finally a moment to comment (mostly related to the language/programming aspects):

I share your goals completely, and those of Tunes, but I have been frustrated over the years at the brittleness of any direct approaches to these problems and at this point I believe they need to be tackled at a more fundamental level. Tunes, for instance, claims it is just a matter of integrating all the existing pieces. But I believe it is the manner of integration itself that is the true missing piece.

What you are looking for, I think, is not more attributes to your programming language, but new fundamentals benieth it.

To be concrete: existing code, in any current useable language, specifies How, but not What or Why. Look at the comments above methods or prototypes in well-documented code, and you will find they are more useful, and longer-lasting, than the code itself. The code will be rewritten from context to context, but the comments often stay the same. Why? Because the comments express, as a chunk of knowledge, What the code does--and that is the real code, or should be. That is the chunk of knowledge that reflects what is in our heads, and it is how we think about the code, and how we decide when to use it and why (and that is what integration is all about...).

Imagine if we thought about our code in terms of the bodies of methods -- we would be unable to do anything more abstract with them. Yet imagine if I gave you a function foo(a, b, c) and didn't tell you what was in it -- it would be useless to you. This is the world visible to any modern compiler.

So, I ask: if you read the body of a method and/or the comments above it and understand what it does, what is that understanding, and how can it be written down? Can it be made more accurate than english, but more general and concise than code?

(And is the answer to that question necessarily full AI, or could it be just another programing paradigm? And can TUNES really succeed without answering that question? I realize it's not immediately obvious on the surface why not, but my suspicion is not.)


Anyway, my two cents. I reserve the right to change my mind about anything and everything on a moment's notice. :)

[gustavolacerda.livejournal.com]

We seem to be generally on the same page.

But I believe it is the manner of integration itself that is the true missing piece. I don't think the folks at TUNES would disagree with you. "dynamic thinking" is one of their mottos as is (or should be) "build freedom".

You seem to be hinting at the ideas of Intentional Programming. What are your thoughts on that? There doesn't seem to be that much explicit information about it on the web. I've collected the following links:

http://tesugen.com/irrational/archives/moreOnIntentionalProgramming.html

http://www.aisto.com/roeder/paper/

Can you guess why Microsoft aborted their IP project?


To be concrete: existing code, in any current useable language, specifies How, but not What or Why. Look at the comments above methods or prototypes in well-documented code, and you will find they are more useful, and longer-lasting, than the code itself.

I think users of high-level languages such as Lisp, ML and logical languages might disagree with you. I once complained to a professor because he took points off from a Prolog assignment of mine for lack of comments. I asked him what he would have written in the comments and he agreed with me that it was completely obvious from the code (to finish the story, his final argument was reduced to "but it was only a couple of points!" and I didn't insist)


Regarding "necessarily full AI" question, I believe TUNES answers it negatively, and I agree with them. But I'm an optimist by default. I never understood why software systems have to be so complex anyway. I say: if you can think about something simply and explicitly, you should be able to implement it simply. But for some reason (which I don't understand) it's not that simple.

So the problem of programming is: how do you take the process in your head and put it in the machine? And that is essentially formalization work. (no wonder there is a parallel between programs and proofs)

What I get out of IP is: with the freedom to represent things in arbitrary ways, we can more easily model the simple (but many and diverse) representations which we have in our minds: you have more freedom with which to make the virtual world mirror the mind world. All existing programming languages place restrictions on how you can represent things, whereas IP seems to be an open framework where if you don't have a suitable representation, you can make one. I suppose this could be a bad thing as far as neatness is concerned, but hopefully we can find ways to deal with that. But I am talking on the clouds here... I need to read more about IP.

So I think what we need is a new "programming meta-paradigm" (not to be confused with "meta-programming paradigm", which is concerned specifically with languages for meta-programming).

Why we don't have such a nice executable language (more formal than English, more general and more "expressive" than current languages) might have *something* to do with quirky human logic, but that by itself should be much much simpler than the so-called "AI problem". A professor of mine here seems to have very good results in explaining psycholinguistics and human reasoning with a theory based on the Event Calculus.

But I'm getting uncomfortable talking about such abstractions without having enough experience of them. I want to do some concrete work, see the limitations of the existing paradigms and then get back to exploring these ideas.

[simonfunk.livejournal.com]

You seem to be hinting at the ideas of Intentional Programming. What are your thoughts on that?

Yes, IP is after many of the same goals. When I first read the description a while back I thought it was the same thing, but then I started looking into the details and ... Well, I think they have the right goals, but haven't yet "unlearned" the mistakes of existing paradigms.

Can you guess why Microsoft aborted their IP project?

(Wasn't aware they had one, let alone aborted it.)

I think users of high-level languages such as Lisp, ML and logical languages might disagree with you. I once complained to a professor because he took points off from a Prolog assignment of mine for lack of comments [...] and he agreed with me that it was completely obvious from the code [...]

If you had changed all the names of your predicates and variables to A, B, C, D, and so on, would it have remained obvious?

Regarding "necessarily full AI" question, I believe TUNES answers it negatively, and I agree with them. But I'm an optimist by default. I never understood why software systems have to be so complex anyway. I say: if you can think about something simply and explicitly, you should be able to implement it simply. But for some reason (which I don't understand) it's not that simple.

This is a question I've been working on for the last decade. I could tell you two concrete reasons right now, but I'm in the process of implementing some related tech and don't want to "give it away" just yet... (but I'd be happy to talk about it in detail in a more private venue).

So the problem of programming is: how do you take the process in your head and put it in the machine? And that is essentially formalization work.

Here I disagree (but this is related to the items mentioned above).

I think what we need is a new "programming meta-paradigm"

Agreed!

Why we don't have such a nice executable language (more formal than English, more general and more "expressive" than current languages) might have *something* to do with quirky human logic, but that by itself should be much much simpler than the so-called "AI problem".

A decade ago I predicted general AI would first emerge in a compiler--not in some soda-spilt-on-the-circuits magic sort of way, but because I think the evolutionary pressures on compilers are pushing them in precisely that direction (more so than any other commercial application I can think of). Now I'm not so sure, since there is suddenly renewed direct commercial and academic interest in pursuing AI, but I still give it good odds.

The question you pose is about representation--forget how to do anything with it, how do you even represent it? ("It" being... knowledge in the general sense.) If you knew how to concisely write down what was in your head, it would probably be a lot easier to figure out how to compute with it (in the same ways that you do, or more). I think this question of representation is central to both IP/Tunes/etc.., and to general AI. I don't think you need to solve general AI to solve the programming paradigm problem, but I think the current, and perhaps largest, hurdle is the same for both at the moment.

continuation...

[gustavolacerda.livejournal.com]

In my opinion, the big problem is actually not so much the programming paradigms, but the openness of software to customization and to meta-programming. Radically-refactored open-source software would probably do most of what I want. But ideally you wouldn't NEED to refactor things: it would be EASIER to be program in a nice, modular way.

Human software uses multiple, diverse representations. Programming would be much easier in a language that would naturally embody these representations, but such a language cannot be neat. Languages choose neatness and thus limit the freedom of the programmer. Extrapolating from the general principle I stated about software users, this limitation is probably good for the beginning programmer (there's only so many structures to learn), but bad for the expert.

So, do we need programming languages which are self-extensible? If so, how? IP, not being a programming language itself, seems to suggest a different approach.


I have a disclaimer too: read my ideas for what they're worth. They may be completely wrong and worthless.

Perhaps you can show me what you're doing and we can collaborate through IM?