MACISTE

[Fare Rideau]

Dear Tunespeople,
   on the previous week, I saw at work perhaps the only running system
that's based on deep reflection: Jacques Pitrat's MACISTE.
Here is a short report of what I saw, and what it made me think about.

   MACISTE is written entirely in itself
(more exactly, every version is written in an earlier version).
The system knows everything about itself;
it is its own development environment.
   After around 15 years of evolution,
everything is now written in high-level declarative style;
the system's heuristics are wholly responsible
for parsing (or pretty-printing) it,
producing interpreted bytecodes or optimized C code
(restricting to an assembly-ish subset of C),
dynamically calling the C compiler and dynamically linking code in,
managing the memory (GC, swapping).
   Its heuristics and meta-heuristics can solve
all kinds of problems puzzles using lots of techniques from AI;
as of performance, it tries to detect when interpreted inferences
brings no more much information, then dynamically compiles code optimized
for the particular remaining subproblems including all known data.
JL Lauriere's ALICE system has been reimplemented inside MACISTE.
Etc, etc.
   It all looks like a very powerful system,
that proves how meta-programming can help save enormous amounts
of both programmer and machine resources.

   However, it's a one-man system: one man has been writing it,
and it's got no documentation, according to the same principle that
Chuck Moore (inventor of FORTH and MISC) followed
until he recently changed his mind:
"the map is not the land". There's no map. When Jacques Pitrat
wants to know how something behaves, he queries the system about that
thing, and the code (as prettified by itself) is its own documentation!
Moore recently decided that the map, being more abstract than
the land, is also what the user wants to know about the land,
hence starts making maps; J Pitrat takes the opposite way:
if the land is not abstract enough, then make the land more abstract
instead of making a map.
   Anyway, some minimal docs are just required before a newbie could
start using MACISTE: after all, as good as the self-documenting aspects
of the system be, J Pitrat also relies on his decades-long
experience with MACISTE and his earlier systems.
The interactive setup is also tuned for quick interaction by one man:
most usual commands are one- or two- letter to reduce typing;
that's great as a personal setup; not so great for newbies.
   Of course, Pitrat cannot do otherwise: he's a one man, with no help;
as a searcher, the only external workers he can find are his few PhD
students, to whom he cannot decently ask to develop MACISTE,
because they'd rather spend time on their thesis
(like this automated Go player that a student developed in one year
using meta-heuristics for learning,
and that was 4th in the world-wide competition, before many
multi-million-dollar hundred-man-years costly competitors --
this year, hopefully it might be first).
Moreover, the said students would spend lots of time learning MACISTE
before they could be useful.
Pitrat has so many ideas of research experiments to do with MACISTE,
that he has no time in developing large documentations
or nice user-interfaces either.
   Finally, the MACISTE reflective development environment
is not prepared (as it is) for concurrent enhancement by several people.
It has got rather simple module and version systems not suited to that.
There is no automated tool for diff'ing or merge'ing code;
only two versions can reflectively debug each other
(i.e. an old stable backup version cannot be used to debug the latest one).
Hence, the rare meta-bugs that happen when deep parts of the system are
hacked can take the several days to fix with little help.

   All in all, it seems that MACISTE, like Tunes currently, seems
to be failing to be usefully spread because its development policy
is not open enough (see Eric Raymond's "Cathedral and Bazaar" article
<URL:http://www.ccil.org/~esr/writings/cathedral.html>.
Of course, in both cases, research aspects make it difficult to bootstrap
the open development of the system; however, my feeling is that allowing
and promoting such development should be the #1 priority.
Maybe the venerable Jacques Pitrat is too old to change his priorities;
we are not.

   Well, regards, and have a nice summer.

== Faré -=- (FR) François-René Rideau -=- (VN) Уng-Vû Bân -=- rideau@ens.fr ==
Join a project for a free reflective computing system! | 6 rue Augustin Thierry
TUNES is a Useful, Not Expedient System.               | 75019 PARIS     FRANCE
http://www.eleves.ens.fr:8080/home/rideau/Tunes/ -=- Reflection&Cybernethics ==