Remarks
Altaira has proven to be a very flexible, general language within its
intended problem domain. We note the following specific areas in which we
feel this is already a highly successful experiment:
- The visual representation of sensors, motors,
and the other elements of the language is very intuitive, requiring little or
no explanation. Oddly enough, a number of language elements which are obvious
to the user immediately upon exposure proved to be very difficult for the
implementers to conceptualize in advance. A case in point is the necessary
rotation of states from the state stored in the execution engine map to the
rule lookup in the execution engine itself. While it is obvious immediately
upon seeing it in action, several project meetings were devoted to the topic.
- The nearly complete independence of the rules makes debugging much
simpler. In the event of an error, relating the robot's behavior to the
contents of the rule is immediate. In short, all of the benefits claimed
for conventional rule-based systems are true of Altaira.
- The freedom provided users to develop their own visual representations of
states makes it possible to develop state sets which are appropriate to the
problem at hand, and useful to the users.
- The ability of the language to explore its own map without moving the
robot (as seen in the optional problem solution) gives a great deal of power
to the language, and permits behavior analogous to introspection. Coding
algorithms for problems such as finding the shortest path to a given tile
would be straightforward, though tedious.
- The simulation environment is invaluable for debugging rulesets. The
ability to debug rules in a controlled, repeatable environment reduces the
time required to solve a problem by at least half.
We do, however, see room for improvement in the language. It has deficiencies
that result from its nature as a prototype (such as the lack of a robot
state editor; robot states were added late in the development); mistakes in
the user interface (the required ``apply'' of ruleset changes is an example)
and the language semantics. Of these, the most important is that there is
not possibility of a ``don't care'' in the rule selection. Because of this,
there is no way to share fragments of rulesets between similar situations:
when changing state due to the presence of a line, it is necessary to account
for all of the cases of line-following at the same time. This causes an
explostion in the size of the ruleset. Also, because of this, when a bug is
found in a situation such as turning at an intersection, there is no easy
way to generalize the fix to other situations (in the compulsory problem, it
is possible to tell how long ago a given intersection type was debugged by how
gracefully the robot copes with it). In short, the rules are too
independent - a very definite case of too much of a good thing.
The Kids
The results of having children program the language were very interesting.
As hoped, they found the basic concepts very easy to grasp, and all four of
them were able to write rulesets to follow lines (though Becca's and Chandra's
best rulesets were not saved). They also found the necessity to rewrite
essentially identical rules for similar situations to be very tedious. Also,
the system was not fully debugged, and they found the not-infrequent failures
(which, like as not, would crash the X server!) to be extremely frustrating,
a situation which to some extent sabotaged our goal of getting impressions
of the system's ease of use.
The kids' use of Altaira was, quite deliberately, not in the nature of a
scientific experiment. Rather, we were hoping to gain an early impression of
the language's ease of use.