[Retros] Magic, Anthropology, Microsoft

[Andrew Buchanan]

A composition depends for its soundness on the rules which the author
considered to prevail at the time.

In the same way, a software program written in the 1960s may be hard to run,
because one can't find a compiler for it. It's necessary when talking about
an old problem today to put it into the context of its time.

While this may be possible on a per-problem basis for an author writing a
review article, there are tremendous economies of scale possible by
developing a history of what rules/conventions applied at different times in
chess history. After all, we almost always have the year, which acts as a
key (in the database sense) into the rule set.

Of course, an issue is that we can't agree on what the rules/conventions
are. We must agree to differ, and to present the alternatives. Actually, I
think that the differences are most difficult to resolve for the present
day, but everything becomes clearer in hindsight. Historical objectivity is
often elusive when writing about the present.

My route to chess problems is a rather unique one: I came here after
spending years playing the collectible card game "Magic the Gathering".
(Some may shudder at this point :-) One thing which impressed me is the way
that the contradictory rules for *thousands* of cards and ten years of
self-referential case law have been organized and simplified into an
algorithm which can run superbly on a computer (Leaping Lizards' "Magic
Online"). The simplifications necessary were extremely radical: a
fundamentally different concept of temporal sequencing and causality was
necessary: and this is a game with tens of thousands of active players
worldwide.

In comparison, the world of chess problems is absolutely tiny, and it's
baffling indeed that I can't find a clear specification of what the problem
conventions were in 1895. If the heritage of chess problems has value (and
we surely believe that it does) we need to record the context in which it
was created.

Otherwise, we lose ourselves in arguments about relative soundness and
unsoundness. We lose our own perspective.

Anthropologists in Victorian times would go to Africa and record the stories
that natives told them. Collections of such tales would then be published.
Today's anthropologists are sad about this waste. The stories have been
taken out of context: nothing is known about the cultures in which the
stories existed.
Today's anthropologists (with the benefit of superior technology also) will
record the stories, but also the music and the dance, the context in which a
story is told, the circumstances of the people listening to it.

I believe there is a parallel. Using the technology at our disposal
(databases) we need to record the context (the rules and conventions) which
pertained at the time of a problem's composition.

Actually, I think it goes further than that. The context is more than just
the rules and conventions: it's actually refers to the aesthetic goals of
the composer. To track this is too ambitious, but we should be aware of what
we are losing. At the very least, I would like to see PDB store tourney
objectives for problems published there. There are so many helpmates sitting
in the PDB, "2nd Prize in so-and-so tourney of 1958". And what were the
criteria that the composer was trying to optimize. I'd also like to see, for
problems published in magazines, the contextual remarks which the magazine
editor gave.

The comparison between Magic and Chess reminds me of the competition in the
IT world between Microsoft and the Open Source movement. The Magic rules
became organized because of an act of will by a corporation that wanted to
continue to make a great deal of money. Microsoft similarly succeeds in
imposing a monopoly on the world, because it is so *convenient* to have a
monopoly.

In chess however, we are generally speaking a more heterogeneous bunch, and
there are no huge sums of money at stake. However, the Open Source movement
shows that people can agree to differ, and develop standards that work. I'd
like to see that happen. As a computer professional, I believe in the virtue
of specifying things properly at the start, rather than trying to fix them
later.

Regards,
Andrew.