A DE FACTO ANTI-STANDARD FOR CYBERSPACE

                  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.