Quick
index
main
eev
eepitch
maths
angg
blogme
dednat6
littlelangs
PURO
(C2,C3,C4,
 λ,ES,
 GA,MD,
 Caepro,
 textos,
 Chapa 1)

emacs
lua
(la)tex
maxima
git
agda
forth
squeak
icon
tcl
tikz
fvwm
debian
irc
contact

Why Users Should Not Exist

(Notes (2004apr01) about the origins of this text and whether I'm going to finish it or not. The original text starts at the "(1)", below).

In mid-2000 (I think) RMS gave a talk in Campinas, SP, Brazil; that's not very far from where I live, and I went there to meet him in person and to see what the Brazilian Free Software community was like. I was then in the process of making eev an official part of GNU Emacs, and I had just signed the papers transfering eev's copyright to the FSF.

After the talk I went to him to chat about the changes that he asked me to do on eev, as he had been too brief in the mails he had sent to me. Then he told me he thought eev should be split into several packages according to functionality -- one for hyperlinks, another for saving scripts, etc -- and this request I thought it was fair, even though some of eev's functions were hybrids and would be difficult to classify; but then he said that I should provide another interface for eev's hyperlink scheme, as they're implemented by inserting Lisp code in text, and "users should not be forced to see Lisp". That pissed me off SO MUCH that in the space of a few seconds afterward he had decided it was impossible to talk to me, as I should be some kind of madman, and he cut the conversation and tried to join another group.

What I said in those few seconds included the fragment: "and, besides, users should not exist". I was using a very precise definition of "user" that I had constructed over several months of heated conversations with colleagues, on how the innards of most modern software are so complex and boring they frighten people off; it is that that creates what I was calling "users". Unfortunately I wasn't able, in those few seconds, to make clear to RMS what are these "users" I was talking about.

I wrote most of this text a few hours later, in the bus station and in the bus, coming back from Campinas to Rio.

Now it's been years from that and I still believe that Emacs, with its interface that allows people to embed arbitrary pieces of Lisp code in text, is the best interface we have around -- better than GUIs, better than command-line, better than SmallTalk, better than Forth -- and that Emacs+Lisp+eev can be a cure for "users" and several other computerphobias and informationphobias. And that's what the Eev Project is about.



1)

When I started using computer in the mid-eighties they were sold as machines that could be programmed to do anything, and they were a lot of fun.

Now computers are generally considered as being for office work, or for playing games, or for communicating via the Internet.

Programming is now regarded as a difficult thing that is only done either by professionals or by several classes of weird people: hackers, script kiddies, hobbyists, etc.

The worst thing is that we now have hordes of people that will proudly declare that they are "only users!", and that they only want to know the bare minimum; and we can't just blame them, because they have been faced with programs and books and a whole mentality that does not encourage them to learn more -- except maybe to become "more qualified", and thus getting better jobs.

2)

The point of this essay is that it should be very easy to use programs while knowing very little about them, but it should be also easy and natural to learn more and more about those programs, until knowing most of what happens in the machine. It is in this sense that I say that "users should not exist": software for "users" is software that hides its details artificially; it would be better to offer to show the details in an elegant way, maybe with a warning saying "this may be too technical!", and with pointers to "light" explanations and also to the real, "heavy" information (the source code, say).

Much of the software of today have layers that were introduced to keep the users isolated from the details. Everything that is meant for users is accessible through clicking, say (in the case of windowing systems); the rest is just for hackers. Unfortunately, users often perceive that these programs, though apparently simple to use, are complex inside, and sometimes a bit unpredictable. The complexity is not well-hidden enough, and maybe there are other ways to deal with it besides trying to hide it at all costs.

3)

People now tend to think that there is a hard-to-cross barrier between knowing little and knowing much, and most current software reinforces that idea; however, some features of the command-line interfaces found in *NIX systems (surprise!) can be used to break that barrier. It shocking to see how little attention this way of combining these features -- that technically is very simple, and several people may have reinvented that themselves without giving much importance to it -- has received; let's see what happens when it gets more divulgation.

4) (interfaces)

Computers are much more powerful today than they were in the eighties, and so one might think that now they have to be much harder to use and understand... But of all the thought that has been invested in computers in the last, say, 20 years, much has gone to interfaces: that is, how to let computers have more pre-programmed capabilities and at the same time keep them simple to use, maybe even simpler than before, instead of letting them become unbearably complex. I see three main tendencies on this; note that what I'm discussing is the "interface" between the user and all the knowledge that went on making the computer and its programs, not only the interface between the "end-user" and the machine that edits text and schedules appointments. Also I'll use the term "knowledge" as if denoted a concrete, desirable quantity, like "food" and "money"; I'm aware that this may sound a bit mystical sometimes, but it will make several ideas much easier to express.

4.1) Windowing systems

All the windowing systems in wide use today are descendants (of bastard lineage) of SmallTalk; but while in SmallTalk the philosophy was that everything should be not only easily accessible but also easily programmable, in the current windowing environments this has been reduced to the idea that everything that exists can be accessed through clicking... I have heard that on the MacIntosh it was possible to automate interactions in a way similar to the one I will describe soon, but I haven't got the details; and, anyway, I have use windowing systems very little because I got addicted to the "console+pipes" way, and so I'm not the right person to say.

4.2) Forth systems

Some people have been able to reduce drastically the complexity of computer software and to create environments that are sufficiently powerful, and yet simple enough that it is not impossible (or even very difficult) to understand them completely; the trick is to use a programming language called Forth that allows for very compact programs, clean design, quick debugging, high speed, and many other wonders. I haven't been using much Forth lately because I didn't like any of its implementations for *NIX... [and the community issue.] see http://www.ultratechnology.com/.

4.3) Console mode (and pipes)

Most satisfactory to me.

The underlying model of a computer: in a computer there are huge loads of information stored, in many formats; you will often need to find some piece of information, convert it from one format to another and probably also transform it in other ways, and use it somewhere else. As new formats appear all the time, this requires a very modular system, plus tools to help you find your way between all the existing modules.

4.3.1) Shells

(show a pipe, say that the commands may come from scripts. Temporary script files, and sourcing.)

4.3.2) Emacs

(Its lisp is accessible, and can be used to program/test new extensions, to open new files (hyperlinks)!, and even to invoke a shell in a buffer; the invoked shell acts as a sort of "a ghost user" that is also writing to the buffer. Debuggers can also be run in a similar way, and invoked by hyperlinks.)

4.3.3) Expect

(Emacs can control shells, debuggers and other programs, by controlling their I/O, like telnet and ssh do; Expect is a language to let we program that. eeg.)

5) The eev/eeg interface

Write for yourself. Put in a public place. Refer to parts, in, e.g., IRC sessions. If we want to make the information available then it is conceivable that in some time (example: twu) putting things in homepages will be common. Note that I'm not saying only "you should make your information public"; I'm saying "you should have access to the notes of the people that want to make them public".

6) Security and "hackers"

The news are always reporting cases of "hackers" that invade other people's machines. There are many definitions for the term "hacker", and all of them are related either to knowing something very well of to doing something to gain knowledge; but in what sense is it that the knowledge that those "hackers" (more correctly: "crackers") want is stored outside their own machines, and can only be gotten by illegal means?

Most people still don't know that if you install a GNU system in your machine you'll have at your hands the work of many thousands of people who have struggled to make [easiest, clearest, most convenient, most functional, yet open, not a product, there's not an artificial distinction between the makers of the system and the users]

There's still a gap between those who have more experience and those who still don't; there is even in some circles a widespred belief that it would be impossible to remove this gap [link to "larval stage"]. Well, there are no word of god

A way of getting rid of crackers: reformulate society

7) Why am I doing that

My graduation/no access/outcast/social skills/e-mail doesn't work (people don't answer/I haven't answered sometimes).

The "us and them" mentality, in knowledge, personal relationships (gender issues, mainly).