Please consider a donation to the Higher Intellect project. See https://preterhuman.net/donate.php or the Donate to Higher Intellect page for more info.

Interview with Bill Joy

From Higher Intellect Vintage Wiki
Jump to navigation Jump to search
   The following interview is taken from the August 1984 issue of Unix
   Review magazine (which briefly changed its name to Performance
   Computing, but then dropped out of print and went to an online-only
   format at www.unixreview.com). Permission has not been given to copy
   this, so you should only use it for your own personal or scholastic
   purposes. Do not distribute it without obtaining permission from the
   publisher of Unix Review.

   Actually, I tried to get permission to distribute this with elvis, but
   the publisher wasn't sure who owned the copyright. Since they weren't
   sure it was theirs, they didn't feel they could give me permission.
   I've decided to make this available on my web site until somebody
   steps forward to claim it as theirs.
     _________________________________________________________________

                            Interview with Bill Joy

   By Jim Joyce

   Bill Joy is one of those rare people who can carry on a rapid-fire
   technical conversation while coding at the keyboard. His seemingly
   inexhaustible energy has produced the C shell command interpreter, the
   vi screen editor and the Berkeley paging kernel, among other
   accomplishments. UNIX REVIEW sent Jim Joyce to Sun Microsystems, where
   Joy is Vice President in charge of Research and Development, to
   capture some of this energy. 

   REVIEW: How did vi come about? 
   JOY: It's an interesting story. I came to Berkeley in '75 as a theory
   student and got involved with Mike Harrison working on general
   context-free parsing algorithms, so I tried to write the thing in
   Pascal because Pascal had sets, which Ken Thompson had permitted to be
   of arbitrary length. The program worked, but it was almost 200 lines
   long - almost too big for the Pascal system. I talked to Thompson to
   figure out how I could make the Pascal system handle this program.
   Chuck Haley and I got involved in trying to make the Pascal system
   handle it, but the thing was wrong because it was building the entire
   thing in core. So I got sucked in, got department help, and built some
   hope of receiving enough support eventually to pay for this program to
   work under Pascal.

   But while we were doing that, we were sort of hacking around on ed
   just to add things. Chuck came in late one night and put in open mode
   - where you can move the cursor on the bottom line of the CRT. Then
   George Coulouris from Queen Mary College came to Berkeley and brought
   along this thing called em, which stood for "editor for mortals." It
   had two error messages instead of one. It had a prompt, and its own
   strange version of open modes done for ITT terminals, which really
   didn't work very well on ADM-3As.

   So Chuck and I looked at that and we hacked on em for a while, and
   eventually we ripped the stuff out of em and put some of it into what
   was then called en, which was really ed with some em features. Chuck
   would come in at night - we really didn't work exactly the same hours
   although we overlapped in the afternoon. I'd break the editor and he'd
   fix it and then he'd break it and I'd fix it. I got really big into
   writing manual pages, so I wrote manual pages for all the great
   features we were going to do but never implemented.

   Eventually Chuck graduated with his Ph.D. for his part of the Pascal
   system. After he left, there was ex Version 0.1 at the Computer
   Center. There was a version of the editor from EP016, which stood for
   September 1, '76, the date that the binary was created - after which
   we promptly lost the source because we were making so many changes and
   didn't have SCCS.

   Really, what started it all was that we got some ADM-3As to do screen
   editing. I remember right after Carter got elected, I was sitting in
   my apartment in Albany, CA, on a Saturday listening to people call
   Carter and ask stupid questions while I designed the screen editor.
   That dates it: it was probably '76. It was really a consequence of our
   initial frustration with Pascal. It went on from there. I stopped
   working on it whenever they made the reference cards - '78 - '79 - and
   I really haven't worked on it for five years.

   Mike Horton brought his editor along from Bell Labs called hed for
   "Horton's editor." He was disappointed when vi won out over it. But vi
   had momentum with the local users - and Mark, somewhat out of
   frustration, went out and actually supported vi. That was nice,
   because I didn't have the patience to do it anymore. Just putting the
   termcap entries in that people would mail me would take hours a week,
   and I was tired after three or four years.

   REVIEW: Didn't Bruce Englar implement the count fields feature? 
   JOY: Bruce suggested that. At one point there was an acknowledgment
   section in the documentation for the editor that mentioned all the
   people who had helped - I don't know if it's still there in Volume 2.

   A lot of the ideas for the screen editing mode were stolen from a
   Bravo manual I surreptitiously looked at and copied. Dot is really the
   double-escape from Bravo, the redo command. Most of the stuff was
   stolen. There were some things stolen from ed - we got a manual page
   for the Toronto version of ed, which I think Rob Pike had something to
   do with. We took some of the regular expression extensions out of
   that.

   REVIEW: What would you do differently? 
   JOY: I wish we hadn't used all the keys on the keyboard. I think one
   of the interesting things is that vi is really a mode-based editor. I
   think as mode-based editors go, it pretty good. One of the good things
   about EMACS, though, is its programmability and the modelessness.
   Those are two ideas which never occurred to me. I also wasn't very
   good at optimizing code when I wrote vi. I think the redisplay module
   of the editor is almost intractable. It does a really good job for
   what it does, but when you're writing programs as you're learning...
   That's why I stopped working on it.

   What actually happened was that I was in the process of adding
   multiwindows to vi when we installed our VAX, which would have been in
   December of '78. We didn't have any backups and the tape drive broke.
   I continued to work even without being able to do backups. And then
   the source code got scrunched and I didn't have a complete listing. I
   had almost rewritten all of the display code for windows, and that was
   when I gave up. After that, I went back to the previous version and
   just documented the code, finished the manual and closed it off. If
   that scrunch had not happened, vi would have multiple windows, and I
   might have put in some programmability - but I don't know.

   The fundamental problem with vi is that it doesn't have a mouse and
   therefore you've got all these commands. In some sense, its backwards
   from the kind of thing you'd get from a mouse-oriented thing. I think
   multiple levels of undo would be wonderful, too. But fundamentally, vi
   is still ed inside. You can't really fool it.

   Its like one of those pinatas - things that have candy inside but has
   layer after layer of paper mache on top. It doesn't really have a
   unified concept. I think if I were going to go back - I wouldn't go
   back, but start over again.

   I think the wonderful thing about vi is that it has such a good market
   share because we gave it away. Everybody has it now. So it actually
   had a chance to become part of what is perceived as basic UNIX. EMACS
   is a nice editor too, but because it costs hundreds of dollars, there
   will always be people who won't buy it.

   REVIEW: How do you feel about vi being included in System V? 
   JOY: I was surprised that they didn't do it for so long. I think it
   killed the performance on a lot of the systems in the Labs for years
   because everyone had their own copy of it, but it wasn't being shared,
   and so they wasted huge amounts of memory back when memory was
   expensive. With 92 people in the Labs maintaining vi independently, I
   think they ultimately wasted incredible amounts of money. I was
   surprised about vi going in, though, I didn't know it was in System V.
   I learned about it being in System V quite a while after it had come
   out. They had this editor, se, but I guess it failed.

   I think editors have to come out of a certain kind of community. You
   need a cultural context. As you mentioned before, Bruce Englar thought
   of a number of things, Dick Fateman contributed work to the cursor
   position after the join command - little things like that. There were
   just dozens of people involved, but if you are in an environment where
   management says, "This person shall do an editor," it doesn't
   necessarily work. It's funny, the politics at Bell Labs.

   REVIEW: You had said, when you were giving a demonstration earlier
   today, that when you are on foreign systems you use ed. 
   JOY: That's right. Absolutely.

   REVIEW: You don't even try to use vi? 
   JOY: I'm used to having a 24-line terminal with no ability to scroll
   back. The reason I use ed is that I don't want to lose what's on the
   screen. I used to have a Concept terminal which had eight pages of
   memory, like a mini-version of a window system. I just don't like to
   lose what's in the window. I'm looking forward to the editor that's
   going to be embedded in the window system Warren Teitelman is working
   on. Having editing functionality everywhere would be great in the same
   sense that it would be nice to have history everywhere.

   REVIEW: So there will be a history mechanism in the new editor? 
   JOY: I would be surprised if there wasn't. Warren basically invented
   all those things. He's very keen on that. I tried to use EMACS and I
   liked it. The problem was I spent all my time programming it because
   it was improving so fast that my programs kept breaking. I got tired
   of maintaining my macros so I guess I'm looking forward to an editor I
   can learn and then forget about.

   I started to write a new editor not too long ago and had it about half
   done after two days. It was going to have almost no commands, but,
   instead use what's basically the smalltalk editing menu, a scroll bar,
   and a thumb bar. Lines just went off the right and if your window
   wasn't big enough - too bad - it just threw them away. There was going
   to be an edit file, and a store and read file. That was it.

   It was called be. I'll let you guess what that stands for. It actually
   stands for about eight different things.

   REVIEW: Bill's editor? 
   JOY: That's one of the eight. It's also the English verb "to be"
   because it is. There are six more. I got tired of people complaining
   that it was too hard to use UNIX because the editor was too
   complicated. Since I sort of invented the editor that was most
   complicated, I thought I would compensate by also designing the editor
   that was most simple. But I got distracted. If I had just spent
   another day on it... I could actually edit a file on it. I actually
   used it to edit itself and scrunched the source code - sort of old
   home day, because we used to do that all the time.

   I had threatened to remove all the copies of vi on January 1 of this
   year and force people to use be. I don't think it would have worked,
   though, because I don't know any of the root passwords here anymore.
   These editors tend to last too long - almost a decade for vi now.
   Ideas aren't advancing very quickly, are they?

   REVIEW: So you use Interleaf now? 
   JOY: I use Interleaf for all my documentation. When I'm writing
   programs, I can type them in half the time with cat because the
   programs are six lines - a #include, main and a for loop and one or
   two variables. I actually use vi for editing programs. James Gosling
   did a really nice editor as part of a project at Carnegie Mellon
   University which is AWYSIWYG: Almost What You See Is What You Get.
   It's also a program editor built into the window system he's working
   on. I think that will ultimately replace vi.

   Interleaf is very nice. I expect there to be a lot of competition for
   programs like that. I don't expect that to be the only one. By the end
   of next year there will be half a dozen UNIX-based integrated office
   systems. Interleaf is based on the formatting process.

   I think you'll see others focused on database, calendar management,
   mail, and spreadsheets - you need all those things to have a generic
   office automation application. I don't really know who is going to
   win. I know about a few that are unannounced, but it's not clear which
   is the mode desirable. None of them are open, really. None are as
   programmable as UNIX. You really can't go in and add things that you
   need. That lack of programmability is probably what ultimately will
   doom vi. It can't extend its domain.

   REVIEW: Some would argue that vi's domain is already far too extended.
   JOY: That's probably fair, too. That's why it's so complicated, and
   has left and right parentheses commands. You start out with a clean
   concept and then sort of accrete guano. It lands on you and sticks and
   you can't do anything about it really.

   REVIEW: What is it that Interleaf offers you that EMACS doesn't? 
   JOY: I can just look at my screen, and when I print it off, it's the
   same as it looks on the screen. It is formatted, and I'm tired of
   using vi. I get really bored. There have been many nights when I've
   fallen asleep at the keyboard trying to make a release. At least now I
   can fall asleep with a mouse in my hand. I use the Xerox optica mouse
   instead of the other one because it is color coordinated with my
   office. Did you notice? I prefer the white mouse to the black mouse.
   You've got to have some fun, right?

   This business of using the same editor for 10 years - it's like living
   in the same place for 10 years. None of us does it. Everyone moves
   once a year, right?

   REVIEW: What about Documenter's Workbench and Writer's Workbench? 
   JOY: I used to use diction. I wrote some papers for some conferences
   and used diction on them. But with Interleaf I don't even have a spell
   program.

   REVIEW: Why? 
   JOY: Don't need one. Well, I guess I do. I could use one. It just
   doesn't have spell.

   REVIEW: You don't use spell? 
   JOY: I don't spell things wrong. Except t-h-i-e-r. But no, I don't
   generally have trouble with spelling mistakes. What spell did for me
   was catch errors introduced by the substitute commands. With sentences
   in ed or something, you only see one line, and substitutes can be done
   wrong. With spell, you can catch fuzzballs that show up in your
   document. But diction is funny. I didn't like reading documents when
   diction got done with them.

   REVIEW: Did you use suggest? 
   JOY: Yes, I've tried some of those things. I don't like reading things
   that have been heavily dictionized because they don't flow. I would
   like to have an expert system that would help me but I don't think
   those (style and diction) are close enough. I don't need double or
   spell either. I don't think any of those can help me write better or
   be better organized. I think an editor with a hierarchical sort of
   structure where I could look at the section outlines or make
   annotations in the margin would be helpful. Post-it notes are perhaps
   the greatest technological thing in the last 10 years. An electronic
   analog of the post-it would be wonderful so you could scribble on the
   document. I find much more of a need to just doodle on the screen than
   to run these programs. I think some of these tools are overkill.
   Writers Workbench is fine if you're stuck with troff and nroff.

   I've never used pic. Some people have done great stuff with it, but it
   is too bad that instead of allowing you to think pictorially and draw
   pictorially, it forces you to translate images back into words and
   then compile back. That seems like the Linda Ronstadt song, "You're
   Taking the Long Way Around."

   REVIEW: You've already mentioned the mouse. What other hardware do you
   see for the documenter to make things better? 
   JOY: I think the Macintosh proves that everyone can have a bitmapped
   display. The fundamental tension in UNIX that I think AT&T doesn't
   understand is that everyone is going to have a bitmap. Bitmap display
   is media compatible with dot matrix or laser printers. With a mouse to
   point with, you've got sort of a baseline of facilities around which
   you can build a document environment. I think you also need a
   full-page display. I think we'll have to wait for Big Mac from Apple,
   maybe two years away, to get full-page display. I think a lot of the
   implications for developers is that this kind of development has to
   come from the low end, the Volkswagen of the document industry.

   Document preparation systems will also require large screen displays.
   Something like the Sun is what I think you need - a 19-inch screen
   where you can see a full page and be able to put up screens and menus
   with something that's fast enough to allow you to scroll at a
   reasonable rate. We don't know how to do that without a mouse, really.
   All of the good research was been done using a pointing device.

   Touch finger, joystick, voice input are all either too late or too
   early.

   REVIEW: Voice is too early and touch is too late? 
   JOY: I'm not sure voice yet works. I can't talk clearly enough. There
   was an editorial in Datamation about why the UNIX user interface is
   horrible. It was pretty poor, but the author does have some good
   things to say. I think he says something about people buying stoves.
   If you look at stoves and the way knobs are arranged. You'll see why
   it is that when you walk up to a random stove you can't tell which
   knob is going to turn on which burner. It's really stupid. There is no
   sensible way to put the knobs on the front to tell you. Some stoves
   have the knob in the center right next to the burners. That makes a
   lot more sense.

   The point is that you want to have a system that is responsive. You
   don't want a car that talks to you. I'll never buy a car that says,
   "Good morning." The neat thing about UNIX is that it is very
   responsive. You just say, "A pipe to B" - it doesn't blather at you
   that "execution begins," or "execution terminated, IEFBR14."

   The trouble is that UNIX is not accessible, not transparent in the way
   that Interleaf is, where you sit down and start poking around in the
   menu and explore the whole system. Someone I know sat down with a
   Macintosh and a Lisa and was disappointed because, in a half hour, he
   explored the whole system and there wasn't as much as he thought.
   That's true, but the point is in half an hour, almost without a manual
   you can know which button to push and you can find nearly everything.
   Things don't get lost. I think that's the key.

   Systems are going to get a lot more sophisticated. Things will tend to
   get lost unless the interfaces are done in the Macintosh style. People
   who use these machines may run applications but won't necessarily be
   skilled at putting applications together. A lot of these people won't
   even have access to the underlying UNIX system.

   The fundamental tension in System V is that it is oriented toward a
   character-mapped environment. The software you have to build is
   completely different. You don't assume a mouse and you don't assume a
   reasonable-sized display. You just forget it. Those are two different
   problems.

   It's ultimately the media and the set of peripherals that you have on
   your machine that affects what the user sees. I don't think the
   Macintosh software is of any value. I'm not even sure it can be taken
   to a larger machine. You can spend your time making software small, or
   you can spend time making it functional and sensible. You can't do
   both. I think there is an ax that is going to chop the two apart.

   You'll see WordStar, the database sort of word processing environment
   that doesn't have bitmaps, and you'll see the ones that do, and the
   difference between the two will be like night and day... The
   Macintosh's days are numbered. Non-bitmap machines have no future.
   Personal laser printers will see to that. The days of non-raster stuff
   are numbered, though sheer momentum will carry it to the end of the
   decade. These things come and go.

   We went from printing terminals to dumb CRTs to smart CRTs, with
   tangents off toward storage display tube displays and black and white
   bitmaps. I think the days of even black and white bitmaps are very
   numbered. Color will take care of that. And then, with the demise of
   the last vacuum tube, which is the CRT, and with the advent of thin
   film transistors, which will be flat displays, it will all be color.

   Black and white bitmaps supplanting CRTs make for a small wavelet, but
   if you don't see that little wavelet, you're really going to get hit
   by the tsunami that is to come.

   I've wiped troff off my machine, and I'd rather live in the bitmap
   world than in the spell/diction world. I want to get mud in my face
   and arrows in my back with the bitmap.

   REVIEW: The basic UNIX tools that can be used for documentation are
   plentiful but misunderstood. For example, the use of make to do
   document control. What are your views on that? 
   JOY: I think make is the program that causes people to write the
   things down that formerly were scribbled on the wall. It's sort of the
   graffiti recorder. That's the wonderful thing about it. People don't
   use SCCS and make enough. The people here doing documentation now use
   SCCS, mostly because I put all the documentation under SCCS and sort
   of twisted people's arms into using it.

   REVIEW: Real programmers use cat as their editor. 
   JOY: That's right! There you go! It is too much trouble to say ed,
   because cat's smaller and only needs two pages of memory - plus you're
   not likely to get swapped out. That's why ed didn't prompt, you know.
   The performance of the system was just horrible. It would swap things
   out randomly and do all sorts of things. In ed you might type "a", but
   have no idea how far behind the system was. And it didn't matter, and
   long as it didn't get more that a few hundred characters behind and
   start throwing lines away without telling you.

   Typically it wasn't that bad. If it had been prompting, you would have
   hit carriage return and wait for the prompt, and it would have taken
   three seconds to comment. That's something we noticed when we put em
   up. We put in the prompt and suddenly realized it had to go through
   the operating system.

   I think UNIX has lived with grace for years. We've had the grace of
   people not being able to tell when the system was doing a bad job of
   scheduling the CPU. Now we can't hide behind time-sharing.

   I think SCCS is misunderstood. I think make has never had a good
   document. Henry McGilton just finished rewriting a troff manual for
   the first time. Since troff has never really had a manual, he had to
   sit down and figure out what some of these things meant - backslash,
   right adjusting tab stops. No one ever really wrote a good manual for
   it - partially because Joe Osanna, who wrote troff, died in 1976. The
   program was written in assembly language, then translated line for
   line in C and it's all done with global variables - it's an ancient
   program. It's basically an accretion of all this completely unrelated
   stuff on top of a very, very small base. It's not surprising that
   people don't understand it.

   When you look at the manual, tbl looks really good but you sort of get
   it right by iterative approximation; it's very difficult to get a
   good-looking table. I think the thing that's really missing is that
   none of these things help you with graphics or graphic design very
   much. I want a program that helps me learn how to draw and learn how
   to paint. Some attempt is made at that by pic but it's solving it in
   the wrong domain. I don't want to type "arc from A to B." I wouldn't
   mind saying that, though. Maybe that's the answer: talk to the
   program.

   I think the hard thing about all these tools is that it takes a fair
   amount of effort to become proficient. Most people are lazy. I'm lazy.
   I'm enjoying using other people's software now. At Berkeley for so
   long, all the software we were using was stuff I had something to do
   with and that wasn't fun. I have fun with Interleaf because if it
   crashes, I don't feel responsible. I've even divested myself of
   responsibility for the operating system. I don't have to worry about
   that crashing. Editing without guilt.

   REVIEW: All the directions you were talking about really assume a lot
   more compute power than we have at present. 
   JOY: I think that to make that assumption is bad. All projections that
   I see have memory going to $300 a megabyte by 1989. Soon the processor
   will be $50, and you'll be able to use it to refresh video. There are
   too many good things you'll be able to do with this stuff for it not
   to be available cheap. The real cost is very low. One has to wonder
   what software is going to be worth, too. It's going to be produced in
   such enormous volume.

   When can that stuff go portable? You don't really want to have a
   telephone in the office or be tied to an office. You'd like to have
   the office with you and the phone with you. I want to be able to turn
   the phone off, thank you. I think that's going to require very
   different technology.

   REVIEW: You mention everything but disks. 
   JOY: You might want to page over satellite telephone... Page fault,
   and the computer makes a phone call. Direct broadcast or audio disk -
   that's the technology to do that. It's half a gigabyte - and you get
   100 kilobyte data rate or a megabyte or something. I don't remember.
   You can then carry around with you all the software you need. You can
   get random data through some communications link. It is very like Dick
   Tracy. Have you seen these digital pagers? You can really communicate
   digital information on a portable.

   I don't think you need to have a disk with you. There are so many
   people who believe that you need to have a disk that you'll be able to
   have one because they'll make it cheap. That's the way things work.
   It's not what's possible but what people believe is possible. That's
   what makes imagination so wonderful, right? Silicon is such an
   incredible amplifier. If you can figure out what should be and you get
   people to believe you enough that they will give you money, you can
   almost make it come true. That's why bubble memory never made it.
   People didn't believe it was the right thing to do. But there's
   nothing wrong with bubble memory.

   There's an incredible amount of momentum in the technology. Look at
   the momentum in vacuum tubes. It's all an economy of scale. There's an
   incredible momentum in UNIX. It really doesn't matter what UNIX is
   anymore. It ceased to matter when the vendors started adopting it.
   People used to call me up saying, "I don't know what UNIX is but I've
   got to have it! How do I get it?" It's at that point now.

   REVIEW: Like designer jeans? 
   JOY: I don't buy designer jeans - well, what I'm wearing aren't bad
   jeans. They're my burlap sacks. Wrinkles are in, you know.