------------------------------- Page    i -------------------------------

                Learn - Computer-Aided Instruction on UTS




                                                 Brian W. Kernighan

                                                 Michael E. Lesk



                                                 Edited for UTS

------------------------------- Page   ii -------------------------------

                            TABLE OF CONTENTS


Abstract  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   1

1.    Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .   1

2.    Educational Assumptions and Design. . . . . . . . . . . . . . .   2

3.    Scripts.  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6

4.    Experience with Students. . . . . . . . . . . . . . . . . . . .   7

5.    The Script Interpreter. . . . . . . . . . . . . . . . . . . . .   8

6.    Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . .  14

7.    Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .  15

8.    References  . . . . . . . . . . . . . . . . . . . . . . . . . .  16


                                                            Last Page  16

-------------------------------- Page  1 --------------------------------

ABSTRACT

This paper describes the second version  of the learn program for  inter-
preting CAI scripts  on the UTS  operating system, and  a set of  scripts
that provide  a computerized  introduction to  the system.   The  current
scripts cover basic  commands and file  handling, the editor,  additional
file  handling  commands,  and  an  introduction  to  the  C  programming
language.  Many users from a wide variety of backgrounds have  used learn
to acquire basic skills.  Most usage  involves the first two scripts,  an
introduction to UTS files and commands, and the UTS editor.




1.    INTRODUCTION

Learn is a driver  for CAI scripts.   It is intended  to permit the  easy
composition of  lessons and  lesson  fragments to  teach people  computer
skills.  Since it is teaching the same system on which it is implemented,
it makes direct use of UTS facilities to create a controlled UTS environ-
ment.  The system includes two main  parts: (1) a driver that  interprets
the lesson scripts; and  (2) the lesson  scripts themselves.  At  present
there are the following scripts:

  -  basic file handling commands

  -  the UTS text editor ed

  -  advanced file handling

  -  the C programming language

The purported advantage of  CAI scripts for  training in computer  skills
include the following:

 a.  students are forced to perform  the exercises that  are in fact  the
     basis of training in any case;

 b.  students receive immediate feedback and confirmation of progress;

 c.  students may progress at their own rate;

 d.  no schedule requirements are imposed; students may study at any time
     convenient for them;

 e.  the lessons may be  improved individually and  the improvements  are
     immediately available to the new users;

-------------------------------- Page  2 --------------------------------

 f.  since the student has access to a computer for the CAI script  there
     is a place to do exercises;

 g.  the use of high technology  will improve student motivation and  the
     interest of their management.

Opposed to this, of course, is the absence of anyone to whom the  student
may direct  questions.  If  CAI is  used without a  "counselor" or  other
assistance, it should properly be compared to a textbook, lecture series,
or taped course, rather  than to a seminar.   CAI has been used for  many
years in a variety of educational areas.  [1, 2, 3] The use of a computer
to teach itself, however, offers unique advantages.  The skills developed
to get through the script are exactly  those needed to use the  computer;
there is no wasted effort.

The scripts written so far are  based on some familiar assumptions  about
education; these  assumptions  are outlined  in  the next  section.   The
remaining sections describe the  operation of the  script driver and  the
particular scripts now  available.  The driver  puts few restrictions  on
the script writer,  but the  current scripts are  of a  rather rigid  and
stereotyped form in accordance  with the the  theory in the next  section
and practical limitations.




2.    EDUCATIONAL ASSUMPTIONS AND DESIGN.

First, the way to teach people how to do something is to have them do it.
Scripts should  not  contain  long  pieces of  explanation;  they  should
instead frequently  ask the  student to  do some  task.  So  teaching  is
always by example: the typical  script fragment shows a small example  of
some technique and then asks  the user to either  repeat that example  or
produce a variation on it.  All are intended to be  easy enough that most
students will get most questions right, reinforcing the desired behavior.

Most lessons fall into one of three types.  The simplest presents a  les-
son and asks for a yes or no answer to  a question.  The student is given
a chance  to  experiment before  replying.   The script  checks  for  the
correct reply.  Problems of this form are sparingly used.

The second type asks for  a word or number as  an answer.  For example  a
lesson on files might say

     How many files are there in the current directory?  Type "answer N",
     where N is the number of files.

The student is expected to respond (perhaps after experimenting) with

-------------------------------- Page  3 --------------------------------

     answer 17

or whatever.  Surprisingly often,  however, the idea  of a  substitutable
argument (i.e., replacing N by  17) is difficult for non-programmer  stu-
dents, so the first few such lessons need real care.

The third type of lesson  is open-ended--a task is  set for the  student,
appropriate parts of the input  or output are monitored, and the  student
types 'ready' when the task is done.  Figure 1 shows a sample dialog that
illustrates the last of these, using two lessons about the cat (concaten-
ate, i.e., print) command  taken from  early in the  script that  teaches
file handling.  Most learn lessons are of this form.  After  each correct
response the computer congratulates the student and indicates the  lesson
number that has just  been completed, permitting  the student to  restart
the script after that  lesson.  If the  answer is wrong,  the student  is
offered a chance to repeat the lesson.  The "speed" rating of the student
(explained in section 5) is given after the lesson number when the lesson
is completed  successfully; it  is  printed only  for the  aid of  script
authors checking out possible errors in the lessons.

It is assumed that there is no foolproof way to determine if the  student
truly "understands" what  he or  she is doing;  accordingly, the  current
learn scripts only measure performance,  not comprehension.  If the  stu-
dent can perform a given task, that is deemed to be "learning." [4]

The main point of  using the computer  is that what  the student does  is
checked for correctness immediately.   Unlike many CAI scripts,  however,
these scripts provide few facilities for dealing with wrong answers.   In
practice, if most of the  answers are not right the script is a  failure;
the universal  solution to  student error  is to  provide a  new,  easier
script.  Anticipating possible wrong answers is an endless job, and it is
really easier as well as better to provide a simpler script.

Along with this goes the assumption that  anything can be taught to  any-
body if it can  be broken into  sufficiently small pieces.  Anything  not
absorbed in a single chunk is just subdivided.

-------------------------------- Page  4 --------------------------------

        _________________________________________________________
       |                                                        |
       | Figure 1.    Sample dialog from basic files script     |
       |                                                        |
       | (Student responses in italics; '$' is the prompt)      |
       |                                                        |
       | A file can be printed on your terminal                 |
       | by using the "cat" command.  Just say                  |
       | "cat file" where "file" is the file name.              |
       | For example, there is a file named                     |
       | "food" in this directory.  List it                     |
       | by saying "cat food"; then type "ready".               |
       | $ cat food                                             |
       |   this is the file                                     |
       |   named food.                                          |
       | $ ready                                                |
       |                                                        |
       | Good.  Lesson 3.3a (1)                                 |
       |                                                        |
       | Of course, you can print any file with "cat".          |
       | In particular, it is common to first use               |
       | "ls" to find the name of a file and then "cat"         |
       | to print it.  Note the difference between              |
       | "ls", which tells you the name of the file,            |
       | and "cat", which tells you the contents.               |
       | One file in the current directory is named for         |
       | a President.  Print the file, then type "ready".       |
       | $ cat President                                        |
       | cat: can't open President                              |
       | $ ready                                                |
       |                                                        |
       | Sorry, that's not right.  Do you want to try again? yes|
       | Try the problem again.                                 |
       | $ ls                                                   |
       | .ocopy                                                 |
       | X1                                                     |
       | roosevelt                                              |
       | $ cat roosevelt                                        |
       |   this file is named roosevelt                         |
       |   and contains three lines of                          |
       |   text.                                                |
       | $ ready                                                |
       |                                                        |
       | Good.  Lesson 3.3b (0)                                 |
       |                                                        |
       | The "cat" command can also print several files         |
       | at once.  In fact, it is named "cat" as an abbreviation|
       |_for_"concatenate"....__________________________________|

-------------------------------- Page  5 --------------------------------

To avoid boring the faster  students, however, an effort  is made in  the
files and editor scripts to provide three tracks of different difficulty.
The fastest sequence of lessons is aimed at roughly the bulk and speed of
a typical  tutorial manual  and  should be  adequate for  review and  for
well-prepared students.  The next track is intended for most users and is
roughly twice  as long.   Typically, for  example, the  fast track  might
present an idea and ask for a variation on the example shown; the  normal
track will first  ask the student  to repeat the  example that was  shown
before attempting a  variation.  The  third and slowest  track, which  is
often three or four times the length of the fast track, is intended to be
adequate for anyone.  (The lessons of Figure 1 are from the third track.)
The multiple  tracks  also mean  that  a student  repeating a  course  is
unlikely to hit the same series of lessons; this makes it profitable  for
a shaky user to back up and try again, and many students have done so.

The tracks are not completely distinct, however.  Depending on the number
of correct answers the  student has given  for the last few lessons,  the
program may switch tracks.  The  driver is actually capable of  following
an arbitrary directed graph of lesson sequences, as discussed in  section
5.  Some more  structured arrangement,  however, is used  in all  current
scripts to aid the script writer in organizing the material into lessons.
It is sufficiently difficult to write lessons that the three-track theory
is not  followed very  closely except  in the files  and editor  scripts.
Accordingly, in some cases, the fast track is produced merely by skipping
lessons from the slower track.  In others, there is essentially  only one
track.

The main reason for using  the learn program  rather than simply  writing
the same  material as  a workbook  is not  the selection  of tracks,  but
actual hands-on experience.   Learning by  doing is  much more  effective
than pencil and paper exercises.

Learn also provides a mechanical check  on performance.  If a student  is
unable to complete one lesson, that does not prevent access  to the rest.
Learn allows the student  to skip a  lesson that he  cannot pass; a  "no"
answer to the "Do you want to try again?" question  in Figure 1 will pass
to the next lesson.  However, learn will  not tell the student the  right
answer.

Of course, there are valid objections to the assumptions above.  In  par-
ticular, some  students may  object to  not understanding  what they  are
doing; and the  procedure of  smashing everything into  small pieces  may
provoke the retort "you can't cross a ditch in two  jumps." Since writing
CAI scripts is considerably more tedious than ordinary manuals,  however,
it is  safe to  assume  that there  will always  be  alternatives to  the
scripts as a way of learning.  In fact, for a reference manual of 3 or  4
pages it would not  be surprising to have  a tutorial manual of 20  pages
and a (multi-track) script of 100 pages.  Thus the reference manual  will
exist long before the scripts.

-------------------------------- Page  6 --------------------------------

3.    SCRIPTS.

As mentioned above, the present  scripts try at most  to follow a  three-
track theory.  Thus little  of the potential  complexity of the  possible
directed graph is employed, since care must be taken in lesson  construc-
tion to see that every necessary fact is presented in every possible path
through the units.  In  addition, it  is desirable that  every unit  have
alternate successors to deal with student errors.

In most existing courses, the first  few lessons are devoted to  checking
prerequisites.  For  example, before  the student is  allowed to  proceed
through the editor  script the  script verifies that  the student  under-
stands files and is  able to type.   It is felt  that the sooner lack  of
student preparation is detected, the  easier it will  be on the  student.
Anyone proceeding through  the scripts should  be getting mostly  correct
answers; otherwise, the system  will be unsatisfactory  both because  the
wrong habits are being learned and because the scripts make little effort
to deal with wrong answers.  Unprepared students should not be encouraged
to continue with scripts.

There are some preliminary items which  the student must know before  any
scripts can be tried.  In  particular, the student must know how to  con-
nect to a UTS system, set the terminal properly, log in, and execute sim-
ple commands (e.g., learn itself).  In addition, the character erase  and
line kill conventions (# and @) should be known.   It is hard to see  how
this much could be taught by computer-aided instruction, since a  student
who does not know these basic skills will not be able to run the learning
program.  Assistance will thus be needed for the first few minutes.  This
assistance, however, need not be highly skilled.

The first script in  the current set  deals with files.   It assumes  the
basic knowledge above and teaches the student about the ls,  cat, mv, rm,
cp and diff commands.  It also deals with the abbreviation characters  *,
?, and [ ] in  file names.  It does  not cover pipes or I/O  redirection,
nor does it present the many options on the ls command.

This script contains 31 lessons  in the fast track;  two are intended  as
prerequisite checks, seven are review exercises.  There are a total of 75
lessons in all three tracks, and the instructional passages typed at  the
student to begin each lesson total 4,476 words.  The average  lesson thus
begins with a 60-word message.  In  general, the fast track lessons  have
somewhat longer introductions, and the slow tracks somewhat shorter ones.
The longest message is 144 words and the shortest 14.

The second script trains students  in the use of  the UTS context  editor
ed, a sophisticated editor using regular expressions for searching.   [5]
All editor features except encryption,  mark names and ';' in  addressing
are covered.  The fast track contains 2 prerequisite checks, 93  lessons,
and a review lesson.   It is  supplemented by 146  additional lessons  in
other tracks.

-------------------------------- Page  7 --------------------------------

The advanced file handling script  deals with ls options, I/O  diversion,
pipes, and supporting programs like  pr, wc, tail, spell and grep.   (The
basic file handling script is  a prerequisite.) It is  not as refined  as
the first two scripts; this is reflected at least partly in the fact that
it provides much less of  a full three-track sequence  than they do.   On
the other hand, since it is perceived as "advanced," it is hoped that the
student will have somewhat more sophistication and be better able to cope
with it at a reasonably high level of performance.

The script on C is in a state of transition.  It was originally  designed
to follow a tutorial on  C, but that document has since become  obsolete.
The current script has been  partially converted to  follow the order  of
presentation in The C Programming Language, [7] but this job  is not com-
plete.  The C script was never intended to teach C; rather it is supposed
to be a series of exercises for which the computer  provides checking and
(upon success) a suggested solution.

This combination of scripts  covers much  of the material  which any  UTS
user will need to know to make effective use of  the system.  Although we
make no pretense that learn  will replace other instructional  materials,
it should provide a useful supplement to existing tutorials and reference
manuals.




4.    EXPERIENCE WITH STUDENTS.

Most of the usage of learn is on the first two scripts, so these are more
thoroughly debugged and polished.  As  a (random) sample of user  experi-
ence, the learn program  has been used  at Bell Labs  at Indian Hill  for
10,500 lessons in a  four month period.  About  3600 of these are in  the
files script, 4100 in the editor, and 1400 in advanced files.  The  pass-
ing rate is about 80%, that is, about 4 lessons  are passed for every one
failed.  There have been 86 distinct users of the files script, and 58 of
the editor.  At Murray Hill, there have been nearly 2000 lessons over two
weeks that include Christmas and New Year.  Users have ranged in age from
six up.

It is difficult to characterize  typical sessions with the scripts;  many
instances exist of someone doing one or two lessons and then logging out,
as do instances  of someone  pausing in a  script for  twenty minutes  or
more.  In the earlier version of learn, the average session  in the files
course took 32 minutes and covered 23 lessons.  The distribution is quite
broad and skewed, however; the longest session was 130 minutes  and there
were five sessions shorter  than five minutes.   The average lesson  took
about 80 seconds.  These numbers are roughly typical for non-programmers;
an expert can do the scripts at approximately 30 seconds per lesson, most

-------------------------------- Page  8 --------------------------------

of which is the system printing.




5.    THE SCRIPT INTERPRETER.

The learn program itself merely interprets scripts.  It provides  facili-
ties for  the  script  writer  to capture  student  responses  and  their
effects, and simplifies the job of passing control to and recovering con-
trol from the student.  This section describes the operation and usage of
the driver  program, and  indicates what  is required  to produce  a  new
script.  Readers only interested  in the existing  scripts may skip  this
section.

The file structure  used by learn  is shown  in Figure 2.   There is  one
parent directory  (named lib)  containing the script  data.  Within  this
directory are subdirectories, one for each  subject in which a course  is
available, one  for  logging (named  log),  and one  in which  user  sub-
directories are  created (named  play).  The  subject directory  contains
master copies of all lessons, plus any supporting material for  that sub-
ject.  In a given subdirectory, each lesson is a single text file.   Les-
sons are usually named systematically; the file that contains lesson n is
called Ln.

When learn is executed, it makes a private directory for the user to work
in, within the learn portion of the file system.  A fresh copy of all the
files used in each lesson (mostly data  for the student to operate  upon)
is made each  time a student starts  a lesson, so  the script writer  may
assume that everything is  reinitialized each time  a lesson is  entered.
The student  directory  is  deleted  after each  session;  any  permanent
records must be kept elsewhere.   The script writer must provide  certain
basic items in each lesson:

 1.  the text of the lesson;

 2.  the set-up commands to be executed before the user gets control;

 3.  the data, if any, which the user is supposed to edit, transform,  or
     otherwise process;

 4.  the evaluating commands to be  executed after the user has  finished
     the lesson, to decide whether the answer is right; and

 5.  a list of possible successor lessons.

Learn tries to minimize the work of bookkeeping and installation, so that
most of the effort involved in script production is in  planning lessons,

-------------------------------- Page  9 --------------------------------

writing tutorial paragraphs, and coding tests of student performance.


      _____________________________________________________________
     |                                                            |
     |             Figure 2.    Directory structure for learn     |
     |                                                            |
     | lib                                                        |
     |       play                                                 |
     |                         student1                           |
     |                                    files for student1...   |
     |                         student2                           |
     |                                    files for student2...   |
     |       files                                                |
     |                         L0.1a      lessons for files course|
     |                         L0.1b                              |
     |                         ...                                |
     |       editor                                               |
     |                         ...                                |
     |       (other courses)                                      |
     |_______log__________________________________________________|



The basic sequence of  events is  as follows.  First,  learn creates  the
working directory.  Then, for each lesson, learn reads the script for the
lesson and processes it a line at a time.   The lines in the script  are:
(1) commands to the  script interpreter to  print something, to create  a
files, to test something, etc.; (2) text to be printed or put in a  file;
(3) other lines, which are sent to the shell to be executed.  One line in
each lesson turns control over to the user; the user can run any UTS com-
mands.  The user mode terminates  when the user types yes, no, ready,  or
answer.  At  this point,  the user's  work is  tested; if  the lesson  is
passed, a new lesson is selected, and if not the old one is repeated.

Let us illustrate this with the script for the second lesson of Figure 1;
this is shown in Figure 3.

Lines which begin with #  are commands to  the learn script  interpreter.
For example,

     #print

causes printing of any text that follows, up to the next line that begins
with a sharp.

-------------------------------- Page 10 --------------------------------

           __________________________________________________
          |                                                 |
          |      Figure 3.    Sample Lesson                 |
          |                                                 |
          |                                                 |
          | #print                                          |
          | Of course, you can print any file with "cat".   |
          | In particular, it is common to first use        |
          | "ls" to find the name of a file and then "cat"  |
          | to print it.  Note the difference between "ls", |
          | which tells you the name of the files,          |
          | and "cat", which tells you the contents.        |
          | One file in the current directory is named for  |
          | a President.  Print the file, then type "ready".|
          | #create roosevelt                               |
          |   this file is named roosevelt                  |
          |   and contains three lines of                   |
          |   text.                                         |
          | #copyout                                        |
          | #user                                           |
          | #uncopyout                                      |
          | tail -3 .ocopy >X1                              |
          | #cmp X1 roosevelt                               |
          | #log                                            |
          | #next                                           |
          |_3.2b_2__________________________________________|




     #print file

prints the contents of file; it is the same as

     cat file

but has less overhead.  Both forms of #print have the added property that
if a lesson is  failed, the #print will  not be executed the second  time
through; this avoids annoying the student by repeating the preamble to  a
lesson.

     #create filename

creates a file of the specified name,  and copies any subsequent text  up
to a # to the  file.  This is used for creating and initializing  working
files and reference data for the lessons.

     #user

-------------------------------- Page 11 --------------------------------

shell for execution.  The #user mode is terminated when the student types
one of  yes, no,  ready or  answer.   At that  time, the  driver  resumes
interpretation of the script.

     #copyin
     #uncopyin

Anything the student types between these  commands is copied onto a  file
called .copy.   This lets  the  script writer  interrogate the  student's
responses upon regaining control.

     #copyout
     #uncopyout

Between these commands, any material typed at the student by any  program
is copied to the  file .ocopy.  This  lets the script writer  interrogate
the effect of what the student typed, which true believers in the perfor-
mance theory of learning usually prefer to the student's actual input.

     #pipe
     #unpipe

Normally the student input  and the script  commands are fed  to the  UTS
command interpreter (the "shell") one line at a time.  This  won't do if,
for example, a sequence of editor  commands is provided, since the  input
to the editor must  be handed to the  editor, not to the shell.   Accord-
ingly, the material between  #pipe and #unpipe  commands is fed  continu-
ously through a  pipe so that  such sequences work.   If copyout is  also
desired the copyout brackets must include the pipe brackets.

There are  several commands  for  setting status  after the  student  has
attempted the lesson.

     #cmp file1 file2

is an in-line implementation of cmp,  which compares two files for  iden-
tity.

     #match stuff

The last line of the student's input is  compared to stuff, and the  suc-
cess or fail status is  set according to it.  Extraneous things like  the
word answer are stripped  before the  comparison is made.   There may  be
several #match lines; this  provides a convenient mechanism for  handling
multiple "right" answers.  Any text up to a # on subsequent lines after a
successful #match is printed;  this is illustrated  in Figure 4,  another
sample lesson.

-------------------------------- Page 12 --------------------------------

            _________________________________________________
           |                                                |
           |  Figure 4.    Another Sample Lesson            |
           |                                                |
           |                                                |
           | #print                                         |
           | What command will move the current line        |
           | to the end of the file?  Type                  |
           | "answer COMMAND", where COMMAND is the command.|
           | #copyin                                        |
           | #user                                          |
           | #uncopyin                                      |
           | #match m$                                      |
           | #match .m$                                     |
           | "m$" is easier.                                |
           | #log                                           |
           | #next                                          |
           |_63.1d_10_______________________________________|




     #bad stuff

This is similar to #match, except that it corresponds to specific failure
answers; this can be used  to produce hints for particular wrong  answers
that have been anticipated by the script writer.

     #succeed
     #fail

print a message upon success or  failure (as determined by some  previous
mechanism).

When the student types one of the  "commands" yes, no, ready, or  answer,
the driver terminates the #user command, and evaluation of the  student's
work can begin.  This can be done either by the built-in commands  above,
such as #match and  #cmp, or by  status returned by normal UTS  commands,
typically grep and test.  The last command should return status true  (0)
if the task was  done successfully and  false (non-zero) otherwise;  this
status return tells the driver  whether or not  the student has  success-
fully passed the lesson.

Performance can be logged:

     #log file

writes  the   date,  lesson,   user  name   and  speed   rating,  and   a
success/failure indication on file.  The command

-------------------------------- Page 13 --------------------------------

     #log

by itself writes the logging information in the logging directory  within
the learn hierarchy, and is the normal form.

     #next

is followed by  a few lines,  each with  a successor lesson  name and  an
optional speed rating on it.  A typical set might read
     25.1a   10
     25.2a   5
     25.3a   2
indicating that unit 25.1a  is a suitable  follow-on lesson for  students
with a speed rating of 10 units, 25.2a for student with speed near 5, and
25.3a for speed near 2.   Speed ratings are  maintained for each  session
with a student; the rating is increased by one each time the student gets
a lesson right and decreased by four each time the student gets a  lesson
wrong.  Thus the driver tries to maintain a level such that the users get
80% right answers.  The maximum rating is  limited to 10 and the  minimum
to 0.  The  initial rating is  zero unless the  student specifies a  dif-
ferent rating when starting a session.  If the student passes a lesson, a
new lesson is selected and the process repeats.

If the student fails, a false status is returned and the program  reverts
to the previous lesson and tries another alternative.  If it can not find
another alternative, it  skips forward  a lesson.  The  student can  ter-
minate a session at  any point by  typing 'bye', which causes a  graceful
exit from the learn system.  Hanging up is the usual novice's way out.

The lessons may form  an arbitrary directed  graph, although the  present
program imposes a limitation on cycles in that it will not present a les-
son twice in the same session.  If the student is unable to answer one of
the exercises correctly, the driver searches for a previous lesson with a
set of alternatives as successors  (following the #next line).  From  the
previous lesson with alternatives one  route was taken earlier; the  pro-
gram simply tries a different one.

It is perfectly possible to write sophisticated scripts that evaluate the
student's speed  of response,  or  try to  estimate the  elegance of  the
answer, or provide detailed analysis of wrong answers.  Lesson writing is
so tedious already, however, that  most of these abilities are likely  to
go unused.

The driver program depends heavily on features of UTS that are not avail-
able on many other operating systems.  These include the ease  of manipu-
lating files and directories,  file redirection, the  ability to use  the
command interpreter as just another program (even in a pipeline), command
status testing and branching,  the ability to  catch signals like  inter-
rupts, and of course the pipeline mechanism itself.  Although some  parts
of learn might  be transferable  to other systems,  some generality  will

-------------------------------- Page 14 --------------------------------

probably be lost.




6.    CONCLUSIONS

The following observations can  be made about  secretaries, typists,  and
other non-programmers who have used learn:

 a.  A novice must have  assistance with the  mechanics of  communicating
     with the computer to  get through to  the first lesson or two;  once
     the first few lessons are passed people can proceed on their own.

 b.  The terminology used in the  first few lessons  is obscure to  those
     inexperienced with computers.   It would  help if there  were a  low
     level reference card for UTS  to supplement the existing  programmer
     oriented bulky manual.

 c.  The concept  of  "substitutable  argument" is  hard  to  grasp,  and
     requires help.

 d.  They enjoy the system for the most part.  Motivation matters a great
     deal, however.

It takes an hour or  two for a novice to  get through the script on  file
handling.  The  total time  for  a reasonably  intelligent and  motivated
novice to proceed from ignorance  to a reasonable  ability to create  new
files and manipulate old ones  seems to be a few days, with perhaps  half
of each day spent on the machine.

The normal way of proceeding has been to  have students in the same  room
with someone  who knows UTS  and the  scripts.  Thus the  student is  not
brought to a halt by difficult  questions.  The burden on the  counselor,
however, is much lower than that on a teacher of  a course.  Ideally, the
students should  be encouraged  to proceed  with instruction  immediately
prior to  their actual  use of  the computer.  They  should exercise  the
scripts on the same computer and the same kind of terminal that they will
later use for their real work, and their first few  jobs for the computer
should be relatively easy ones.

One disadvantage of training with learn  is that students come to  depend
completely on the CAI system, and do not try to read manuals or use other
learning aids.  This is  unfortunate, not only  because of the  increased
demands for completeness  and accuracy  of the scripts,  but because  the
scripts do not cover all of the UTS system.  New users should have  manu-
als (appropriate for their level) and read them; the scripts  ought to be
altered to recommend suitable documents and urge students to read them.

-------------------------------- Page 15 --------------------------------

There are several other difficulties which are clearly evident.  From the
student's viewpoint, the most serious is that lessons still crop up which
simply can't be passed.  Sometimes this is due to poor explanations,  but
just as often it is  some error in the lesson itself--a botched setup,  a
missing file, an invalid  test for correctness,  or some system  facility
that doesn't  work on  the local system  in the  same way it  did on  the
development system.  It takes knowledge  and a certain healthy  arrogance
on the part of the  user to recognize that the fault is not his or  hers,
but the script writer's.  Permitting the student to get on with the  next
lesson regardless does alleviate  this somewhat, and the logging  facili-
ties make it easy to  watch for lessons that no  one can pass, but it  is
still a problem.

Another potential problem is that it is possible to break learn  inadver-
tently, by pushing interrupt at  the wrong time, or by removing  critical
files, or any number of similar  slips.  The defenses against such  prob-
lems have steadily been improved, to the point where most students should
not notice difficulties.  Of course, it will always be possible to  break
learn maliciously, but this is not likely to be a problem.

One area is more fundamental--some  UTS commands are sufficiently  global
in their effect that learn  currently does not allow them to be  executed
at all.  The most obvious is cd, which changes to another directory.  The
prospect of  a student  who is learning  about directories  inadvertently
moving to some random directory and  removing files has deterred us  from
even writing lessons on cd,  but ultimately lessons on such topics  prob-
ably should be added.




7.    ACKNOWLEDGMENTS

We are grateful to all those who have tried learn, for we have  benefited
greatly from their suggestions and criticisms.  In particular, M. E. Bit-
trich, J. L. Blue, S. I. Feldman, P. A. Fox, and M. J. McAlpin have  pro-
vided substantial feedback.  Conversations with E. Z. Rothkopf also  pro-
vided many of  the ideas  in the  system.  We  are also  indebted to  Don
Jackowski for serving as a guinea pig for the second  version, and to Tom
Plum for his efforts to improve the C script.

-------------------------------- Page 16 --------------------------------

8.    REFERENCES

 [1]  D. L. Bitzer and D. Skaperdas, "The Economics of a Large Scale Com-
      puter Based  Education System:  Plato  IV," pp.  17-29 in  Computer
      Assisted Instruction,  Testing and  Guidance, ed.  Wayne  Holtzman,
      Harper and Row, New York (1970).

 [2]  D. C. Gray, J. P. Hulskamp, J. H. Kumm, S. Lichtenstein, and N.  E.
      Nimmervoll, "COALA--A Minicomputer CAI System," IEEE Trans.  Educa-
      tion E-20(1), pp. 73-77 (Feb. 1977).

 [3]  P. Suppes, "On Using Computers  to Individualize Instruction,"  pp.
      11-24 in The Computer  in American Education,  ed.  D. D.  Bushnell
      and D. W. Allen, John Wiley, New York (1967).

 [4]  B. F. Skinner, "Why We Need Teaching Machines," Harv. Educ.  Review
      31, pp. 377-398,  Reprinted in Educational  Technology, ed.  J.  P.
      DeCecco, Holt, Rinehart & Winston (new York, 1964). (1961).

 [5]  UTS Programmer's Manual, section ed in volume 1.

 [6]  A Tutorial Introduction to the UNIX Text Editor,

 [7]  B. W.  Kernighan and  D. M.  Ritchie, The  C Programming  Language,
      Prentice-Hall, Englewood Cliffs, New Jersey (1978).
