A DE FACTO ANTI-STANDARD FOR CYBERSPACE Randal Walser Autodesk, Inc. A speech at Meckler Virtual Reality Conference Fairmont Hotel San Jose, California September 23-25, 1992 (To appear in conference proceedings) INTRODUCTION When I spoke at this conference two years ago I presented a vision of cyberspace as an emerging new medium and I sketched out some ideas for what it would take to foster a cyberspace industry. I compared and contrasted cyberspace with other media, particularly film, the theatrical stage, and the computer desktop. I pointed out that the impediments to a cyberspace industry were not primarily technical, but rather economic and conceptual. I felt it was vitally important that we understand the unique qualities of cyberspace, and then apply technology in a way that would bring out and support those qualities. The problem, however, was that we were caught in a classic chicken and egg situation: we couldn't understand cyberspace without experiencing it directly, yet we couldn't do that without building an underlying technology. I suggested that the way out of the dilemma was to give up all ideas of creating the ultimate cyberspace system, and concentrate instead on the development of systems and tools that would foster widespread experimentation, both with cyberspace and with alternative cyberspace systems. Toward the end of my talk I briefly mentioned Trix, a programming system, under development at the time, that would give programmers unprecedented power and freedom to explore alternative evolutionary pathways. Today I'm here to give you an update on Trix, particularly as it relates to a cyberspace industry. Time is limited, so I'm not going into great detail about what Trix is -- that's really a subject for a more technical conference. Rather, today, I want to explain why Trix is; that is, the philosophy underlying it, because Trix is a system that's specifically designed for application in the early stages of the industry. Before proceeding, so there is no misunderstanding, let me emphasize that Trix is not, itself, a cyberspace system. Nor was Trix ever intended to be the definitive cyberspace programming language. Rather, Trix is intended to be a thoroughly open technology for experimenting with cyberspace and devising techniques and languages peculiar to cyberspace. Most of all, it was designed to be instrumental in the emergence of a cyberspace industry. Since Trix was developed at Autodesk, in order to further Autodesk's initiative in cyberspace, it may seem that I'm using this occasion inappropriately to promote Autodesk's interests. While it is true of course that the motives for developing Trix coincide with Autodesk's motives with regard to cyberspace, I hope you will see that my comments bear on the concerns of any company wishing to play a role in the emerging industry. In any case, I can assure you that my purpose here is not to sell Trix. In fact Autodesk has no immediate plans to market Trix, though we most certainly plan to market a cyberspace developer's kit that includes essential cyberspace technology. FOUR YEARS AGO IT SEEMED EASY Four years ago it seemed easy. John Walker, the founder of Autodesk, had just written "Through the Looking Glass," the classic white paper in which he put cyberspace in historical perspective. The idea of cyberspace, or of something like it, had been bandied about by hackers for years. A score of pioneers had already demonstrated simple spaces, but they were the avant garde. To most people, cyberspace was the stuff of science fiction. Walker, however, was serious about making it serious business, and he argued convincingly that cyberspace was not only possible, but that it was a natural and inevitable progression of computer technology. Unlike many other new fields, there were few if any technical barriers. The ingredients of cyberspace, both hardware and software, were well developed and readily available. It remained simply to package them in a new way, to support the new medium. Walker challenged Autodesk to take the lead in cyberspace, to have the "... vision to see the opportunity, the courage to break new ground, the decision to do it, and the will to see it through." Autodesk accepted the challenge, formed a project, and demonstrated a working system, based around ordinary personal computers, in just over four months. I was a member of that first cyberspace project at Autodesk, and I can tell you those were intense and exciting times. Our mission, from the beginning, was to promote the emergence of a cyberspace industry, but at first we really weren't sure cyberspace would "take." All doubt was quickly removed, however, when we demonstrated our prototype at a trade show in Anaheim, and shortly thereafter at SIGGRAPH in Boston. The response, to put it mildly, was overwhelming. The crowds were gigantic, and it seemed they'd never stop coming. In Boston they swamped our hotel suite, where we'd intended to give private demonstrations, and they streamed in and out relentlessly throughout the night and early morning. I remember catching about an hour of sleep, on the floor at about five in the morning, as the crowd milled around me. There was something about cyberspace that absolutely grabbed people, to such an extent it seemed irrational. Many compared the experience to a vivid dream. I'll never forget one handicapped person, tears streaming down his face, who had just had a vision of being whole again in a virtual body. By then, we knew we'd uncorked something special, and we were certain we had the makings of an industry. In six months we had proved Walker right: cyberspace was inevitable, doable, and imminent. Or so we thought. That was more than three years ago. Today, while a lot of important and interesting progress has been made by many individuals and companies, the cyberspace industry is still in an embryonic stage. This has been a source of great frustration and disappointment to many who bet their talents and their money on the quick emergence of an industry. It looked so easy. Yet here we are today, facing essentially the same problems. THE WILL TO DO IT I don't pretend to know exactly why things have moved slowly, but I can, perhaps, offer some words of encouragement. I find myself coming full circle at this point. Over the years I've worked on cyberspace, I've gone from optimism to enthusiasm to frustration to bewilderment. Now, as I consider worldwide developments in the field, slow as they may be, I'm coming back round to cautious optimism. If Walker was a bit off in his timing, time has made him right again: cyberspace is imminent because the processes that engender industries have been at work for some time now, for cyberspace, though we who work in the field are probably too much a part of those processes to appreciate their cumulative effect. Part of the problem, of course, has been that many of us expected too much too soon. Most of us in the field are technologists, so it was natural that we would look at the technology, see nothing particularly difficult, and conclude that we only had to put the nuts and bolts in place and the industry would emerge automatically. What we overlooked was that technologies do not make industries. Technologies are essential, certainly, to all industries, but social, economic, and organizational factors are also critical. Comparing the emergence of cyberspace to the emergence of other industries, it is clear there's nothing exceptional about a cyberspace industry, exceptional as cyberspace itself may be. It took over ten years for the movie industry to emerge from the time the enabling technology of filmmaking was invented. Television ran a similar course and so, most recently, did the computer desktop, if you start the clock about the time of Douglas Engelbart's early experiments with mice, screens, and the augmentation of human intellect (as he put it). As a technologist, I must admit that I'm puzzled by the long time course. I tend to think that if we can do the job, technically, and if the stakes are high enough, as they are with cyberspace, then we can find a way in short order to put the requisite infrastructure in place. We knew four years ago, for example, that cyberspace costs too much. We knew there could be no industry comparable to the desktop industry until cyberspace systems cost no more than ordinary personal computers. But we figured numerous hardware vendors would see the opportunity and supply affordable devices, like head-mounted displays, gloves, and trackers, that support immersion. Certainly some vendors have seen the opportunity, and are trying heroically to lower costs to end users. But the ones who are trying are mainly little guys who can't afford to produce affordable products, while the big guys, who could make affordable products, are reluctant to try because they don't see the opportunity. Now it would be easy to say "Well, that's it, that's what's holding cyberspace back: it costs too much." But again, there's nothing remarkable in this particular bottleneck, as industries go. It's always the case that products are expensive, initially, and then plummet in cost as the particular industry kicks in and matures. So it seems to me the reason cyberspace is taking so long to emerge is not due only to the affordability issue, or to technical difficulties in creating the infrastructure. Given the will, technologists will always find a way. What has been lacking up to this point is the will to seize the opportunity. By will, here, I do not mean simply the willingness to take on the challenge, but rather a motivating belief in a new way of doing things. Industries take about ten years to emerge because it takes about that long for communities of people to change their minds. A new industry isn't like a new machine, after all. A new industry is a new society, and those who join it must have the will to pull up stakes and leave an older society (an older industry). This is not an easy thing for people to do, and it is naive to expect people to do it without substantial justification. In the end, for most people, the justification is economic. If you're sure the new way of doing things will make you money, and change your life for the better, then it's much easier to leave older ways of doing things behind. If you aren't sure, then you'll only make the change as a leap of faith -- and you'll only do that if you've already changed your mind and embraced a new world view. THE GAME ALWAYS CHANGES OK, so what? Why does this matter? It matters because we are all entrepreneurs, where cyberspace is concerned, and it behooves us to get some perspective on what we're doing relative to what we want to achieve. Unless we understand that cyberspace is fundamentally different from other media, we will continue to try to build it using old approaches and techniques. We also must understand that it is not enough to build cyberspace technology, nor even to build cyberspaces. I do think it's vitally important for cyberspace technology to be driven by honest attempts to build cyberspaces, but above all we must be explicitly conscious of the fact that we are building an industry as well as a medium. Cyberspace will not emerge, and can have no significant effect in the world at large, until it becomes profitable. None of us, in the end, can make money with cyberspace until all of us can make money with cyberspace. On the other hand, once we understand that we're seeking to establish a whole new way of doing things, then the absence of infrastructure can be appreciated not as problem, holding back the industry, but rather as part and parcel of a natural progression, and a marvelous opportunity. The computer industry today has passed from maturity into a period of stagnation, with most of the players jostling for elbow room within niches they staked out years ago. When John Walker proposed the formation of Autodesk in 1982, he rallied his cofounders by pointing out that the game, in the computer industry, had changed. About a year ago, in a famous internal Autodesk memo called "The Final Days", Walker pointed out that the game has changed once again. I would add that the game always changes, and it is entrepreneurs who change it. What I'm suggesting is that cyberspace entrepreneurs have a unique opportunity, today, to change the rules of the game in the computer industry. While I'm skeptical of revolutionary proposals to leapfrog today's computer industry in a near time frame, for reasons I've just cited, I do believe that cyberspace entrepreneurs can accelerate the evolutionary processes that will eventually lead not just to new rules, but to a whole new game. The important thing for us to realize, as cyberspace entrepreneurs, is that we have a tremendous advantage over those who haven't embraced the cyberspace paradigm. While established companies play a defensive game, protecting their interests in older paradigms, fast-moving entrepreneurs can redefine the game on their own terms, knocking out the ability of other companies even to compete. The danger to the defenders of the status quo is that they will be blind to the changes the entrepreneurs are making. They are likely to end up like the French army fighting the Blitzkrieg in World War II: foolishly defending strategically irrelevant ground while their new competitors "hit em where they ain't." The history of the computer industry is replete with examples of once successful companies who lost their entrepreneurial spirit and suffered devastating losses, or went out of business. DEC, Wang, and Data General, to cite three recent examples, aren't in trouble because their products are inferior. They are in trouble because times have changed while they stood still, or moved too slowly. Today the personal computer reigns, and quality minicomputer products are now irrelevant. It wasn't that DEC, Wang, and Data General couldn't have been competitive. They simply didn't see the competition coming at them. DIVERSITY If there is anything that stands out about the computer industry today it is diversity: in computers, languages, operating systems, interfaces, styles, techniques, peripherals, protocols, and even, paradoxically, standards. We can view the industry as a Tower of Babel, and try to put our own standards in place, or we can understand that computers breed diversity, and bank on it. Diversity is healthy for business, and particularly for entrepreneurs seeking to create new markets. The emerging cyberspace industry is especially amenable to a multicultural approach because it is based on a radically new paradigm that emphasizes social interaction, and it represents a distinct break with traditional ways of using computers. The industry is so new that opposing camps have not yet formed, so there is an opportunity to establish a prevailing multicultural philosophy emphasizing adaptation across camps and application areas. To promote diversity, at this early stage, we need do little more than come out in favor of it, and devise enabling tools that put a premium on adaptation rather than standardization. INTERACTIVE SYSTEMS ARE BETTER EVOLVED THAN SPECIFIED Trix is one such tool. It is a programming system for professional programmers who wish to devise their own cyberspace systems, their way, with building blocks from disparate sources. The original motivation for Trix stemmed from an early design choice we made at Autodesk. We wanted to build a cyberspace system, but we weren't sure how to proceed because none of us had ever built one. We had plenty of ideas and theories, to be sure, based on years of experience making other kinds of software, but no one qualified as an authority. Worse, none of us had ever even experienced cyberspace. Of course, at that time, hardly anyone had, anywhere. So we figured we had two basic choices: we could pretend to be authorities and specify what we thought a cyberspace system ought to be, or we could be honest about our lack of expertise and take an evolutionary approach, growing a system, with the help of our customers, in light of numerous evolutionary experiments. We were hackers by nature, so naturally we took the later course. The traditional approach to software engineering is to first specify a system, in response to a perceived list of requirements, and then to write code that satisfies the specification. In many organizations this requires three different sets of people: systems analysts, who determine the requirements; software engineers, who write the specifications and implement the code; and quality assurance specialists, often software engineers themselves, who guarantee that the final code reliably satisfies the specifications. These, in fact, are the basic operational rules of the game in the computer industry today, and they work very well for the development of products in well understood fields. Unfortunately, the traditional approach is a very poor way to develop an interactive medium. There is nothing wrong with specifications written in response to genuine needs, but theoretical specifications are useless, at best, and possibly even debilitating, particularly for an intensely interactive medium like cyberspace. The point is: YOU CAN'T KNOW HOW SOMETHING WILL FEEL WITHOUT FEELING IT. You can imagine, but that's to say you can hold a theory of how it will feel. In the first phase of the cyberspace project at Autodesk we knew that any specifications we wrote would be purely theoretical, because they could be neither motivated nor informed by our own experiences in cyberspace. In other words, we didn't believe we could do a good job of designing and specifying a cyberspace system, but we did think we could grow an effective one. MOTIVATION FOR TRIX Of course, to say that a system grows is to say it changes a lot. Anticipating this, we also made an early commitment to an object-oriented software paradigm. We envisioned our evolving cyberspace system to be a modular collection of simple components that could be easily plugged in or pulled out. For practical reasons, which I'll come back to momentarily, we decided to grow the system in C++. This proved to be a very good choice, but it had one major drawback. Since we wanted to explore many evolutionary pathways, in order to converge on the "fittest" code, we needed to write and try out a lot of alternatives. Most implementations of C++ aren't good for this purpose because they are compiled languages, and compilation takes a lot of time, particularly when you're making a lot of small changes and submitting them, over and over again, to a compiler. We wanted the advantages of C++, in other words, but we also needed interactivity. Furthermore, we needed a way to make our system programmable by end users, but without requiring them to purchase a compiler from a separate vendor. So Trix was originally conceived as a way to provide programmability to end users of our evolving cyberspace system. Again, I won't go into detail about how Trix is implemented, because I want to focus on its origins and purpose, which was to promote and enable experimentation with cyberspace, in order to further its evolution. Trix is fundamental to that purpose because it gives programmers unparalleled power to devise their own systems of expression and interaction -- to develop their own evolutionary pathways, in other words, in search of the very best ways to implement cyberspace. This is good for an emerging industry because it fosters experimentation and competition, which promotes excellence. PROGRAMMABILITY To be accurate, the power of Trix to foster evolution is really due to Forth, one of the languages underlying it. The reason for this has been explained beautifully by John Walker, who created Atlas, the implementation of Forth out of which Trix evolved. I don't think I can improve upon Walker's explanation, so I'll quote at length from his document on Atlas, written in February of 1990. He sets the stage by mentioning that it was "Autodesk's strategy for AutoCAD from inception that it should be an open, extensible system." "Today," he says, "virtually every industry analyst agrees that AutoCAD's open architecture was, more than any other single aspect of its design, responsible for its success and the success Autodesk has experienced." Despite this fact, Autodesk habitually produces programs that are closed, that admit "no extensions without our adding to [their] source code." Why is this so, considering that Autodesk does in fact offer an extensible interpreter, AutoLisp? The reasons, Walker says, are that 1) interpreters like AutoLisp are intrinsically "slow, slow, slow," and 2) writing an open program, using a traditional compiled language, is inherently difficult. Walker presents Atlas as an alternative that is much smaller, faster, more fundamentally extensible, and more portable (because it carries its own text-based i/o facilities and can easily be embedded in compiled code, regardless of operating paradigm). In concluding the Atlas document, Walker says Everything should be programmable. Everything! I have come to the conclusion that to write almost any program in a closed manner is a mistake that invites the expenditure of uncounted hours "enhancing" it over its life cycle. Further tweaks, "features," and "fixes" often result in a product so massive and incomprehensible that it becomes unlearnable, unmaintainable, and eventually unusable. Far better to invest the effort up front to create a product flexible enough to be adapted at will, by its users, to [meet] their immediate needs. If the product is programmable in a portable, open form, user extensions can be exchanged, compared, reviewed by the product developer, and eventually incorporated into the mainstream product. It is far, far better to have thousands of creative users expanding the scope of one's product in ways the original developers didn't anticipate ... than it is to have thousands of frustrated users writing up wish list requests that the vendor can comply with only by hiring people and paying them to try to accommodate the perceived needs of the users. Open architecture and programmability not only benefits the user, not only makes a product better in the technical and marketing sense, but confers a direct economic advantage upon the vendor of such a product -- one mirrored in a commensurate disadvantage to the vendor of a closed product. I first read these words at a time when, coincidentally, I was trying to work out a way for customers to program and extend Autodesk's first cyberspace developer's kit. I'd considered several alternatives, and had concluded that a threaded approach made a great deal of sense for cyberspace. Early on, I wanted to create a "cyberspace construction kit," ala Apple's Hypercard, that would integrate simulation, multimedia techniques, and programming. I'd built several small applications in Hypercard and I was greatly impressed with it, especially with its power to engender highly energized communities of creative artists. Unfortunately, despite its many virtues, Hypercard left me frustrated because it had several debilitating built-in limitations. When I read Walker's Atlas document I could see he was getting at exactly the same thing as Bill Atkinson of Apple, the principal creator of Hypercard. The major difference was that Walker was focused on enabling programmers whereas Atkinson was focused on enabling non-programmers. For cyberspace, I knew we would eventually need something like Hypercard, a construction kit that artists of various types can use, not just programmers. But we were at the very beginning (as we still are), and it seemed to me that the best way to build a construction kit was to equip our third-party developers with industrial-strength, interactive, and fundamentally customizable tools. Whereas Atkinson was constrained to develop Hypercard out of an infrastructure that was fundamentally closed, we could go the way Walker suggested and develop a construction kit that was fundamentally open, from the ground up. If our customers perceived limitations then they would have all the power they needed to remove the limitations themselves. They would never be stuck and helpless because we had overlooked something peculiar to their needs BEYOND FORTH The only problem was Forth. I was open to it because I'd worked fairly extensively in it in the past, mostly in videogames. I knew it gives programmers unprecedented control and flexibility, but I was also keenly aware of its reputation as a quirky language that's "easy to write but hard to read." Worse, it lacks many features C programmers consider essential, like local variables, function arguments, and data structures. It also lacks object-oriented features, a requirement that practically everyone agreed was essential for cyberspace programming. The needs and sensibilities of C and C++ programmers are of paramount importance because the software industry today is dominated by C, and there is a clear trend toward C++. So it was clear that an extensible macro language for Autodesk's cyberspace developer's kit must not only be compatible with C and C++; it must also be palatable to C and C++ programmers. Forth, clearly, does not fit that bill. I knew Walker was right about the power of Forth, but I also knew he couldn't sell it to C programmers. He tried, but it was too easy for nay-sayers to rattle off a litany of perceived deficiencies. My idea was utterly simple: augment Forth, systematically removing the deficiencies, while retaining the virtues, so that no one could object, on rational, technical, or marketing grounds, to Walker's ideal of a fundamentally open programming system. Publicly, I stated that Trix's design goals were to "enable cyberspace development, give control to developers and customers, accommodate diversity, encourage experimentation, provide interactivitiy, and support object orientation." Privately, however, the goal was mainly to augment Forth, to the satisfaction of C programmers. I didn't mention this goal in public, until now, because I didn't want to risk offending my fellow Forth programmers. To Forth purists, there is nothing wrong with Forth. What it lacks, it lacks on purpose. To them, nothing matters so much as simplicity. As they say, Forth contains everything necessary, and nothing more. I respect that minimalist aesthetic very much, and in fact I held steadfastly to it during the development of Trix. Still, I knew it wasn't enough to build a system with the creative power and freedom of Forth. Trix also had to be marketable, and that meant I had to implement those features, on top of Forth, which C and C++ programmers consider essential. In the end, I created a programming system that is an amalgam of Forth, C++, and Lisp. Even though the syntax is postfix, like Forth, it looks very much like C++. Virtually all the features of C++ are implemented, though Trix presently supports only single inheritance. Trix also includes a simple dialect of Lisp, and this could easily be extended, to implement dialects like AutoLisp or Scheme. THE OLD GAME Let me emphasize once again that my purpose here is not to sell Trix. It is Trix philosophy that's important to cyberspace, and there are many ways to implement that philosophy. Languages are a lot like religions in that people become very devoted to them. Choices between languages often have more to do with personal styles, attitudes, and backgrounds than with technical merit. My own feeling, reflected in Trix design and philosophy, is that savvy information age companies should not, as far as possible, force their customers and third party companies to make exclusive choices. Persuading people to give up the tools and languages they already use or prefer is like trying to convert people from one religion to another. It can be done, but it is a very tough sell, and it serves to fragment rather than engender markets. Yet that is precisely the game most software vendors now play. Enormous energy and expense goes into "evangelizing" The Way We Do It. The usual message is: "Our way is the best, and here's why ... come join us ... we welcome you." It is as if the software industry is divided into numerous opposing cultures, or camps, and the game is to get people to switch camps. The way the game is usually played requires that customers give up one camp, including their investments of time, money, and identity, in order to join another one. XYZ Company comes out with a new operating system or toolbox, for example, and mounts a massive campaign to win over software developers. Much ado is made over the cool XYZ tools the developers will have at their disposal, but no mention is made of the fact that many developers will have to abandon tools and techniques they used previously, at huge cost ("Oh yeah, did we mention you MUST write in Pascal?"). It's like telling a Spaniard she can become an American on condition she never speak Spanish again. DE FACTO ANTI-STANDARD To understand the significance of Trix philosophy you have to understand that Trix is a language designed to capitalize on a moment in the history of an emerging industry. By way of comparison, Basic became a de facto standard in the personal computer industry in large part because it was introduced at a critical moment in that industry's early stages. It had an enormous impact, setting not only a standard but also a tenor, a sort of aesthetic. As McLuhan said, the medium is the message, and Basic preached a philosophy of exclusion: "You will speak and do as I do." Imagine the impact a language like Trix might have had, with its underlying organic and multicultural philosophy that says "You can adapt to any language or environment." My vision for Trix was never to create a de facto standard for the cyberspace industry, but rather to create a de facto ANTI-standard that enables people to contend with and exploit diversity. This may seem to be a prescription for anarchy to those playing the old game who believe companies should attempt to dominate by setting up a camp (a standard) and then cajoling as many people as possible to join it. But Trix was not designed to help Autodesk dominate. It was designed to help Autodesk thrive in an ever-changing, fast-paced, and increasingly diverse set of marketplaces. Standards and dominant players will come and go, but those who survive will accept diversity as a fact of life. Those who thrive will be adept at adapting to the ways and requirements of any market or situation that presents an opportunity.