💾 Archived View for spam.works › mirrors › textfiles › computers › CYBERSPACE › walseran.ti- captured on 2023-07-10 at 19:13:35.
-=-=-=-=-=-=-
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.