Chapter D: The ProgrammingLand
MOOseum
Abstract
The ProgrammingLand Museum implements an Exploratorium-style museum
metaphor to create a hyper-course in computer programming principles aimed at
structuring the curriculum as a tour through a virtual museum. Student visitors are
invited to participate in a self-paced exploration of the exhibit space where they are
introduced to the concepts of computer programming, are given demonstrations of these
concepts in action, and are encouraged to manipulate the interactive exhibits as a way of
experiencing the principles being taught (Duffy, Lowyck, Jonassen, 1983; Duffy and
Jonassen, 1992).
Introduction
Methods for managing distance education continue to evolve. Interactive Video
Networks (IVN) is one method for delivering lecture and other programming to remote
locations. The World Wide Web provides the ability to compose attractive text and
image presentations, and has become an increasingly vibrant medium with animation and
even video. It is more and more common to find course materials online in the form of
syllabi, lecture notes, and reference materials. Recently, more active elements have
appeared in the form of online quizzes and simple demonstrations. These two approaches
supplement the time-honored methods of distance education: correspondence courses and
broadcast media. Most recently, research into the development of virtual environments
for education have started to have a limited but highly promising impact.
Education, like many other disciplines, profits by computer-aided assistance.
Most educational endeavors focus on an instructor, in a classroom, on a campus, at a
particular time. Administrators prefer large lectures because that minimizes cost in an era
of increasingly tight budgets. The ones who lose out in this scheme are the traditional
students, who get very little instructor contact, and those non-traditional learners who
cannot take the time to travel the distance to those campuses where knowledge is
dispensed.
Education is very labor-intensive. Numerous organizations have applied
technology in one form or another to make the instructor more efficient and the process
more cost-effective. Diversity University (www.du.org) is a well-known example. We
suggest another approach.
ProgrammingLand has been developed and used in conjunction with traditional
classroom instruction. However, the goal is for distance learning and non-traditional
classes. It is intended to deliver the content that would normally be obtained from a
lecture or textbook, yet also have many of the attractive qualities of games and other
learner centered activities. Despite the obvious advantages of the World Wide Web, it is
still a relatively passive mechanism. The active learning alternative is the synthetic
environment where learners can experience their education in a "learn by doing" way.
The ProgrammingLand approach implements an Exploratorium-style museum
metaphor to create a hyper-course aimed at structuring the curriculum as a tour through a
virtual museum. Student visitors to the museum are invited to participate in a self-paced
exploration of the exhibit space where they are introduced to the concepts of the
particular domain, are given demonstrations of these concepts in action, and are
encouraged to manipulate the interactive exhibits as a way of experiencing the principles
being taught.
The ProgrammingLand MOOsuem
ProgrammingLand is a MOO (Curtis, 1997) being developed on the VCSU
campus as a Virtual Lecture adjunct to introductory programming language classes. The
paradigm employed is that of a museum where students examine exhibits, reading the
explanatory text displayed on the walls of each room. In addition to the displayed text
there are a number of interactive demonstration objects in the museum that clarify or
demonstrate the concepts. One such object is a code machine, which contains a short
segment of programming language code and can display the code, display with line-by-
line explanations, or display a line-by-line execution of the code. ProgrammingLand
augments programming language courses, either locally or at a distance. At the
beginning of this course there were four wings under construction. One of these was an
introduction to using a MOO; each of the other three dealt with the one of C++, Java or
BASIC.
The Moo is structures into lessons. A lesson is an amount of instruction that
could reasonably be completed in one sitting, whereas a topic is usually several lessons
and hence too large for a single session. It should be noted that both lesson and topic are
arbitrary terms without specific boundaries in the MOO. If student wants to learn one
lesson in several sittings, they have the freedom to progress at their own pace in whatever
way they choose. Thus, students do not perceive lesson boundaries or topic boundaries.
All they see are single exhibits, which are single rooms and the brief amount of
information that is present in that context.
A single exhibit will convey a very limited amount of text. This text may be any
of several types. One common exhibit is a signpost. A signpost exhibit does not convey
much technical information, instead it is usually the entrance to several other lessons and
topics. The C++ Foyer is a signpost directing students in any of several directions.
Figure 1 shows the Function Lesson, which is a signpost exhibit and an example of what
a touring student would actually see.
Function Lesson
This is the start of a number of lessons about functions.
Consider the following menu that may be selected by letter or
topic:
a) The importance and usefulness of functions (why)
b) Using functions or calling functions (call)
c) Overview of function definition (define)
d) Function parameters (parms)
e) Function return values (type)
f) Function and variable scope (scope)
You may choose any of these and enjoy.
Obvious exits: [exit] to C++ foyer, [define] to Function
Definition, [call] to Calling Functions, [parms] to Function
Parameters, [scope] to Scope Lesson, [why] to Why use functions?,
[type] to Types that functions produce
Figure 1: An Example of a Signpost Room
The first line “Function Lesson” is the MOO room name. The next ten lines are
the room description. The last four lines are a listing of the exits from this room. This
description as a signpost does not convey any significant technical information, but it
does direct students to a series of lessons. This particular signpost is arrayed like a menu.
A student may type either “b” or “call” and go to the same room. The name of the room
is given when the room is created. The description of the room is written after the room
is created and is the main means of conveying information. The last four lines are
generated by the MOO server to indicate the available exits. Each of these exits may
have one or more synonyms that cause the student to progress to the destination room.
The most common type of exhibit is informational; a room where some content is
given. This can take any of the forms that a lecturer would use. For example, on the
menu of Figure 1, the first option is mostly motivational – why this feature is useful to
the student. In an actual lecture this is needed to pique the curiosity or otherwise show the
need of the concept about to be discussed. Lecturers do not need to motivate the good
students, but a lecture has to be inclusive, so motivational comments are required for a
good lecture. Yet in the virtual lecture students may pick and choose what they view and
in particular a student may skip the first part of the function lesson if they desire. Other
rooms may have the informational content of other parts of a lecture: simple descriptions,
a variety of longer descriptions. and examples. No oral lecture can have the number of
examples of a virtual lecture since the student does not need to view them all, only
enough to grasp the concept.
The MOO attaches to students a list of exhibits they have visited. This list of
exhibits is available to the instructor and is a record of progress and a diagnostic tool for
that student. This list cannot consider comprehension but does demonstrate exposure.
For distance learners it is a concrete measure of activity for students, who may have no
other communication with the instructor. Students who have a problem may just have
missed the part of the Virtual Lecture that dealt with the item in question, so that an
obvious course of remediation can then be suggested.
This history of exhibits also enables an improvement to the structure of the
museum. In order to keep the hypertext reference document convenient, many more
paths must be created than a novice should be allowed to use. Designing a Virtual
Lecture requires a balance between the single linear path, which penalizes advanced or
returning students, and the potential for too many choices, which invites novices to
exhibits where they are more likely to be confused than educated. The solution to this
dilemma is the active exit.
The active exit checks the prerequisites for the room. Students taking a path to an
advanced topic have their history checked against some possible background exhibits. If
the students have visited rooms that form the foundation for the room to be entered, they
are allowed in without knowing that their prerequisites have been tested. If they have not
visited the rooms needed, then the exit suggests that this room may be more confusing
than helpful and asks them if they really want to proceed. An advanced student may have
acquired the needed knowledge outside the Virtual Lecture and thus can go forward,
while a merely curious novice has been warned and at least knows there is potential
confusion ahead.
A very important consideration for any educational tool is the interest level that
the tool maintains in the student. Consider public libraries: most of those that lend
videotapes are actually lending more tapes than books, which is especially remarkable
when considering the selection of book dwarfs that of video tapes in most libraries. The
implication is clear, videotapes are more engaging than books. Similarly, the
Exploratorium model for a museum is more interesting than the older museums with
glassed in exhibits and no interaction. If interest level was not a consideration we would
write good textbooks, hand them to the students and administer examinations at the end
of the time. The impracticality of such an approach is obvious. A web implementation
of the reference document will hold a student for a while, but it will eventually become
essentially the reading of an electronic text. What is needed is something even more
interactive than the reference document or even the Virtual Lecture possible in a MOO.
In the web implementation this may be accomplished by Java applets, but in the
MOO this will be accomplished by software agents. Such an agent may appear as a code
machine that occupies the room and has various commands that operate it. It may also be
a robot that the students might or might not distinguish from other students, who come
alongside and question or tutors the students as they walk through the museum.
The Programming Land MOO at present has but one agent, a code machine. The
code machine is an interactive object placed in appropriate exhibits. The main job of the
code machine is to demonstrate short pieces of programming language code. It accepts
several commands:
Show lists the lines of code.
Explain gives an explanation of each line in succession.
Trace shows the execution of each line in succession.
Next advances an explanation or trace by one line.
Help explains the possible commands of the machine.
This object is intended to raise the interaction level and engage the interest of the
student in an active way impossible for a textbook or web page.
This Virtual Lecture does not eliminate the utility of a web site for the class; both
complement each other. The class web pages contain a general page about the entire
course, which includes the announcement of tests, links to assignment documents, the
source of programs discussed in class, answers to exercises, and overview documents like
the syllabus and course outline. The normal web browser makes it easier to download
documents than most MOO clients. Therefore, the web is a very handy administration
tool for the course, but the Virtual Lecture is far better for instruction.
The Virtual Lesson
Synthetic environments, such as those described above, are dynamic and
extensible spaces. These environments support multiple users (so learners can interact
with both the environment and each other), real-time simulation of events, and interactive
software agents, particularly tutors. This flexibility permits complementary approaches
to student tracking and modeling, as well as mentor-style interactions where an "over the
shoulder" software tutor monitors student actions and "visits" participants with timely
and felicitous help and advice.
Content in ProgrammingLand
A typical session for the students starts with the execution of a client program.
There are several applets that allow the students to use their web browser for this, as well
as many good standalone clients. The students connect to the MOO and are registered for
tracking purposes. The MOO itself is structured into rooms, with exits being the path
from one room to another. Students each have a home that is usually the main entryway
of the MOO, but they may change their home if they desire. The MOO is built on
Version 2.0.1 of the enCore database (Holmevik and Haynes, 1997).
The motif of ProgrammingLand is that of an Exploratorium style museum.
Therefore the term exhibit is usually used instead of room. Whenever an exhibit or room
is entered, the MOO displays a description. Typically this is a paragraph or two of
instruction on some topic. The MOO will also indicate what exits exist and where they
lead. The student is always free to choose which path to take and what to look at next.
Although an exit is a one way path from one room to another, they often come in pairs so
that a student may return to an exhibit conveniently. The student entering the Compound
Statement Room would see the following display.
The Compound Statement
The compound statement is not a flow of control statement,
however it is used in most flow of control statements and is essential
to the Structured Programming model.
In the Structured Programming model there is the notion of a
block. The block in C++ is the compound statement. It is a wrapper that
binds several statements into one. It is also the block that greatly
affects the scope of variables.
You may choose any of the following exhibits to consider next.
a) The syntax of the compound statement
b) Scope of variables in the compound statement
c) The compound statement and other statements
or
x) Return to the main exhibit on flow of control
Example 1: The Compound Statement Room
Students meander through the museum, picking and choosing what they want to
read and also choosing the order to consider topics. If this were the extent of the
techniques used in the MOO, it might be useful, but it would not be superior to a series of
web pages. What must be considered next are the objects that work together to make this
experience more educationally beneficial.
Fundamental Objects
In a MOO every thing is an object. Rooms are objects, exits are objects, players
are objects and everything else that we will later consider are objects. These objects have
properties that may carry information and methods that may perform useful functions.
The students are oblivious to most of this; they walk through the museum without much
thought to the processing the server is doing. The first objects that need to be considered
are the student’s character and the rooms.
When students log into the MOO, the students’ character is activated. This
character is the object that the server uses to manage everything that is known about the
player. There are several important properties that are attached to the student object that
have an impact on the educational use of the MOO. The first is a list of every room that
the player has visited. There are certain objects that mark events and make awards. The
students score points in this way, either by visiting an exhibit, taking a quiz, or achieving
some other accomplishment. Finally, students have a goal, which is what they should be
working on currently.
The MOO is not used to compile student programs. The compiler resides on the
student’s own computer or perhaps in a publicly available machine. Hence, some of the
practice that would be desirable for a programming class must be done out of the MOO.
However, the workbench represents an attempt to place part of this practice into the
MOO. A workbench is a table driven parser with enough of the tokens of a program
fragment to allow the students to test whether they have the syntax of a contruct correct.
The student builds a statement or program fragment from the pieces that are inserted into
the workbench. When complete the student can ask the workbench to determine if the
fragment is correct or not. In very simple instances the workbench may also interpret the
code and run the program fragment. Like the code machine, a successful parse of the
code produces a point-scoring event on the student character.
Lesson Structure
ProgrammingLand is not a random collection of rooms containing instructional
material any more than a textbook is a random collection of pages. There is an order
imposed that organizes rooms into related clusters of rooms called sub-lessons. Sub-
lessons have no required shape or size but often have some common characteristics.
They are always a group of rooms on a single topic. There is often only one entrance into
the group and usually just one or two exits out. The first exhibit in the group is usually
an entryway room with a short introductory paragraph and then a menu of available
rooms. Often one of the rooms has only text that attempts to motivate the student or
explain how the topic fits in the overall scheme of things. There is often a workroom in a
sub-lesson as the final example. A sub-lesson may be nested within a larger sub-lesson.
The following objects were created to support the lesson: a sub-lesson, a sub-
lesson-exit, a quiz room, a dispatcher and the roving goalie. These work together to post
events on the student object and test the events.
Sub-lessons
The head of the structure is the sub-lesson exhibit. It is a descendent of the
lecture room so contains all the properties and methods of that object. It contains two
additional properties as well, the all_rooms property and the requirements property. The
all_rooms property is a list of all the exhibits in the sub-lesson. If a student is given
credit for the lesson, then the rooms on this list are removed from the student’s history of
rooms visited. This is done to shorten what can be a long list of rooms, under the
assumption that mastery of the sub-lesson is more important than any subset of rooms
visited. The requirements property states what is expected for students to gain credit for
the sub-lesson. It is a list of lists. If they satisfy any of the sublists, they are given credit
for the sub-lesson. To satisfy a list, however, they must satisfy every requirement of the
list. Each of the sublists may require any combination of simple room visits or specific
events recorded. The order that these requirements are satisfied is irrelevant, only that
the students did each of the items on one of the sublists. A requirements property does
not have to contain multiple sublists, but that is often the case.
The sub_lesson_exit is a descendent of the normal exit object but behaves in a
rather different way. When students choose an exit that will leave the sub_lesson, their
progress towards satisfaction of the requirements is checked. If the students have
previously met the requirements, the exit moves them to their intended destination with
no action out of the ordinary. If any of the sublists of the requirements of the sub-lesson
have been fully met, then the exit tells the students that they have completed the
sub_lesson. It also posts a completion of sub_lesson event to their event list. If they
have not completed the sub_lesson they get a different set of messages. The first sublist
of the requirements is checked, and one or two unmet requirements are displayed. They
are then asked if they want to continue to their destination and finish the sub_lesson later
or if they want to prove their mastery with a quiz. If they opt for a quiz, they are
transported to a quiz room.
Interactive Objects
The ProgrammingLand MOOseum is composed of "wings" dedicated to different
programming languages: including C++, Lisp, Basic, and Java. Most wings have several
interactive objects, usually code machines and workbenches. A code machine gives an
explanation and trace of a piece of example code. A workbench allows students to
construct a small piece of code and then parses it. However, since it is problematic to
install a full compiler into the MOO, it is assumed the students have access to a compiler
or interpreter for the language they are studying (but see Future Work, below).
Therefore, assignments to be done outside of the MOO are currently required. This is
accomplished by an interaction between several objects including a "lesson dispatcher"
and a "roving goalie" agent.
A short program with assignments
This code machine is named simple, with an alias of s. It
demonstrates a short program with assignments and outputs. Use
help simple
to get help on using code machines.
It would be a good exercise to look at the code in simple and try
to compute manually what values will be left in the variables a, b and
c. Then use the trace feature to determine how close you were.
You see simple here.
Obvious exits: [exit] to Practice with the assignment statement
Figure 1: An Exhibit With a Code Machine
5.1 Code Machines
The code machine contains a piece of programming code, which it will display,
explain, or trace (see Figures 1-4). The code machine may display the code with or
without line numbers. The line numbers are important for the explanation and trace, but
suppressing line numbers allows the students to copy the code from the MOO client and
paste it into an edit window and actually compile the code.
=>show simple
1: #include
2: #include
3: int main () {
4: int a = 3, b = 5,c = -7;
5: a = b+c;
6: b = c + b * a;
...
Figure 2: Displaying Contents of a Code Machine
The explanation of the code works on a line-by-line basis. The numbered line is
displayed with the explanation of just that line. The students then request the next line.
The trace of the code is a simulated execution.
=>explain simple
1: #include
The first include obtains access to the I/O stream objects of cin
and cout as well as the put-to and get-from operators.
...
=>next simple
4: int a = 3, b = 5,c = -7;
Declare and initialize the three integer variables. The
initialization uses literals, rather than computed expressions.
=>n s
5: a = b+c;
Store the sum of b and c into a. Whatever value a had before is
now lost. Thus the initialization of a was not needed.
Figure 3: Receiving the Explanation of a Code Machine
The code machine displays the lines that are executed along with a description of
what is happening at run time, including the new contents of any variables that are
changed. When a student completes either the explanation or trace of a code machine, an
"event" token is recorded, giving the students credit for their actions.
=>trace simple
4: int a = 3, b = 5,c = -7;
The program begins with the initialization of the three
variables.
Variable a receives 3
Variable b receives 5
Variable c receives -7
=>n s
5: a = b+c;
The first assignment computes the value of b + c, which results
in -2, which is assigned to a.
Variable a receives -2
=>n s
6: b = c + b * a;
The precedence of multiplication is higher so the multiply is
done first and yields -10. This is then added to c to give -17.
Variable b receives -17
Figure 4: Tracing the Execution of a Code Machine
Workbenches
A workbench is built around a table driven parser, with enough of the tokens of a
program fragment to allow the students to test whether they have the syntax of a
construct correct. The students build a statement or program fragment from the pieces
that are inserted into the workbench. When complete, the student can ask the workbench
to determine if the fragment is syntactically correct or not. In very simple instances the
workbench may also interpret the code and run the program fragment. Like the code
machine, a successful parse of the code records an event token on the student characters.
The Structure of ProgrammingLand
It will be helpful to consider the structure of the MOO from two different
perspectives: the logical structure and the pedagogical structure. The logical structure is
shared with every other MOO and the pedagogical structure is superimposed on this
logical structure and distinguishes ProgrammingLand from most other MOOs.
The Logical Structure
The logical structure of any MOO is that of a directed graph with nodes, usually
called rooms in a MOO, and arcs, which are called exits. These names for nodes and arcs
are from the dungeons and dragons ancestry of the MOO, but in ProgrammingLand
rooms are more often called exhibits to conform to the museum paradigm.
A room or exhibit is just a MOO object that may contain players or other objects
and various properties. Each MOO object, including rooms, has a name and a
description, both of which are displayed to players when they enter the room. Most of
the subject content of ProgrammingLand is in the descriptions of the exhibits.
When a student enters a room, the server displays the name and description of the
room, plus the names of any objects contained by the room, which may include other
players. Each room has a property that determines whether to display the exits or not.
Usually this property is set to cause the server to display the names of the exits and their
destinations as the last part of the description when a player enters the room. However,
signpost rooms have a menu of possible exits in their descriptions and the exit display is
suppressed as redundant. The server notifies relevant players when someone enters or
leaves an exhibit.
Exits are the directed graph arcs that connect nodes or rooms. An exit has a name
and possibly some aliases, like any other object in a MOO, but the name or alias of an
exit is a command to use the exit to move to another node. In many MOOs the exits are
named spatially, such as up, down, North, East, but in ProgrammingLand they usually
identify topics or menu entries. Sample exhibits are shown in Figure 1, 5, 7, 8, 11, 13,
15, and 17.
In Figure 1, the first line is the name of the room. This is followed by the room
description, which is several lines. The next to the last line shows that there is an object
in this room named simple. The final line indicates that "exit" is the name of an exit that
leads to a room named “Practice with the assignment statement.” Should the student type
“help simple” or “look simple” the server displays help on how the simple object works.
Simple is an instance of a code machine, described above, which is used to show, trace
and explain a small portion of programming language code.
The Three Characteristics of Variables
Gaining a mastery of programming requires that you be able to
declare and use variables. This exhibit looks at the three
characteristics in more depth. Since each one of these takes at least
one exhibit, choose from the following menu:
a) What is a legal variable name?
b) Variable types in C++
c) The idea of a value
or
x) Return to the Variable exhibit
Figure 5: A Signpost Room
Figure 5 is an example of a signpost room. This room displays a menu of exit
choices; its description indicates the exits, so it has no list of obvious exits from the
server. It has no object other than the player in it, so there is no mention of things being
present either.
In the simplest case, students use the MOOseum much like a web page. They
enter a room and view the description and contents of the room. However, if there are
any objects in the room, the students may interact with them in any way the object
allows. If the object is another player then they may have a conversation.
The Pedagogical Structure
Embedded into the room, exit, and object structure of ProgrammingLand are a
number of items that work towards the education of students. The basic unit is called a
lesson. A lesson covers one distinct topic of the material. It does not have to be
exhaustive on the topic but does need to be self-contained. Lessons in ProgrammingLand
are usually hierarchical; that is, a lesson may contain smaller lessons within it. A lesson
may have many of the following parts: a) an introduction that motivates the students or
demonstrates the need for the topic, b) the content material, c) some kind of exercise that
causes the student to use the new knowledge, and d) some type of assessment of the
students grasp of the material. Although there is no attempt at a formal mapping, and
while there are many exceptions, the readers can usefully think of a lesson as akin to a
chapter in an imaginary textbook.
A lesson in ProgrammingLand usually consists of several exhibits as well as
several specialized objects. Typically there is an entryway that is the only way into or
out of the lesson. The entryway is often a signpost/menu room, suggesting an order of
perusing the material; but the student ultimately decides how to take the lesson. A
sample lesson’s rooms and exits are diagrammed in figure 6.
Figure 6: The Exhibits in the Compound Statement Lesson
The Compound Statement exhibit is the entrance to the lesson. It controls access
to the entire lesson. A student entering into the lesson will see the display in figure 7.
The Compound Statement
The compound statement is not a flow of control statement,
however it is used in
most flow of control statements and is essential to the
Structured Programming
model.
In the Structured Programming model there is the notion of a
block. The block in
C++ is the compound statement. It is a wrapper that binds several
statements
into one. It is also the block that greatly affects the scope of
variables.
You may choose any of the following exhibits to consider next.
a) The syntax of the compound statement
b) Scope of variables in compound statement
c) The compound statement and other statements
or
x) Return to the main exhibit on flow of control
Figure 7: The Compound Statement Signpost Room
Goals and Scoring
In order for students to learn from the MOO they will have to visit certain rooms
that have the needed content and interact with certain objects while there. When students
visit an exhibit, that fact is recorded. Likewise, when they complete an exercise with an
interactive object that fact is also recorded. The lesson dispatcher, described below,
checks for these accomplishments.
The Compound Statement room in Figure 7 is a lesson room, which contains the
requirements of the lesson. These requirements are organized as a list of lists. If the
students have satisfied any of the sub-lists then they have satisfied the lesson. The
requirements on any of these sub-lists may be that: a) a certain room has been visited, b)
an object has been exercised, or c) another lesson has been completed. However, the
students must satisfy every requirement of one sub-list to satisfy the lesson and receive
their award.
The Compound Statement exhibit shown in Figure 7 allows for two methods of
satisfying requirements; either 1) the students visit eight specified rooms within the
lesson, or 2) they execute the trace of a code machine found within the lesson’s rooms.
When students leave the Compound Statement exhibit, a lesson dispatcher checks
their completion of the lesson requirements. If the student has satisfied any of them they
are given credit for the lesson. Otherwise they are told some or all of the requirements
they still need to accomplish, depending on how many there are. Next they are given a
choice of either to continue on their way, assuming they will finish the lesson later, or
take a quiz to show their mastery of the material, which is another way to satisfy the
lesson requirements.
The typical lesson has a single entrance and exit. However, that is not the only
shape a lesson may take. A lesson may have several lesson exits that start within the
lesson cluster and end outside the lesson cluster. There are also specialized objects that
check the requirements and possibly transport the students to a quiz room. Moreover,
lessons may be hierarchical in two senses. First, a lesson may contain other lessons.
Second, a lesson may have, as one of its requirements, the completion of another lesson.
For example, if a student has not visited certain required rooms, they may take a quiz
instead. However, if the students have not interacted with a required machine or
completed a prerequisite lesson, then they may not satisfy these types of requirements
with a quiz.
The lesson, lesson-exit, quiz room, lesson dispatcher, and roving goalie work
together to record events that measure student's progress. When students have visited the
important rooms of a lesson, or exercised the machines that exist there, this credit is
recorded. When they have enough credit, students are given an "out of MOO"
programming assignment by a roving goalie, to finalize their learning.
Lesson Dispatcher
Either the lesson-exit or the quiz room may give the student credit for completing
the lesson and also notify the lesson dispatcher object of the students and the event.
Certain lessons are allowed to change the goal of students, which causes the matching
roving goalie to be activated, which tells them about their new goal. There is only one
goalie for each lesson, so if that one is busy with other students, the dispatcher will hold
the request until the goalie returns.
The lesson does not contain any methods that check the students’ progress; this is
done by the lesson-exit via the lesson dispatcher. The lesson-exit has several extra
properties. It has the normal destination that any exit must have, but it also has a quiz
room as an alternate destination, and a property that specifies the lesson to which it
belongs. This lesson does not have to be the room that is the source or destination of the
lesson-exit.
The lesson-exit is a descendent of the generic exit but behaves in a rather different
way. When students choose an exit that will leave the lesson, their progress towards
satisfaction of the requirements is checked. If the students have previously met the
requirements, the exit moves the students to their intended destination with no action out
of the ordinary. If any of the requirements of the lesson have been fully met, then the exit
tells the students that they have completed the lesson and posts a completion of lesson
event token to their event list.
If they have not completed the lesson, they get a different set of messages. The
first sub-list of the lesson requirements list is checked and one or two unmet requirements
are displayed. Students are then asked if they want to continue to their destination and
finish the lesson later, or if they want to prove their mastery with a quiz. If they opt for a
quiz they are transported to a quiz room (described below).
Goalies
A roving goalie is an object with several important properties for the interaction
with the student. Generally, it is intended to give each student a separate, personalized
assignment, usually a programming assignment. This is accomplished by three message
properties. The first is the prefix message. This congratulates the student for completing
the sub_lesson and usually starts to introduce the assignment. The second message is
selected from a list of equivalent assignments. The roving goalie maintains an index that
records the next assignment to be given. When an assignment is given, this index is
circularly incremented. If there are more assignments than students, each student will get
a different assignment. If there are more students, then several may receive the same
assignment. The third message adds whatever concluding information may be
appropriate. Every student receives the same first and third message, but the second
message will vary between students. This message may be quite lengthy, not just a single
sentence. If the students ever want to reread the assignment, the goal and roving goalie
are noted on their character. They have the showgoal command that shows them the
three messages again. Moreover, the roving goalie records the students, which received
each assignment index. Students may only receive one such goal from a particular
sublesson, since the sub_lesson_exit first checks that they do not have the sub_lesson
completion event.
Quiz Rooms
When students elect to take a mastery quiz, they are transported to a quiz room.
A quiz room cannot be reached except by accepting the challenge of a quiz when leaving
a lesson. There is one quiz room attached to each lesson, where the students take a
multiple-choice quiz. If they pass, they are given full credit for the lesson.
The quiz room randomly generates multiple-choice questions, which cover lecture
material the students missed. Attached to each lecture room is a series of quiz questions
on the material covered. Each question consists of three parts: the question, one or more
right answers, and one or more wrong answers. The quiz generator looks at the players
and determines which rooms they did not visit. Then it gathers the questions from these
rooms. It reduces the quiz to five questions. If there are fewer than five questions, it
accesses some general questions from the lesson room to bring it up to five. It then
presents the questions to the students. If they answer incorrectly, the correct answer is
given. If they answer four of the five correctly, they pass the quiz and receive credit for
the lesson. If they miss a second question, the quiz is terminated and they are instructed
to resume the lesson to receive credit. If they attempt a second quiz, they get different
questions. The quiz room is used to verify student mastery of material in the absence of
the usual evidence: completing the goals as assigned. It is also a way for experts to short-
circuit the lesson structure, if they choose. A quiz room has no entrances. The only way
to enter a quiz room is to take the quiz option when using a lesson-exit.
The quiz generator will randomly select one of the right answers and four of the
wrong answers. Therefore it is desirable to form questions that have several right
answers and many wrong answers to prevent students from communicating these
questions to their peers. The randomization of the answers disallows certain types of
multiple-choice answers like both b) and c) and discourages answers like all of these and
none of these. When the students answer, they are given immediate feedback, either that
the answer was correct or of the correct answer. If the students correctly answer a
sufficient number of questions, then a completion event token is recorded for them.
Toys in the Attic
In the spirit of the Exploratorium, the ProgrammingLand MOOseum is populated
with a range of demonstrations, toys, robots, and interactive exhibits. These artifacts are
intended to engage a visitor in the exploration of the content stored in the museum such
that these playful, interactive objects will serve to both entertain and teach.
Demonstration Machines and Checker Machines
Demonstration machines were built for Lisp functions as an in-class project in the
summer of 1998. A class of 50+ students were each assigned a unique Lisp function, and
instructed to create a machine with a “demo” function that would illustrate the operation
of the function. These machines are accessed in rooms made specially for them.
For example, the Lisp “cons function” room, implemented by a student, is
displayed in Figure 8.
The cons Cave
You see a white room with writing on the wall in big red letters.
In the center of the room is a cons machine.
In the far corner is a cons checker machine with six options
hanging on the wall behind it.
To operate the machine just type
plug into cons checker machine
Message on wall:
cons [Function]
(Information is taken from Common Lisp the Language, 2nd Edition
located at the web site www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html)
cons x y
cons is the primitive function to create a new cons cell whose
car is x and whose cdr is y. cons may be thought of as creating a cons,
or as adding a new element to the front of a list.
You see cons machine, cons checker machine,
#2278)(cons 'a '())=>(a ()),
#2270)(cons nil '(b c))=>(nil b c) or (() b c),
#2273)(cons a (b c))=>(a b c),
#2277)(cons '(a b) '(c d))=>(a b c d),
#2258)(cons 'a '(b c))=>(a b c), and
#2267)(cons '(a b) '(c d))=>((a b) c d) here.
Obvious exits: [exit] to List functions, [lists] to List
Manipulation
Figure 8: the Cons Cave
The cons machine is demonstrated in Figure 9.
=>look cons machine
You are looking at a large blue box with a shiny red button. To
see a demonstration type: demo.
=>demo
(cons 'a (cons 'b (cons 'c '())))=>(a b c)
(cons 'a '(b c d))=>(a b c d)
Figure 9: the Cons Machine
The “cons checker machine” is designed to test a students’ application of the
information stored in the cons room and demonstrated by the cons machine. To do this,
the students must choose from the sample executions that are hanging on the wall and
plug the correct ones into the cons checker machine. The cons checker machine looks
and acts as shown in Figure 10 (note that cons options are displayed in Figure 8, above,
and that object numbers are used as shorthand identifiers):
=>look cons checker machine
You see a cons checker machine in the far corner. The options to
check are hanging on the wall around the machine. To test an option
just type plug into cons checker machine.
=>plug #2270 into cons checker machine
Way to go! The cons checker machine has accepted this as a
correct answer.
=>plug #2277 into cons checker machine
According to the cons checker machine this is an incorrect
answer.
The following statement is the correct answer:
(cons '(a b) '(c d))=>((a b) c d)
Figure 10: the Cons Checker Machine
When the students plug a correct value into the machine, a congratulation
message is returned and an “award”is added to the players’ history. When the players
make a mistake, the feedback includes the correct answer.
The Recursive Leprechaun
Since recursion is one of the most difficult concepts for students to master, it is
important to expose the students to recursion as often as possible. One approach is to
implement a recursive leprechaun, which resides in the Realm of Recursion (one of
several exhibits implemented by students). The recursion leprechaun demonstrates a
recursive counting function in a visually descriptive manner:
Realm of Recursion
On the wall you see a poster that reads:
(defunc leprechaun( stuff )
(cond
((nil stuff) nil)
((t leprechaun(cdr (stuff)) + 1)
))
The above function defines the recursive behavior of this
leprechaun.
His syntax is 'count with leprechaun'.
This is still a 'simple' leprechaun so please use the form
( ab cd ef ) or (a b c) for your list; () or ( ) for an empty
list.
This will get him to recursively determine the length of a list.
If you receive an error, you most likely failed to match the form
shown
You see leprechaun here.
Obvious exits: [exit] to The null function
Figure 11: the Realm of Recursion
The Leprechaun gives demonstrations of recursive counting.
=>look leprechaun
You see a small green leprechaun carrying a sack.
He tells you that he is a LISP list length leprechaun, and that
you can see a demonstration of recursion by following the instructions
on the wall.
=>count (a b c) with leprechaun
leprechaun #1 takes a new leprechaun from its sack, keeps one
element from the list, and hands the rest to the new leprechaun asking
him to count it.
leprechaun #2 takes a new leprechaun from its sack, keeps one
element from the list, and hands the rest to the new leprechaun asking
him to count it.
leprechaun #3 takes a new leprechaun from its sack, keeps one
element from the list, and hands the
rest to the new leprechaun asking him to count it.
leprechaun #4 receives an empty list and counts to 0
He shouts "0!" and leaps into the sack from which he came.
leprechaun #3 adds the one item he still has, shouts "1!", eats
the list element, and leaps into the sack from which he came.
leprechaun #2 adds the one item he still has, shouts "2!", eats
the list element, and leaps into the sack from which he came.
The leprechaun scratches his head for a moment and then proudly
tells you that your list contained 3 objects before he destroyed it.
He then pops the remaining element into his mouth, and goes back
about his business, mumbling something about being used.
Figure 12: the Leprechaun Counts
The Ring Toss Game
The Ring Toss game is intended to provide an amusing challenge in the area of
associating programming languages with their historical antecedents.
Game room
Welcome to 'Rings and Pegs Game Room'. Here you can play an
exciting game of rings and pegs.
You see four rings and twelve pegs here. These rings and pegs are
related to each other by some properties. Try to match a ring with a
peg. For that you have to TOSS a RING at the appropriate PEG. If you
get it right, you will be rewarded.
Enjoy!!!!
To play:
toss at
You see lisp_ring, c_ring, smalltalk_ring, fortran_ring,
Dennis_Ritchie_peg, John_McCarthy_peg, Alan_Kay_peg,
Laning_and_Zierler_peg,
System_Programming_peg
Object_Oriented_peg, Scientific_Computing_peg, AI_peg,
Year_1957_peg, Year_1959_peg, Year_1971_peg, and Year_1980_peg here.
Obvious exits: [back] to The remprop function room
Figure 13: the Ring Toss Room
The goal of the ring toss game is to associate languages with people and other
concepts. More than one ring can be tossed on a single peg.
=>toss lisp_ring at John_McCarthy_peg
Your ring is still flying in the air....ooo!!! It has just
touched the right peg...
Yeeeeees!! You got it....You WON
=>toss lisp_ring at Year_1957_peg
Oh! Your ring just MISSED the target by a whisker....
Sorry!!....You lost...try again.
=>toss lisp_ring at Year_1959_peg
Your ring is still flying in the air....ooo!!! It has just
touched the right peg...
Yeeeeees!! You got it....You WON
Figure 14: Playing the Ring Toss Game
The History Jukebox
The History Jukebox is a device for summarizing programming language history
in an entertaining and on-demand fashion.
CS History Jukebox Room
You have entered a grand hall with wonderful furnishings. Lovely
shafts of light pour in through skylights in the ceiling. There is a
delicately painted sign hanging on the wall.
You see History Jukebox here.
Obvious exits: [trig] to Trigonometric Functions Room, [disco] to
Disco Room
=>look History Jukebox
You see a Jukebox. To operate it, type:
'press on '
Note: the material for this jukebox was principally borrowed
from Sebesta (1999).
The History Jukebox's song list contains
1945 Plankalkul 1967 Simula 67
1953 Laning and Zierler System 1968 Algol 68
1957 FORTRAN I 1971 Pascal
1958 Algol 58 1972 C
1959 Lisp 1973 Prolog
1960 COBOL 1990 Smalltalk
1962 APL 1983 Ada
1964 Basic 1985 C++
1965 PL/1 1995 Java
Figure 15: the History Jukebox
The Jukebox plays historical "tunes."
=>press 1959 on History Jukebox
Lisp : Lisp was designed at MIT by John McCarthy. Modeled after
the Lambda Calculus, it was intended to process lists, rather than
arrays, for symbolic computation, rather than numbers. Lisp has only
two native data types: atoms and lists, and program control is via
recursion and conditional statements. It pioneered functional
programming and is still the dominant language for AI, although it has
largely been replaced by Common Lisp and Scheme, the contemporary
dialects (Sebesta, 1996).
Figure 16: Playing the History Jukebox
Tutor Robots
Tutor Robots were implemented to make the function rooms in the LambdaMOO
wing more active and engaging. They are created from a prototype Turing Robot
provided with the EnCore Moo ( Haynes and Hulmevik, 1987), based on the Eliza model
(Weizenbaum, 1966) which was inspired by Turing (1950). The Robots are user
programmable and capable of matching key words and sentence patterns and can be
implemented with random responses and question responses.
isa room
isa [Function]
isa (objects,class)=>true if object is a descendant of
class(or==)
The isa function tells whether or not the object that has been
passed to the function is of the class that has also been passed to the
function
Definition found from on-line lambdaMOO help(help
object_utils:isa
In the isa_code_room there is a code machine. To see it type isa
to get to the room.
You see isa machine and Curly here.
Obvious exits: [foyer] to Object Utilities, [tutor] to Curley's
room, [isa] to isa_code_room
Curly says, Hello. Good to see you.
=>look curly
A huge mass of metal with a deep booming voice.
=> "where am i?
Curly says, "You are in a Virtual museum of programming languages
and you are looking at the isa function."
=> "how do you use the isa function
Curly says, "[example] Ahh, you would like to see a demo of the
isa function. Just type demo isa machine"
Figure 17: a Tutor Robot
demo isa machine
;$object_utils:isa(#3867,#3)=>1
;$object_utils:isa(#3,#3867)=>0
=> "What do the results mean?
Curly says, "[results] 1 means that the object is the parent of
the second object entered, 1 can also mean that the objects are the
same, 0 means that the first object is not the parent of the second
object"
=> "thanks, what should I do now?
Curly says, "You are most welcome..."
=>"WHAT should I do now?
Curly says, "Gosh, I'm not sure I can answer that..."
Figure 18: Tutoring by a Tutor Robot
As the examples show, Tutor Robots can display both remarkable responses and
remarkably obtuse responses.
Future Work
In general, any time the educationally useful interactivity of ProgrammingLand
can be increased, the whole system will be enhanced. There are several specific lines that
should be pursued. The first is the automatic evaluation of the produced student
programs, such as has been done by the Ceilidh system (reference). This would cause the
MOO to be a substantially more effective self-contained education system.
The metaphor that is chosen may hide some of the possibilities that are present.
The museum metaphor is very apt for the introductory learning of material. However, a
museum lacks a very nice feature that a lowly textbook always provides, namely an
index. Students have mentioned that finding a particular topic, once they have studied it
is somewhat tedious. One solution is some type of index that would allow a student
quick access to material that is present. The metaphor of a textbook suggests that an
index may take the reader to material that has never been covered, but there are reasons
to restrict the index to material that this student has already covered. An index of what an
individual has covered is not present in either the textbook or the museum metaphor.
Introductory programming is mainly text based so the MOO as a text only
medium has not been as restrictive as in other areas. However, certain machines, such as
the workbench, are clumsy using just text and could be much easier to use with a
graphical interface. Furthermore, ProgrammingLand is currently a first semester
programming course aid. The emphasis is much more on syntax and semantics than on
techniques. As the content expands to more advanced topics, the use of graphics to
demonstrate these topics will increase. For example, the MOO currently has little content
on sorting, dynamic data structures, or graphical user interfaces. These would be much
easier to handle with graphical displays or graphical machines.
The ProgrammingLand MOO is an interactive learning environment that attempts
to balance content material and immersive exploration. It is more interactive than a
textbook or a lecture, it keeps better records than web instructional pages; it also
productively uses the information that it records.
The ProgrammingLand MOOseum is both a virtual environment and a web
server. Anyone can visit and traverse the geography by pointing their browser to
http://newton.vcsu.nodak.edu:7000/. This method of visiting the MOOseum is not fully
interactive, which requires a login, but nonetheless provides a convenient way for touring
the environment.
Anecdote
I was finishing the spring semester of 1998 and looking forward to a summer of
research, but my departmental chairman needed someone to teach Comparative
Programming Languages in the 4-week summer session. "The pay is bad," he said, "but
the work is hard. What do you say?"
I pondered.
"Before you answer," he said, "Remember it's two hours a day and you need to
cover a semester of material in just 18 days."
"If it benefits the department and the institution," I said, "I'll do it, of course."
I was in a tenure track at the time; what else could I say? It was decided.
A few days later I received a call from our continuing Education office. "There
are students at some other university locations who would like to take your course this
summer. Would you be willing to teach it over IVN?"
"IVN," I said, "what's that?"
"IVN is the interactive video network.”
"You lecture from an instrumented classroom that multicasts the video over fiber
optic cables to other similar classrooms in the state."
I pondered.
"The other locations have cameras and microphones," they continued, "so you can
see the students asking questions."
I considered.
"I'd have to change a lot of things, " I said, " so that it will play well over video. It
would be a lot of extra work."
"Don't worry," they said, "there's no extra money."
"Well then," I said, "of course I'll do it!"
A few days later I received a phone call from the Registrars office.
"We understand you're offering CS372 over IVN in the 4 week summer session."
"That's right," I said.
"There's a problem. IVN rooms are only available an hour and fifty minutes per
day, your course runs 18 days, which is 1,980 minutes. A semester course must have at
least 2,130 minutes of "seat time" in the IVN room according to our accreditation
agreement."
"Really?" I asked.
“You’re 150 minutes short,” they said.
“I see”, I said.
"What do you propose to do about it?"
"Me? You're saying this is MY problem?"
"Exactly."
"I'll have to get back to you."
I pondered. I called them back
“We’ll do four 1-hour online outside-of-class exams,” I said, “Good enough?”
“Yes,” they said, “as long as you do it.”
“I’ll do it,” I said, “of course.”