For the people at Apple involved with HyperCard, 1990 was a chaotic year. The Claris software subsidiary of Apple was almost spun off as a separate company, then pulled back in, whereupon HyperCard was transferred to Claris. As version 2 finally came out more than three years after version 1, it turned into three products, and there was confusion about the capabilities of the three HyperCards. Word got out that Claris was considering bundling a crippled, run-only version with Apple computers. HyperCard inventor Bill Atkinson left Apple to start his own company, General Magic, taking along Dan Winkler, the author of HyperTalk, among others. By the end of the year virtually none of the team was intact.
In the midst of the confusion, Bill Duvall was coaxed out of semiretirement in Idaho to direct future HyperCard development.
The choice is suggestive. Duvall is best known for producing professional development tools, including an early C compiler for the Macintosh. But his roots are in what he calls investigating "how computers can work as augmenters of human intellect." If that language sounds vaguely familiar, it's because it's the way Doug Engelbart, pioneer in human interface design, has talked about his own work for decades. Duvall comes by the phrasing honestly, having worked with Engelbart at SRI, and later at Xerox PARC. If Duvall brings to his work for Claris the interests and skills that he has acquired in his work to date, we might be tempted to draw certain inferences about the future evolution of HyperCard. Such as: HyperCard will become a more serious tool for professional software development. Such as: HyperCard's user interface will improve.
Duvall invites us to draw these inferences.
DDJ: When did you start at SRI?
Duvall: In the mid-'60s. I worked at a number of places within SRI, [including] an artificial intelligence group doing robotics, and then I went to work for Doug Engelbart at what was at that time the Augmented Human Intellect Research Center, the AHIRC, and later became the Augmentation Research Center.
DDJ: There's a legendary story about Doug Engelbart involving a brick. Is it true?
Duvall: Doug used to have some wonderful examples of the power of tools when they are companions to people. The first time you met Doug he would tell you that what people produce are products of the people and their tools, and that the tools are absolutely critical. And he'd reach behind his desk and pull out a brick with a pencil taped to it. He'd say, "Suppose this was the writing implement that you had. How would writing have evolved?"
DDJ: Very differently, I suppose. What exactly was Engelbart working on at that time?
Duvall: Doug at that time was, basically, one of two people in the world working on hypertext concepts, the other of course being Ted Nelson at Brown. I think that Doug and his group had far and away the best implementation of a hypertext system. In fact there's a videotape which I've ordered and am going to be receiving shortly of the presentation that Doug gave at the 1968 AFIPS conference. He had computers at SRI with microwave linkup to San Francisco and a terminal in San Francisco, and he went through his entire NLS system, which demonstrated linking and graphics and mixed graphics and text. It was very impressive.
DDJ: I understand you were linked up with SRI remotely, that you were an early telecommuter.
Duvall: After working there for a couple of years I was taken with the idea of getting out of the city. We were just beginning to gain some expertise in modems and things like that, so I went off to Sebastopol and we put in a "high-speed" phone line (2000 baud), and an Imlac PD81, which may have been the first personal computer in the sense that we know it today. It had a vector generator display on it and 8K of local memory and a local processor and some serial communications ports. We had that interfaced to the PDP-10 at SRI and I worked for a number of years up there doing various things for Doug.
DDJ: Such as?
Duvall: Something called the Network Information Center, which was an ARPA-net-wide repository for data and information. I designed it and set it up.
DDJ: When did you move from SRI to Xerox PARC?
Duvall: That was in the early '70s. There were a number of projects I did for them, all of them having to do with video display systems, operating systems, text editing, and the genre of office systems.
DDJ: Were you still a telecommuter then?
Duvall: At first I worked with PARC remotely, but then I moved down to the Bay Area.
DDJ: You've seen a lot of the development of the personal computer and interactive computing from the inside. You've said that there are some unsung heros.
Duvall: When you trace the roots of interactive computing as we know it today, there have been people who have been instrumental along the way, and one of them is Bill English. He was a key person at SRI, the coinventor of the mouse. Later he went to PARC and was instrumental in getting a lot of their programs going. In fact, he was probably the person who invented the desktop metaphor. I remember very clearly a meeting where that came up. Another person was Gary Starkweather at PARC, who was instrumental in the development of the laser printer. Roger Bates, one of the best hardware designers around, was key in designing some of the early personal computers. Now he's the vice-president of development at La Cie.
DDJ: When did you first get involved with the Macintosh?
Duvall: I became involved with the Mac some years before it was released when Apple asked me to write an assembly language development system for the Macintosh: an editor, a debugger, an assembler, and a linker. Which I did.
DDJ: Why did Apple come to you?
Duvall: The fellow that Apple hired to head up the Mac as an engineering manager was Bob Belleville, a person with whom I had done a lot of work at PARC. He had a need for a development system, knew that I had some expertise in that area, and asked me to come and do it.
DDJ: Early Macintosh developers may know you as the author of that development system, and more Mac developers should remember your company, Consulair, for its C compiler. But Consulair was around before the Mac.
Duvall: Consulair was first formed in the mid-'70s. Most of our work was in the area of word processing; in particular, we did a lot of work in one of the early Japanese word processors. There was a fair amount of systems work, writing operating systems. There was some language development; we did some debugging systems, things like that. In general, [it was] what you would classify as advanced development or systems programming.
DDJ: You were doing tools for programmers, then?
Duvall: We always worked on development systems, but primarily up until the early to mid-'80s we had done development systems as internal tools. In fact, we first wrote what later became the Consulair C compiler in the late '70s as a tool for programming our own projects. This was just after the publication of Kernighan and Richie's original book, and I looked around to see what was the best system programming language around, one that was going to be around for the next few years, and came to the conclusion that C was probably the best candidate. So I wrote a C compiler.
DDJ: Where did the commercial Consulair C compiler come into the picture?
Duvall: After the Mac was released to the world it became apparent that there was a need for a C language development system. Since we had a C compiler that we had been using internally for five years, it was -- I won't say it was a short step, but it was a logical step -- to put that in a form that could be used commercially on the Macintosh.
DDJ: It was well received. Didn't you get the first MacUser Editor's Choice Award for a development language?
Duvall: It's difficult to answer something like that. I, like many people, suffer from the programmer's dilemma.
DDJ: The programmer's dilemma?
Duvall: Any time you've worked on a program, you realize all of the faults in it. It's difficult to go back and look at it and say, yes, that was really important. Rather, you look at it and say, "Oh my God." But, yeah, I think it played an important role in the early development of the Mac, although clearly it was superceded by MPW and Lightspeed.
DDJ: Did the Mac seem at the time like just another development platform?
Duvall: It was not just another development platform. It would be nice to say that the philosophy and the image of the Mac were well established and that it was clear that we were setting forth on a new journey. In fact, nobody knew what the Mac was going to be. There were some good ideas, some good visions, and a lot of chaos. The project took twice as long as it should have, maybe three times as long as it should have, and the reason was just sorting out how the Mac should go, what it should look like.
DDJ: For the past few years, you've been living in semiretirement in Idaho. But you came back to Silicon Valley to be the director of HyperCard development for Claris. Why was this job so attractive? In fact, what's a developer's developer like you doing heading up development on a weekend developer's such as HyperCard?
Duvall: Well, first of all, I don't believe it's a weekend developer's tool. Part of the beauty of HyperCard is that it has the potential for being a development tool, not only for the person whose job is something other than professional development, but for the professional developer as well. For me, that's part of its intrigue. You have a broad range of skills as a professional developer. One of those skills is very detailed: assembly language, C programming, whatever. But another of those skills is higher-level programming. And if you're at all motivated to get things done, you'd much rather spend your time at the higher level than at the lower level, because you're more effective. So I view HyperCard as entirely appropriate for the professional developer.
DDJ: This from a C compiler author.
Duvall: Make no mistake: I support C as a language. I sold it professionally for a long time. But this is a question you might almost have asked an assembly language programmer 10 or 15 years ago about C. "What's a hard-nosed assembly language programmer like you doing going to a higher-level language like C?" And the answer is that you want to be able to get more done in a shorter period of time, and you want it to have less maintenance and be more transportable and more affordable, and so forth. All of those arguments go likewise between C and HyperCard.
DDJ: HyperCard 1 was never taken very seriously by professional developers, but HyperCard 2 definitely is closer to meeting professional developers' needs.
Duvall: It's a significant step toward bringing HyperCard up to a level where we can begin to view it as a professional development tool. Although HyperCard 1 did serve many people very well, from a professional development perspective some people did feel that it had kind of a hobby characteristic. HyperCard 2 begins to address some of those things. You can have multiple stacks open, multiple windows. There's the increased sophistication of the X commands, where you have message passing, and can call up an X command interactively. The thing that is intriguing to me is, where can we move it to now?
DDJ: Is that a good trajectory to sight along, HyperCard 1 to HyperCard 2, to guess where you might be headed?
Duvall: I don't know. Both HyperCard 1 and HyperCard 2 are broad enough platforms that I don't think they make a very good gunsight. What you can look at is in the history of Hypercard. In its very spirit is the concept that this is something that everyone can program in. There's a lot of momentum there, and that will carry forward. And you can look at my history.
DDJ: In hiring you, Claris appears to be making a statement about the direction in which it wants to see HyperCard taken.
Dunvall: I've been concerned with user interfaces since the very beginning, starting with the things Doug Engelbart was doing back at SRI. I've also been concerned with development systems for a long time. You can put those things together and get some sense of where we're going to go. If I were to try and summarize it briefly I'd say that the areas in which I see HyperCard advancing would be the area of usability, both for the professional and for the novice; and the area of power, in particular for the higher-end developer and the professional developer.
DDJ: Who are your developer customers today? The developer kit packaging says the product is for custom development. What about commercial developers? Do the developers of commercial stacks fall more in the realm of weekend programmers? That tends to be the general view of stackware as a market, that it's for weekend programmers.
Duvall: I don't agree with that. There is what I would call professional development going on in HyperCard in a number of areas. I made a pass through MacWorld Expo looking to see if the hand of HyperCard was up there. There were an awful lot of them. I was impressed.
DDJ: The hand of HyperCard? Oh, you mean the idle cursor, which looks like a hand. That's how you spot a HyperCard application?
Duvall: I asked myself when I came into this position, "How do I tell if this is a HyperCard product?" And the answer is, if you see a hand up there, you know it's a HyperCard product. I saw a lot of hands.
DDJ: Otherwise, I guess it could be hard to tell. With HyperCard 2, it's possible to control the menubar, and display multiple windows of different sizes. You can pretty much make your HyperCard application look like any professional Mac application. I guess you're saying these don't just look like professional applications.
Duvall: The people who exhibit at MacWorld are not weekend programmers. These are professional programmers.
DDJ: What categories do these professional products fall into?
Duvall: The obvious one is multimedia. HyperCard is very strong in multimedia; in fact, many people believe that HyperCard is the enabling tool in multimedia. It's the tool that allows the pieces to be pulled together and controlled. Education is, of course, in some ways a custom application area, but beyond that there is a tremendous number of educational products that are HyperCard-based. Something that wasn't so much visible at MacWorld, but that represents a significant customer base for HyperCard is people who are developing front ends to another system, especially in the corporate world.
DDJ: Do you see a change in this audience?
Duvall: Yeah, there's no question that, as we improve HyperCard in the way it serves the professional developer, I expect to see many more people using HyperCard as a development platform. We have to increase the power of HyperCard so that it does the things a professional developer needs; that's number one. Number two is that the professional development community has to begin to realize the power that HyperCard has. My gut feeling is that that's not going to take very long.
DDJ: Well, Claris marketing and customer support should help, because in both cases you're essentially starting from zero.
Duvall: As we get our customer support programs in place, not only will developers find themselves with a new tool but they'll also find themselves with a new set of resources for dealing with that tool.
DDJ: One "resource" that developers would surely like to have is the ability to port stacks easily to other platforms. It's well known that Claris is looking at the multiplatform problem very seriously. But taking HyperCard multiplatform would seem to involve some difficult problems.
Duvall: Absolutely. This is an issue that we're looking at right now. If we can solve the issues, there's an incredible amount of power there. The easiest way to realize that power is this: We talked earlier about going from assembly language to C; well, from C to HyperCard is a least as big a step. Now, if you look at the platform independence you gain in going from assembly language to C, you probably gain that much and more in going from C to HyperCard. It could be an immensely important step.
DDJ: But difficult. I see the problem presented by external commands. How big a problem would it be to produce a Windows version of HyperCard?
Duvall: There are some immensely difficult problems to solve. If you "solve" the multiplatform problem for a development system like HyperCard, then you may to a large degree have solved the multiplatform problem, period. I'm not so naive as to believe that in one fell swoop you can solve that problem. We're looking at the possibilities, trying to plot a path through that morass to a point where you don't have to worry about the platform that you're programming on.
DDJ: There's also a marketing challenge. At least one competitor is being bundled with Windows.
Duvall: Um-hm.
DDJ: Even though you're taking on an existing, well-known product, you do have the opportunity to start pretty much from scratch in building a team. Do you have a strategy for that? Do you have a philosophy of software development?
Duvall: Yes, I do. There are a couple of things that I feel are important. One of them is that software is best done by small teams. I'm not a proponent of the software factory. Then there is what I would call an opportunistic approach to software; this is one of the reasons you use small teams. Software is sufficiently complex that you can't go into a large project understanding everything you need to understand to complete it. That's just the nature of the beast. No effort to do that has ever been successful. My philosophy is that you go into a project with an understanding of where you want to go, a basic understanding of how you might get there, and an awareness of what the opportunities are along the way. That way, as things change, you can take advantage of opportunities to help you get to where you want to go. That's reflected in the way I like to structure software projects, which is to set a fairly long-term vision two or three years out, or even longer in some cases, and then in terms of products to have shorter-term product releases, say once a year. This basically gives you checkpoints where you can look around and say, "Where am I, where are the opportunities now?" Yet you still have that long-term vision.
DDJ: Are there things you've picked up along the way that have stayed with you?
Duvall: I think the thing that you pick up along the way as much as anything is an image of how things might be.
DDJ: Can you pin that down a little more?
Duvall: It's difficult to define. When I go to work on a very complex project the first thing I do is to go in and start handling the pieces. I would love to say that I get a piece of paper out and do a clear, concise analysis of the problem. I don't. What I do is I pick a corner of it and I fiddle with the corner, and then I pick another corner and I fiddle with that. And I find that if I feel the pieces enough and I hold the pieces and manipulate the pieces, then sooner or later not only does the problem become clearer but a path to the solution becomes clearer. There's this way of looking at things that you get by feeling various parts of the problem.
DDJ: And the "image of how things might be"?
Duvall: Well, I think you can take that same concept and spread it over time. As you work on different projects, these projects are all a part of a larger problem, so you gain a sort of intuition, or way of looking at things, or a feeling for how things might be.
DDJ: It sounds like you're defining experience.
Duvall: I'd say that this is the thing you carry forward most. In my case, the pieces that I've dealt with most have been in the area of how people and computers can interact; how computers can work, as Doug used to put it, as augmenters of human intellect. So over the years, that's what I carry forward. When I see a problem or a possibility, that's the area that I think in.
DDJ: Are there values you keep in mind when designing tools for people?
Duvall: It's a wide-open game.
DDJ: No general rules? No advice for the young developer?
Duvall: If I were to give people advice, I'd say, first of all, understand whether you're trying to solve a problem or trying to investigate an area. If you're trying to solve a problem, try to understand what that problem is and make sure that you're doing something that makes sense toward trying to solve that problem. If you're not trying to solve a problem, but are just trying to investigate an area, accept that and don't try to turn it into something that it's not. That's a very general rule.
DDJ: Do you have a ten-year vision for Bill Duvall?
Duvall: Nope. For myself as well as my work, I tend to look about two or three years out. I'm perfectly happy looking a couple of years ahead and saying, Where we going next?
Copyright © 1991, Dr. Dobb's Journal