AGORIA-FIVE development

[Mark S. Miller <vlad!mark>]

Hi!  I finally have time to respond.  I'm really glad to hear about
how things are progressing.

   Date: 5 Dec 90 01:36:00 EDT
   From: "AGORICS PROJ" <xanadu!gmuvax.gmu.edu!agorics>

   Hi, MarkM,
	   Don and I had a long discussion about Agoria-FIVE (do I really like
   that name??) today.  

Terry says she hates the name "Agoria".  Says it feels bad on the
tongue.  I don't have a better suggestion though.  What's the "-FIVE"
for?  Were there Agorias 1 through 4?  Terry is using the name "The
Village" for her Axelrod-oriented micro-world.  Besides "The
Prisoner"[s Dillemma] tie in, it sounds like a community.  

   ...

	   By the way, I love getting the email discussions of software
   repossession, property rights, 1st Amendment and privacy, etc.  Being on
   the Net is a whole new world for me.  Anyway, to business...

Several people at Xanadu have expressed an interest in being on the
"agorics" mailing list.  Ravi (I think) has suggested that the
simplest way to administer this would be for you to list
"agorics@xxxxxxxxxx" as a member of your list, and then we'd
administer local membership at our end.  (An arrangement I think
referred to as a "local redistribution list".)

	We give a Tuesday colloquium on Agoria in February, the 5th or 12th.  I
   plan to work hard on it until then, and then turn my attention to my
   dissertation.  We think we have some major design decisions to make, and we
   need your advice.

Can we get a video tape of the colloquium?  By the way, what happened
to the video tapes of the other meetings?  Several people here have
been asking for them.

	   1) We want meetings of more than two people.  Our traders need to be
   able to communicate in groups.  We are considering having a meeting object
   created whenever two or more traders gather at the same spot (more on this
   below).  They would communicate their offers and bids through this meeting
   object in some manner.  This seems a desirable feature, true to the world.
	   2) But we think this change must entail abandoning, or at least
   modifying significantly, our present technology whereby the return of an
   offer is hard-wired to the question, "whatIsYourOffer?"  As you know, we
   have been uncomfortable from the first with having the offer automatically
   returned.  (In the <respond: other> method for the receptionists, the code
   is "o := other whatIsYourOffer."  "o" then gets passed on as an argument to
   the offerEvaluator.)  We would rather have the otherTrader in effect say,
   "Okay," and then decide to return the offer, at his own initiative, rather
   than as a quick bit of some first trader's own method.  We think we want
   the offer requests to be heard by a bunch of traders, any of whom can
   decide to make an offer if they want.
	   Now we know you had strong reasons for guiding us into our present
   methods.  How about it now, as we want to evolve?


I agree it is desirable to be "true to the world".  However...  But
first, a brief digression.


		The Way I First Got Involved in Xanadu 

When I was a sophmore in college, I was taking my second ever
programming course (learning the C language).  Half of the class
consisted of exercises and homework, but for the other half we each
got to choose a class project.  I had just read this incredible book
called "Computer Lib" by this guy named Ted Nelson.  (It is still an
incredible book.  I recommend it quite highly.)  In it he describes
all sorts of amazing ideas that had me all excited.  In particular,
Xanadu.  As a result, I decided to implement a Xanadu system (or at
least, a Xanadu-type system) as my class project.

Being a randroid at the time, I had wierd ideas about intellectual
property.  So I decided to call Ted and ask his permission to use
ideas from his book in the Hypertext publishing medium I was going to
build as my class project.  We had a wonderful conversation that
resulted in Ted & I working together, and eventually to my involvement
with Xanadu.  However, I did not quite get Xanadu done in time for my
course credit.  A similar story explains how Ted started Xanadu 30
years ago.  The moral of these stories is a line by Ted on the nature
of software:

"In software, everything is possible, nothing is easy."

As a kid, I quickly figured out the first clause.  Appreciation of the
second clause only came later.


			Why We Will Deliver Anyway

As a result of Xanadu's long and tortuous history, we had a problem.
The people who one finds attached to a project after 26 years and no
funding are self selected to be ones with a different sense of time
and urgency than most.  Left to our own devices, I think it is fair to
say we would have taken forever, but the result (at the end of time)
would be near perfect.  (I should point out that I am probably among
the worst offenders here.)  Realizing this problem, Marc Stiegler
introduced a bunch of techniques to deal with it.  Perhaps the most
important is "Version 1.1".

"Version 1.1" is what you try to imagine so that you can stand to
leave something non-essential but really neat out of "Version 1.0".
It's what enables you to build a version 1.0 which is (in Drexler's
phrase) "good enough to be wonderful" but is much less than you'd
like.  You console yourself with the thought that you can put those
things in later.  Besides, it is in most ways easier to extend
something that works than something that doesn't.  This re-orients the
design goals of Version 1.0 to be that it can be extended to be
perfect with minimal violence (especially to our developers and
users), rather than that it itself approach perfect.

Drexler may succeed in getting the first draft of his technical book
on nanotech done in *only another year* by using "The Second Edition"
in a similar fashion.  And he's working really hard.

I think you see what I'm worried about.  This isn't to say that
multi-way communication isn't a good idea.  It's just that two-way
communication is naturally supported by the Smalltalk language, and is
sufficient for an Agoria that's "good enough to be wonderful".  If you
did do multi-way communication in Smalltalk, I think your proposed
meeting object is the way to go.  And congratulation on making the
right choice!  There are many other seemingly as plausible ways to do
multi-way communication in Smalltalk.  

Remember, Agoria doesn't have to be an accurate model of the world, or
to display all the kinds of richness that the world does.  As you
already know, such goals are hopeless anyway.  The whole game in
building informative micro-worlds is to capture enough richness to be
interesting, and to give rise to emergent phenomena which can lead to
new hypotheses.  Agoria is already orders of magnitute more rich than
Axelrod's iterated prisoner's dilemma tournament, and look how much
we've learned from it!

Of course, one should strive to make Agoria as rich and true to the
world as one can afford, so we need to look at what the trade-offs
are.

I would guess that the readability of the Agoria code critically
depends on the traders communicating with each other in the way in
which it is natural for Smalltalk objects to communicate with each
other.  Smalltalk itself is tuned to make code for objects which
communicate in this way readable.  This is why I think it is good idea
(for now) to stick both with two way communication and using return
values for results.  I don't know about Smalltalk-V, but the
Smalltalk-80 system contains many unreadable examples of code which
communicates in ways other than what the language naturally supports.

By the way, most of the concurrent logic programming languages (which
you were propagandized about at ECOOPSLA) support multi-way
communication as naturally as Smalltalk supports two-way
communication.  Both concurrent logic programming languages and Actor
languages avoid a special return path.  Instead, in both it is natural
to "return" a result by sending another message much as you suggest
above.

I do think that these other communications patterns can be supported
well even in Smalltalk, and code using them can be readable.  But
getting there is a lot of work which has little payoff with respect to
the utility of Agoria "Version 1.0".  Even with all the simplifying
assumptions of the current architecture, it will be much more work
than you know to get Agoria to the point where 1) others can figure
out how to contribute new stategies, 2) you can run games with a
significant number of players, 3) the system is instrumented well
enough that you have enough hooks to tell what's going on, 4) you've
got visualizations which make sense of what the instrumentation
reports, 5) you've got enough user-interface design and engineering
that the whole thing is usable, and 6) it is all solid and documented
enough that you don't have to be in the room for someone else to use
it.  I would say that a crack *team* of experienced programmers would
find the above a challenging task.  When does Don's course start?  And
did you say something about a dissertation?

Besides, when you write papers on Agoria, you need something juicy for
the "Future Research Directions" section.  Seriously.  It is fine to
accumulate the above into a nice long list about important ways we
know that Agoria isn't true to the world of trade.  No matter what we
do the list will be long.  It's always a lot of fun in such sections
to speculate on how we may eventually handle this and that.  It's also
a great way to spread the research program to other universities--they
can quickly see lots of opportunities.


	   3) We want space and time in our cities.  Don has used discrete event
   simulation techniques, which he explained to me a little.  I take it that
   everything must run on the clock.  So the clock becomes a dominant object,
   then, right?  We would like, say, to have two meetings going on at two
   different parts of town, and have the system handle them as if they were
   simultaneous.  Any ideas?  Should we go for it?  Pitfalls?  Alternatives?

In light of my above comments, I think it would be a mistake to get
into this in any fancy way now.  In particular, concurrency is a
fascinating and deep topic which is best avoided in Smalltalk when you
can.  Once again, in the concurrent logic languages and the actor
languages the story is different.  At Xanadu we have 3 people that are
among the best in the world at understanding concurrent programming.
However, some significant intellectual effort was put into enabling
Xanadu Version 1.0 to be purely sequencial.

If you do want meetings which extend over time, which overlap in time,
and which interact, then Don's "discrete event simulation techniques"
are probably a good way to go.  I would recommend though that meetings
be instantaneous, don't overlap in time, and don't interact.  Rather,
an entire meeting (everything that happens starting from sending "a
meet: b" until it returns) is considered by Agoria to be an
instantaneous event.  Agoria can still have time and space--each
meeting event can happen at a particular point in Agoria's space-time.
Doing the latter doesn't involve using any of Smalltalk's wretched
concurrency facilities.

	   4) As implied above, we want to have the traders meeting at certain
   places now, perhaps giving them strategies which focus on *where* they have
   been able to trade successfully before.  We are thinking of sticking with a
   small number of traders and a small number of places, but we think we would
   like to get into this.  What do you think?

This sounds like an excellent idea!  (Note that it is compatible with
the simple notion of time and space I advocate above.)  This direction
does not put us at war with the language, and actually aids
visualizability.  In particular, it lets us explore the strategics of
spacial Schelling point formation--how does a convention like "go to
Castro Street to buy or sell Chinese food or used cars" come about?
This is a kind of question that I'd most like to see Agoria help us
think about.

	   We need the guidance of our ... trusted and experienced
   advisor MarkM.  We are definitely planning
   to have an explicit design session, where we use index cards and all that,
   but we would love to have your input, even if quick and telegraphic,
   beforehand.

I hope this is helpful.  Above all, I hope it isn't discouraging.
I've come to realize lately a distressing trend in myself: I've become
ever more skilled at proposing reasons why something can't be done or
is harder than is expected.  At the same time, I am not thinking of
neat new things to do as often as I used to.  Perhaps I am simply
getting old and tired and frustrated by the incredible number of
details one has to deal with to actually make something happen in the
world.  This results in my being more of a wet blanket on the
enthusiasm of others than I intend.  So please keep in mind that (in
my humble opinion):

What you are doing may be the single most important piece of economics
research happening right now (outside of Eastern Europe).  Not because
of what the first version will do directly, but because of the new
methodological processes which it will set in motion.

	Best to Terry and Dean and all our friends and colleagues at CSMP West.
				   --Howie

Thanks.  Best to all at CSMP East.  Good luck!

  --MarkM